Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?

[Lukas P. (lumapu)]

Holger S. schrieb:
> Ab 6 Inverter startet der Wemos nicht mehr durch.
> In der Console meckert er:
>
> Settings not valid, erasing ...
>
> Ist da irgendwo eine Abfrage programmiert die ab 6 Stück Alarm schreit ?

Habe den Fehler soeben gefunden und gefixt.
Für die es interessiert: Wenn man in Macros addiert und subtrahiert muss 
man sich klar machen, dass alles expandiert wird. Gewollt war z.B. 
(2+2+4+5)-(2+4) es wurde aber 2+2+4+5-2+4 berechnet.
Es waren einfach zwei Klammern um `ADDR_NEXT` und `ADDR_START_SETTINGS` 
nötig, da sonst die Länge des Blocks falsch berechnet wird. Mal wieder 
ein Wunder, dass es überhaupt bisher funktioniert hat.

Hier die betroffene Zeile (existiert ähnlich auch nochmal in 
main.cpp:130)
https://github.com/grindylow/ahoy/blob/0347a3df44d77952524666794c888e6ef4693e45/tools/esp8266/app.cpp#L855

[isnoAhoy (Gast)]

According to `usart_nrf3.h` DEVCONTROL_ALL is defined as `0x51`:

```
#define DEVCONTROL_ALL         0x51
#define ANSWER_DEVCONTROL_ALL     (DEVCONTROL_ALL|0X80)
```

Hence the `UsartNrf3_Send_PackDevControl` method above is actually very 
much the same as the `CONTROL_LOCK_MI__LIMIT_POWER_ONOFF` for the legacy 
Gen 1 or 2 MI-inverters. The answer will be starting with Command `0xC1` 
or `ANSWER_DEVCONTROL_ALL`. This can be used to set various settings in 
HM-inverters e.g. the "sinus" wave `pWaveData = mymalloc(1200 * 
sizeof(uint8_t));` being recorded.

The main routine is in `UsartNrf3_Send_NetCmdToNrfCmd` where all the 
commands and subcommands are defined:

```
/***********************************************
** Function name: ��������ת��Ϊ����Э��nrfָ��
** Descriptions:
** input parameters:    ?
** output parameters:   ?
** Returned value:      ?
*************************************************/
//  Type_ReactivePowerContr = 12,
//  Type_PFSet = 13,
//  Type_CleanState_LockAndAlarm = 20,
void UsartNrf3_Send_NetCmdToNrfCmd(void)
{
    if((CurNetCmd >= NET_TURN_ON) && (CurNetCmd <= NET_RESTART))
    {
        switch(CurNetCmd)
        {
            case NET_INVERTER_HW_INFOR:
            case NET_TERMINAL_INFOR:
                SubCmd = InverterDevInform_All;
                MainCmd = REQ_ARW_DAT_ALL;
                break;

            case NET_TURN_ON:
                SubCmd = Type_TurnOn;//����
                MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
                break;

            case NET_TURN_OFF:
                SubCmd = Type_TurnOff;//�ػ�
                MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
                break;

            case NET_LIMIT_POEWR:
                SubCmd = Type_ActivePowerContr;//���ƹ���
                MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
                break;

            case NET_DOWNLOAD_PRO:
                MainCmd = DOWN_PRO;
                SubCmd = Type_Init;
                break;

            case NET_DOWNLOAD_DAT://���������ļ�
                MainCmd = DOWN_DAT;
                SubCmd = Type_Init;
                break;

            case NET_RESTART: //���س���/��λ
                MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
                SubCmd = Type_Restart;
                break;

            case  NET_UNLOCK:
                SubCmd = Type_Unlock;
                MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
                break;

            case NET_LOCK:
                SubCmd = Type_Lock;
                MainCmd = CONTROL_LOCK_MI__LIMIT_POWER_ONOFF;
                break;

            default:
                break;
        }
    }
    else if(CurNetCmd == NET_INIT)
    {
        SubCmd = RealTimeRunData_Reality;
        MainCmd = REQ_ARW_DAT_ALL;
    }
    else if(CurNetCmd == NET_ALARM_DATA)
    {
        MainCmd = REQ_ARW_DAT_ALL;
        SubCmd = AlarmData;
    }
    else if(CurNetCmd == NET_RECORD_DATA)
    {
        MainCmd = REQ_ARW_DAT_ALL;
        SubCmd = RecordData;
    }
}
```

where the Sub Commands are of `DevControlType`

```
typedef enum
{
    Type_TurnOn = 0, // 0x00
    Type_TurnOff = 1, // 0x01
    Type_Restart = 2, // 0x02
    Type_Lock = 3, // 0x03
    Type_Unlock = 4, // 0x04
    Type_ActivePowerContr = 11, // 0x0B
    Type_ReactivePowerContr = 12, // 0x0C
    Type_PFSet = 13, // 0x0D
    Type_CleanState_LockAndAlarm = 20, // 0x14
    Type_Init = 0xff, // 0xFF
} DevControlType;
```

The AlarmDataType can store up to 50 Alerts as far as I could tell from 
the `UsartNrf3_Process_DevInform_Alarm` method.

BTW: The most recent version of the Gen3 protocol can be found in 
hoymiles-DTU-PRO-GPRS/User/NRF/usart_nrf3.c accompanied by the 
NetProtocol.c and AntiBackflow.c/.h
This implementation is more detailed than the ones under the 0.0.2 and 
0.0.1-20191115 Release directories.

Find attached the latest Test Report that came with the gitee repo. It 
has the following hint on this code line in NetProtocol.c:

> Enter the super password 10165082, you can change the password
```
            else if(Password_old == 10165082)
```

[isnoAhoy (Gast)]

Hallo Lukas,

> Settings not valid, erasing ...
gratuliere ein weiteres Problem behoben!

Da muß man auch erstmal drauf kommen in Zeile 130 und 855 noch 
zusätzliche Klammern zu setzen. Man könnte auch die Summen-Ausdrücke in 
den #Defines bereits in Klammern setzen, dann kann man sich auch in 
Zukunft nicht mehr verrechnen =^}

[Herbert K. (avr-herbi)]

Guten Morgen !
Wollte einfach nur mal ein Danke an die Nachtaktiven da lassen !

[Mel Yoshi (Gast)]

Grüezi mitenand,

es gibt anscheinend noch eine etwas neuere Version von usart_nrf3.c 
(hoymiles-DTU-PRO-APP/User/NRF/usart_nrf3.c) in folgendem repository:

https://gitee.com/iotloves/hoymiles-DTU-PRO.git

[Daniel R. (daniel92)]

Moin zusammen,

bin aktuell noch Unterwegs seit einer Woche. Melde mich wenn ich wieder 
Zuhause bin.

PS: Cool wie Ihr es bisher geschaft habt.

Beste Grüße Daniel :)

[Daniel M. (daniel_m821)]

Mel Yoshi schrieb:
> Grüezi mitenand,
>
> es gibt anscheinend noch eine etwas neuere Version von usart_nrf3.c
> (hoymiles-DTU-PRO-APP/User/NRF/usart_nrf3.c) in folgendem repository:
>
> https://gitee.com/iotloves/hoymiles-DTU-PRO.git

Moin,
wenn ich dort schauen will, bekomme ich die Meldung, dass das Repo für 
unregistrierte Benutzer gesperrt ist.
War das schon länger so oder ist das frisch?

lg :)

[Mel Yoshi (Gast)]

Grüezi Daniel M.,

versuch mal:
git clone https://gitee.com/iotloves/hoymiles-DTU-PRO.git

[Martin P. (mpolak77)]

Ich habe ja meine eigene esp8266 Version zugunsten der esp8266 ahoy 
Version aufgegeben, weil dort das multiple messages handling schon 
funktioniert ... und habe dort das von mir benötigte json format für 
matt dazu gebaut. (wenn ich mal funktioniert, werde ich gerne einen MR 
damit erstellen).

Was mir aber auffällt ist, dass die Werte alle immer wieder Ausreißer (0 
oder mehrere zehntausend) haben ... ich habe versucht das im Code 
abzufangen und nur "gültige" Werte zu publishen, aber das funktioniert 
nur mäßig gut, weil es immer wieder unterschiedliche Werte betrifft.

Ich hatte eigentlich gemeint, dass der CRC das verhindern sollte?
Kann es sein, dass es ein Problem unterschiedlicher threads bzw Kontexte 
ist (also dass ein RX IRQ schon Daten überschreibt, während der MQTT 
Teil noch am versenden ist?

[Ziyat T. (toe_c)]

Mel Yoshi schrieb:
> Grüezi Daniel M.,
>
> versuch mal:
> git clone https://gitee.com/iotloves/hoymiles-DTU-PRO.git

Grüezi wohl Mel Yoshi
Bei mir gehts auch nicht, kannst du das neue usart_nrf3.c hier anhaengen 
bitte? Danke

[Lukas P. (lumapu)]

Nein, der ESP8266 hat nur einen Core und der IRQ setzt nur ein boolean. 
Daher ist hier eine Nebenläufigkeit ausgeschlossen. Zudem wird die 
Payload in einen extra Datenbereich kopiert und erst dann gepublished.

Bei mir läuft die Kommunikation schon immer ohne Ausreißer, die einzigen 
kommen von Wetter, zB. bei gemischter Bewölkung.

Welchen WR hast du? Der einzige, der hier Probleme machen könnte wäre 
der HM600

[Martin P. (mpolak77)]

Lukas P. schrieb:
> Welchen WR hast du? Der einzige, der hier Probleme machen könnte wäre
> der HM600

ich verwende einen HM-700 und einen HM-350 .... ich versuche mal genauer 
mitzuloggen, was da so vorsich geht. Aufgefallen ist es mir ja nur 
meinen Plots im IOBroker

[Lukas P. (lumapu)]

Dann schau doch Mal in deiner History in ioBroker ob da tatsächlich 
falsche Werte drin stehen, oder ob evtl zu selten ein Wert abgelegt 
wird.

Der HM-700 wäre auch betroffen, allerdings kann ich mir das nicht 
vorstellen.

[Holger S. (skusi)]

Hallo,
ich wollte gerade die 0.4.19 ausprobieren.
Geflasht auf Wemos d1 mini, AP verbunden, SSID und Passwort eingetragen, 
Bootloop, Console:

[13:57:41]I: connect to network 'Flackerlighter' ...
[13:57:43]...........
[13:57:53]
[13:57:53] ets Jan  8 2013,rst cause:4, boot mode:(3,6)
[13:57:53]
[13:57:53]wdt reset
[13:57:53]load 0x4010f000, len 3460, room 16
[13:57:53]tail 4
[13:57:53]chksum 0xcc
[13:57:53]load 0x3fff20b8, len 40, room 4
[13:57:53]tail 4
[13:57:53]chksum 0xc9
[13:57:53]csum 0xc9
[13:57:53]v0005af00
[13:57:53]~ld

Jemand einen Tipp ???

[Wo (Gast)]

Liebe Leute, ich habe seit einer Weile den HM700 und bin auf diese 
Diskussion gestoßen. Großartige Arbeit kann ich nur sagen! Ich habe 
nicht die nötige Expertise um hier mitreden zu können, möchte aber 
zumindest mein Feedback geben. Mit diesem Setup hatte ich sofort Erfolg:

.) "DollaTek NRF24L01 + PA + LNA mit Antenne"

.) Raspberry Pi 3B v1.2 (kein Plus)

.) Pi OS 32bit (vom 4.4.2022) mit Raspberry Imager aufgesetzt

.) Build/install RF24 und Anschlußbelegung Raspberry von hier:
https://tutorials-raspberrypi.de/funkkommunikation-zwischen-raspberry-pis-und-arduinos-2-4-ghz/ 
Allerdings mit diesen Paketen für Python3:
  sudo apt-get install python3-dev libboost-python-dev
  sudo apt-get install python3-setuptools
(für Python3 muss man noch die richtige boostlib verlinken, bei mir war 
es:
sudo ln -s /usr/lib/arm-linux-gnueabihf/libboost_python39.so.1.74.0 
/usr/lib/arm-linux-gnueabihf/libboost_python3.so )

.) Python-Software von hier: https://github.com/grindylow/ahoy

.) Im Verzeichnis  ahoy-main/tools/rpi  das ahoy.yml.example als 
ahoy.yml kopiert, mqtt disabled auf true gestellt, Seriennummer dort auf 
mein Gerät angepasst

.) Start mit: sudo python3 -um hoymiles --log-transactions --verbose 
--config ahoy.yml

Der Mikroinverter hat sofort geantwortet, die Leistungsangabe hat mit 
dem angeschlossenen Powermeter auch zusammengepasst - welches ich nun 
nicht mehr wirklich brauche.... Einfach super!

Danke schön für all die Mühen und die tolle Software!

[Günter H. (gnter_h534)]

Holger S. schrieb:
> ich wollte gerade die 0.4.19 ausprobieren.
> Geflasht auf Wemos d1 mini, AP verbunden, SSID und Passwort eingetragen,
> Bootloop, Console:

Ich habe bei meinem Wemos D1 mini mit 0.4.19 einen "Factory Reset" 
gemacht, meldet sich als AP unter 192.168.1.1, beim ersten Mal bewusst 
falsches Passwort für mein WLAN eingegeben, AP bleibt aktiv, mit 
richtigem Passwort Verbindung zum WLAN (s. angehängte Log-Datei).

Frage der Vollständigkeit halber: Ist dein Router so konfiguriert, dass 
neue Netzwerkgeräte zugelassen werden?

[Mel Yoshi (Gast)]

Grüezi Ziyat T.,

ich bin mir nicht sicher ob es eine gute Idee wäre, die Datei hier 
einfach anzuhängen (Thema Copyright). Außerdem sind die einzelnen 
Revisionen möglicherweise auch nicht ganz uninteressant.

[Mel Yoshi (Gast)]

Vielleicht geht bei euch dieses Repository (mit gleicher Revision)?:

git clone https://gitee.com/andycao1860/hoymiles-DTU-PRO.git

[Herbert K. (avr-herbi)]

keine Probleme beim Download  :-)
allerdings hatte ich mich angemeldet beim 1. gitee Link
Datum der Dateien in obigem (also 3. Link) ist 13.07.2020 09:38
Ist der gleiche Zeitstempel wie beim 2. Link so wie ich das sehe.

[Holger S. (skusi)]

Günter H. schrieb:
> Frage der Vollständigkeit halber: Ist dein Router so konfiguriert, dass
> neue Netzwerkgeräte zugelassen werden?

Ja, ist er. Mit den anderen Revisionen hat es ja funktioniert.

[Damian B. (damian_b)]

Hilfe
Meine DTU-Konfiguration auf ESP funktioniert nach der Programmierung 
maximal 10 Minuten und reagiert nicht auf Ping, sie kehrt nach einiger 
Zeit zurück und dies ist kein Problem für mein Netzwerk.

Ist MQTT für den ordnungsgemäßen Betrieb erforderlich?
ist eine spezielle Konfiguration erforderlich?

Momentan habe ich die Version 4.19 und nach dem Einrichten des Setups 
und der Eingabe von Visualisiert stirbt es ...

[isnoAhoy (Gast)]

Hallo Holger S.,
er kann Deinen Router nicht erreichen, deshalb (oder trotzdem) macht er 
den Access Point auf. Das hat er auch früher schon so gemacht. Nach 60 
Sekudnen sollte er eigentlich nochmal den Router versuchen.
Dabei scheint er sich aber irgendwie zu verrechnen, er kommt nämlich von 
42 Sekunden wieder auf 60 Sekunden ohne die WiFi Verbindung zu 
probieren!

I: connect to network 'HWW-WLAN-2-5G1581' ...
...............................
........................................................................ 
............................
I:
---------
AP MODE
SSID: AHOY-DTU
PWD: esp_8266
Active for: 60 seconds
---------

I: AP will be closed in 42 seconds
I: 1 clients connected, resetting AP timeout
I: AP will be closed in 60 seconds
I: 1 clients connected, resetting AP timeout
I: AP will be closed in 60 seconds
I: Serial debug is I: off

[isnoAhoy (Gast)]

Hallo Daniel M & Ziyat T.,

> Moin,
> wenn ich dort schauen will, bekomme ich die Meldung, dass das Repo für
> unregistrierte Benutzer gesperrt ist.
> War das schon länger so oder ist das frisch?

Ihr müsst Euch zwingend einen Account bei gitee.com erstellen, das war 
auch schon beim ersten Repolink dorthin so. Sonst kann man auf gitee.com 
m.E. nichts runterladen.

@Mel Yoshi, wie findest Du denn die anderen Repos von Hoymiles. Bei mir 
ergibt die Suche z.B. nach "usart_nrf3.c" auf gitee.com keinen einzigen 
Treffer ?

[Stefan T. (isnoahoy)]

Herbert K. schrieb:
> keine Probleme beim Download  :-)
> allerdings hatte ich mich angemeldet beim 1. gitee Link
> Datum der Dateien in obigem (also 3. Link) ist 13.07.2020 09:38
> Ist der gleiche Zeitstempel wie beim 2. Link so wie ich das sehe.

Habe es mal ausgepackt und verglichen mit diff/meld und kann auch keine 
Unterschiede feststellen.
Es gibt in 
hoymiles-DTU-PRO-master-iotloves/hoymiles-DTU-PRO-APP/User/NRF/
neben den bekannten usart_nrf3.c/.h auch eine usart_nrfConfig.h und in 
der usart_nrf3.c stehen einige Kommentare:

//dong 2020-0515
//dong 2020-06-17

Ich habe noch nicht ganz verstanden was der Unterschied zwischen 
hoymiles-DTU-PRO-APP und hoymiles-DTU-PRO-GPRS ist. Mal sehen ob das die 
ModBus RS485 Anbindung oder etwas anderes ist ?

[Stefan T. (isnoahoy)]

@Ziyat T. & Daniel M.,

es gibt in dem neuen gitee Repo(s) (iotloves === andycao1860) zwei neue 
Dateien namens SunSpec.c/.h die einiges an Implementierung zu MI-XXX 
Wechselrichtern enthalten.

[Mel Yoshi (Gast)]

Grüezi mitenand,

"hoymiles-DTU-PRO-GPRS" wurde in Commit bfb4da7 einfach in 
"hoymiles-DTU-PRO-APP" umbenannt. Das Ganze ist aber etwas neuer und 
könnte deshalb vielleicht mehr Infos zur HM-Serie enthalten. Deshalb 
meinte ich, dass es vielleicht interessant wäre auch die Commit-History 
mal anzuschauen (also am besten nicht nur das Archiv von gitee.com 
herunterladen sondern mit das gesamte Repository mit "git clone" 
klonen). Die Repositories iotloves und andycao1860 haben den selben 
Stand.

@isnoAhoy: Ich habe einfach mit Google gesucht:
https://www.google.de/search?q=site:gitee.com+hoymiles

[Holger S. (skusi)]

Günter H. schrieb:
> Holger S. schrieb:
>> ich wollte gerade die 0.4.19 ausprobieren.
>> Geflasht auf Wemos d1 mini, AP verbunden, SSID und Passwort eingetragen,
>> Bootloop, Console:
>
> Ich habe bei meinem Wemos D1 mini mit 0.4.19 einen "Factory Reset"
> gemacht, meldet sich als AP unter 192.168.1.1, beim ersten Mal bewusst
> falsches Passwort für mein WLAN eingegeben, AP bleibt aktiv, mit
> richtigem Passwort Verbindung zum WLAN (s. angehängte Log-Datei).
>
> Frage der Vollständigkeit halber: Ist dein Router so konfiguriert, dass
> neue Netzwerkgeräte zugelassen werden?

Also ich hab es heute nochmal in Ruhe von vorne angefangen:
Ich glaube ich habe bei meinen gestrigen Versuchen falsche Pins in 
Pinout angegeben. Statt CS -> D8 hab ich wohl GPIO8 ausgewählt. Kann das 
sein das es dann in einen Bootloop geht ?
Dann hängt er auch in dieser Schleife, versucht immer mein WLan zu 
erreichen, schafft aber kein connect, öffnet aber auch keinen AP. Dann 
bleibt nur noch neu flashen !?

Nun funktioniert die 0.4.19 aber endlich super !
Ich habe zur Zeit 3 Inverter HM-300 dran und trotz Testaufbau und 
Blechdach und Amplifier Power Level auf Min recht gute Statistic Werte:

Uptime: 0 Tage, 00:10:01

Time: 2022-06-18 11:10:36

Statistics:

Receive success: 120
Receive fail: 3
Frames received: 387
Send Cnt: 169

Inverter 'West' is available and is producing
Inverter 'Sued_1' is available and is producing
Inverter 'Sued_2' is available and is producing
MQTT: connected

Mit der anderen version hatte ich bedeutend mehr fails.

Klasse Arbeit. Ich bin begeistert.
Übrigens, damit ich auch mal was beisteuern kann wenn ich schon keine 
Ahnung von Programmieren hab, arbeite ich gerade an einer Platine die 
auf kompakte Weise den Wemos, RF24 und ein Netzteil verbindet. Das 
Endprodukt soll dann eine kleine Box werden die man per Netzstecker 
direkt in eine Steckdose betreiben kann. Ich bin kein Freund dieser 
ganzen USB Netzteile.

Wenn dann Interesse besteht werde ich entsprechende Stückzahlen fertigen 
lassen. Ich halte Euch auf dem laufenden. Bin noch am Layouten...

[Maik R. (bastelbarney)]

Heinz R. schrieb:
> IsnoAhoy schrieb:
>> 2. Grid Power Profile
>
> Damit ist wohl die Einstellung des CosPhi gemeint

Bisschen spät, aber da mir gestern das entspr. PDF in die Finger fiel 
... ich denke, der CosPhi wird in meiner Branche auf Englisch 
üblicherweise als "Power Factor" bezeichnet.
"Grid Power Profile" könnte sich daher mMn eher auf "Grid Type" aus dem 
Handbuch

https://www.hoymiles.com/wp-content/uploads/2021/11/Technical-Note_Hoymiles-Export-Management_Global_EN_V1.1.pdf

Seiten 3 und 4 beziehen. Lässt sich aber leider nicht durch

https://www.shinetech-power.de/wp-content/uploads/2021/07/Technical-Note-Modbus-implementation-using-3Gen-DTU-Pro-V1.2.pdf

untermauern. Aber auch nicht widerlegen ;-)

[MaXx (Gast)]

Stefan T. schrieb:
> Ich habe noch nicht ganz verstanden was der Unterschied zwischen
> hoymiles-DTU-PRO-APP und hoymiles-DTU-PRO-GPRS ist. Mal sehen ob das die
> ModBus RS485 Anbindung oder etwas anderes ist ?

Den DTU-Pro von Hoymiles gibt es in einer WLAN- und einer GPRS-Version:
https://www.alpha-solar.info/images/datenbl%C3%A4tter/Hoymiles/User-Manual_DTU-Pro-DE_V202103.pdf 
(Seite 5)

Grüazi, MaXx

[Günter H. (gnter_h534)]

Holger S. schrieb:
> Nun funktioniert die 0.4.19 aber endlich super !

Das freut mich zu hören.

> Das
> Endprodukt soll dann eine kleine Box werden die man per Netzstecker
> direkt in eine Steckdose betreiben kann. Ich bin kein Freund dieser
> ganzen USB Netzteile.

Das halte ich für eine gute Idee. Ich bin auf das Ergebnis gespannt.

[Daniel M. (daniel_m821)]

Ich habe jetzt etwas rumgebaut und komme einfach nicht weiter.

Die Requests werden korrekt abgesetzt, allerdings renne ich entweder in 
den Fehler "Frame 1 missing" oder "last frame missing"

12:01:10.197 -> I: Inverter #0 I: no Payload received! (retransmits: 5)
12:01:10.197 -> I: Requesting Inverter SN 114163500316
12:01:10.197 -> I: Transmit 11 | 09 63 50 03 16 78 56 34 12 00 27 
12:01:10.251 -> E: while retrieving data: last frame missing: Request Retransmit
12:01:10.251 -> I: Transmit 11 | 09 63 50 03 16 78 56 34 12 00 27 
12:01:10.298 -> 89 63 50 03 16 63 50 03 16 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE 
12:01:10.551 -> E: while retrieving data: last frame missing: Request Retransmit
12:01:10.551 -> I: Transmit 11 | 09 63 50 03 16 78 56 34 12 00 27 
12:01:10.651 -> 89 63 50 03 16 63 50 03 16 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE 
12:01:10.651 -> 89 63 50 03 16 63 50 03 16 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE 
12:01:10.698 -> 89 63 50 03 16 63 50 03 16 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE 
12:01:10.898 -> E: while retrieving data: last frame missing: Request Retransmit

Die app.cpp ab Zeile 224 original:

                if(0 != len) {
                    Inverter<> *iv = mSys->findInverter(&p->packet[1]);
                    if(NULL != iv) {
                        uint8_t *pid = &p->packet[9];
                        if((*pid & 0x7F) < 5) {
                            memcpy(mPayload[iv->id].data[(*pid & 0x7F) - 1], &p->packet[10], len-11);
                            mPayload[iv->id].len[(*pid & 0x7F) - 1] = len-11;
                        }

                        if((*pid & 0x80) == 0x80) {
                            if((*pid & 0x7f) > mPayload[iv->id].maxPackId) {
                                mPayload[iv->id].maxPackId = (*pid & 0x7f);
                                if(*pid > 0x81)
                                    mLastPacketId = *pid;
                            }
                        }

mit meiner Version:

                if(0 != len) {
                    Inverter<> *iv = mSys->findInverter(&p->packet[0]);
                    if(NULL != iv) {
                        uint8_t *pid = &p->packet[0]; //9
                        if((*pid & 0x88) < 5) { // (*pid & 0x7F)
                            memcpy(mPayload[iv->id].data[(*pid & 0x88) - 1], &p->packet[9], len-12); // (*pid & 0x7F)
                            mPayload[iv->id].len[(*pid & 0x88) - 1] = len-12; // (*pid & 0x7F)
                        }
                        if((*pid & 0x89) < 5) { // (*pid & 0x7F)
                            memcpy(mPayload[iv->id].data[(*pid & 0x89) - 1], &p->packet[9], len-12); // (*pid & 0x7F)
                            mPayload[iv->id].len[(*pid & 0x89) - 1] = len-12; // (*pid & 0x7F)
                        }
                        if((*pid & 0x91) < 5) { // (*pid & 0x7F)
                            memcpy(mPayload[iv->id].data[(*pid & 0x91) - 1], &p->packet[9], len-12); // (*pid & 0x7F)
                            mPayload[iv->id].len[(*pid & 0x91) - 1] = len-12; // (*pid & 0x7F)
                        }
                        if((*pid & 0x92) < 5) { // (*pid & 0x7F)
                            memcpy(mPayload[iv->id].data[(*pid & 0x92) - 1], &p->packet[9], len-12); // (*pid & 0x7F)
                            mPayload[iv->id].len[(*pid & 0x92) - 1] = len-12; // (*pid & 0x7F)
                        }

                        //if((*pid & 0x80) == 0x80) {
                        if( ((*pid & 0x88) == 0x88) || ((*pid & 0x89) == 0x89) || ((*pid & 0x91) == 0x91) || ((*pid & 0x92) == 0x92) ) {
                            if((*pid & 0x88) > mPayload[iv->id].maxPackId) { // (*pid & 0x7F)
                                mPayload[iv->id].maxPackId = (*pid & 0x7F); // (*pid & 0x7F)
                            }
                            if((*pid & 0x89) > mPayload[iv->id].maxPackId) { // (*pid & 0x7F)
                                mPayload[iv->id].maxPackId = (*pid & 0x7F); // (*pid & 0x7F)
                            }
                            if((*pid & 0x91) > mPayload[iv->id].maxPackId) { // (*pid & 0x7F)
                                mPayload[iv->id].maxPackId = (*pid & 0x7F); // (*pid & 0x7F)
                            }
                            if((*pid & 0x92) > mPayload[iv->id].maxPackId) { // (*pid & 0x7F)
                                mPayload[iv->id].maxPackId = (*pid & 0x7F); // (*pid & 0x7F)
                                                   
                                if(*pid > 0x92) // (*pid & 0x81)
                                    mLastPacketId = *pid;
                            }
                        }

Bei len-11 ist Frame 1 missing, len-12 bringt last frame missing.

Den Reqest habe ich so gestaltet:

                    if(mSerialDebug)
                        DPRINTLN(DBG_INFO, F("Requesting Inverter SN ") + String(iv->serial.u64, HEX));
                    //mSys->Radio.sendTimePacket(iv->radioId.u64, mPayload[iv->id].ts);
                    // for MI-Series or TSUN
                    static uint8_t tel = 0;
                    if (tel = 2)
                      tel = 0;
                                        
                    if (tel == 0) {
                      //mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x09, mLastPacketId, true);
                      mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x09, 0x00, true);
                      }
                      else if (tel == 1) {
                        //mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x11, mLastPacketId, true);
                        mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x11, 0x00, true);
                      }
                      else if (tel == 2) {
                        //mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x11, mLastPacketId, true);
                        mSys->Radio.sendCmdPacket(iv->radioId.u64, 0x10, 0x00, true);
                      }     
                      tel++;                    
                    mRxTicker = 0;

Direkt danach folgt der Fehler:

else if(mSerialDebug)
                DPRINTLN(DBG_WARN, F("time not set, can't request inverter!"));
            yield();

für die Position, wo ich das geändert habe.

Das repo aus China konnte ich clonen und wühle mich da gerade durch. von 
dort habe ich auch den CMD 0x10, für Debug- und Verständniszwecke mal 
mit eingebaut. Gesehen habe ich die Antwort darauf auch schon, nur noch 
keine Idee, was ich mit den Werten am Ende mache (aktuell auch 
irrelevant).

Was die Payload-länge, maxPackID usw. angeht, habe ich keine Ahnung, was 
ich da tue und wie es richtig geht. Habe einiges durchprobiert, mangels 
Verständnis und Wissen scheitere ich an diesem Punkt.

&p->packet[0] findet auf jeden Fall die Antwort-ID, &p->packet[9] zeigt 
auf den Punkt, ab wann Nutzdaten kommen, die Länge der Nutzdaten ist 12 
(6 Werte).
Habe ich einen Denkfehler bei "len-12" das hier nicht die Gesamtlänge 
gefragt ist sondern eine Position in der Payload verschoben wird?

Ich würde den Knoten im Kopf gerne lösen.

edit: typo

[Thomas B. (tbnobody)]

Martin P. schrieb:
> Ich habe ja meine eigene esp8266 Version zugunsten der esp8266 ahoy
> Version aufgegeben, weil dort das multiple messages handling schon
> funktioniert ... und habe dort das von mir benötigte json format für
> matt dazu gebaut. (wenn ich mal funktioniert, werde ich gerne einen MR
> damit erstellen).

Hallo Martin,
nur so aus eigenem Interesse, was ist denn matt?

[Ziyat T. (toe_c)]

@isnoAhoy
Also ich bin schon alt aber...;-)
Sicher habe einen gitee Account! Ich hab ja schon mal das 1. Repo 
runtergeladen, seit dem geht es nicht mehr und ich wollte mich nicht 
wieder neu registrieren.


@Mel Yoshi
Nach dem hier die Uebersetzungen v. div. files schon veröffentlicht 
wurden, ist eine Diskussion über das Thema Copyright für mich nicht mehr 
aktuell, aber jeder soll so handhaben, wie es ihm richtig scheint...

@Stefan T.
Das ist sicher die Implementierung das Sunspec Protokolls des MI-WR, das 
kann man auch im Modbus-HB lesen.

@Maik R., @isnoAhoy
Das Grid Profile enthaltet mehr Daten als nur den Power Factor, im 
Anhang ist mein Grid Profile für meinen Standort.


Und weitere Nachrichten aus MI-1500 Front:

Nach dem ich mit dem MI-1500 erfolglos war, habe noch einen Sniffer auf 
arduino/nrf24 basis neben dem esp8266/nrf24 (aeltere Vers.) gestellt, 
und sah in den Sniffer-Daten die Antworten vom WR ab und zu kommen, 
immer auf die Anfragen auf CH 75!!

Die esp8266/nrf24-SW erkennt die Antworten nicht, weil das CRC nicht 
stimmt, guckst du:

ab hier geht es nicht mehr weiter:
  if(mHoymiles->checkCrc(p->packet, &len, &rptCnt))

Ich habe vor dem if diese Zeile eingefügt:
  mHoymiles->dumpBuf("RAW ", p->packet, PACKET_BUFFER_SIZE);
So sehe ich ab und zu die Antworten auch im esp8266.

hmmmmm...???

[Martin P. (mpolak77)]

Thomas B. schrieb:
> Martin P. schrieb:
>
>> Ich habe ja meine eigene esp8266 Version zugunsten der esp8266 ahoy
>> Version aufgegeben, weil dort das multiple messages handling schon
>> funktioniert ... und habe dort das von mir benötigte json format für
>> matt dazu gebaut. (wenn ich mal funktioniert, werde ich gerne einen MR
>> damit erstellen).
>
> Hallo Martin,
> nur so aus eigenem Interesse, was ist denn matt?

Das ist Mqtt mit Autokorrektur ;-)

[Peter L. (leliep)]

Holger S. schrieb:
….
>
> Klasse Arbeit. Ich bin begeistert.
> Übrigens, damit ich auch mal was beisteuern kann wenn ich schon keine
> Ahnung von Programmieren hab, arbeite ich gerade an einer Platine die
> auf kompakte Weise den Wemos, RF24 und ein Netzteil verbindet. Das
> Endprodukt soll dann eine kleine Box werden die man per Netzstecker
> direkt in eine Steckdose betreiben kann. Ich bin kein Freund dieser
> ganzen USB Netzteile.
>
> Wenn dann Interesse besteht werde ich entsprechende Stückzahlen fertigen
> lassen. Ich halte Euch auf dem laufenden. Bin noch am Layouten...

Gute Idee, ich hab da mal was probiert, siehe Fotos.

[Carsten B. (carstenb)]

Carsten B. schrieb:

> Da ich derzeit keinen ESP8266 da habe, habe ich versucht es auf einem
> ESP32 ans laufen zu bekommen. Bin aber daran gescheitert, die o.g.
> Software anzupassen, da einige Libraries für den ESP32 anscheinend nicht
> kompatibel sind.
>
> Hat jemand eine lauffähige Version für ESP32?

Das Thema ESP32 habe ich erst mal aufgegeben und benutze einen ESP8266. 
Die Ahoy-Software läuft darauf einwandfrei, allerdings musste ich in 
"defines.h" folgendes anpassen:

#define PWD_LEN             64

da mein WLAN-Schlüssel die volle Länge nutzt.

Mit der Änderung funktioniert es bei mir.

LG

Carsten

[Heinz R. (heijz)]

sorry wenn OT - gibt es in Euren chinesischen Quellen auch was für die 
HMS-Serie von Hoymiles?
Die HMS-Serie ist die neueste Serie - nutzt wieder 2,4 GHz, aber denke 
mal das hier nicht das Rad komplett neu erfunden wurde , das ähnlich dem 
HM-Protokoll ist?

Viele Grüße

[Daniel M. (daniel_m821)]

Heinz R. schrieb:
> sorry wenn OT - gibt es in Euren chinesischen Quellen auch was für die
> HMS-Serie von Hoymiles?
> Die HMS-Serie ist die neueste Serie - nutzt wieder 2,4 GHz, aber denke
> mal das hier nicht das Rad komplett neu erfunden wurde , das ähnlich dem
> HM-Protokoll ist?
>
> Viele Grüße

Hallo Heinz,

bei der Durchsicht der NRF-Dinge ist mir der HMS nicht begegnet. Die 
Daten sind von 2020, also nicht super aktuell.

Kannst du was genaueres sagen, welche DTU/DTU-Pro dafür passt?

Edit:
Was mir noch eingefallen ist: welche Seriennummer hat dein HMS und 
wieviele PV-Anschlüsse/MPPT Tracker?

[oxylog (Gast)]

Daniel M. schrieb:
> welche DTU/DTU-Pro dafür passt?


Gestern hatte ich das aus interesse nachgeschaut:
https://www.shinetech-power.de/wechselrichter/hoymiles/
"Die Überwachung für HMS Serie ist der DTU Lite S / Pro S, die für 
HM-Serie gebaute DTU Lite/Wlite/Pro funktioniert nicht mit HMS."
Hier gibt es die Anleitung dazu
https://manuals.plus/m/1ecf6e51138bca7f81443c62f0c1d440fcbbbf26c16146d949870e807c943955_optim.pdf

Hier ist das passende Datenblatt zu finden
https://www.mini-nrg.de/download

Heinz R. schrieb:
> Die HMS-Serie ist die neueste Serie - nutzt wieder 2,4 GHz, aber denke
> mal das hier nicht das Rad komplett neu erfunden wurde , das ähnlich dem
> HM-Protokoll ist?

In den Spezifikationen ist "Sub-1G" unter Kommunikation angegeben.

Inn der Bedienungsanleitung ist folgendes zu finden:
https://www.hoymiles.com/wp-content/uploads/2021/11/User-manual_HMS-160018002000-4T-NA_EN_V202201.pdf
"Range of Sub-1GHz wireless: Unlike Wi-Fi or Zigbee which both operate 
on the 2.4 GHz band, Sub-1GHz op-
erates on the 868 MHz or the 915 MHz band. Generally speaking, Sub-1GHz 
wireless transmission covers 1.5
to 2 times longer distance than the 2.4GHz spectrum"

Hierzu ist eventuell diese Dokumentation über das Sendemodul (?) 
interessant:
https://manuals.plus/m/a345e161e8ceba2155593aaeefcb3e2f3de7dfe1e13fe1e4dc9d421e50725131_optim.pdf

Aus einer Hoymiles-Präsentation habe ich noch ein Slide angehängt über 
HMS/HMT (Über das Protokoll heißt es hier nur "Proprietary"). Vielleicht 
hilft es euch etwas.

[Carsten B. (carstenb)]

Holger S. schrieb:
>
> Kann man vermeiden das der Wemos sich bei jedem reboot mit einer Anderen
> Kennung per MQTT verbindet. Ich übermittele die Werte per MQTT zu meinem
> Fhem System, und da ist es sehr unschön nach jedem Reboot per autocreate
> ein neues Gerät zu bekommen. Ich muß dann alle Verknüpfungen neu setzten
> und den Namen ändern.
> Jetzt hat er sich zum Besipiel mit ESP_c6a2 angelegt.

Hallo Holger,

ich betreibe es auch auf dem ESP8266 und übermittle via MQTT an mein 
FHEM seit gestern. Hast du bezüglich der wechselnden ID schon eine 
Lösung gefunden?

Carsten

[Holger S. (skusi)]

Carsten B. schrieb:
> Holger S. schrieb:
>>
>> Kann man vermeiden das der Wemos sich bei jedem reboot mit einer Anderen
>> Kennung per MQTT verbindet. Ich übermittele die Werte per MQTT zu meinem
>> Fhem System, und da ist es sehr unschön nach jedem Reboot per autocreate
>> ein neues Gerät zu bekommen. Ich muß dann alle Verknüpfungen neu setzten
>> und den Namen ändern.
>> Jetzt hat er sich zum Besipiel mit ESP_c6a2 angelegt.
>
> Hallo Holger,
>
> ich betreibe es auch auf dem ESP8266 und übermittle via MQTT an mein
> FHEM seit gestern. Hast du bezüglich der wechselnden ID schon eine
> Lösung gefunden?
>
> Carsten

Hallo Carsten,

wenn Du die aktuelle Version 0.4.19 verwendest ist die ID immer 
"AHOY_DTU"! Ich hatte das zwischenzeitlich auch schon geändert, aber nun 
wurde es wohl so eingepflegt.

Gruß Skusi

[Holger S. (skusi)]

Peter L. schrieb:
> Holger S. schrieb:
> ….
>>
>> Klasse Arbeit. Ich bin begeistert.
>> Übrigens, damit ich auch mal was beisteuern kann wenn ich schon keine
>> Ahnung von Programmieren hab, arbeite ich gerade an einer Platine die
>> auf kompakte Weise den Wemos, RF24 und ein Netzteil verbindet. Das
>> Endprodukt soll dann eine kleine Box werden die man per Netzstecker
>> direkt in eine Steckdose betreiben kann. Ich bin kein Freund dieser
>> ganzen USB Netzteile.
>>
>> Wenn dann Interesse besteht werde ich entsprechende Stückzahlen fertigen
>> lassen. Ich halte Euch auf dem laufenden. Bin noch am Layouten...
>
> Gute Idee, ich hab da mal was probiert, siehe Fotos.

WOW !!! So kompakt hatte ich eigentlich nicht vor. Das Gehäuse ist 
sicherlich gedruckt !? Ich habe keinen 3D Drucker, deshalb wird meine 
Box nicht direkt der Netzstecker sein, sondern eher ein Kleingehäuse von 
Pollin. Die Platine Darin enthält dann ein Mini Netzteil vom Typ 
HLK-PM01 von HI-LINK. Die Spannungsversorgung wird dann über ein EURO 
Netzkabel erfolgen.

Deine Arbeit ist noch eine Stufe Kompakter, aber für mich zu aufwendig. 
Aber großen Respekt!!! Ich finde die Lösung sehr gut, kann ich nicht 
gegen anstinken...

[Carsten B. (carstenb)]

Hallo,

sehr cool und schön kompakt. Ich habe meine Aufbau grade in eine 
IP65-Verteilerdose eingebaut. Das habe ich bei ähnlichen Anwendungen 
schon öfter so gemacht. Ist kostengünstig und lässt sich ggf. auch 
draussen benutzen.

Carsten

[Carsten B. (carstenb)]

Hallo,

ich hatte grade auch schon gefunden, wo ich es ändern kann und läuft 
jetzt.

Natürlich sollte ich mal die aktuelle Version einsetzen, aber für heute 
ist erst mal Schluss mit basteln :-)

Carsten

[Günter H. (gnter_h534)]

Carsten B. schrieb:
> Ich habe meinen Aufbau grade in eine
> IP65-Verteilerdose eingebaut.

Ist da ein separater 3,3V-Spannungsregler zur Versorgung des 
nRF24L01-Moduls eingebaut?

Ich mache gerade Versuche damit - inzwischen schafft mein Aufbau häufig 
24 h und länger ohne reboot.

Was jetzt auffällt: Nach dieser Zeitspanne geht in meinem Fall die 
Uhrzeit der "DTU" ca. 8 min nach.

Es sieht für mich so aus, als würde beim Booten NTP abgerufen, danach 
aber nicht mehr?

(Leider habe ich vom Programmieren praktisch null Ahnung)

[Daniel M. (daniel_m821)]

oxylog schrieb:

> "Range of Sub-1GHz wireless: Unlike Wi-Fi or Zigbee which both operate
> on the 2.4 GHz band, Sub-1GHz op-
> erates on the 868 MHz or the 915 MHz band. Generally speaking, Sub-1GHz
> wireless transmission covers 1.5
> to 2 times longer distance than the 2.4GHz spectrum"

868 MHz dieses mal. Ich kann mir nicht vorstellen, dass es ein neues 
oder groß anderes Protokoll gibt.

Vielleicht aber erstmal die aktuellen Baustellen abarbeiten und MI- und 
HM-Serie auf 2,4GHz vollständig implementieren.

Interessant ist das aber auf jeden Fall mit der 1G Verbindung, wurde ja 
bereits vor einigen Tagen hier schonmal mit YT-Links gezeigt.

@Heinz R.
> Die HMS-Serie ist die neueste Serie - nutzt wieder 2,4 GHz, aber denke
> mal das hier nicht das Rad komplett neu erfunden wurde , das ähnlich dem
> HM-Protokoll ist?

Die 2,4GHz sind leider falsch. Beim Protokoll muss man sehen.
Hab bitte etwas Geduld :)

[Carsten B. (carstenb)]

Ja, ich habe das Spannungsreglermodul von AZ-delivery benutzt und 
zusätzlich zwei Elkos angeschlossen (5V und 3,3V). Damit läuft es auch 
bei PA_HIGH stabil.

https://www.az-delivery.de/products/adapter-fur-nrf24l01

Ich habe allerdings immer noch fehlerhafte Pakete, seit der Aufbau nah 
am WR ist (ca. 2-3m durch eine Holzbalkendecke) ist es aber besser.

Statistics:

Receive success: 807
Receive fail: 103
Send Cnt: 2861

[Peter L. (leliep)]

Holger S. schrieb:

> WOW !!! So kompakt hatte ich eigentlich nicht vor. Das Gehäuse ist
> sicherlich gedruckt !? Ich habe keinen 3D Drucker, deshalb wird meine
> Box nicht direkt der Netzstecker sein, sondern eher ein Kleingehäuse von
> Pollin. Die Platine Darin enthält dann ein Mini Netzteil vom Typ
> HLK-PM01 von HI-LINK. Die Spannungsversorgung wird dann über ein EURO
> Netzkabel erfolgen.
>
> Deine Arbeit ist noch eine Stufe Kompakter, aber für mich zu aufwendig.
> Aber großen Respekt!!! Ich finde die Lösung sehr gut, kann ich nicht
> gegen anstinken...

Danke, freut mich, wenn es Dir gefällt. Das Schöne an so einer Community 
ist, dass die Diskussion mit Anderen die eigene Kreativität beflügelt. 
Über eine solche Kompaktlösung hatte ich vor Deinem Beitrag noch nicht 
nachgedacht :-)

Für diese Variante habe ich folgende Komponenten verwendet:
1. das Schukostecker-Unterteil eines Euro-Mehrfachadapters von 
Brennenstuhl. Da der Adapter aus zwei Teilen besteht, die 
freundlicherweise verschraubt und nicht genietet sind, leicht zu 
zerlegen und perfekt für den vorgesehenen Zweck geeignet.
2. ein dazu passend konstruiertes Gehäuse-Unterteil mit 
Verschraub-Möglichkeit für den obigen Schukostecker.
3. das Mini-Netzteil 5V, das Du auch verwendest.
4. eine passend konstruierte Trennplatte mit Bohrung zum Abtrennen des 
Netzspannungs-Bereichs vom Rest.
5. ein ESP8266 D1 von AZ-Delivery mit zwei Buchsenleisten.
6. eine passende (ESP8266-Format) Leerplatine von AZ-D.
7. ein NRF24L01+ Modul von AZ-D mit Platinenantenne. Modul mit 
Fädeltechnik und Steckerleisten auf Leerplatine gelötet.
8. 10uF Elko an 3.3V Versorgung dazu, bisschen isolierte Alufolie um den 
Prozessorteil des NRF24L01+, unter Vermeidung von Kurzschlüssen das 
Ganze zum Sandwich zusammengesteckt.
9. passend zum Gehäuse konstruierter Deckel.

Teile 2,4 und 9 sind 3D-gedruckt (die waren ursprünglich für eine 
ESPEasy-basierte Lösung zur Temperaturmessung mit DS1820 entstanden).

Im Moment liegen die Platinen nur locker im dafür vorgesehenen 
Gehäusebereich, das könnte man noch durch Anpassung der inneren 
Formgebung verbessern.

:-)

[Heinz R. (heijz)]

Daniel M. schrieb:
> Die 2,4GHz sind leider falsch. Beim Protokoll muss man sehen.
> Hab bitte etwas Geduld :)

sorry, hatte es verwechselt - HM und MI-Serie sind ja 2,4 GHz

Wollte hier jetzt auch nicht noch groß ein Thema wegen HMS aufmachen - 
aber hätte ja sein können jemand hat in den diversen chinesischen Seiten 
was dazu gefunden

Viele Grüße

[Daniel M. (daniel_m821)]

Heinz R. schrieb:
> Daniel M. schrieb:
>> Die 2,4GHz sind leider falsch. Beim Protokoll muss man sehen.
>> Hab bitte etwas Geduld :)
>
> sorry, hatte es verwechselt - HM und MI-Serie sind ja 2,4 GHz
>
> Wollte hier jetzt auch nicht noch groß ein Thema wegen HMS aufmachen -
> aber hätte ja sein können jemand hat in den diversen chinesischen Seiten
> was dazu gefunden
>
> Viele Grüße

Den Fortschritt beobachten ist auf jeden Fall wichtig.
Meinen TSUN als MI-Verschnitt habe ich damals geholt weil ich dachte, 
dass er gut und auch kommunikativ ist.
Hätte ich da gewusst, dass es sich um einen MI-Klon handelt, wäre ich 
gleich auf die HM-Serie gegangen.
Schlecht ist er nicht, er fängt sehr früh schon an mit produzieren und 
hält lange durch, aber für mehr als mal schnell irgendwo 2 Module 
hinlegen würd ich ihn auch nicht weiter einsetzen.
Da ich jetzt schlauer bin, werd ich die nächsten 16 Module wohl mit der 
HM-Serie bestücken. Wenn HMS jetzt kommt, fallen die HM hoffentlich im 
Preis. Aktuell ist ja fast nichts lieferbar, das ändert sich hoffentlich 
auch noch.

[Wo (Gast)]

Liebe Leute, eine Kleinigkeit ist mir aufgefallen - kann jetzt doch noch 
einen unbedeutenden Beitrag leisten... :-)

In Zeile 471 der Datei: 
https://github.com/grindylow/ahoy/blob/main/tools/rpi/hoymiles/decoders/__init__.py 
(in "class Hm600Decode0B") sollte wohl das stehen: "return 
self.unpack('>H', 34)[0]/100" (statt "/10"), sonst passt der ausgegebene 
AC Strom nicht.
Für die 1-String Inverter (in "class Hm300Decode0B") ist der Code 
korrekt.

Danke nochmal, Wolfgang

[Claus T. (Gast)]

Hallo,
ich verfolge diesen Thread schon ein paar Tage, dauert ja bei so vielen 
Einträgen schon ne Weile, bis man alles gelesen hat :-) und muss sagen, 
super Arbeit in so kurzer Zeit.
Da ihr ja auch an der Einspeise-Leistungsregelung arbeitet, hab ich noch 
eine Idee zu einer einfachen Leistungsmessung.
Mit den neuen elektronischen Stromzählern kann man über Optokopler den 
Zählerstand und die aktuelle Leistung auslesen (Obis/SML-Schnittstelle). 
Die wird bei mir auch negativ angezeigt, wenn der WR Überschuss 
produziert.
Meine Idee war, eine Software zum auslesen für den ESP schreiben und die 
Daten per MQTT weiter geben, oder eure Schaltung noch mit einer 
Photodiode ergänzen und die Obis-SW gleich mit integrieren.
Und wie es im Internet so ist, war da schon jemand anderer auf die Idee 
gekommen, ESP mit Obis-SW gibts schon:

https://github.com/mruettgers/SMLReader

Nur mal so als günstige Anregung der Leistungsmessung, ist auch leicht 
im Schaltschrank zu installieren, ohne Elektriker, nur auf den Zähler 
mit Magnet oder Klebeband aufsetzen. Bilder und Schaltplan sind bei 
GitHub dabei.

Grüße
Claus T.

P.S. ich habe seit kurzem ein Balkonkraftwerk mit Wechselrichter 
TSOL-M800 von TSUN, würde mich also über die Unterstützung dieses WR 
freuen.

[Holger S. (skusi)]

Peter L. schrieb:
> Für diese Variante habe ich folgende Komponenten verwendet:
> 1. das Schukostecker-Unterteil eines Euro-Mehrfachadapters von
> Brennenstuhl. Da der Adapter aus zwei Teilen besteht, die
> freundlicherweise verschraubt und nicht genietet sind, leicht zu
> zerlegen und perfekt für den vorgesehenen Zweck geeignet.

Solche alten Gehäuse ausgeschlachteter Steckernetzteile hab ich auch 
noch zu Hauf rumligen. Aber je mehr ich damit hantiere fällt mir auf das 
ich es immer gehasst habe das man diese Dinger nie da reingesteckt 
bekommt wo man sie gerade heben möchte. In Mehrfachsteckdosen belegen 
sie meist 2 Plätze oder passen eben gar nicht mit den anderen 
Winkelsteckern zusammen, usw...
Außerdem denke ich ist man mit der WLan Antennen Ausrichtung des Wemos 
flexibler wenn man das Gehäuse mit einem 230V Netzkabel ausstattet.

Ich werde die Variante mit Standard Gehäuse weiter verfolgen.

> 7. ein NRF24L01+ Modul von AZ-D mit Platinenantenne.

Ich werde in das Gehäuse ein Nrf24l01+pa+lna Modul verbauen. Dann kann 
ich ein SMA  Verlängerungskabel verwenden um die Antenne flexibel, 
wahrscheinlich sogar Outdoor (weil Blechdach) zu positionieren.
Dann muß ich die Technik selber auch nicht wasserdicht ausführen und 
kann sie Indoor lassen, ist mir lieber.

> 8. 10uF Elko an 3.3V Versorgung dazu

Ist das zu empfehlen ? Arbeitet das dann stabiler ? Auch ein Elko an 5V 
?

Gruß Skusi

[Holger S. (skusi)]

Carsten B. schrieb:
> Ja, ich habe das Spannungsreglermodul von AZ-delivery benutzt und
> zusätzlich zwei Elkos angeschlossen (5V und 3,3V). Damit läuft es auch
> bei PA_HIGH stabil.

Meinst Du das der Spannungsregler auf dem Wemos minderwertiger ist und 
deshalb oft rebootet wird ? Oder sind es eher die Elkos die da abhilfe 
schaffen.

Mein Testaufbau rebootet auch öfters. 24 Std hab ich noch nicht 
geschafft.
Ich beobachte das auch schon mit Sorge und frage mich was man da 
Hardwareseitig machen kann. Ich dachte immer das es noch 
Kinderkrankheiten der Software sind.

Gruß Skusi

[Stefan T. (isnoahoy)]

oxylog schrieb:
> Hierzu ist eventuell diese Dokumentation über das Sendemodul (?)
> interessant:
> 
https://manuals.plus/m/a345e161e8ceba2155593aaeefcb3e2f3de7dfe1e13fe1e4dc9d421e50725131_optim.pdf

Interessant ist neben den Pin-Outs folgender Absatz aus der Anleitung:

3.6 Label and compliance information
An exterior label on OEM’s end product can use wording such as the 
following:
“Contains Transmitter Module FCC ID: 2ARNB-HMS101” or “Contains FCC ID:
2ARNB-HMS101”

Die Photos von der FCC ID zeigen einen E230G8 AS2RPK JJ2019 von GD (das 
ist m.W. Giga Devices, China) und einen 300A E965 945 chip. Die chin. 
Chip(s)-Hersteller produzieren viele ST32, nRF24 o.a. Clones.
https://fccid.io/2ARNB-HMS101/Internal-Photos/Internal-Photos-5204735

Du kannst ja mal weiter oben nachschauen ob das die selbe FCC ID ist wie 
im bisherigen nRF24-basierten Modul ?

Das mit dem Sub-1G Funkmodul steht auch bei den aktuellen Hoymiles 
HM-600 Invertern im Data Sheet, da nimmt es der Hersteller wohl nicht 
ganz so genau mit dem Marketing der Sende-Frequenzen.
Es könnte aber auch ein LoRaWAN ähnliches Modul sein, zumindest die 
genutzten Frequenzen von 868 & 915 MHz sprächen dafür, wobei in US 
glaube ich 433 MHz genutzt werden.

[Stefan T. (isnoahoy)]

Hallo Daniel M.,

probier mal die Anfrage umgekehrt zu stellen, d.h. erst DTU dann WR 
Adresse:

12:01:10.197 -> I: Requesting Inverter SN 114163500316
12:01:10.251 -> I: Transmit 11 | 09 63 50 03 16 78 56 34 12 00 27
12:01:10.298 -> 89 63 50 03 16 63 50 03 16 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE

Also

> Transmit 11 | 09 78 56 34 12 63 50 03 16 00 27

das sollte dann eigentlich die Antwort geben

> 89 63 50 03 16 78 56 34 12 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE

Hier noch ein paar Kommentare um den Code zu verdeutlichen

> Die app.cpp ab Zeile 224 original:
>

>                 if(0 != len) {
>                     Inverter<> *iv = mSys->findInverter(&p->packet[1]);
>                     if(NULL != iv) {
// paket ID in byte 10, d.h. packet[9]
>                         uint8_t *pid = &p->packet[9]; 
// die paket ID muß < 5 sein, wenn man 0x80 abzieht bzw. sich alle unteren Bits ansieht.
>                         if((*pid & 0x7F) < 5) { 
// kopiere das Ergebnis in die Payload .data[1..5] ab der 11. Stelle bis zum  Ende, das Ende ist die Länge des Paketes len-11 Bytes (= 10 Bytes davor plus 1 Byte CRC-8 ganz am Ende)
>                             memcpy(mPayload[iv->id].data[(*pid & 0x7F) - 
> 1], &p->packet[10], len-11); 
// Berechne die Länge der Payload des Paketes, analog zur Länge davor
>                             mPayload[iv->id].len[(*pid & 0x7F) - 1] = 
> len-11;
>                         }
> 
// Wenn die Paket ID das höchstwertige Bit 0x80 gesetzt hat bzw. > 0x80 ist == Letztes Paket oder Antwort auf ein Retransmit  
>                         if((*pid & 0x80) == 0x80) {
// wenn die Paket ID > die maxPackId ist.
>                             if((*pid & 0x7f) > 
> mPayload[iv->id].maxPackId) {
// setze die maxPackId gleich der aktuellen Paket ID
>                                 mPayload[iv->id].maxPackId = (*pid & 
> 0x7f);
// falls die Paket ID > 0x81 ist, also 0x82 ... 0x85
>                                 if(*pid > 0x81)
// setze die mLastPackId = der aktuellen paket ID
>                                     mLastPacketId = *pid;
>                             }
>                         }
>

> mit meiner Version:
>

>                 if(0 != len) {
>                     Inverter<> *iv = mSys->findInverter(&p->packet[0]);
>                     if(NULL != iv) {
>                         uint8_t *pid = &p->packet[0]; //9
>                         if(*pid == 0x88) { // A Event
>                             memcpy(mPayload[iv->id].data[2], &p->packet[9], len-12);
>                             mPayload[iv->id].len[2] = len-12; 
>                         }
>                         if(*pid == 0x89) { // A Data
>                             memcpy(mPayload[iv->id].data[0], &p->packet[9], len-12);
>                             mPayload[iv->id].len[0] = len-12;
>                         }
>                         if(*pid == 0x91) { // B Event (or Data ?)
>                             memcpy(mPayload[iv->id].data[1], &p->packet[9], len-12);
>                             mPayload[iv->id].len[1] = len-12;
>                         }
>                         if(*pid == 0x92) { // B Data (or Event ?)
>                             memcpy(mPayload[iv->id].data[3], &p->packet[9], len-12);
>                             mPayload[iv->id].len[3] = len-12;
>                         }
> 
Den Rest würde ich erstmal weglassen und sehen, daß er die o.a. 0x89 Antwort sauber dekodiert. Das sollte er in processPayload machen.
Dabei kannst Du m.E. den Punkt mit buildPayload überspringen, dabei werden alle Teil-Payloads der Pakete zusammen nochmal mit einer CRC-16 validiert.
Das gibt/gab es bei den MI-Wechselrichtern nicht, dort reicht die bereits in Zeile 216 überprüfte CRC-8 die immer am Ende jedes Pakets vorhanden ist.

>                         if( (*pid == 0x88) || (*pid == 0x89) || (*pid == 0x91) || (*pid == 0x92) ) {
>                             if((*pid == 0x89) && (mPayload[iv->id].maxPackId < 1)) {
>                                 mPayload[iv->id].maxPackId = 1;
>                             }
>                             if((*pid == 0x88) && (mPayload[iv->id].maxPackId < 3) { 
>                                 mPayload[iv->id].maxPackId = 3;
>                             }
>                             if((*pid == 0x91) && (mPayload[iv->id].maxPackId < 2) { 
>                                 mPayload[iv->id].maxPackId = 2;
>                             }
>                             if((*pid == 0x92) && (mPayload[iv->id].maxPackId < 4)) {
>                                 mPayload[iv->id].maxPackId = 4;
> 
>                                 if(*pid == 0x92)
>                                     mLastPacketId = *pid;
>                             }
>                         }
>

Ich bin mir nicht sicher in welcher Reihenfolge die einzelnen Anfragen 
0x09, 0x11, 0x08 / 0x12 denn gestellt werden bzw. reinkommen. Ich habe 
jetzt einfach mal eine hypothetische Reihenfolge angenommen und nehme 
an, daß auch tatsächlich alle view Pakete gesendet / empfangen werden. 
Sollte das nicht der Fall sein, muß man das eben entsprechend kürzen. 
Persönlich wäre für mich nach 0x89 (als Antwort auf 0x09) und 0x91/0x92 
(als Antwort auf 0x11) erst mal Schluss. D.h. eigentlich nur zwei 
Antwort-Pakete und dann die mLastPacketId setzen.

> dort habe ich auch den CMD 0x10, für Debug- und Verständniszwecke mal
> mit eingebaut. Gesehen habe ich die Antwort darauf auch schon, nur noch
> keine Idee, was ich mit den Werten am Ende mache (aktuell auch
> irrelevant).

Laut Command Summary ist 0x10 Collect grid-connected configuration file 
name and version information  die Antwort beginnt dann mit 0x90.

> Was die Payload-länge, maxPackID usw. angeht, habe ich keine Ahnung, was
> ich da tue und wie es richtig geht. Habe einiges durchprobiert, mangels
> Verständnis und Wissen scheitere ich an diesem Punkt.

In der app.h wird die folgende Struktur definiert, die pro 
Wechselrichter existiert:

typedef struct {
    uint8_t invId;
    uint32_t ts;
    uint8_t data[MAX_PAYLOAD_ENTRIES][MAX_RF_PAYLOAD_SIZE];
    uint8_t len[MAX_PAYLOAD_ENTRIES];
    bool complete;
    uint8_t maxPackId;
    uint8_t retransmits;
    bool requested;
} invPayload_t;

> &p->packet[0] findet auf jeden Fall die Antwort-ID, &p->packet[9] zeigt
> auf den Punkt, ab wann Nutzdaten kommen, die Länge der Nutzdaten ist 12
> (6 Werte).

Ich denke das ist richtig.

@Lukas, kannst Du das und die weiteren Annahmen / Fragen zu buildPayload 
/ processPayload eventuell noch bestätigen bzw. etwas erklären ?

> Habe ich einen Denkfehler bei "len-12" das hier nicht die Gesamtlänge
> gefragt ist sondern eine Position in der Payload verschoben wird?

len ist die Länge des gesamten Antwort Paketes vom nRF24, also len-10 
sollte m.E. bei Dir richtig sein (10 Bytes = 1 Byte Command + 4 Bytes 
Source Adr + 4 Bytes Destination Adr + 1 Byte CRC-8 am Ende)

89 >63 50 03 16< >78 56 34 12< >01 2B< >00 56< >09 5C< >13 85< >09 A5< >02 B8< >01 FF< DE
1 + 4          + 4         + 2   + 2   + 2   + 2   + 2   + 2   + 2   + 1
CMD >WR ADR    < >DTU ADR    < >299 W< > 86 ?< >2396?< >4997?< >2469?< >696?< >511?< CRC8

> Ich würde den Knoten im Kopf gerne lösen.

Ich hoffe das o.a. ist jetzt nicht komplett verwirrend sondern hilft Dir 
etwas weiter. Vielleicht kann ja auch nochmal Lukas etwas zu einer 
möglichen Implementierung in der Methode processPayload (bzw. 
buildPayload) sagen.

Ich hoffe das klappt mit dem MI-Wechselrichtern bei Euch noch demnächst.

[Herbert K. (avr-herbi)]

Stefan T. schrieb:
...
> Die Photos von der FCC ID zeigen einen E230G8 AS2RPK JJ2019 von GD (das
> ist m.W. Giga Devices, China)
...
Könnte dieser sein (Datenblatt siehe Anhang)

[Daniel M. (daniel_m821)]

Stefan T. schrieb:
> Hallo Daniel M.,
>
> probier mal die Anfrage umgekehrt zu stellen, d.h. erst DTU dann WR
> Adresse:
> Also
>
>> Transmit 11 | 09 78 56 34 12 63 50 03 16 00 27
>
> das sollte dann eigentlich die Antwort geben
>
>> 89 63 50 03 16 78 56 34 12 01 2B 00 56 09 5C 13 85 09 A5 02 B8 01 FF DE

DTU und WR-ID umdrehen klappt nicht, es folgen keine Antworten mehr.
Ich sende 0x09 und erhalte im normalfall eine 0x88 und eine 0x89 zurück.

88 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 8B 
89 63 50 03 16 63 50 03 16 01 2F 00 05 09 5D 13 86 00 97 07 CC 01 60 5E

Die 0x88 ist der Status, hier die 03 ist der Modulstatus (verbunden und 
aktiv)
Die 0x89 sind die Werte:

 89 63 50 03 16 63 50 03 16 01 2F 00 05 09 5D 13 86 00 97 07 CC 01 60 5E
1 + 4           + 4         + 2   + 2   + 2   + 2   + 2   + 2   + 2   + 1
CMD >WR ADR    < >WR ADR   < >29,9V<>0,86A<>239,6V<>4997Hz<>24,69W< 
>0,696kWh< >51,1°C< CRC8

CMD, WR-ID, WR-ID, DC_U, DC_I, AC_U, AC_Freq, AC_Pow, Day_kWh, 
WR_Temperatur

Das gleiche gilt für die Anfrage 0x11 mit den Antworten 0x91 Status und 
0x92 Werte.

Mit Hubi seiner NRF24_SendRcv bekomme ich folgedes als Payload zurück:

00 7388888801 0096 12 3 88 63500316 63500316 00030000000000008B187E 1
00 7388888801 00C4 18 2 89 63500316 63500316 012B000409641384007D07D8014BB5780D 1

00 7388888801 00C4 18 2 91 63500316 63500316 013400030965138500720768014A0BACD6 1

00 7388888801 0096 12 3 92 63500316 63500316 00030000000000009158D6 1

Ich habs bisher noch nicht geschafft, das komplett anzeigen zu lassen.
Wird in der ahoy-Version der kram vor 0x88 usw. verworfen und ich starte 
quasi mit der Antwort bei packet[0] oder starte ich bei [10] und mit der 
Adresse bei [11]?

In allen Versuchen mit verschiedenen Adressen in dem Teil:

if(0 != len) {
                    Inverter<> *iv = mSys->findInverter(&p->packet[1]);
                    if(NULL != iv) {

habe ich nichts verwertbares bekommen. Den Debug konnte ich soweit 
verändern, dass er mir immer eine len=0 und maxPackId=4 ausgegeben hat, 
falls da überhaupt was war. Bei packet[1] hat die Funktion retransmit 
gegriffen, "Frame 1 missing", bei allen anderen Versuchen war "Last 
Frame missing".

Die anderen Tips schau ich mir gleich an.

> Ich hoffe das o.a. ist jetzt nicht komplett verwirrend sondern hilft Dir
> etwas weiter. Vielleicht kann ja auch nochmal Lukas etwas zu einer
> möglichen Implementierung in der Methode processPayload (bzw.
> buildPayload) sagen.

War nicht komplett verwirrend, aber ich brauche etwas Zeit um alles 
anzuschauen und nachzuvollziehen.
Ich denke, ich bin immernoch nur am Symptom dran, nicht an der Ursache. 
Irgendwo hab ich etwas übersehen, was verkehrt läuft.
Gerne mehr Informationen und Ideen :)

> Ich hoffe das klappt mit dem MI-Wechselrichtern bei Euch noch demnächst.

Das hoffe ich auch, hab ich ehrlich gesagt unterschätzt, wie aufwändig 
es ist.

Danke auf jeden Fall für deine ausführliche Antwort, ich probier weiter.

[Peter L. (leliep)]

Holger S. schrieb:
> Peter L. schrieb:
>> Für diese Variante habe ich folgende Komponenten verwendet:
>> 1. das Schukostecker-Unterteil eines Euro-Mehrfachadapters von
>> Brennenstuhl. Da der Adapter aus zwei Teilen besteht, die
>> freundlicherweise verschraubt und nicht genietet sind, leicht zu
>> zerlegen und perfekt für den vorgesehenen Zweck geeignet.
>
> Solche alten Gehäuse ausgeschlachteter Steckernetzteile hab ich auch
> noch zu Hauf rumligen. Aber je mehr ich damit hantiere fällt mir auf das
> ich es immer gehasst habe das man diese Dinger nie da reingesteckt
> bekommt wo man sie gerade heben möchte. In Mehrfachsteckdosen belegen
> sie meist 2 Plätze oder passen eben gar nicht mit den anderen
> Winkelsteckern zusammen, usw...
> Außerdem denke ich ist man mit der WLan Antennen Ausrichtung des Wemos
> flexibler wenn man das Gehäuse mit einem 230V Netzkabel ausstattet.
>
> Ich werde die Variante mit Standard Gehäuse weiter verfolgen.
>
ich denke, die Umsetzung sollte sich immer an den individuellen 
Anforderungen orientieren. Für mich ist klein und kompakt wichtig...

>> 7. ein NRF24L01+ Modul von AZ-D mit Platinenantenne.
>
> Ich werde in das Gehäuse ein Nrf24l01+pa+lna Modul verbauen. Dann kann
> ich ein SMA  Verlängerungskabel verwenden um die Antenne flexibel,
> wahrscheinlich sogar Outdoor (weil Blechdach) zu positionieren.
> Dann muß ich die Technik selber auch nicht wasserdicht ausführen und
> kann sie Indoor lassen, ist mir lieber.

bisher habe ich leider noch kein mit dem HM-1200 funktionierendes 
Funkmodul mit Antennenpin auftreiben können, daher die Platinenversion, 
die aber erstaunlich gut funktioniert. Auch eingebaut und fest in der 
Steckdose verstöpselt.

>
>> 8. 10uF Elko an 3.3V Versorgung dazu
>
> Ist das zu empfehlen ? Arbeitet das dann stabiler ? Auch ein Elko an 5V
> ?

es gibt irgendwo in diesem Thread eine Empfehlung dazu, die für mich 
plausibel klingt, daher habe ich das gemacht. Zu einem Elko an 5V kann 
ich nichts sagen, es schadet nicht, aber ob es eine Verbesserung 
bringt...?

[oxylog (Gast)]

Holger S. schrieb:
> Ist das zu empfehlen ?

Quelle für den Tipp: http://stefanfrings.de/esp8266/ oder 
https://esp8266-server.de/Tipps.html

[Stefan T. (isnoahoy)]

oxylog schrieb:
> Holger S. schrieb:
>> Ist das zu empfehlen ?
>
> Quelle für den Tipp: http://stefanfrings.de/esp8266/

Wemos D1 Mini Board
...
Der Spannungsregler reicht gerade für den WLAN Chip aus, er darf extern 
nur minimal belastet werden (50 mA bei 5 V). Um die Zuverlässigkeit zu 
verbessern, empfehle ich einen 100 µF Kondensator zwischen 3,3V und GND.

> oder https://esp8266-server.de/Tipps.html

Adapter Plate With IO Lead Out For ESP-07 ESP-08 ESP-12
...
Außerdem fehlt auf der Platine ein Puffer Kondensator an 3,3V –Seite. Es 
muss mindestens 100uF sein, denn ESP8266 Modul erzeugt kurzzeitig die 
Strompeaks von 400mA.

[Stefan T. (isnoahoy)]

Herbert K. schrieb:
> Stefan T. schrieb:
> ...
>> Die Photos von der FCC ID zeigen einen E230G8 AS2RPK JJ2019 von GD (das
>> ist m.W. Giga Devices, China)
> ...
> Könnte dieser sein (Datenblatt siehe Anhang)

Treffer GD32 E329G8 ist ein STM blue pill clone.

Wegen dem 300A E965 945 habe ich dem o.a. FCC Beitrag noch folgendes 
entnommen:

4.1 NRF Channel List
Depending on the program, the module can work on 915MHz for North 
America and 868MHz for Europe. Unless necessary, it’s forbidden to 
change the module program.

Das spricht zumindest für NRF m.W. ein Nordic Semiconductors Standard. 
Vielleicht findet man ja mit NRF und der Frequenz etwas mehr, ich tippe 
auf einen nRF905 Clone ?

Data Sheet z.B. hier
https://www.sparkfun.com/datasheets/IC/nRF905_rev1_1.pdf

[Daniel R. (daniel92)]

Moin zusammen,

ich habe nun das NRF Module auf dem Raspberry zum laufen bekommen. :)

Poll inverter 116174403329
2022-06-20 14:43:35.254088 Transmit 27 | 15 74 40 33 29 78 56 30 01 80 0b 00 62 b0 79 87 00 00 00 05 00 00 00 00 bd d7 ec
2022-06-20 14:43:35.311724 Received 27 bytes channel 3: 95 74 40 33 29 74 40 33 29 01 00 01 00 01 00 00 00 01 00 00 00 00 00 00 00 00 95
2022-06-20 14:43:35.346887 Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 02 00 00 00 00 00 00 00 00 00 d7 00 00 00 03 00 01 42
2022-06-20 14:43:35.417421 Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 03 00 07 00 00 00 00 00 00 00 01 00 00 00 00 00 03 93
2022-06-20 14:43:35.458275 Received 27 bytes channel 75: 95 74 40 33 29 74 40 33 29 84 00 00 00 00 00 00 00 00 00 00 01 0d 00 0b c4 fc 2e
2022-06-20 14:43:35.960403 Payload: 00 01 00 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d7 00 00 00 03 00 01 00 07 00 00 00 00 00 00 00 01 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 01 0d 00 0b c4 fc
2022-06-20 14:43:35.960403 Decoded: temp=26.9, pf=0.0 phase0=voltage:0.3, current:0.0, power:0.0, frequency:0.0 string0=voltage:0.1, current:0.0, power:0.0, total:0.0, daily:0 string1=voltage:0.1, current:0.01, power:0.0, total:0.0, daily:0 string2=voltage:21.5, current:0.0, power:0.1, total:0.0, daily:0 string3=voltage:21.5, current:0.03, power:0.7, total:0.001, daily:0

Bekomme aber hin und wieder ein missing frame zurück. =(
Error while retrieving data: Frame 3 missing: Request Retransmit
Error while retrieving data: Frame 1 missing: Request Retransmit
Error while retrieving data: Missing packet: Last packet 2

[Holger S. (skusi)]

Tach auch,

ich habe nun gestern mein Platinenlayout fertig gestellt. Nun stellt 
sich mir noch die Frage nach der stabilen Spannungsversorgung des RF24.

Ich habe mal eben eine über 30 min die Stromaufnahme des Transceiver bei
Amplifier Power Level Max und drei Invertern gemessen. Die Spitzen lagen 
bei 34 mA.
Auf http://stefanfrings.de/esp8266/ steht geschrieben:

3V3  VCC  Spannungsversorgung 3,3 V (Eingang 500 mA oder Ausgang max. 50 
mA)

Wäre also im Limit. Trotzdem ist ein 100 µF Kondensator sicher nicht 
falsch.

Ich könnte zur Sicherheit natürlich noch einen eigenen Spannungsregler 
für den RF24 dazu stricken.

Eine andere Überlegung ist ein 3,3V Netzteil einzusetzen und den RF24 
sowie den Wemos damit zu versorgen. Im Netzt ließt man aber 
unterschiedliche Meinungen dazu ob es gut ist den Wemos eigenen 
Spannungsregler "rückwärts" mit 3,3 V zu betreiben. Es würde die Sache 
aber um einen Spannungsregler leichter machen. Den 100 µF Kondensator 
würde ich zur Sicherheit dann trotzdem an das Netzteil hängen.

Ich kann mich nicht entscheiden, wie ist Eure Meinung dazu ?

[Günter H. (gnter_h534)]

@ Holger

Der nRF24L01+ kann aber auch deutlich mehr Strom aufnehmen:
"The modules operate in the 2.4GHz band at data rates of 250Kbps, 1Mbps 
or 2Mbps.  Max operating current is < 115mA."
(Quelle: 
https://protosupplies.com/product/nrf24l01palna-2-4ghz-rf-wireless-module/)

Mit diesem Wert wäre man außerhalb einer stabilen Spannungsversorgung.

Mein Vorschlag: Zweiten 3,3V-Spannungsregler (und Peripherie) auf 
Platine vorsehen mit der Option, diesen Spannungsregler ggf. nicht zu 
bestücken und über eine dann einzulötende Drahtbrücke zu überbrücken.

[Ziyat T. (toe_c)]

MI-1500:
- Beim Sniffen keine Sender Daten vom ESP gesehen, lange gesucht und
- meine beiden ESP's waren futsch!!!!!, MOSI gehen an beiden nicht??!
- auf Arduino gewechselt
- es muss die PA Einstellung RF24_PA_LOW sein, schon mit RF24_PA_HIGH 
geht nichts mehr! Mein MurxBoard ist 10m vom WR weg.

- Warum bei beiden ESP's die MOSI's kaputt sind: kann die Standard 
Einstellung RF24_PA_MAX der Grund sein???

Hier mit 3 PV's

Send... CH75 36637071607222841200F2
Send... CH3 37637071607222841200F3
Send... CH23 38637071607222841200FC
Send... CH40 39637071607222841200FD
Send... CH61 36637071607222841200F2
00 1284227201 00DE 1B 3  B6 63707160 63707160 
01750004091E1387009703E0013E0300030EEAC5 1
PV:1 37.30V 0.40A 15.10W 992.00Wh 233.40V 49.99Hz 31.80C  Sts:3 Cnt:0

Send... CH75 37637071607222841200F3
Send... CH3 38637071607222841200FC
Send... CH23 39637071607222841200FD
Send... CH40 36637071607222841200F2
Send... CH61 37637071607222841200F3
00 1284227201 00DA 1B 1  B7 63707160 63707160 
017500040920138600AE040C013E030003E28DBB 1
PV:2 37.30V 0.40A 17.40W 1036.00Wh 233.60V 49.98Hz 31.80C  Sts:3 Cnt:0

Send... CH75 38637071607222841200FC
Send... CH3 39637071607222841200FD
Send... CH23 36637071607222841200F2
Send... CH40 37637071607222841200F3
Send... CH61 38637071607222841200FC
00 1284227201 00D8 1B 0  B8 63707160 63707160 
0163000409231387009106E1013F03000328AD7E 1
PV:3 35.50V 0.40A 14.50W 1761.00Wh 233.90V 49.99Hz 31.90C  Sts:3 Cnt:0

Send... CH75 39637071607222841200FD
Send... CH3 36637071607222841200F2
Send... CH23 37637071607222841200F3
Send... CH40 38637071607222841200FC
Send... CH61 39637071607222841200FD
00 1284227201 00D8 1B 0  B9 63707160 63707160 
016300000921138600030006013E0300035C4E20 1
PV:4 35.50V 0.00A 0.30W 6.00Wh 233.70V 49.98Hz 31.80C  Sts:3 Cnt:0

[Richard K. (laserrichi)]

Holger S. schrieb:
> Eine andere Überlegung ist ein 3,3V Netzteil einzusetzen und den RF24
> sowie den Wemos damit zu versorgen. Im Netzt ließt man aber
> unterschiedliche Meinungen dazu ob es gut ist den Wemos eigenen
> Spannungsregler "rückwärts" mit 3,3 V zu betreiben. Es würde die Sache
> aber um einen Spannungsregler leichter machen. Den 100 µF Kondensator
> würde ich zur Sicherheit dann trotzdem an das Netzteil hängen.
>
> Ich kann mich nicht entscheiden, wie ist Eure Meinung dazu ?

auf dem Wemos ist ja ein RT9013 verbaut, vom Blockschaltbild sehe ich 
erstmal kein Problem wenn auf der 3,3V Seite Spannung anliegt.

Ich würde das ganze sowieso entkoppeln, alleine wegen dem ganzen Funk 
und HF zeugs was sich gegenseitig ja stört. Einfach einen zweiten RT9013 
nur für den RF24 nehmen und dann kannst du alles mit 5V Versorgen.

[Daniel M. (daniel_m821)]

Ich habe nach Stefan seiner Anleitung noch etwas rumprobiert und bin 
hier rausgekommen:

D: Received 18 bytes channel 75: 88 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 8B
D: ],[0,6103,"normal"],[0,3104,63.62],[0,6101,0],[0,9101,"roller"],[0,4108,239.21]]}

D: Received 24 bytes channel 3: 89 63 50 03 16 63 50 03 16 00 E4 00 00 09 4E 13 88 00 0D 01 E2 00 BC E3
D: ],[0,6103,"normal"],[0,3104,63.62],[0,6101,0],[0,9101,"roller"],[0,4108,239.21]]}

Wo kommen "normal" und "roller" her, was ist das?

Wie genau wird die mPayload zusammengebaut? Wofür stehen die 
".data"-Adressen?

memcpy(mPayload[iv->id].data[3], &p->packet[16], len-9);
mPayload[iv->id].len[3] = len-8;

Ich denke, so langsam verstehe ich, was passiert.

@Ziyat:
Glückwunsch! :)
Das PA_Max war es wahrscheinlich nicht, mein Wemos hält bisher stand.

lg

[Stefan T. (isnoahoy)]

Hallo Holger,

ich kann noch das folgende vom Author der RF24 Bibliothek beisteuern:

my PA/LNA module fails to transmit
https://nrf24.github.io/RF24/md_COMMON_ISSUES.html

You may find variants of the nRF24L01 transceiver that are marketed as 
“nRF24L01+PA+LNA”. These modules are distinct in the fact that they come 
with a detachable (SMA-type) antenna. They employ seperate RFX24C01 IC 
with the antenna for enhanced Power Amplification (PA) and Low Noise 
Amplification (LNA) features. While they boast greater range with the 
same functionality, they are subject to a couple lesser known (and 
lesser advertised) drawbacks:

    Stronger power source. Below is a chart of advertised current 
requirements that many MCU boards’ 3V regulators may not be able to 
provide (after supplying power to internal components).
    Specification   Value
    Emission mode current(peak)   115 mA
    Receive Mode current(peak)   45 mA
    Power-down mode current   4.2 µA
    Needs shielding from electromagnetic interference. Shielding usually 
works best when it has a path to ground (GND pin), but this connection 
to the GND pin is not required. It is important that the sheilding does 
not touch any current carrying parts.
        Professionals tend to use a faraday cage/mesh to implement 
electromagnetic shielding, but it can be pricey for this scenario.
        A quick do-it-yourself solution (as proof-of-concept) would be 
to wrap the PA/LNA module with electrical tape and then wrap foil around 
the electrical tape (for shielding) while being very careful to not let 
the foil touch any current carrying parts (like the GPIO pins, the 
antenna mount, and the soldier joints for the antenna mount). Observe 
ghetto_shielding_1.png ghetto_shielding_2.png


Sowie hier die Empfehlung einen Kondensator zwischen 3,3V und GND zu 
klemmen:

Troubleshooting
https://howtomechatronics.com/tutorials/arduino/arduino-wireless-communication-nrf24l01-tutorial/

It’s worth noting that power supply noise is one of the most common 
issues people experience when trying to make successful communication 
with the NRF24L01 modules. Generally, RF circuits or radio frequency 
signals are sensitive to power supply noise. Therefore, it’s always a 
good idea to include a decoupling capacitor across the power supply 
line. The capacitor can be anything from 10uF to 100uF.
NRF24L01 Troubleshooting- decoupling capacitor and external power supply

Another common issue is that the 3.3V pin of the Arduino boards, cannot 
always supply enough power to the NRF24L01 module. So, powering the 
module with an external power source is also a good idea.


Fixing NRF24L01+ Modules Without Going (Too) Insane
https://hackaday.com/2021/01/22/fixing-nrf24l01-modules-without-going-too-insane/

Ich habe auch irgendwo bei Hack-A-Day gelesen, daß es evtl. besser ist 
einen Elko mit ca. 100uF und 25V und ein Tantalum Cap mit 1-10pF 
parallel anzuklemmen um sowohl hoch- als auch niederfrequente Teile der 
Versorgungsspannung zu glätten.


Bei mir läuft es (das o.g. PA Modul mit Antenne und ohne Schirmung vom 
maker"laden") ganz ohne Elko, etc. Ich würde daher empfehlen drei Plätze 
vorzusehen, für den Elko, für den Tantalum und einen für die Lötbrücke, 
am besten die Lötbrücke fest verdrahten zum raus-cuttern, wenn man die 
Elkos und/oder Tantalum einbaut.

[Stefan T. (isnoahoy)]

Hallo Daniel,

mach doch mal ein Issue auf Github auf, damit wir dort die Punkte für 
den MI-Wechselrichter abstimmen, hier gehen die Punkte m.E. etwas 
verloren, da ja auch noch andere Diskussionen ablaufen ?

Daniel M. schrieb:
> Wo kommen "normal" und "roller" her, was ist das?
>
> Wie genau wird die mPayload zusammengebaut? Wofür stehen die
> ".data"-Adressen?
>

> memcpy(mPayload[iv->id].data[3], &p->packet[16], len-9);
> mPayload[iv->id].len[3] = len-8;
>

>
> Ich denke, so langsam verstehe ich, was passiert.

normal und roller habe ich bei mir noch gar nicht gesehen... "roller" 
z.B. kann ich auch im repo von grindylow/ahoy nirgends finden ?

mPayload ist eine Struktur, mit einem data[] Array.
In data[0..3] werden Deine vier Antworten bzw. die Daten davon, also 
alles ab packet[10..len] abgelegt, das sind dann len-10 bytes.
in len[0..3] wird die Länge der jeweiligen Daten im Packet abgelegt, 
also die len-10 bytes.

Bei diesem Vorgang werden die Daten mit der memcpy(ziel, anfang_quelle, 
länge) Funktion kopiert.
Die Länge ist nur ein Wert, der wird direkt zugeordnet.
Das heißt am Ende hast Du in mPayload.data[0..3] Deine Daten, ohne die 
Adressen und die Antwort ID 0x88/0x89,0x91/0x92.
Weil die Daten beim HM-Wechselrichter unterschiedlich lang sein können, 
vor allem das letzte Paket ist i.d.R. nicht 12 Byte lang, deshalb gibt 
es das len[0..3] Feld in dem die jeweilige Länge steht.
Der HM-Wechselrichter hat dann in den letzten beiden Bytes des letzten 
Pakets noch eine Prüfsumme (CRC-M/CRC-16) stehen, die in buildPayload 
geprüft wird.
Da die MI-Baureihe keine zweite Quersumme hat, kann der Teil m.E. 
entfallen.

Du mußt also nur die Daten in processPayload den entsprechenden Werten 
zuordnen und ggf. durch 100 oder 1000 teilen. Das wird in hmDefines.h 
für jeden HM-Wechselrichter definiert und dann nach diesen Vorgaben 
umgerechnet.

[Ziyat T. (toe_c)]

MI-1500
========
Limitierung laeuft!

Hier als Bsp. die Limitierung auf 5% (5a:5a:05:)

Send... CH61 51:63:70:71:60:72:22:84:12:5a:5a:05:90:
00 1284227201 0066 0C 3  D1 63707160 63707160 5A5AD1272F 1
Rcv... auf 0x51 cmd=0xD1  (korrekt)

WR zeigt Status 8 > PVs sind ausgeschaltet, weil bei MI unter 10% nicht 
limitiert werden kann

Send... CH3 38:63:70:71:60:72:22:84:12:00:fc:
Send... CH23 39:63:70:71:60:72:22:84:12:00:fd:
Send... CH40 36:63:70:71:60:72:22:84:12:00:f2:
Send... CH61 37:63:70:71:60:72:22:84:12:00:f3:
00 1284227201 00DA 1B 1  B7 63707160 63707160 
01C900000941138700050062017E081F01ADC76E 1
PV:2 0.50W 45.70V 0.00A 98.00Wh 236.90V 49.99Hz 38.20C  Sts:8 Cnt:31

Send... CH3 39:63:70:71:60:72:22:84:12:00:fd:
Send... CH23 36:63:70:71:60:72:22:84:12:00:f2:
Send... CH40 37:63:70:71:60:72:22:84:12:00:f3:
Send... CH61 38:63:70:71:60:72:22:84:12:00:fc:
00 1284227201 00DA 1B 1  B8 63707160 63707160 
01C1000009441387000700B5017D081F01793AD4 1
PV:3 0.70W 44.90V 0.00A 181.00Wh 237.20V 49.99Hz 38.10C  Sts:8 Cnt:31

Send... CH75 39:63:70:71:60:72:22:84:12:00:fd:
Send... CH23 37:63:70:71:60:72:22:84:12:00:f3:
Send... CH40 38:63:70:71:60:72:22:84:12:00:fc:
00 1284227201 00D8 1B 0  B9 63707160 63707160 
01C10000093C138700050001017D081F01B6D1BA 1
PV:4 0.50W 44.90V 0.00A 1.00Wh 236.40V 49.99Hz 38.10C  Sts:8 Cnt:31

[Herbert K. (avr-herbi)]

Ziyat T. schrieb:
> MI-1500
> Limitierung laeuft!
Gratulation !

[Steff (Gast)]

Hallo Forum!

Eine Frage treibt mich um: Bei uns wurde ein STP 5.0-3SE-40 / SMA SUNNY 
TRIPOWER 5.0 - SMART ENERGY verbaut. Vielleicht findet die 
Schwarmintelligenz (?) auch darauf eine Antwort:
Gilt das in den letzten 1270 Beiträgen Gesagte dafür auch?

LG Steffi

[Andreas S. (drschiffler)]

Ziyat T. schrieb:
> MI-1500
> ========
> Limitierung laeuft!
>
Hi,

wie ich sehe ist auch bei Dir die Spannung an den Modulen 3/4 und 1/2 
identisch. Das liegt am Code im Decoder da hier die gleichen Bytes 
aufgelöst werden.
Allerdings ist in der Antwort vom Umrichter auch keine weitere 
Information zu den Spannungen drin. (Es fehlen schlicht Bytes rein 
rechnerisch)
Es gibt meinerseits zwei Vermutungen:
1. Das ist im Umrichter intern so verschaltet, dass die Module 3/4 und 
1/2 jeweils am gleichen Potential hängen.
2. Den Wert gibt es schlicht nicht. (Die Leistung ist ja individuell für 
jede der vier Module / Eingänge und wird auch ausgegeben)

Sonst noch Erklärungen?

Grüße
Andreas

[Ziyat T. (toe_c)]

Steff schrieb:
> Hallo Forum!
>
> Eine Frage treibt mich um: Bei uns wurde ein STP 5.0-3SE-40 / SMA SUNNY
> TRIPOWER 5.0 - SMART ENERGY verbaut. Vielleicht findet die
> Schwarmintelligenz (?) auch darauf eine Antwort:

Hallo Steff
Hier geht es nur um die Hoymiles Inverter, leider keine Lösung für den 
SMA SUNNY TRIPOWER hier

[Daniel R. (daniel92)]

Ziyat T. schrieb:
> MI-1500
> ========
> Limitierung laeuft!

Sehr sehr cool schonmal. Unabhängik davon, konnte jemand schon was beim 
HM-1500 oder kleiner, etwas erreichen?

Die Dokus von Gitee sind ja fast ausschlieslich für MI bezogen, oder hab 
ich was übersehen?

[Ziyat T. (toe_c)]

Andreas S. schrieb:
> Ziyat T. schrieb:
>> MI-1500
>> ========
>> Limitierung laeuft!
>>
> Hi,
>
> wie ich sehe ist auch bei Dir die Spannung an den Modulen 3/4 und 1/2
> identisch. Das liegt am Code im Decoder da hier die gleichen Bytes
> aufgelöst werden.
> Allerdings ist in der Antwort vom Umrichter auch keine weitere
> Information zu den Spannungen drin. (Es fehlen schlicht Bytes rein
> rechnerisch)
> Es gibt meinerseits zwei Vermutungen:
> 1. Das ist im Umrichter intern so verschaltet, dass die Module 3/4 und
> 1/2 jeweils am gleichen Potential hängen.
> 2. Den Wert gibt es schlicht nicht. (Die Leistung ist ja individuell für
> jede der vier Module / Eingänge und wird auch ausgegeben)
>
> Sonst noch Erklärungen?
>
> Grüße
> Andreas
Hallo Andreas
MI hat 2 MPPTs für 4PVs
Module 1/2 am MPPT1
Module 3/4 am MPPT2
Die Grafik zeigt es auch, ich denke die hängen am gleichen Potential

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Ziyat T. schrieb:
>> MI-1500
>> ========
>> Limitierung laeuft!
>
> Sehr sehr cool schonmal. Unabhängik davon, konnte jemand schon was beim
> HM-1500 oder kleiner, etwas erreichen?
>
> Die Dokus von Gitee sind ja fast ausschlieslich für MI bezogen, oder hab
> ich was übersehen?

Danke, es hat ja ziemlich lange gedauert...

Richtig, in den Dokus hab ich auch nichts extra für HM gesehen, aber
das Modbus-Doku beschreibt die gleiche Limitierung-Register für alle 
WR-Modelle, vielleicht geht es auch mit dem HM

[Daniel R. (daniel92)]

Das probiere ich Zuhause dann aus! =)

Ziyat T. schrieb:
> Send... CH61 51:63:70:71:60:72:22:84:12:5a:5a:05:90:
> 00 1284227201 0066 0C 3  D1 63707160 63707160 5A5AD1272F 1

Könntest du bitte ein Auszug von deinem Code durch geben?

Ich würde es ca. so abschicken. (Habe aktuell noch nicht viel 
abgeschickt)
Kümmere mich gerade um die Einbindung in 'Home Assistant' über MQTT. 
Dort will ich es als Entität einbinden und später mit Grafana noch 
anzeigen.

payload={0x5a, 0x5a, 0x05}
request=next(hoymiles.compose_esb_packet(payload,seq=b'\x80',src=dtu_ser,dst=inverter_ser)))

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Das probiere ich Zuhause dann aus! =)
>
> Ziyat T. schrieb:
>> Send... CH61 51:63:70:71:60:72:22:84:12:5a:5a:05:90:
>> 00 1284227201 0066 0C 3  D1 63707160 63707160 5A5AD1272F 1
>
> Könntest du bitte ein Auszug von deinem Code durch geben?
> >>>

payload={0x5a, 0x5a, 0x05}   0x05 ist % die Limitierung also hier 5% der 
angeschlossene Nennleistung.

Ich verwende immer noch die Hubi's SW auf Arduino, es wird hier 
gesendet:

void isTime2Send () {
//-----------------
  int32_t size = 0;
  uint64_t dest = WR1_RADIO_ID;
  uint8_t UsrData[5];
  // Second timer

  if (millis() >= tickMillis) {
    static uint8_t tel = 0;
    tickMillis += 500;    //200;
    //tickSec++;
    hmPackets.UnixTimeStampTick();
/*    if (++tickSec >= 5) {   // 5
      hmPackets.UnixTimeStampTick();
      tickSec = 0;
    } */

    if (tel > 5) {   tel = 0;    }

    if (COMMAND > 0x0039)
      COMMAND= 0x0036;

    if (tel == 0) {// Limitierung Command 0x51
      //set SubCmd and  UsrData
      UsrData[0]=0x5A;UsrData[1]=0x5A;UsrData[2]=0x0a;// 10% limit
      size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, 
DTU_RADIO_ID >> 8, 0x51, UsrData,3);
    }
    else {
      UsrData[0]=0x0;//set SubCmd and  UsrData
      size = hmPackets.GetCmdPacket((uint8_t *)&sendBuf, dest >> 8, 
DTU_RADIO_ID >> 8, COMMAND, UsrData,1);
    }
   // DEBUG_OUT.print(F("size: ")); DEBUG_OUT.print(size);

    SendPacket(dest, (uint8_t *)&sendBuf, size);
    tel++;
    COMMAND++;
/*    for (uint8_t warte = 0; warte < 2; warte++) {
      delay(1000);
      hmPackets.UnixTimeStampTick();
    }*/
  } //if millis
}

[Günter H. (gnter_h534)]

Stefan T. schrieb:
> Ich würde daher empfehlen drei Plätze
> vorzusehen, für den Elko, für den Tantalum und einen für die Lötbrücke,
> am besten die Lötbrücke fest verdrahten zum raus-cuttern, wenn man die
> Elkos und/oder Tantalum einbaut.

Wenn die beschriebene Lötbrücke/Stelle zum Raus-Cuttern nur die 
Kondensatoren betrifft, braucht man das nicht vorzusehen: Bei 
Kondensatoren reicht bestücken oder nicht bestücken.

[Daniel R. (daniel92)]

Daniel R. schrieb:
> Das probiere ich Zuhause dann aus! =)

Habe ein HM-1500!

Folgende Antwort habe ich erhalten:
Transmit 16 | 15 74 40 33 29 78 56 30 01 80 5a 5a 05 70 ab 7a
Transmit 16 | 15 74 40 33 29 78 56 30 01 80 5a 5a 05 70 ab 7a
Received 27 bytes channel 3: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 
00 00 00 00 00 00 00 00 00 01 81 eb 9b

Edit:

Habe das ganze mal mit '\x5a\x5a\x01' (1% P-Limit?) gemacht.
Bekomme dann das hier, was könnte das alles sein?:

Poll inverter 116174403329
2022-06-21 15:49:21.612117 Transmit 16 | 15 74 40 33 29 78 56 30 01 80 5a 5a 01 b3 aa bc
2022-06-21 15:49:22.848184 Transmit 16 | 15 74 40 33 29 78 56 30 01 80 5a 5a 01 b3 aa bc
2022-06-21 15:49:22.888219 Received 27 bytes channel 75: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b
2022-06-21 15:49:23.391443 Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb
 payload has valid modbus crc
 payload has 14 bytes

Field view: int
Pos        0     1     2     3     4     5     6     7     8     9    10    11    12    13
Hex       80    00    00    00    00    00    00    00    00    00    00    00    00    01
>B       128     0     0     0     0     0     0     0     0     0     0     0     0     1

Field view: shorts
Pos        0     1     2     3     4     5     6     7     8     9    10    11    12    13
Hex       80    00    00    00    00    00    00    00    00    00    00    00    00    01
>H           32768           0           0           0           0           0           1
>H                     0           0           0           0           0           0

Field view: longs
Pos        0     1     2     3     4     5     6     7     8     9    10    11    12    13
Hex       80    00    00    00    00    00    00    00    00    00    00    00    00    01
>L                  2147483648                       0                       0
>L                                 0                       0                       0
>L                                       0                       0                       1
>L                                             0                       0
 type utf-8  : utf-8 decode error
 type ascii  : ascii decode error
Poll inverter 116174403329
2022-06-21 15:49:23.395573 Transmit 16 | 15 74 40 33 29 78 56 30 01 80 5a 5a 01 b3 aa bc
2022-06-21 15:49:23.441496 Received 27 bytes channel 75: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b

[IsnoAhoy (Gast)]

Hallo Ziyat T.,
Gratuliere zur MI-1500 Limitierung!

@Daniel R.,
Ziyat schickt ein Cmd 0x51, Du schickst nach wie vor ein 0x15 Cmd das 
kann also auch mit dem HM-1500 nur schiefgehen.

Und die Implementierung für HM-1500 etc. steckt wie für alle Hoymiles 
Generation 3 Geräte in der usart_nrf3.c, die die weiterhin genutzten 
Grundfunktionen der MI- und HM-Geräte der Generation 2 in usart_nrf.c 
erweitern / vervollständigen.
Lad den ganzen Code doch mal in VSCode oder einer anderen IDE Deines 
Vertrauens?

@Günther H.,
danke für die Korrektur! Irgendjemand schrieb was von Drahtbrücke 
einlöten. Aber so ein Kurzschluss zwisch +3V3 und GND ist natürlich 
elektronischer Blödsinn =^!

[Daniel R. (daniel92)]

IsnoAhoy schrieb:
> Ziyat schickt ein Cmd 0x51, Du schickst nach wie vor ein 0x15 Cmd das
> kann also auch mit dem HM-1500 nur schiefgehen.

Das ist mir auch aufgefallen, habe es dann korriegiert und erneut 
getestet.

Um denn WR in seiner Leistung zu drossel, sendet man ja folgenden Befehl 
ab:

              CMD                             (data )<value>
Transmit 16 | [51] 74 40 33 29 78 56 30 01 80 (5a 5a) <05> 70 ab 3e
Transmit 16 | [51] 74 40 33 29 78 56 30 01 80 (5a 5a) <05> 70 ab 3e
Received 27 bytes channel 75: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b
Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb

Nun wollte ich die Drosselung auslesen, jedoch kommt immer beim senden 
2b automatisch dazu (ohne mein willen)... Wieso?

              CMD                             (data ) <value?>
Transmit 15 | [d1] 74 40 33 29 78 56 30 01 80 (5a 5a) <2b> bb f0
Received 15 bytes channel 61: [d1] 74 40 33 29 74 40 33 29 80 (5a 5a) <2b> bb c1
Error while retrieving data: int too big to convert

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Daniel R. schrieb:
>> Das probiere ich Zuhause dann aus! =)
>
> Habe ein HM-1500!
>
> Poll inverter 116174403329
> 2022-06-21 15:49:23.395573 Transmit 16 | 15 74 40 33 29 78 56 30 01 80
> 5a 5a 01 b3 aa bc
> 2022-06-21 15:49:23.441496 Received 27 bytes channel 75: f1 74 40 33 29
> 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b
>
> [/code]

Wenn dein Inverter die SN 116174403329 hat, dann müsste dein Packet zum 
Senden etwa so sein:
WR= 29 33 40 74
DTU= 78 56 30 01 (nehme ich mal an)
Command= 51 für Limitierung (früher MID)
SubCommand= 5a 5a (früher CMD aber nur 1 byte!)
UserData= 05   (z.Bsp: 0x05 für 5%, HM geht nicht unter 2%)
ergibt CRC=90
51 74 40 33 29 78 56 30 01 5a 5a 0b 90

aber du schickst:
15 74 40 33 29 78 56 30 01 80 5a 5a 01 b3  ???
15 ist, glaube, ein MID für Timepacket, 80 CMD für WR-Data


wenn ok, dann bekommst du als Bestaetigung CMD = 0xD1

Hier nochmals wie bei mir:
Send... CH61 51:63:70:71:60:72:22:84:12:5a:5a:05:90:
Receive... 00 1284227201 0066 0C 3  D1 63707160 63707160 5A5AD1272F 1

Ich glaube, du musst das Senden für Command=0x51 sep. neu programmieren.

Die bisher verwendeten Bezeichnungen MID und CMD sind nun etwas 
unglücklich, denn es gibt viele Kontroll Befehle/Commands mit 
SubCommands und Userdata, wie die Limitierung eben.

[Herbert S. (herbert_s445)]

Hallo Zusammen,

ich verfolge seit einiger Zeit diesen Thread und bin beeindruckt von der 
Professionalität und was man mit einer guten Zusammenarbeit gemeinsam 
erreichen kann ...

Jetzt versuche ich das System (esp8266 und nRF24L01) zum Laufen zu 
bringen.
Aktuelle nutze ich Version 0.4.19
ich komme leider nicht weiter, denn ich bekomme die folgende 
Fehlermeldung:

W: WARNING! your NRF24 module can't be reached, check the wiring

I: [NTP]: 2022-06-20 23:14:32
I: Inverter #1 I: no Payload received! (retransmits: 0)
I: Requesting Inverter SN 116174401924
I: Transmit 27 | 15 74 40 19 24 78 56 34 12 80 0B 00 62 B0 FF 58 00 00 
00 05 00 00 00 00 7F EC 7C
E: while retrieving data: last frame missing: Request Retransmit
I: Transmit 27 | 15 74 40 19 24 78 56 34 12 80 0B 00 62 B0 FF 58 00 00 
00 05 00 00 00 00 7F EC 7C
pm open,type:2 0
E: while retrieving data: last frame missing: Request Retransmit
I: Transmit 27 | 15 74 40 19 24 78 56 34 12 80 0B 00 62 B0 FF 58 00 00 
00 05 00 00 00 00 7F EC 7C


folgendes habe ich schon versucht:
1) Tausch des NRF24 moduls
2) verschiedene Varianten der Verdrahtung (CE,CS,IRQ)
3) 10µF Kondensator zwischen GRND und 3,3V

Aber alles hat keinen Einfluss auf die Fehlermeldung.
Vielleicht kann mir jemand helfen, wäre doch schade, wenn ich kurz vor 
dem Ziel scheitere.

LG
Herbert

[Andreas Arp (Gast)]

...stärkeres Netzteil ?

[Ziyat T. (toe_c)]

@Daniel R.

Ziyat T. schrieb:
> WR= 29 33 40 74
> DTU= 78 56 30 01 (nehme ich mal an)
> Command= 51 für Limitierung (früher MID)
> SubCommand= 5a 5a (früher CMD aber nur 1 byte!)
> UserData= 05   (z.Bsp: 0x05 für 5%, HM geht nicht unter 2%)
> ergibt CRC=90

sorry, in dem Fall ist der CRC natürlich nicht 0x90, ich meinte nur als 
Bsp.

[Daniel R. (daniel92)]

Also ich bekomme es gerade nicht ganz hin...

Transmit 15 | 51 74 40 33 29 78 56 30 01 5a 5a 0b b4 2a f5

Statt letzten drei bytes, soll nur ein byte für CRC geschickt werden.
Aber irgendwie wird im Python code angehängt.

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Also ich bekomme es gerade nicht ganz hin...
>
> Transmit 15 | 51 74 40 33 29 78 56 30 01 5a 5a 0b b4 2a f5
>
> Statt letzten drei bytes, soll nur ein byte für CRC geschickt werden.
> Aber irgendwie wird im Python code angehängt.

- ist die CRC=0xb4 für  0x51 bis 0xb richtig?
- wurde die buffer len des Pakets zum Senden richtig übergeben?

[Daniel R. (daniel92)]

Genau da bin ich aktuell dran, aber ich finde nirgendwo eine Angabe wie 
lang das Paket seien soll. - Ich mach mal ein cut. Hab schon ewig nicht 
mehr mit Python mich ausseinander gesetzt.

Ziyat T. schrieb:
> - ist die CRC=0xb4 für  0x51 bis 0xb richtig?

Glaube ich nicht, da die CRC erst am ende angehängt wird.

Ziyat T. schrieb:
> - wurde die buffer len des Pakets zum Senden richtig übergeben?
von meiner Seite 'noch?' nicht.

Beim debuggen sehe ich das meine payload genau 3 bytes lang ist '5a 5a 
0b'.
Das passt. Nur der hintere Teil ist für mich gerade sehr gespenstig! :(

Der ganze Python script steckt ja noch in den Kinderschuhen.

Gruß

[SeekerBot (Gast)]

Hallo zusammen, ich möchte mich ganz herzlich für die tolle Arbeit 
bedanken! Ich nutze seit ein paar Tagen Ahoy-esp8266 mit einem HM1500 
und es war super easy einzurichten und alles scheint zu funktionieren.

Eine Frage: darf/soll ich in der Readme bei esp8266 den HM1500 ergänzen? 
In anderen Worten, ist die Datei veraltet oder gibt es einen Grund, 
warum ihr den HM1500 nicht aufführt?

Und ich kann sogar etwas beitragen: ich habe ein kleines Gehäuse 
entworfen für den 3D Drucker... die Dateien findet Ihr auf 
https://www.printables.com/model/229686-box-case-housing-for-wemos-d1-mini-and-nrf24l01-fo 
zum selber drucken, anpassen, drucken lassen... Und als Dankeschön von 
mir an alle Programmierer: wer hier beigetragen hat und so ein Gehäuse 
gerne hätte braucht sich nur zu melden. :)

Vielen Dank und Grüße

Seekerbot

[Stefan T. (isnoahoy)]

Hallo Daniel R.,

anbei nochmal ein Screenshot aus den RF_communication_protocol_v6.5.xlsx 
als Wink mit der Dokumentation des Herstellers.

Daniel R. schrieb:
> Genau da bin ich aktuell dran, aber ich finde nirgendwo eine Angabe wie
> lang das Paket seien soll. - Ich mach mal ein cut. Hab schon ewig nicht
> mehr mit Python mich ausseinander gesetzt.
>
> Ziyat T. schrieb:
>> - ist die CRC=0xb4 für  0x51 bis 0xb richtig?

Gute Frage Ziyat, die Antwort muß Daniel sich noch geben: Das ist auf 
jeden Fall um zwei Bytes zu lang!
51 74 40 33 29 78 56 30 01 5a 5a 0b b4 2a f5

So lang sollte es maximal sein und anstelle von 0xb4 muß da definitiv 
die richtige CRC-8 hin, sonst verwirft es der WR gleich wieder und 
antwortet mit nem Fehler:
<51>  <74 40 33 29> <78 56 30 01> <5a 5a>  <0b>  <b4>
<CMD> <WR Addresse> <DTU Adresse> <SubCmd> <10%> CRC8
1,2,3,4, ... 12 Bytes plus ein Byte CRC8.

Warum steht da bei Dir Daniel eigentlich 78 56 30 01 und nicht die sonst 
übliche DTU Addresse 78 56 34 12 ?

[Maik R. (bastelbarney)]

IsnoAhoy schrieb:
> Wenn
> ihr wollt kann ich auch noch ein Fritzing Schematic für NodeMCU und
> Raspberry Pi hochladen.

Das wäre sehr cool!

Ich habe meine NodeMCU auf einem freien Rest Breadboard 
zusammengesteckt, wobei die NodeMCU ja dann leider "unter" der Platine 
zu verdrahten ist (Fotos) weil sie zu breit für Breadboards ist. Die 
Kabelfarben zum nRF24 habe ich 1:1 übernommen, die waren im 
Wemos-Fritzing schon top gewählt! Aber die Drahtbrücken für das 
Breadboard hatte ich nicht in den nötigen Farben. Hier ging nur, was 
noch in der Kiste übrig war.

Vielleicht ist meine Fotosammlung eine Anregung für Zögerliche, endlich 
auch loszulegen? Ja, ja, Breadboard und Brücken sind unzuverlässig, ich 
weiss. Aber es läuft und nichts hält länger als ein Provisorium...

Der Breadboard-Aufbau läuft auch in kleinster Sendeleistung um eine 
Hausecke herum (Poroton und Klinker) und entweder durch die Panels oder 
um die Panels herum. Es sind ca. 10 m Entfernung zum HM-1500. und in 4 m 
Entfernung funkt noch ein DTU-WLite.
Allerdings benutze ich für die AHOY-nRF24 eine über 50 Jahre alte, 
hölzerne Statue zweier lokaler Superhelden ;-) vielleicht macht's das XD

[Stefan T. (isnoahoy)]

Hallo Herbert S.,

schau doch mal bitte im Github Issue #36 vorbei. Da diskutieren wir das 
bzw. ähnliche Probleme bei der Schaltung mit der ESP8266 Software.

ESP8266: Discussion Verkabelung / Pinout #36
https://github.com/grindylow/ahoy/issues/36

Das hier sagt eindeutig, daß er das NRF24 Modul nicht erreichen kann:
W: WARNING! your NRF24 module can't be reached, check the wiring

Die darauf folgenden anderen Versuche mit der fehlenden / falschen 
Konfiguration zu senden schlagen natürlich fehl.
Schau doch mal bitte im Setup Menü nach den dort hinterlegten Pin 
Einstellungen und speichere alles noch Mal. Eventuell muß man auch alle 
0xFF oder sonstigen Werte aus den anderen Feldern nochmal entfernen und 
die Settings speichern und den ESP rebooten (Flag ganz unten links).

Wichtig wäre auf jeden Fall welches ESP8266 Modul Du verwendest und 
welches nRF24L01+ Modul Du hast.

Vielleicht kannst Du dort auch mal Deine Schaltung und die Konfiguration 
(Screenshot aus der Setup Seite) hochladen ?

[Maik R. (bastelbarney)]

Ziyat T. schrieb:
> Richtig, in den Dokus hab ich auch nichts extra für HM gesehen, aber
> das Modbus-Doku beschreibt die gleiche Limitierung-Register für alle
> WR-Modelle, vielleicht geht es auch mit dem HM

Wie oben erwähnt, läuft mein HW-15000 mit AHOY / ESP8266 ver 0.4.19, 
selbst compiliert (nutze ohnehin gelegentlich ArduinoIDE oder VSCode) 
und ich kann gerne Patches oder andere Programme von Euch übernehmen und 
ausprobieren.

Habe ein Messgerät auf der Hutschiene, kann also recht schnell in echt 
sehen, was Änderungen bewirkt haben. Nur leider den RS485 am Stromzähler 
verplombt bekommen :,-(

Was ich mangels DTU-Pro nicht kann, ist sniffen, welche Kommandos der 
senden würde.

Abends zwischen 18:00 und Sonnenuntergang kann ich oft noch was testen.
Einfach bescheid sagen...

[Maik R. (bastelbarney)]

Herbert S. schrieb:
> Vielleicht kann mir jemand helfen, wäre doch schade, wenn ich kurz vor
> dem Ziel scheitere.

Ich nutze diese NodeMCU von AZ-Delivery (weil sie hier rumliegen):

"AZDelivery 3 x NodeMCU Lolin V3 Module ESP8266 ESP-12F WiFi WiFi 
Development Board mit CH340"

und

"NRF24L01+ PA LNA SMA" von Makershop.de.

Ganz primitiv auf einem Breadboard gesteckt, also eher "schlecht" 
verdrahtet, wenn man Bedenken bzgl. der Spannungsstabilität am NRF24 
hat.
(Fotos: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?")

Kein Elko, keine Tantalperle, keine separate 3V3 Versorgung!
CSN => D8
CE => D4
IRQ => D3
Sendeleistung auf Min oder Low (bei mir egal).

Lief sofort (nachdem ich ein Micro-USB-Kabel ausgewechselt habe, aber 
mit dem vorigen Kabel war schon der COM-Port in der Systemsteuerung und 
ArduinoIDE nicht sichtbar - also eher nicht das Problem, das Du hast). 
Habe damit ab und zu Falsch-Anzeigen und in der Statistik etwa 20% 
Fehler, aber läuft erstmal.

Vielleicht MOSI und MISO vertauscht?

[Stefan T. (isnoahoy)]

Hallo Maik R.,

>> Wenn ihr wollt kann ich auch noch ein Fritzing Schematic für NodeMCU und
>> Raspberry Pi hochladen.
> Das wäre sehr cool!

habe mal schematics und fritzing für Arduino, Raspberry Pi und ESP8266 
(NodeMCU) in mein github eingecheckt.

https://github.com/grindylow/ahoy/pull/80/commits/6015cbe0729ec13661a7229fdb15b90b587395d9

Mal sehen wann Lukas den PR mergen kann.

> Allerdings benutze ich für die AHOY-nRF24 eine über 50 Jahre alte,
> hölzerne Statue zweier lokaler Superhelden ;-) vielleicht macht's das XD

Ja die sind schick, nur leider sieht man auf dem Photo die Gesichter der 
Beiden nicht =^D

Hier im Anhang die Bildchen von meinem Aufbau mit NodeMCU. Auf meinem 
großen Breadboard passt der ESP gerade so zwischen zwei Reihen, daß noch 
bißchen mehr Platz für die Kabel übrig ist. Das ist ein echter Nachteil 
von dem Modul: der Platz auf dem Breadboard =^D

[Daniel R. (daniel92)]

Stefan T. schrieb:
> Gute Frage Ziyat, die Antwort muß Daniel sich noch geben: Das ist auf
> jeden Fall um zwei Bytes zu lang!
> 51 74 40 33 29 78 56 30 01 5a 5a 0b b4 2a f5

Richtig, das habe ich gestern auch so geschrieben. Vielleicht mit 
anderen worten (irgendwann sieht man den Wald vor lauter Bäumen nicht 
mehr => hab eine Pause gebraucht).


> So lang sollte es maximal sein und anstelle von 0xb4 muß da definitiv
> die richtige CRC-8 hin, sonst verwirft es der WR gleich wieder und
> antwortet mit nem Fehler:
> <51>  <74 40 33 29> <78 56 30 01> <5a 5a>  <0b>  <b4>
> <CMD> <WR Addresse> <DTU Adresse> <SubCmd> <10%> CRC8
> 1,2,3,4, ... 12 Bytes plus ein Byte CRC8.

Richtig, daran werde ich mich heute nochmal hinsetzen.

> Warum steht da bei Dir Daniel eigentlich 78 56 30 01 und nicht die sonst
> übliche DTU Addresse 78 56 34 12 ?

Ui, das ist ja Interessant! Ähm, hmm... auf der Seite 5 in diesem Thread 
war es noch richtig bei mir in der Log. Danke für denn Hinweis, ich 
werde mal drauf schauen. =)

Edit: Stimmt jetzt weiß ich es wieder! Hatte vorher das ganze in die 
'Home Assistant' eingebunden und zu Testzwecken habe ich den Wert 
geändert. Wahrscheinlich vor euphorie dann vergessen es wieder zu 
ändern. Hupps. ^^

[Herbert S. (herbert_s445)]

Hallo Stefan T.,

vielen Dank für die Hilfe. Habe das System mittlerweile am Laufen.  Ich 
hatte die Kabel für MISO und MOSI vertauscht.

LG

Herbert

[Daniel R. (daniel92)]

Hallo zusammen,
manchmal hilft es eine Nacht darüber zu schlafen. :)
Hab meinen Fehler gefunden... trotzdem keine Rückantwort.

WR= 74 40 33 29
DTU= 78 56 34 12
Command= 51
SubCommand= 5a 5a
UserData= 05   (z.Bsp: 0x05 für 5%, HM geht nicht unter 2%)
CRC= 72

Poll inverter 116174403329
2022-06-22 14:58:37.633634 Transmit 13 | 51 74 40 33 29 78 56 34 12 5a 5a 05 72
2022-06-22 14:58:38.870592 Transmit 13 | 51 74 40 33 29 78 56 34 12 5a 5a 05 72
2022-06-22 14:58:40.107719 Transmit 13 | 51 74 40 33 29 78 56 34 12 5a 5a 05 72

Laut Excel Protokoll gab es denn Befehl zum auslesen der eingestellen 
Leistung. - Das kam dabei bei mir heraus:

2022-06-22 15:07:10.486528 Transmit 12 | d1 74 40 33 29 78 56 34 12 5a 5a f7
2022-06-22 15:07:11.721448 Transmit 12 | d1 74 40 33 29 78 56 34 12 5a 5a f7
2022-06-22 15:07:11.760218 Received 12 bytes channel 61: d1 74 40 33 29 74 40 33 29 5a 5a d1

Ich lese das hierbei so: CMD | WR | WR | 5a 5a | CRC?

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Laut Excel Protokoll gab es denn Befehl zum auslesen der eingestellen
> Leistung. - Das kam dabei bei mir heraus:
>
> [code]
> 2022-06-22 15:07:10.486528 Transmit 12 | d1 74 40 33 29 78 56 34 12 5a
> 5a f7

Hallo Daniel
Nach meiner Lesung, es gibt keinen Befehl zum Auslesen der Limitierung.
Das command=0xD1 ist die Bestaetigung/Antwort auf 0x51.
Anfrage mit 0x51, Antwort drauf 0xD1, es wird immer bei der Antwort 
8.Bit gesetzt.

Also somit kannst du diesen Befehl nicht schicken:
> 2022-06-22 15:07:11.721448 Transmit 12 | d1 74 40 33 29 78 56 34 12 5a
> 5a f7
Wenn du ihn schickst, bekommst einfach ein Echo.

[Ziyat T. (toe_c)]

Limitierung:

Es ist mir noch was aufgefallen:
Send... CH61 51:63:70:71:60:72:22:84:12:5a:5a:05:90:
00 1284227201 0064 0C 2  D1 63707160 63707160 5A5AD1ADE9 1
51 cmd=D1

Die 0xD1 Antwort bekomme ich nur wenn ich das 0x51 über CH61 sende.
Ich muss es noch laengere Zeit beobachten....

[Daniel R. (daniel92)]

Ähm, ich schau mal ob es bei mir auch damit zusammen hängt mit CH61.

Ziyat T. schrieb:
> Nach meiner Lesung, es gibt keinen Befehl zum Auslesen der Limitierung.

Ahh glaube jetzt verstehe ich was das Protokoll in der Excel Tabelle 
meint, wenn ich denn Befehl abgeschickt wurde, bekommt man eine Quittung 
zurück. Die ist gleich wie der Befehl abgeschickt wurde, nur ohne 
SubCMD.


Edit: So, ich schicke es auf CH61 raus. Leider ohne erfolg. =(

Edit: Habe nun folgende CH durch probiert.
tx_channel_list = [3,23,40,61,75]

[Holger S. (skusi)]

Hallo zusammen,

ich habe das Platinen Layout nun um die Kondensator Möglichkeit und den 
Spannungsregler für den RF24 erweitert. Vielen Dank für die Hinweise und 
die Links zu den Erklärungen.

Bevor ich nun die Dingen fertigen lasse, macht mir noch Sorge das mein 
Prototype den ich auf einem Breadboard aufgebaut habe sehr häufig neu 
bootet. Auch nachdem ich nun den Spannungsregler und den Elko 100uF 
nachgerüstet habe schafft der Wemos keine langen UpTimes. Das längste 
waren so ca 6 Stunden.

Spannungsversorgung ist derzeit noch ein USB Netzteil

Liegt das an der Breadboard Verkabelung ?
Wie sind Eure Erfahrungen mit der UpTime ?

Glücklicherweise gehen ja bei einem reboot die Werte nicht verloren, 
aber das ja auch nicht so bleiben.

Sonst läuft alles recht reibungslos. Ich habe nur 3 fails bei meinen 3 
HM-300 Invertern. Diese kommen immer beim Booten zu Stande wenn die 
ersten Abfragen in lehre gehen.

[Stefan R. (rossiman)]

Hallo Leute,
beeindruckend was ihr hier macht und schon erreicht habt. Ich verfolge 
diesen Thread schon seit Beginn.
Nun habe ich mir das ahoy 0.4.19 bi binary auf einen ESP8266 geflashed. 
Zusammen mit einem NRF24L01+ Long Range mit Antenne hat das sofort 
funktioniert und läuft stabil. Vielen Dank an Euch.

Ich habe zwei HM-600 mit jeweils 2 PV Module und einen HM-300, den ich 
für einen Pufferspeicher einsetzen möchte. Derzeit verwende ich die 
Batterie meines Elektrorollers. Eine Leistungsbegrenzung des HM-300 wäre 
dafür perfekt.

Ich arbeite viel mit ESP8266 und Raspberry aber nur low-code. (ESPEasy, 
Tasmota, Node Red, FHEM, ..)

Wäre es möglich eine Version zu bauen, die über MQTT Raw Daten an die 
Wechselrichter sendet und empfängt? Ich könnte mich dann beim Testen 
beteiligen.

Grüße, Stefan

[Daniel M. (daniel_m821)]

Habe jetzt für den MI/TSUN das ganze soweit, dass ich:
- alle Pakete sehe
- immer wieder, noch unzyklisch, requests sende
- die Fehlermeldungen reduziert habe (wie auch immer das passiert ist)
- einen Teil der Payload des Inverter in die Payload übertragen bekomme
- den Teil der Payload angezeigt bekomme

Payload Inverter:

Received 18 bytes channel 75: 92 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 91 
Received 24 bytes channel 23: 91 63 50 03 16 63 50 03 16 01 44 00 15 09 52 13 8A 02 A0 07 DD 01 A5 DF 

Received 18 bytes channel 61: 88 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 8B 
Received 24 bytes channel 3: 89 63 50 03 16 63 50 03 16 01 3E 00 15 09 52 13 8A 02 9C 08 51 01 A5 02

Payload zusammengebaut:

Payload (32): 00 03 00 00 00 00 00 00 8B 01 3E 00 15 09 52 13 8A 00 03 00 00 00 00 00 00 91 01 44 00 15 09 52

Decode (auf Konsole):

17:34:13.185 -> I: Vordach/ch1/U_DC: 31.000 V
17:34:13.185 -> I: Vordach/ch1/I_DC: 4.600 A
17:34:13.185 -> I: Vordach/ch1/U_AC: 238.500 V
17:34:13.185 -> I: Vordach/ch1/Freq: 50.010 Hz
17:34:13.185 -> I: Vordach/ch0/U_AC: 238.500 V
17:34:13.219 -> I: Vordach/ch0/Freq: 50.010 Hz
17:34:14.222 -> I: Vordach/ch1/U_DC: 31.000 V
17:34:14.222 -> I: Vordach/ch1/I_DC: 4.600 A
17:34:14.222 -> I: Vordach/ch1/U_AC: 238.500 V
17:34:14.222 -> I: Vordach/ch1/Freq: 50.010 Hz
17:34:14.222 -> I: Vordach/ch0/U_AC: 238.500 V
17:34:14.222 -> I: Vordach/ch0/Freq: 50.010 Hz
17:34:15.193 -> I: Vordach/ch1/U_DC: 31.000 V
17:34:15.193 -> I: Vordach/ch1/I_DC: 4.600 A
17:34:15.193 -> I: Vordach/ch1/U_AC: 238.500 V
17:34:15.193 -> I: Vordach/ch1/Freq: 50.010 Hz
17:34:15.193 -> I: Vordach/ch0/U_AC: 238.500 V
17:34:15.193 -> I: Vordach/ch0/Freq: 50.010 Hz
17:34:16.227 -> I: Vordach/ch1/U_DC: 31.000 V
17:34:16.227 -> I: Vordach/ch1/I_DC: 4.600 A
17:34:16.227 -> I: Vordach/ch1/U_AC: 238.500 V
17:34:16.227 -> I: Vordach/ch1/Freq: 50.010 Hz
17:34:16.227 -> I: Vordach/ch0/U_AC: 238.500 V
17:34:16.227 -> I: Vordach/ch0/Freq: 50.010 Hz

hmDefines enum:

enum {INV_TYPE_1CH = 0, INV_TYPE_2CH, INV_TYPE_4CH, MI_INV_TYPE_1CH, MI_INV_TYPE_2CH, MI_INV_TYPE_4CH};

hmDefines Werte:

//MI-Version
    { FLD_UDC, UNIT_V,   CH1, 9, 2, 10   },
    { FLD_IDC, UNIT_A,   CH1, 11, 2, 10   },
    { FLD_UAC, UNIT_V,   CH1, 13, 2, 10   },
    { FLD_F,   UNIT_HZ,  CH1, 15, 2, 100  },
    { FLD_PAC, UNIT_W,   CH1, 17, 2, 10   },
    { FLD_YD,  UNIT_WH,  CH1, 19, 2, 1    },
    { FLD_T,   UNIT_C,   CH1, 21, 2, 10   },
    //{ FLD_YT,  UNIT_KWH, CH1, 24, 0, 1    },
    { FLD_IRR, UNIT_PCT, CH1, CALC_IRR_CH, CH1, CMD_CALC },

    { FLD_UDC, UNIT_V,   CH2, 34, 2, 10   },
    { FLD_IDC, UNIT_A,   CH2, 36, 2, 10   },
    { FLD_UAC, UNIT_V,   CH2, 38, 2, 10   },
    { FLD_F,   UNIT_HZ,  CH2, 40, 2, 100  },
    { FLD_PAC, UNIT_W,   CH2, 42, 2, 10   },
    { FLD_YD,  UNIT_WH,  CH2, 44, 2, 1    },
    { FLD_T,   UNIT_C,   CH2, 46, 2, 10   },
//    { FLD_YT,  UNIT_KWH, CH1, 24, 0, 1    },
    { FLD_IRR, UNIT_PCT, CH2, CALC_IRR_CH, CH2, CMD_CALC },

//    { FLD_UAC, UNIT_V,   CH0, 26, 2, 10   },
//    { FLD_IAC, UNIT_A,   CH0, 34, 2, 100  },
    { FLD_PAC, UNIT_W,   CH0, 17, 2, 10   },
    { FLD_T,   UNIT_C,   CH0, 21, 2, 10   },
    { FLD_PAC, UNIT_W,   CH0, 42, 2, 10   },
    { FLD_T,   UNIT_C,   CH0, 36, 2, 10   },
    { FLD_UAC, UNIT_V,   CH0, 13, 2, 10   },
    { FLD_F,   UNIT_HZ,  CH0, 15, 2, 100  }

Ich habe die Werte sowohl in einem eigenen Abschnitt als auch im 2-Kanal 
HM drin und wechsle die SN zwischen 1041 und 1141.

Die Erkennung im Webinterface für 10xx funktioniert mit meiner 
Modifikation leider nicht, mittlerweile bekomme ich auf allen 3 
möglichen Einträgen 4 Kanäle angezeigt, hier schaue ich noch.

Die Payload wird nicht so zusammengebaut, wie ich ich es erwartet habe, 
in den meissten Fällen kriege ich entweder die Event-Daten oder die 
Leistungsdaten und bei denen wird jedoch noch nach 3-4 Werten 
abgeschnitten.
Der erste Teil kommt meißt mit einer Länge 7 (statt 9) rein, der 2. wird 
mit 3 Werten angehängt, es fehlt ein Stück:

Received 18 bytes channel 75: 88 63 50 03 16 63 50 03 16 00 03 00 00 00 00 00 00 8B 

Received 24 bytes channel 3: 89 63 50 03 16 63 50 03 16 01 38 00 2C 09 3C 13 88 05 37 08 18 01 C0 D1 

Payload (7): 00 03 00 00 00 00 00 
Payload (15): 00 03 00 00 00 00 00 00 8B 01 38 00 2C 09 3C 
Payload (24): 00 03 00 00 00 00 00 00 8B 01 38 00 2B 09 3E 13 88 00 03 00 00 00 00 00

Zwischendurch klappt das auch mit dem 2. Kanal, das ist allerdings eher 
Glückssache.
Angezeigt/Dekodiert wird nur auf Kanal 1, egal welche Werte kommen.

Auswertung:

if(0 != len) {
                     Inverter<> *iv = mSys->findInverter(&p->packet[1]);
                     if(NULL != iv) {
                        uint8_t *pid = &p->packet[0]; //9
                         if(*pid == 0x88) { // A Event
                            DPRINTLN(DBG_INFO, F("A Event"));
                             memcpy(mPayload[iv->id].data[0], &p->packet[9], len-9);
                             //DBGPRINT(String('mPayload[iv->id].data[1]', HEX) + String("\n"));
                             mPayload[iv->id].len[0] = len-9; 
                         }
                         if(*pid == 0x89) { // A Data
                            DPRINTLN(DBG_INFO, F("A DATA"));
                             memcpy(mPayload[iv->id].data[1], &p->packet[9], len-16);
                             //DBGPRINT(String('mPayload[iv->id].data[0]', HEX) + String("\n"));
                             mPayload[iv->id].len[1] = len-16;
                         }
                         if(*pid == 0x91) { // B Event (or Data ?)
                            DPRINTLN(DBG_INFO, F("B DATA"));
                             memcpy(mPayload[iv->id].data[3], &p->packet[9], len-16);
                             mPayload[iv->id].len[3] = len-16;
                         }
                         if(*pid == 0x92) { // B Data (or Event ?)
                            DPRINTLN(DBG_INFO, F("B EVENT"));
                             memcpy(mPayload[iv->id].data[2], &p->packet[9], len-9);
                             mPayload[iv->id].len[2] = len-9;
                         }

                         if( (*pid == 0x88) || (*pid == 0x89) || (*pid == 0x91) || (*pid == 0x92) ) {
                              if((*pid == 0x88) && (mPayload[iv->id].maxPackId < 1)) { //1
                                 mPayload[iv->id].maxPackId = 1;
                                 mLastPacketId = *pid;
                              }
                              if((*pid == 0x89) && (mPayload[iv->id].maxPackId < 2)) { //3
                                mPayload[iv->id].maxPackId = 2;
                               // if(*pid == 0x89)
                                     mLastPacketId = *pid;
                              }
                              if((*pid == 0x91) && (mPayload[iv->id].maxPackId < 3)) { //2
                                mPayload[iv->id].maxPackId = 3;
                               // if(*pid == 0x91)
                                     mLastPacketId = *pid;
                              }
                              if((*pid == 0x92) && (mPayload[iv->id].maxPackId < 4)) { //4
                                mPayload[iv->id].maxPackId = 4;
                                mLastPacketId = *pid;
                                 }
                              }
                        } //iv
                    } //0 = len
[c/]

Die Antworten sind:
0x88 - A Event
0x89 - A Data
0x91 - B DATA
0x92 - B Event

Die Längen 9 bzw. 16 sind die gesamte Payload, die ich bekomme. Irgendwo sind für die Gesamtleistung noch ein High- und Low-bit versteckt, ich nehme an, das sind die letzten beiden, die mitgesendet werden. Mit der Bitverschiebung werde ich mich aber erstmal nicht beschäftigen. 

Den Invertertype in hmSystem.h habe ich etwas erweitert:
[c]
if(p->serial.b[5] == 0x11) {
                switch(p->serial.b[4]) {
                    case 0x21: p->type = INV_TYPE_1CH; break;
                    case 0x41: p->type = INV_TYPE_2CH; DPRINTLN(DBG_INFO, F("HM 2 Channel")); break;
                    case 0x61: p->type = INV_TYPE_4CH; break;
                    default: DPRINTLN(DBG_ERROR, F("unknown inverter type: 11") + String(p->serial.b[4], HEX)); break;
                }
            }
            else if(p->serial.b[5] == 0x10) {
                switch(p->serial.b[4]) {
                    case 0x21: p->type = MI_INV_TYPE_1CH; break;
                    case 0x41: p->type = MI_INV_TYPE_2CH; DPRINTLN(DBG_INFO, F("MI 2 Channel")); break;
                    case 0x61: p->type = MI_INV_TYPE_4CH; break;
                    default: DPRINTLN(DBG_ERROR, F("unknown inverter type: 10") + String(p->serial.b[4], HEX)); break;
                }
            }
            else
                DPRINTLN(DBG_ERROR, F("inverter type can't be detected!"));

Die Debug-Info taucht nur nirgends auf der Konsole auf, in debug.h ist 
debug als Level eingestellt. Ich weiß also nicht, ob der Part wirklich 
greift.

Am meissten Kopfschmerzen macht mir aktuell die unvollständige Payload 
und das nicht richtige dekodieren der Werte.
Ich habe zwischenzeitlich mit den maxPackId und mit den *pid 
verschiedene Varianten ausprobiert, keine führte zum Erfolg.

Was habe ich übersehen?

edit: Payload zusammenhängende Werte im Log gefunden

[Esp_loeter (Gast)]

Der Wemos D1 Mini liefert genug Strom für das NRF24 Modul.
Man braucht auch keinen Kondensator. Habe die 3.3V oszilloskopiert mit 
Trigger auf Spg.Abfall. —-> die 3.3V sind stabil

[Daniel R. (daniel92)]

Hallo Daniel M.,

erstmal Respekt! Schön das wir alle zusammen irgendwie voran kommen. :)
Bevor ich es vergesse, wäre es sinnvoll je nach Hersteller eine eigene 
Klasse zu erstellen. Oder?

- TSUN
- Hoymiles (MI,HM,...)

Für Arduino/ESP könnte es später etwas knapp werden mit dem Speicher, 
oder was meint Ihr dazu?


Ich schau mir mal dein Code an, da ich selbst kein TSUN habe kann ich 
nichts nachprüfen. Aber vielleicht kommt jemand später dazu. =)

@grindylow: Ich bin mir nicht 100% sicher, aber wäre es möglich im 
Github unter Project ein Backlog anzulegen damit man weiß was noch alles 
zu machen ist? - So kann man das ganze bisschen sauber führen. 8-)

z.B.: https://github.com/users/DanielR92/projects/2/views/1

Gruß Daniel

[Daniel M. (daniel_m821)]

Daniel R. schrieb:
> erstmal Respekt! Schön das wir alle zusammen irgendwie voran kommen. :)
> Bevor ich es vergesse, wäre es sinnvoll je nach Hersteller eine eigene
> Classe zu erstellen. Oder?
>
> - TSUN
> - Hoymiles (MI,HM,...)

Ja, zieht sich mit den Außenseitern und Altmodellen halt wie Kaugummi, 
aber solang es Spaß macht :)

Das mit den eigenen Klassen erstellem ist auf jeden Fall nötig. Wenn ich 
was lauffähiges habe, kann man das theoretisch vereinzeln, bis dahin ist 
es für mich einfacher.
Ich bin kein Softwareentwickler und weiß nicht, was ich tue, also 
versuchen zu verstehen, modifizieren und schauen, was passiert (der 
Compiler hasst mich mittlerweile).

>
> Für Arduino/ESP könnte es später etwas knapp werden mit dem Speicher,
> oder was meint Ihr dazu?

Jep, das wird definitiv eng.

>
> Ich schau mir mal dein Code an, da ich selbst kein TSUN habe kann ich
> nichts nachprüfen. Aber vielleicht kommt jemand später dazu. =)

TSUN/MI sind Baugleich in der Kommunikation.
Falls du (oder wer anderes) willst, kannst du auch per Anydesk direkt 
bei mir schauen. Macht das Debuging wahrscheinlich einfacher.

Ein Kollege hat sich jetzt einen HM1500 bestellt, an dem werd ich Ahoy 
ausprobieren :)

[Daniel R. (daniel92)]

Hi Daniel M.,

habe selbst ein HM-1500. Es läuft schon ziemlich stabil bei mir. Arbeite 
hier direkt mit einem Raspberry statt ESP. Ich kann schnell denn Code 
ändern ohne immer alles neu zu kompilieren und zu warten bis es auf dem 
ESP läuft. :)

Ich hatte schon früher die Idee mit discord, habe es aber nicht 
angesprochen. Da jeder auch seine "Freizeit" hat und man eher selten 
wahrscheinlich zusammen kommt um gemeinsam dran zu arbeiten.

[Holger S. (skusi)]

So, hab mal den Abend damit verbracht mein Layout als Einzelstück zu 
fertigen. Dabei hab ich dann auch den Tipp mit dem Abschirmen des RF 
Moduls umgesetzt. Mit einem Schrumpfschlauch und etwas Alu Klebeband 
ging das ganz gut. Morgen werde das Ganze in das Gehäuse einbauen und 
die Version gegen meinen Breadboard Aufbau tauschen. Mal sehen wie sich 
das dann mit den Reboots verändert.

Hier mal ein paar Impressionen:

[Richard K. (laserrichi)]

Esp_loeter schrieb:
> Der Wemos D1 Mini liefert genug Strom für das NRF24 Modul.
> Man braucht auch keinen Kondensator. Habe die 3.3V oszilloskopiert mit
> Trigger auf Spg.Abfall. —-> die 3.3V sind stabil

das klingt ja gut, auch mit max. Sendeleistung ?

wieviel mV hattest du den Trigger ?

[ESP_loeter (Gast)]

Richard K. schrieb:
> Esp_loeter schrieb:
>
>> Der Wemos D1 Mini liefert genug Strom für das NRF24 Modul.
>> Man braucht auch keinen Kondensator. Habe die 3.3V oszilloskopiert mit
>> Trigger auf Spg.Abfall. —-> die 3.3V sind stabil
>
> das klingt ja gut, auch mit max. Sendeleistung ?
> wieviel mV hattest du den Trigger ?

Trigger stand auf 3.2V, Sendeleistung auf Max.

[Daniel R. (daniel92)]

@skusi: Nicht schlecht. :)

[Ziyat T. (toe_c)]

MI-1500 Limitierung:

Limitierung mit absolut Wattzahl funktioniert auch, hier z.B. 500W 
Limit:

Send... CH61 51|63707160|72228412|5A5A|64|1388|6A
Command|WR|DTU|SubCommand|100%|500W|CRC

510.9W PV:2 123.2W 42.9V 2.9A 304.0Wh 227.3V 50.0Hz 52.5C  Sts:3 FCnt:0
510.9W PV:3 253.4W 39.2V 6.7A 474.0Wh 226.7V 50.0Hz 52.4C  Sts:3 FCnt:0
510.9W PV:4 0.5W 39.2V 0.0A 2.0Wh 226.7V 50.0Hz 52.4C  Sts:3 FCnt:0
511.0W PV:1 133.9W 42.9V 3.2A 304.0Wh 226.2V 50.0Hz 52.5C  Sts:3 FCnt:0

[Daniel R. (daniel92)]

Hi Ziyat T.,

das ist sehr cool. :D
Natührlich super für die MI-Nutzer da hier die Dokumente vorhanden sind.

Ich nutze ein HM, da hat es leider nicht funktioniert.

Wobei, ich glaube ich kenne nun mein Fehler!
Die Watt anzahl muss noch mit 10 multipliziert werden. Korrekt?
Zusätzlich frage ich mich, die Prozent Angabe die sagt eigentlich was 
aus?
Ich dachte hier trägt man von zb. 1500W nur 10% ein um dann 150W zu 
erhalten.

Bei dir steht es weitherhin auf 100%, jedoch im nächste Byte 500W.
Ich bin da etwas verwirrt.^^

Das heißt ich müsste folgendes senden:
value = 10(%) * 10 => 100 = 0x00 0x64
value = 50(%) * 10 => 500 = 0x01 0xF4
value = 75(%) * 10 => 750 = 0x02 0xEE
...

Transmit 14 |  [51] [74 40 33 29] [78 56 34 12] [5a 5a] [xy%] [val|val] 
CRC

Kann das jemand von HM-Nutzer bestätigen (bin aktuell nicht Zuhause)?


Danke für die Infos vorab! :)

[Günter H. (gnter_h534)]

Esp_loeter schrieb:
> Der Wemos D1 Mini liefert genug Strom für das NRF24 Modul.
> Man braucht auch keinen Kondensator. Habe die 3.3V oszilloskopiert mit
> Trigger auf Spg.Abfall. —-> die 3.3V sind stabil

Gut, dass das einmal gemessen wurde.

Leider gibt es nicht den Wemos D1 mini. Siehe z. B. :
https://github.com/bbqkees/Wemos-the-Clone-Wars/blob/master/README.md

Zum Thema "reboot": Es gibt Hinweise, dass bei manchen Clones der 
verbaute Spannungsregler der Grund für häufiges Rebooten ist.
(Quelle: https://www.letscontrolit.com/forum/viewtopic.php?t=6603)

Das könnte das unterschiedliche Verhalten in Bezug auf Rebooten bei den 
verschiedenen Usern sein.

@Holger S.
Sehr kompaktes Layout.
Einige Anmerkungen:
- Den 3.3V-Spannungsregler weiter vom AC-Eingang weg platzieren, der 
Abstand zwischen AC-Eingang und der übrigen Schaltung erscheint mir sehr 
klein zu sein. Besonders dann, wenn eine externe Antenne geplant ist.
- Datenblatt HiLink_3W_Power_Supply Seiten 7-8, Kap. 8 "Typical 
Application Circuit". Dort ist ausgeführt: "Fuses and varistors are the 
basic protection circuits (required)" sowie "For certification, safety 
capacitors and common mode inductors cannot be omitted". (Danke an den 
Google-Übersetzter)

[Ziyat T. (toe_c)]

Hallo Daniel R.

Variante mit %:
[51] [74 40 33 29] [78 56 34 12] [5a 5a] [xy%] CRC

Variante mit abs(Watt*10, 1 dec):
[51] [74 40 33 29] [78 56 34 12] [5a 5a] [100%] [val=P-lo|val=P-hi] CRC
Ich glaube hier wird 100% ignoriert.

hier 1388=500,0W
Send... CH61 51|63707160|72228412|5A5A|64|1388|6A

Das mit der Prozentzahl ist sehr mühsam.
Ich steuere meine DTU-Pro über Modbus(zero export), dort geht es nur mit 
Prozent.
Mann muss die angeschlossene PVs Total P als 100% betrachten.
Ich habe den MI-1500 aber nur 3PVs mit je 450W brutto, total bekomme ich 
(gemessen mit Verlust) etwa 1100W unter "meine" Sonne am Sommer/Mittag. 
Produktion ist nicht linear, darum habe ich eine Tabelle:
100%  1100
90%  1050
80%  996
70%  900
60%  820
50%  750
45%  700
40%  610
30%  460
25%  380
20%  310
17%  261
15%  230
13%  200
12%  182
11%  170

[Ziyat T. (toe_c)]

@Günter H.
@Holger S.
@Esp_loeter
Ich habe auch mal mit Wemos1 und NRF24L01 + PA + LNA/Antenne probiert.
Bei 3 versch. nrf24 Modulen, konnte ich nur mit einem senden und 
empfangen, die anderen 2 nur empfangen? Ich dachte zuerst an 
Spannungsproblem.
Allerdings, die 2 Module hatte ich lange mit RF24_PA_MAX betrieben, 
danach ging auch das ESP kaputt..

[Daniel R. (daniel92)]

Ziyat T. schrieb:
> Mann muss die angeschlossene PVs Total P als 100% betrachten.

Vielen Dank für die Infos.
Ok das ist auch sehr Interessant.

Ich würde sagen, jetzt kann es langsam dran gehen den ganzen Code sauber 
zu machen und die ersten Klassen zu generieren? :)

Um für die User mit ESP/Arduino speicher zu sparen, wäre die Frage ob 
man alle Kombination (HM/MI/TSUN/...) unter einem Hut bringen kann. Oder 
ob es sogar Notwendig ist diese zu splitten?

Ich hoffe man bekommt alles unter. Wobei ich denke hier muss man das 
ganze anders heran gehen.

Frage an alle: kann man mittels der S.Nr herausfinden um welchen WR es 
sich handelt (Marke, Typ?)

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Ich würde sagen, jetzt kann es langsam dran gehen den ganzen Code sauber
> zu machen und die ersten Klassen zu generieren? :)

Da bin ich gespannt;-)
HM und MI haben völlig andere Tx/Rx-Message Struktur und Polling, so wie 
ich beurteilen kann, bisherige SW sind alle auf HM zugeschnitten. Habe 
mal versuch den MI in die HM-SW zu integrieren, geht nicht so einfach, 
ich konnte nicht, habe aufgegeben, und das ist echt schade.

[Daniel R. (daniel92)]

Ich meine das sollten wir hinbekommen.
Wäre es möglich das du deine Änderung als MI-Version irgendwie hier 
bereitstellen könntest?

Ich bin nähmlich dabei erstmal ein UML aufzustellen. Finde ich erstmal 
einfacher, damit jeder weiß wie es später aussehen könnte. :)

Was meint ihr dazu?

[Günter H. (gnter_h534)]

Daniel R. schrieb:
> Frage an alle: kann man mittels der S.Nr herausfinden um welchen WR es
> sich handelt (Marke, Typ?)

Hier

https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx

wurden vor zwei Monaten Typen und Seriennummern zusammengestellt.

[Daniel R. (daniel92)]

Danke.

Ich hab zwecks UML angefangen, aber konnte kein gutes Tool/Designer 
findet indem man das ganze schön Darstellen kann.

Hab mal ganz grob denn Anfang gemacht. Ich schau mir gerade von Gitee 
noch deren Klassen durch wie Sie das gelöst haben.

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> Ich meine das sollten wir hinbekommen.
> Wäre es möglich das du deine Änderung als MI-Version irgendwie hier
> bereitstellen könntest?

Deise SW ist orig. vom Hubi, ich habe für den MI-1500 abgaendert und als 
Arbeits-/Debug-SW zu verstehen.
Nur für ArduinoUno.

[Thomas B. (tbnobody)]

Hallo zusammen,

ich habe auch begonnen Firmware für den ESP32 zu schreiben.
Es ist in der aktuellen Form schon komplett funktionsfähig und läuft 
stabil (NodeMCU32 + NRF24 mit zusätzlichem 10uF Kondensator).

Vielleicht kann man da auch Anregungen für eine Klassenstruktur finden. 
Ich habe versucht die Hoymiles Implementierung eigenständig als Library 
zu gestalten.
Die Web GUI ist in Vue.js geschrieben und wird zur Firmware Binary 
hinzugelinkt. Bei dieser aufwändigeren Projektstruktur und auch zwecks 
Dependency Verwaltung eignet sich die Arduino IDE hiefür natürlich nicht 
mehr. Das Projekt basiert auf PlatformIO.

Es gibt noch etliche Stellen die nicht perfekt sind, einer 
Implementierung oder einer Überarbeitung bedürfen. Aber ich wollte 
erstmal was lauffähiges haben.
Das Repo wäre hier zu finden: https://github.com/tbnobody/OpenDTU
Im docs Ordner gibt es auch ein paar Screenshots der WebGUI.

In nächster Zeit (ggf. heute Abend) wird es noch ein paar "Breaking 
Changes" geben was die Namen der MqTT Topics anbelangt.
Die Payload Erzeugung habe ich auch schon in die Inverter Klassen 
verlegt. Dies ist jedoch mangels Test noch nicht commited.

Über Anregungen und/oder PRs würde ich mich freuen.

Grüße
Thomas

[John P. (brushlesspower)]

Günter H. schrieb:
> Daniel R. schrieb:
>> Frage an alle: kann man mittels der S.Nr herausfinden um welchen WR es
>> sich handelt (Marke, Typ?)
>
> Hier
>
> https://github.com/grindylow/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx
>
> wurden vor zwei Monaten Typen und Seriennummern zusammengestellt.

Wenn man mal quer ließt:

HM beginnt mit 11
MI beginnt mit 10

250 Watt -> xx20
300 bis 400 Watt  -> xx21
500 Watt -> xx40
600 bis 800 Watt -> xx41
1000 Watt -> xx60
1200 bis 1500 Watt -> xx61

[Stefan R. (rossiman)]

Hallo Thomas,
stark, dass du das angehst. Sobald du jemanden zum Testen benötigst kann 
ich helfen. Ich habe einen HM300 und zwei HM600 im Einsatz. Die Ahoy 
0.4.19 funktioniert bei mir 100% stabil ohne Kondensator.
Grüße, Stefan

[John P. (brushlesspower)]

Hallo Thomas,

habe dein ESP32 Projekt ausprobiert.

Soweit hat alles funktioniert, vielen Dank. Dann brauche ich keinen 
ESP8266 bestellen sondern kann einen der vielen ESP32 nehmen.

Leider habe ich grad keinen WR hier, daher kann ich nicht vollständig 
testen.

[Daniel R. (daniel92)]

Hallo Thomas,

ja das sieht schonmal stark aus. =)
Ich bin aktuell nicht Zuhause. Habe zum testen ein HM-1500.

Würde es mir anschauen, aufjedenfall wäre es Klasse wenn man alle 
Hoymiles + TSUN in einem Paket bekommt und somit eine breite Maße 
abdecken kann.

Ich weiß nicht wie groß der Flash ist, aber meine das der ESP32 größer 
ist. Daher sollte das passen oder?

Jetzt kommt aber die Master frage: zwei Githubs zu pflegen macht kein 
Sinn, beide sind soweit ich es sehe (Ahoy habe ich selbst schon 
getestet) soweit ganz gut. Nur welche sollte man für die Zukunft 
pflegen?

Ahoy ist soweit ich weiß sehr aktiv und hat aktuell ein großen Andrang.
Was meint ihr?

Gruß

[Stefan R. (rossiman)]

Nur ein Projekt würde schon besser sein, aus meiner Sicht. Ich würde 
mich über die Implementierung der Leistungsbegrenzung mittels MQTT 
freuen. Wenn der ESP32 besser geeigne ist, dann werde ich mir einen 
kaufen. Die GUIs von Thomas sehen schon gut und konsistent aus. 
Allerdings benötigt der ESP32 3 mal so viel Strom als der ESP8266.
Vielleicht könnten sich die Hauptentwickler dazu abstimmen.
Stefan

[Daniel R. (daniel92)]

Hallo Stefan,

jetzt kann man das noch nicht sagen welches der bessere ist.
Ich glaube es wird sich mit der Zeit zeigen.

Je nach dem wie wir alle zusammen das Projekt programmieren (auf 
effizient getrimmt) desto weniger Speicher wird dafür benötigt.

Auch hier wäre es eventuell Sinnvoll vielleicht auf einige Libarys die 
alles aufblähen raus zu schmeisen. Oder?

Ich behaupte jetzt erstmal das man am ESP8266 bleiben kann. ;)

[Thomas K. (Gast)]

Hallo alle zusammen,

ich verfolge die aktivitäten hier schon seit einer Woche.
Hut ab vor den hier erbrachten Leistungen.

ich habe beide Programme (hubi und Ahoi) mit einem ESP8266 am laufen.
habe lediglich aus früheren Versuchen einen 10uF Kondensator an dem NRF 
Modul.

Diese hier beschriebenen Abstürze bzw. Reboots des ESP konnte ich bis 
jetzt noch nicht beobachten. allerdings habe ich in der Vergangenheit 
schon öfter feststellen müssen, das ein "Handyladegerät" ungeeignet ist 
um  Funkgeschichten mit Strom zu versorgen.
Bei mir hängt das meistens zum testen am Laptop oder einer ähnlichen 
Stromquelle bei der der PE angeschlossen ist, wie weiter oben schon 
erläutert.

ich bin auch brennend an einer Lösung zur Leistungsbegrenzung  des 
HM-600 interresiert.

ich habe die ganze Zeit vergeblich versucht, auf der DC Seite den Strom 
mit einem PWM DC-Wandler zu begrenzen. das funktioniert aber nicht so 
toll, da der MPPT- Tracker mit dem Steilen abfallen der Spannung nicht 
zurecht kommt.

[Richard K. (laserrichi)]

Thomas K. schrieb:
> Diese hier beschriebenen Abstürze bzw. Reboots des ESP konnte ich bis
> jetzt noch nicht beobachten. allerdings habe ich in der Vergangenheit
> schon öfter feststellen müssen, das ein "Handyladegerät" ungeeignet ist
> um  Funkgeschichten mit Strom zu versorgen.
> Bei mir hängt das meistens zum testen am Laptop oder einer ähnlichen
> Stromquelle bei der der PE angeschlossen ist, wie weiter oben schon

So toll Schaltnetzteile auch sind vom Wirkungsgrad, haben sie eben auch 
durch die Taktung von einigen 10khz bis einigen 100khz leider auch viel 
Schmutz auf den Leitungen.
Oberwellen, Interferenzen usw... alles wird getaktet und das sorgt für 
Probleme.

Ich hatte einen wemos d1 mini versucht mit einem Blitzsensor as3935 zu 
betreiben und bin kläglich gescheitert, der ESP hatte einfach zu sehr 
gestört und mit noch so gut gefilterten Spannungsversorgungen und 
Abschirmungen ging es einfach nicht. Denn die Blitzerkennung läuft mit 
500khz Band und Ferritkern Spule als Antenne.

Die Abschirmung die skusi hier auf seinen Bildern gezeigt hat finde ich 
sehr gut, ich werde das auch mal umsetzen um zu sehen ob ich dann auch 
mit max. Power senden kann, denn das geht bei mir ungeschirmt nicht ohne 
massenhafte Funkfehler.

[Richard K. (laserrichi)]

Nachtrag:

die Abschirmungsmethode die Holger S. (skusi) hier auf seinen Fotos 
zeigt ist perfekt !!!
Ich habe es soeben umgesetzt und kann von min low high bis max mit allen 
Einstellungen sauber Senden und Empfangen, auch ohne extra Kondensator 
und Versorgungsspannung.

[Daniel M. (daniel_m821)]

Daniel R. schrieb:
> Danke.
>
> Ich hab zwecks UML angefangen, aber konnte kein gutes Tool/Designer
> findet indem man das ganze schön Darstellen kann.
>
> Hab mal ganz grob denn Anfang gemacht. Ich schau mir gerade von Gitee
> noch deren Klassen durch wie Sie das gelöst haben.

Hi,

das ganze ist soweit gut, allerdings brauchst du für TSUN nichts extra 
machen, TSUN ist ein umgelabelter MI. China standart Copy+Paste. Du 
kannst also MI/TSUN als Klasse machen :)

[Ralf B. (ralf_b210)]

Moin,

hm.. warum gibt es ein so großes Interesse darin den WR zu begrenzen ?
     Ist ein 2ER Zähler verbaut ist alles ok (Überschuss wird 
verschenkt)
     Da sollte man seine Energie inwestieren warum das so  ist.
     Ist ein alter Feraris verbaut dreht der rückwärts (doppelt 
gespart).

[Thomas K. (Gast)]

Hallo Ralf

das problem ist, dass bald keiner mehr einen "alten" Zähler hat.
Der überschüssige Strom, der tagsüber (für lau) ins Netz gespeist würde, 
lässt sich aber auch bequem in einem Akku Speichern und dann findet 
dieser z.B. nachts noch seine Verwendung, um die Grundlast zu decken.

Bei mir zum Beispiel ist die Grundlast den ganzen Tag irgendwo zwischen 
150 und 230 Watt.

Ich habe Aktuell 4 Solarpanels mit mit je 370Watt --> also quasi 1480Wp
diese Energie speise ich in einen LiFePo4 Akku mit 4,4kWh Kapazität ein.
Parallel dazu, soll ein Wechselrichter davon die ca.200W für die 
Grundlast einspeisen.

Der Rest wird in den Akkus für die Nacht gespeichert.
Wenn ich mich nicht verkalkuliert habe, müsste der Akku dann die 16 
Stunden überbrücken können in denen die Sonne nicht scheint.

Um die Energie nicht zu Verschwenden (bzw. dem Netzbetreiber zu 
schenken) wollte ich meinen Shelly 3EM auslesen und den Wechselrichter 
auf
NULL EINSPEISUNG einregeln.

[Ben (Gast)]

Hallo Zusammen,

Ich bin neu im Club und habe heute meinen HM-600 erhalten. Er hängt 
aktuell noch an eine Fritz Steckdose, deshalb weiß ich, dass auch 
fleißig produziert wird.
Ich habe mir auch bereits einen Wemos D1 Mini mit NRF… geholt, verkabelt 
und die Software aufgespielt. WLAN ist verbunden, MQTT connected und der 
Inverter ist ebenfalls verbunden.
Aber jetzt gehen die Probleme los:

1. Inverter ‚Hm600‘ is availabe and is not producing. -> Tut er aber 
nachweisbar.

2. MQTT Probleme
New connection from das.ist.meine.ip on port 1883
New client connected from das.ist.meine.ip as AHOY-DTU (c1, k15, 
u‘mqtt‘).
Client AHOY-DTU has exceeded timeout, disconnecting

3. Die GUI auf dem Wemos D1 ist extrem langsam.

Hat jemand ein paar Tipps für mich?

AHOY Version 0.4.19
NRF24L01+ Platine mit externer Antenne
MQTT Version 1.5.7 (läuft seit Jahren problemlos auf einem RPI)

Viele Grüße
Ben

[Petra R. (petra-kathi)]

Hallo Thomas,

> Der überschüssige Strom, der tagsüber (für lau) ins Netz gespeist würde,
> lässt sich aber auch bequem in einem Akku Speichern und dann findet
> dieser z.B. nachts noch seine Verwendung, um die Grundlast zu decken.

Hier möchte ich mich mal kurz einklinken, weil ich das mittelfristig 
auch gerne so machen würde. Allerdings fehlt mir ein wenig die 
Vorstellung, wie das regelungstechnisch ablaufen soll und wie das (um 
wieder zum hiesigen Thema zurückzukommen) über die Ansteuerung eines 
Wechselrichters (hier: HM-1500 mit 3 Panels) zu organisieren wäre?

Konkret: Wie müsste die Ansteuerung erfolgen, wenn bei überschüssiger 
Produktion der Akku geladen werden soll? Ich begreife noch nicht, wie 
der Wechselrichter definiert, wohin der produzierte Strom denn nun 
gehen soll. Bzw., wie der Akku merken soll, dass er bitteschön gerade 
laden soll?

Wenn das hier am Thema vorbei sein sollte: Gerne auch Erhellung per 
Linknennung!  ;-)

Hier läuft seit ca. 2 Monaten eine leicht modifizierte Version eines 
älteren Ahoy.py auf 'nem Raspi, die auch noch nie Probleme mit dem 
Strombezug des NRF24+ hatte. Allerdings reicht bei mir die schwächste 
Sendeleistung aus.

Tschüssi,
Petra

[Ziyat T. (toe_c)]

Ralf B. schrieb:
> Moin,
>
> hm.. warum gibt es ein so großes Interesse darin den WR zu begrenzen ?
>      Ist ein 2ER Zähler verbaut ist alles ok (Überschuss wird
> verschenkt)
>      Da sollte man seine Energie inwestieren warum das so  ist.
>      Ist ein alter Feraris verbaut dreht der rückwärts (doppelt
> gespart).

Hallo
Weil es nicht überall auf dieser Welt die Rückspeisung so handgehabt 
wird wie in Deutschland, darum darf/muss ich NULL einspeisen.

[Daniel R. (daniel92)]

Daniel M. schrieb:
> China standart Copy+Paste

Stimmt da hast du recht. :)

[Ziyat T. (toe_c)]

Petra R. schrieb:
> Wenn das hier am Thema vorbei sein sollte: Gerne auch Erhellung per
> Linknennung!  ;-)
>
Bitte nicht hier ;-)
Aber hier gibts tonnenweise
https://www.facebook.com/groups/170429543515117/

[Ziyat T. (toe_c)]

@Stefan R. (rossiman)
@Daniel R. (daniel92)
Bei dem Thema Wemos1/esp8266 ist mir das noch aufgefallen:
Wenn jemand den WR steuern möchte, muss man  die Leistung (+/-) beim 
Zaehler über Modbus abfragen, dazu brauchts neben dem nrf24 noch ein 
RS485-Modul an Wemos1, dann fehlt genau ein pin beim Wemos1.

[Daniel R. (daniel92)]

Ziyat T. schrieb:
> Wenn jemand den WR steuern möchte, muss man  die Leistung (+/-) beim
> Zaehler über Modbus abfragen

Naja kommt drauf an wie man das realisieren möchte.
Mir würde es reichen wenn man via MQTT das ganze realisieren. Da ich es 
via Raspberry nutze. Klar der Zähler ist auch via Modbus/S1 Angebunden. 
Denn würde ich jedoch auch direkt am Pi verbinden.

Wir wissen ja nicht wie die gegebenheiten sind. Ich behaupte mal das 
jeder ein Zähler direkt am UV(Unterverteiler) haben und von dort dann 
weiter verarbeiten. :)

> Zaehler über Modbus abfragen, dazu brauchts neben dem nrf24 noch ein
> RS485-Modul an Wemos1, dann fehlt genau ein pin beim Wemos1.

NRF24 läuft doch über SPI und wenn man einen 'MAX3140' Wandler nutzt, 
kann man auch via SPI kommunizieren.  Somit fehlt uns kein Pin mehr. =)

[Daniel M. (daniel_m821)]

Daniel R. schrieb:
> Mir würde es reichen wenn man via MQTT das ganze realisieren. Da ich es
> via Raspberry nutze. Klar der Zähler ist auch via Modbus/S1 Angebunden.
> Denn würde ich jedoch auch direkt am Pi verbinden.
>
> Wir wissen ja nicht wie die gegebenheiten sind. Ich behaupte mal das
> jeder ein Zähler direkt am UV(Unterverteiler) haben und von dort dann
> weiter verarbeiten. :)

MQTT ist eine gute Idee. Modbus via einem weiteren Pfennig-Wemos mit 
RS458-Schnittstelle ist keine Raketenwissenschaft.
Ich hab z.B. SDM630 als zentralen Zähler direkt nach dem vom Versorger 
sowie für alle 3 Etagen einen extra, für Garage, Nebenanlagen und die 
Wallbox.
Insgesamt also 7 Stück, wo ich mit Modbus rankomme.

Hier ist es langfristig das Ziel, die Energieflüsse zu messen und 
Verbräuche zu erfassen.

Wäre später interessant, die abzufragenden Register (im Quellcode) 
konfigurieren zu können oder vllt verschiedene Profile für die gängigen 
Zähler/Messgeräte zu haben.

S1 kann man machen, finde ich aber zu ungenau. Wenn du es sowieso per 
Raspi hast, ist es kein Problem.

[Daniel R. (daniel92)]

S1 habe ich nur mit reingenommen, da es vielleicht jemand da draußen 
gibt der ein Zähler schon verbaut hat und nicht noch extra was 
Invenstieren möchte. :)

Die Register vom deinem Zähler sind im Datenblatt zu finden. :)
https://bg-etech.de/download/manual/SDM630Register1-5.pdf

daher kein Problem die Daten weiter zu vearbeiten.

[Daniel M. (daniel_m821)]

Daniel R. schrieb:
> S1 habe ich nur mit reingenommen, da es vielleicht jemand da draußen
> gibt der ein Zähler schon verbaut hat und nicht noch extra was
> Invenstieren möchte. :)

Verständlich, zumal die Zähler gerade schwierig zu bekommen sind.
S1 wäre aber, meiner Meinung nach, nur eine Zwischenlösung. Wer das 
macht wird früher oder später neugieriger werden. PV macht einfach 
süchtig.

> Die Register vom deinem Zähler sind im Datenblatt zu finden. :)
> https://bg-etech.de/download/manual/SDM630Register1-5.pdf
>
> daher kein Problem die Daten weiter zu vearbeiten.

Weiß ich :)
Es gibt noch andere Varianten von Janitza, Finder, Eltako, Victron und 
Co, die alle irgendwie anders belegt sind. Falls noch Platz im Code ist, 
könnte man hier für die üblichen Verdächtigen schon fertige Belegungen 
hinterlegen.

Meine 7 Stück wollen irgendwie nicht zusammen auf einer Leitung laufen, 
nach einer gewissen Zeit rebooten die und springen im Zählerstand ein 
Stück zurück, Eastron zuckt mit den Schultern und weiß nicht warum. Das 
war der Stand Ende 2019.
Genug OT :)

[RoHS-CE (Gast)]

WOW ... total fix eine EMV Prüfung erfolgreich bestanden ... und eine CE 
und RoHS Erklärung gibts bestimmt auch dazu

https://www.ebay-kleinanzeigen.de/s-bestandsliste.html?userId=17732479

https://www.ebay-kleinanzeigen.de/s-anzeige/ahoy-dtu-fuer-hoymiles-wechselrichter/2141424109-168-8859

[Ralf B. (ralf_b210)]

Ziyat T. schrieb:
> Ralf B. schrieb:
>> Moin,
>>
>> hm.. warum gibt es ein so großes Interesse darin den WR zu begrenzen ?
>>      Ist ein 2ER Zähler verbaut ist alles ok (Überschuss wird
>> verschenkt)
>>      Da sollte man seine Energie inwestieren warum das so  ist.
>>      Ist ein alter Feraris verbaut dreht der rückwärts (doppelt
>> gespart).
>
> Hallo
> Weil es nicht überall auf dieser Welt die Rückspeisung so handgehabt
> wird wie in Deutschland, darum darf/muss ich NULL einspeisen.

Moin,
deshalb schrieb ich:
>>      Da sollte man seine Energie inwestieren warum das so  ist.

Ich bin absolut der Meinung das dieser Strom zu vergüten ist.

Die Nulleinspeisung für nen Akku zu nehmen ist eine schöne aber sehr 
teure Lösung. 2. WR und nen Lifopo4 mit 2,4 kW sind immo ca 2k€.
ob sich das rechnet ?

Btw
Ich selber habe 10 kWp und 14,5 kw Speicher im Keller.
Ist ein schönes Gefühl wenn der Strom von da kommt.

Die HM1200 die ich jetzt noch verbauen will sind für die SchattenPV.

[Lukas P. (lumapu)]

RoHS-CE schrieb:
> WOW ... total fix eine EMV Prüfung erfolgreich bestanden ... und eine CE
> und RoHS Erklärung gibts bestimmt auch dazu
> https://www.ebay-kleinanzeigen.de/s-bestandsliste.html?userId=17732479
> 
https://www.ebay-kleinanzeigen.de/s-anzeige/ahoy-dtu-fuer-hoymiles-wechselrichter/2141424109-168-8859

Leute vergesst den Gedanken mit Ahoy Geld zu verdienen! Die Lizenz 
erlaubt es nicht, dass Ahoy verkauft wird!
Lesen hilft und heulen wenn sich der Anwalt meldet geht gar nicht.

Ich finde es schei**e, dass sich hier irgendwelche ganz schlauen meinen 
es verkaufen zu müssen. Wir stecken echt viel Zeit rein und machen das 
als Community. Ich sehe das eher so: jeder steuert was bei und gemeinsam 
schaffen wir großes - für uns -

[isnoAhoy (Gast)]

Hallo Thomas B.,
habe mir mal Deinen Code angesehen und versucht die Bibliotheken für den 
Build mit dem ESP8266 auszutauschen. Ich strauchele an dem selben Punkt 
den wir auch schon umgekehrt festgestellt hatten:
* Beim ESP32 kann man ISR Routinen auch mit std::bind Klassen 
aufrufen/als Callback einbinden.
* Beim ESP8266 geht dies nur wenn die ISR Routine global als static void 
deklariert ist, also noch nicht als Methode einer Klasse.

Ansonsten ist der Code sehr übersichtlich und aufgeräumt. Hut ab / 
Chapeau!

Es dürfte dadurch vielleicht sogar etwas einfacher werden dies um die 
Inverter MI-/TSUN- zu erweitern.

Schwierigkeit bei beiden (Ahoy ESP8266 / OpenDTU ESP32) ist m.E. daß das 
Senden aktuell nur ein Kommando vorsieht. Bei MI-/TSUN- Wechselrichtern 
muß man aber alle vier Status/Data Pakete einzeln anfragen um die 
Informationen zu bekommen. Bei HM- Wechselrichtern geht das alles mit 
der Zeit setzen / SendTime Anfrage und man muß dann lediglich die Pakete 
sammeln, bzw. einzelne Pakete der Reihe nach retransmitten lassen.

Auch gibt es bei MI-/TSUN- Wechselrichtern keine CRC-Modbus / CRC-16 
Prüfsumme innerhalb der Payload, es existiert nur die Paket-eigene CRC-8 
Prüfsumme.

Der Code dürfte m.E. auch nicht zu viel Speicher verbrauchen, ist ja 
alles im PROGMEM bzw. Flash memory abgelegt und davon hat selbst der 
ESP8266(-12E/F) mit 4M m.E. reichlich, zumindest für die 2x3 
Wechselrichter Modelle, die wir bisher kennen.

Speicher-intensiv wird höchstens, wenn geplant sein sollte Daten zum 
Tages-/Wochenverlauf mehrerer Wechselrichter direkt im lokalen 
Flash-Filesystem des ESP abzulegen. Das könnte mit den entsprechenden 
Schreiboperationen einer RoundRobinDB auch schnell zu Fehlern führen.

[Heinz R. (heijz)]

Thomas K. schrieb:
> Um die Energie nicht zu Verschwenden (bzw. dem Netzbetreiber zu
> schenken) wollte ich meinen Shelly 3EM auslesen und den Wechselrichter
> auf
> NULL EINSPEISUNG einregeln.

was ein Unsinn, dann ist sie doch genau so verschwendet?

Du erzeugst sie halt nicht mehr, wirfst sie weg statt sie dem 
Netzbetreiber zu schenken
Selber hast Du keinerlei Vorteil davon, gönnst halt dem Netzbetreiber 
den Vorteil auch nicht


Die einzig interessante Anwendung die ich mir für eine 
Leistungsbegrenzung bei HM-Wechserichtern vorstellen kann:  Wenn man 
damit Akkukapazität ins Netz einspeisst...

[RoHS-CE (Gast)]

Hallo,
ich hoffe, es ist langsam mal Schluss hier mit Diskussionen, die nix mit 
der Protokoll Entschlüsselung zu tun haben.

Hier geht es um die Protokoll Entschlüsselung, Tests und da ist noch 
viel zu tun !

[Stefan R. (rossiman)]

Ziyat T. schrieb:
> @Stefan R. (rossiman)
> @Daniel R. (daniel92)
> Bei dem Thema Wemos1/esp8266 ist mir das noch aufgefallen:
> Wenn jemand den WR steuern möchte, muss man  die Leistung (+/-) beim
> Zaehler über Modbus abfragen, dazu brauchts neben dem nrf24 noch ein
> RS485-Modul an Wemos1, dann fehlt genau ein pin beim Wemos1.
Ich würde den WR über einen ESP8266 nur über MQTT steuern und lesen. Für 
die Leistungserfassung am Hauszähler habe ich schon einen ESP8266 mit 
Tasmota. Der bekommt die Daten über Infrarot Diode und sendet sie wieder 
über MQTT. Die Regelung mache ich mit Node Red auf dem Raspi meiner 
Heimautomatisierung. Für die Hoymiles Schnittstelle wäre für mich 
deshalb auch eine ESPEasy Plugin total ok. Für mich passt aber natürlich 
auch das was hier gebaut wird. Ich nutze aber die ESPs nur als 
Schnittstelle zu Sensoren und Aktoren.

[Maik R. (bastelbarney)]

Hi Leute,

mir ist da ein kleiner Bug im AHOY aufgefallen. Und weil ich Eure Arbeit 
schon nutze, dachte ich mir: "los, hilf auch mal!"

Aber irgendwie bin ich dermaßen QtCreator und VS verwöhnt, dass ich 
gerne den Code im Single-Step-Debugger durchlaufen wollte. Geht das mit 
dem 8266? In der Ardu-IDE is ja nix. Geht sowas mit VSCode? Oder läuft 
der Code auf dem 8266 direkt aus dem Flash? dann ja wohl eher nix mit 
single-Stepping ...

[isnoAhoy (Gast)]

Hallo Maik R.,
für single-step debugging direkt auf der Hardware brauchst Du einen JTAG 
oder Serial Wire Debug (SWD) Port. Mir ist nicht bekannt, daß die 
Espressif Chips ESP8266 und ESP32 sowas anbieten. Aber eine Suche nach 
OpenOCD (On Chip Debugger) und ESP8266 fördert sogar ein paar Seiten zu 
Tage:

esp8266-openocd/TODO
https://github.com/sysprogs/esp8266-openocd/blob/master/TODO

ESP32 JTAG Debugging
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/jtag-debugging/index.html

Man müsste mal einen ST-Linkv2 an die ESP Module / Chips klemmen und das 
versuchen. Wie man dann den GDB im VSCode mit Platform IO zum laufen 
bekommt, wäre ein weites Thema. Hier ist ein Beispiel:

Debugging ESP8266 code with OpenOCD and Visual Studio
https://visualgdb.com/tutorials/esp8266/openocd/

ESP8266 Development Log 00: Environment Setup
https://blog.thexyzlab.studio/esp8266-development-log-00-environment-setup/

Hier gibt es auch ein Pinout für den o.a. JTAG Port, aber alles in allem 
scheint es mit dem ESP32 einfacher und besser unterstützt zu sein.

WIFI-JTAG
https://github.com/emard/wifi_jtag

[Daniel M. (daniel_m821)]

isnoAhoy schrieb:
> für single-step debugging direkt auf der Hardware brauchst Du einen JTAG
> oder Serial Wire Debug (SWD) Port. Mir ist nicht bekannt, daß die
> Espressif Chips ESP8266 und ESP32 sowas anbieten.

Ich hab hier noch 2 unbenutzte M5Stack Core2 rumfliegen, da tickert ein 
ESP32 drin rum.
Wäre das eine Option zum Testen?

[Daniel R. (daniel92)]

isnoAhoy schrieb:
> Bei HM- Wechselrichtern geht das alles mit
> der Zeit setzen / SendTime Anfrage und man muß dann lediglich die Pakete
> sammeln, bzw. einzelne Pakete der Reihe nach retransmitten lassen.

Moment, nochmal ganz kurz das war mir gerade etwas viel Infos.
Ich habe letztens versucht da weiter zu kommen...

Wie darf ich das mit der Zeit verstehen? Wird hier ein Timestamp 
mitgeschickt von der aktuellen Uhrzeit oder wie das zu verstehen? Wenn 
jemand da mehr Infos für mich hat, gern her damit. :)

Vielleicht findet man dadurch eine Kombination aus dem alten MI und den 
neuen HM, wo man statt '100%' nur die Zeit dafür einsetzt.

Command|WR|DTU|SubCommand|Time|500W|CRC so vielleicht?

Gruß

[ST2 (Gast)]

Ich habe mal eine Frage an die HM-1500 Experten hier im Forum.

Ich hatte mir einen HM-800 bestellt allerdings irrtümlich einen HM-1500 
geliefert bekommen. Bevor ich den wieder zurückschicke und noch länger 
auf einen HM-800 warten muß, weil der zur Zeit beim Händler nicht 
lieferbar ist, dachte ich mir, dass ich den HM-1500 auch verwenden 
könnte. Allerdings liefern die von mir ins Auge gefassten Solarmodule 
bei Pmax 12,5 A und das ist mehr als die 11,5 A pro Kanal die der 
HM-1500 maximal verträgt (der HM-800 kann 12,5 A pro Kanal). Der HM-1500 
hat doch so wie der HM-800 auch nur 2 MPPT Tracker, also die Spannung an 
den zwei rechten bzw. den zwei linken Kanälen ist immer gleich geregelt, 
d.h. mann könnte doch die zwei rechten bzw. die zwei linken Kanäle 
parallel mittel MC4 Splitter an ein Solarmodul schalten, um ihn dann wie 
einen HM-800 zu betreiben. Ist zwar overkill, aber das sollte doch 
funktionieren und der Microinverter wird nicht so warm und ich könnte 
sogar Module mit Imax >12,5 A verwenden?

Vielen Dank für die Hilfe.

Grüße,
Stefan

[Postitiveselektron (Gast)]

ST2 schrieb:
...
> könnte. Allerdings liefern die von mir ins Auge gefassten Solarmodule
> bei Pmax 12,5 A und das ist mehr als die 11,5 A pro Kanal die der
> HM-1500 maximal verträgt (der HM-800 kann 12,5 A pro Kanal). Der HM-1500
...

Hallo Stefan,
warum wird hier ein Thread geentert mit Fragen, die mit der Überschrift 
nix zu tun hat ?
Mach dafür ein extra Thread auf.
Gleiche Fragestellung war vor einigen Tagen schon in einer anderen 
Gruppe.

[ST2 (Gast)]

@Positron Sorry, ich dachte, dass meine Frage viel mit der 
Threadüberschrift zu tun hat, es geht schließlich um "Hoymiles HM-XXXX 
Wechselrichter", die sowohl den HM-800 als auch den HM-1500 umfassen, 
beide lassen sich über Nordic Protokoll auslesen und die hierbei 
gesammelten Erkenntnisse lassen Rückschlüsse über die Anzahl der MPPT 
Tracker und die interne Verschalung der 4 DC Channles beim HM-1500 zu. 
Ich konnte leider keinen anderen Thread mit der gleichen Fragestellung 
finden.

[Daniel M. (daniel_m821)]

ST2 schrieb:
> @Positron Sorry, ich dachte, dass meine Frage viel mit der
> Threadüberschrift zu tun hat, es geht schließlich um "Hoymiles HM-XXXX
> Wechselrichter", die sowohl den HM-800 als auch den HM-1500 umfassen,
> beide lassen sich über Nordic Protokoll auslesen und die hierbei
> gesammelten Erkenntnisse lassen Rückschlüsse über die Anzahl der MPPT
> Tracker und die interne Verschalung der 4 DC Channles beim HM-1500 zu.
> Ich konnte leider keinen anderen Thread mit der gleichen Fragestellung
> finden.

Hallo ST2,

elektrisch ist das sicher kein Problem. Du kannst mit dem Auslesen des 
WR auch überwachen, was er tut. Hier wäre es in deinem Fall wichtig, 
dass du beobachtest, was der WR tut.
Sobald du die Splitter im Einsatz hast, sollte sich der Strom auf beide 
Eingänge aufteilen.
Bereite dir bitte ein Monitoring auf der Basis der Software vor und 
beobachte damit deinen WR.

Klar ist es nicht schön, andere Threads zu entern, allerdings ist es in 
dem Fall durchaus möglich, abseits der eigentlichen Fragestellung eine 
Lösung für ein Problem zu finden.

Sobald du dein System aufgesetzt hast, wäre es schön, Informationen über 
die Performance zu bekommen. Berichte bitte über die AC-Leistung und die 
beiden integrierten Tracker, wie die laufen.
Gerne auch mit MQTT logging. Deine Frage ist mir in anderen Kreisen 
schon oft begegnet.

Nachtrag:
Ich finde es wichtig, sich nicht nur auf das Protokoll zu versteifen 
sondern auch zu verstehen, was am Ende rauskommt. Daten sind das eine, 
aber wenn man diese nicht richtig interpretieren kann, ist es halt 
unschön.
Solche Spezialfälle gibt es immer wieder und genau hier ist das 
Protokoll und die Software eine Hilfe, die zum Erfolg führen kann.
In Bezug auf z.B. einen Akku am WR anstelle von Modulen, eine 
Leistungsbegrenzung und die damit verbundenen weiteren Möglichkeiten, 
die sowohl der WR als auch Software bringen können, finde ich genau 
diese Art Messdaten durchaus interessant für die zukünftige Entwicklung.
Da steckt Potential drin :)

[Ziyat T. (toe_c)]

Daniel R. schrieb:
> isnoAhoy schrieb:
>> Bei HM- Wechselrichtern geht das alles mit
>> der Zeit setzen / SendTime Anfrage und man muß dann lediglich die Pakete
>> sammeln, bzw. einzelne Pakete der Reihe nach retransmitten lassen.
>
> Moment, nochmal ganz kurz das war mir gerade etwas viel Infos.
> Ich habe letztens versucht da weiter zu kommen...
>
> Wie darf ich das mit der Zeit verstehen? Wird hier ein Timestamp
> mitgeschickt von der aktuellen Uhrzeit oder wie das zu verstehen? Wenn
> jemand da mehr Infos für mich hat, gern her damit. :)

Hier 
https://github.com/lumapu/ahoy/blob/main/doc/hoymiles-format-description.txt 
findest du alles für den HM. Speziell Zeile 399.

15:72220200:72220200:80:0B:00:6209049b:00 00 00 00 00 00 00 00 F2 68 
F0

[Tarifarbeiter (Gast)]

Lukas P. schrieb:

> Leute vergesst den Gedanken mit Ahoy Geld zu verdienen! Die Lizenz
> erlaubt es nicht, dass Ahoy verkauft wird!
> Lesen hilft und heulen wenn sich der Anwalt meldet geht gar nicht.


Also ich sehe hier: https://github.com/grindylow/ahoy/blob/main/LICENSE

GNU General Public License v3.0

Damit ist es sehr wohl erlaubt Geld zu machen.
Bei Github gibt es sogar kleine rote und grüne Häkchen die auf dem 
ersten Blick erklären wie die zitierte Lizenz zu nutzen ist.

Das nächste mal muss man halt ein proprietäres Lizenz wählen, dann darf 
auch die Anwalt Keule kommen.

[Lukas P. (lumapu)]

Das stimmt, das Repository ist per GNU 3.0 lizenziert.

Der genannte ESP Code ist aber per CC BY-NC-SA 3.0/DE geschützt:
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/app.cpp#L3

Finde es gut wenn wir dieses Thema klar verständlich für alle umsetzen 
können. Verbesserungen sind willkommen, Ziel soll sein:

- jeder darf die FW bauen / verändern
- jeder darf beitragen
- es darf kein Geld mit dem Wissen  Software  PCB Layout / Gehäuse 
verdient werden

Ich kenne auch ein anderes Projekt, das ein ähnliches Problem hat und es 
mit dieser Zeile in jedem File kenntlich gemacht hat (auch nach dem pull 
des Codes): https://github.com/pa-pa/AskSinPP

Der ESP präsentiert die Lizenz übrigens auch direkt auf der Index.html

[Ziyat T. (toe_c)]

Lukas P. schrieb:
> Das stimmt, das Repository ist per GNU 3.0 lizenziert.
>
> Der genannte ESP Code ist aber per CC BY-NC-SA 3.0/DE geschützt:
> https://github.com/grindylow/ahoy/blob/main/tools/esp8266/app.cpp#L3
>
Es waere ev. besser direkt in hier:
https://github.com/grindylow/ahoy/blob/main/LICENSE
auf diese:
Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
zu verweisen

[Tarifarbeiter (Gast)]

Lukas P. schrieb:
> Das stimmt, das Repository ist per GNU 3.0 lizenziert.
>
> Der genannte ESP Code ist aber per CC BY-NC-SA 3.0/DE geschützt:
> https://github.com/grindylow/ahoy/blob/main/tools/esp8266/app.cpp#L3
>
> Finde es gut wenn wir dieses Thema klar verständlich für alle umsetzen
> können. Verbesserungen sind willkommen, Ziel soll sein:
>
> - jeder darf die FW bauen / verändern
> - jeder darf beitragen
> - es darf kein Geld mit dem Wissen  Software  PCB Layout / Gehäuse
> verdient werden
>
> Ich kenne auch ein anderes Projekt, das ein ähnliches Problem hat und es
> mit dieser Zeile in jedem File kenntlich gemacht hat (auch nach dem pull
> des Codes): https://github.com/pa-pa/AskSinPP
>
> Der ESP präsentiert die Lizenz übrigens auch direkt auf der Index.html

Tatsächlich.
Ja dann habe ich mich geirrt.
Ich fände es auch gut wenn die Lizenz prominenter zu sehen wäre. Dieses 
Projekt ist jetzt "heiß" genug dafür.

Beste Grüße

[IsnoAhoy (Gast)]

Also ich persönlich bin für die GNU GPL v2/3 wie bereits ursprünglich im 
Projekt von Grindylow  Martin  Petersilie vorgesehen. Eine LICENSE 
Datei wäre natürlich schön. Da ich aber bisher kaum Code beigetragen 
habe unterwerfe ich meine Zusätze der Doku auch gerne einer anderen 
Lizenz.
Wenn also einige der Haupt-Contributoren (Lukas P., Thomas B. -> 
ESP8266/32, bzw. Jan-Jonas S. Python) hier eine ggf restriktivere Lizenz 
CC-SA-NC also non-commercial wünschen um zB Copy-Cat und unnötige 
Support-Anfragen zu verhindern dann ist das 1. verständlich und 2. auch 
gerechtfertigt da sie den größten Anteil am Code haben.
Andererseits werden die Support-Anfragen dadurch nicht weniger oder 
qualitativ besser und den Fragestellern sieht man es am Issue / 
Kommentar nicht direkt an ob sie das Ding gekauft oder selbst 
zusammengebastelt haben.
Vielleicht hilft es auch wenn wir hier einen „Selbstkostenpreis“ als 
Richtschnur oder Bill Of Materials im Readme.md definieren um 
unerwünscht hohe Preise von 50 Euro auf Kleinanzeigen als ebensolche 
herauszustellen ?

* Wemos D1 plus 4,65 EUR
* nRF24L01+ Modul 3,65 EUR

bzw. Optional statt der Komponenten oben
* NodeMCU v3.4 6,85 EUR
* nRF24L01+ PA Modul 5,75 EUR
plus
* Wemos Proto Board 3,74 EUR oder
* Platine ca. 2,00 EUR laut Oliver R.
* 100uF Elko Kondensator 25V 0,35-1,79 EUR
* Gehäuse 3D Druck einige Euros zugl Versand
ZB hier mit geringen Versandkosten und klarem Preis. Wieviel Gramm wiegt 
denn ein Gehäuse und wie lange dauert der Druck ? Ich habe immer noch 
kein Cura auf dem Handy =^P
https://www.ebay.de/itm/3D-Druck-Service-Drucken-von-Prototypen-Figuren-uvm-Schnell-und-Preiswert-/265496132225
* Arbeitszeit, Fädeldraht und Lötzinn (unbezahlbar heutzutage =^)

Macht in Summe also schon mal ca. 15-20 Euro je nachdem welche 
Komponenten und wie viel Versandkosten dazu kommen. Auch der Paketboote 
will ja was verdienen.

@Lukas P. wieviel wäre demnach für einen komplett zusammengebauten Satz 
für Dich erträglich / verständlich ?

Abseits der Frage nach der korrekten Lizensierung wäre das ja die Frage 
die wir für uns erstmal beantworten müssten, bevor wir ein Angebot als 
moralisch „unanständig“ oder korrekt („Selbstkostenpreis“) 
klassifizieren.

Für mich wäre zwar bei ca. 30 Euro eine Grenze erreicht (-> Gschmäckle). 
Aber wenn jemand Fremdes mehr dafür bezahlen will oder ein Bekannter mir 
mehr dafür gibt weil ich ja „auch soo viel Arbeitszeit reingesteckt“ 
habe, müsste ich auch nach guten Argumenten suchen dieses nicht 
anzunehmen.

Ich weiss aber nicht ob wir die von Einigen hier produzierten 
Überschüsse (bei 5-10 Modulen sind halt die anteiligen Versandkosten 
geringer und man hat auch immer ein paar Ersatzteile im 
Materialkontinuum für andere Projekte) Einzelner hier auf der Liste 
wirklich mit dem Anwalt sanktionieren müssen.

Ich will jedenfalls nicht die Hardware für andere zusammenlöten und 
verkaufen aber wenn ich die anderen vier PA Module wiederfinde hänge ich 
bestimmt noch eines an den Raspberry Pi oder versuche mal den Hoymiles 
HM-600 mit der P8/Pinetime Smartwatch abzufragen.

[Lukas P. (lumapu)]

Hallo Stefan,

ja genau wir sind noch zu stark in den Kinderschuhen als dass man hier 
zu stark unbedarfte damit versorgen sollte (Support). Daher würde ich 
auch einen nachvollziehbaren Preis von 10-15€ akzeptieren / verstehen.

Was ich halt unterstreichen will: ich bin nicht einer der 'Dummen' um 
anderen ein verkaufsfähiges Produkt auf den Tisch zu zaubern und selbst 
leer auszugehen. Warum kann es nicht einfach offen sein und wer ein 
bisschen Lust auf basteln hat kann sich für lau eine DTU ohne Cloud 
selbst stricken - und sogar noch eigene Anpassungen vornehmen.

Besonders gefährdet als Produkt verkauft zu werden sind glaube ich nur 
die ESPs.
Wir wollen ja auch nicht hoymiles eine Konkurrenz machen, sondern eine 
Cloud freie Version, ursprünglich ging es ja nur um die Entschlüsselung 
des Protokolls ^^

[Holger S. (skusi)]

Günter H. schrieb:
> @Holger S.
> Sehr kompaktes Layout.
> Einige Anmerkungen:
> - Den 3.3V-Spannungsregler weiter vom AC-Eingang weg platzieren, der
> Abstand zwischen AC-Eingang und der übrigen Schaltung erscheint mir sehr
> klein zu sein. Besonders dann, wenn eine externe Antenne geplant ist.
> - Datenblatt HiLink_3W_Power_Supply Seiten 7-8, Kap. 8 "Typical
> Application Circuit". Dort ist ausgeführt: "Fuses and varistors are the
> basic protection circuits (required)" sowie "For certification, safety
> capacitors and common mode inductors cannot be omitted". (Danke an den
> Google-Übersetzter)

Wenn ich hier so lese, das die 3,3V vom Wemos ausreichend stabil sind, 
und man den Elko auch nicht unbedingt benötigt. Bin ich geneigt den 
Spannungsregler und die Kondensatoren rauszuschmeißen um dann Platz für 
eine Sicherung zu schaffen. Ich möchte ungerne auf ein größeres Gehäuse 
aufrüsten müssen.
Ich experimentiere derzeit mit verschienden0en Lösungen. Dabei hat sich 
übrigens schon ergeben das meine Idee mit der Schrumpfschlauch / Alu 
Klebeband Abschirmumg des RF24 den Empfang sehr verschlechtert. Ich habe 
die  Schirmung wieder entfernt, und nun werden meine 6 WR auch ziemlich 
sauber empfangen.
Einzig den Grund für die Abstürze habe ich noch nicht ergründen können. 
Ich habe nun alle meine 3 Verschiedenen Wemos d1 mini clone ausprobiert, 
und keiner schafft mehrere Stunden Uptime.

[Thomas B. (tbnobody)]

Ziyat T. schrieb:
> Deise SW ist orig. vom Hubi, ich habe für den MI-1500 abgaendert und als
> Arbeits-/Debug-SW zu verstehen.
> Nur für ArduinoUno.

Hallo Ziyat,

du verwendest bei deinen Abfragen für den Status ja 0x36 - 0x39. In der 
Excel File RF通讯协议-V6.5.xlsx sind diese Commands ja unter Legacy Commands 
geführt. Hattest du auch mal versucht die Non-Legacy commands zu 
verwenden? (Also die, die oben auf dem Sheet "Data collection 
instructions" stehen? (Sollte MainCMD = 0x15 und SubCommand = 0x00 sein)

Ich glaub mit meiner aktuellen ESP32 Lib sollte man das evtl. mit 
überschaubarem Aufwand umsetzen können (evtl...). Wenn ich da ein paar 
Background Infos hab muss ich mich aber nicht so durch den Arduino Code 
mühen.

[Daniel M. (daniel_m821)]

Thomas B. schrieb:

> du verwendest bei deinen Abfragen für den Status ja 0x36 - 0x39. In der
> Excel File RF通讯协议-V6.5.xlsx sind diese Commands ja unter Legacy Commands
> geführt. Hattest du auch mal versucht die Non-Legacy commands zu
> verwenden? (Also die, die oben auf dem Sheet "Data collection
> instructions" stehen? (Sollte MainCMD = 0x15 und SubCommand = 0x00 sein)

Hallo Thomas,
ich habe heute meine ESP32 bekommen und direkt mit deiner Version 
losgelegt.
Die sendTime-Routine etwas umgefummelt damit Daten gesendet werden:

HM_Abstract.cpp:

    payload->mainCmd = 0x09;
    payload->subCmd = 0x00;
    payload->timeout = 2000;
    payload->len = 0;

mainCmd = 0x09 ergibt Antwort 0x88 (Event/Status Modul 1) und 0x89 (PV 
Daten) auf der Payload Position 0.
Doe 0x11 ergibt die Antworten 0x91 (PV Daten) und 0x92 (Event/Status 
Modul 2).

Ziyat hat einen MI-1500, ich habe einen MI-700 Klon.
Die Befehle sind etwas unterschiedlich, die Grundlegenden Antworten sind 
aber identisch. Ziyat bekommt 8 Antworten, ich 4.

Der mainCmd 0x15 hat keine Auswirkungen auf die alten Modelle.

> Ich glaub mit meiner aktuellen ESP32 Lib sollte man das evtl. mit
> überschaubarem Aufwand umsetzen können (evtl...). Wenn ich da ein paar
> Background Infos hab muss ich mich aber nicht so durch den Arduino Code
> mühen.

Für die Backgroudinfos sind wir sicher zu haben, ich fange mal an.

Ich habe für den 2-Kanal MI folgendes in der MI_2CH.cpp, einer Kopie 
deiner HM_2CH.cpp:

#include "MI_2CH.h"

MI_2CH::MI_2CH(uint64_t serial)
    : HM_Abstract(serial) {};

bool MI_2CH::isValidSerial(uint64_t serial)
{
    return serial >= 0x104100000000 && serial <= 0x104199999999;
}

String MI_2CH::typeName()
{
    return String(F("MI-600, MI-700, MI-800"));
}

const byteAssign_t* MI_2CH::getByteAssignment()
{
    return byteAssignment;
}

const uint8_t MI_2CH::getAssignmentCount()
{
    return sizeof(byteAssignment) / sizeof(byteAssign_t);
}

Die .h habe ich angehängt, diese ist aber noch lange nicht lauffähig, 
jedoch stimmt die Reihenfolge der Bytes bereits.

Zeile 14 hat garantiert die falsche Länge.

Die Hoymiles.cpp habe ich ab Zeile 43 folgend erweitert:

std::shared_ptr<InverterAbstract> HoymilesClass::addInverter(const char* name, uint64_t serial)
{
    std::shared_ptr<InverterAbstract> i;
    if (HM_4CH::isValidSerial(serial)) {
        i = std::make_shared<HM_4CH>(serial);
    }
    else if (HM_2CH::isValidSerial(serial)) {
        i = std::make_shared<HM_2CH>(serial);
    }
    else if (HM_1CH::isValidSerial(serial)) {
        i = std::make_shared<HM_1CH>(serial);
    }
    /*if (HM_4CH::isValidSerial(serial)) {
        i = std::make_shared<MI_4CH>(serial);
    }*/
    else if (MI_2CH::isValidSerial(serial)) {
        i = std::make_shared<MI_2CH>(serial);
    }
    /*else if (HM_1CH::isValidSerial(serial)) {
        i = std::make_shared<MI_1CH>(serial);
    }*/

Leider komme ich mit dem Empfang der Payload nicht weiter.
Log:

Fetch inverter: 17872974971670
TX 9 60 53 3 16 78 56 34 12 0 27 
RX Period End
All missing
Nothing received, resend whole request
TX 9 60 53 3 16 78 56 34 12 0 27 
RX Period End
All missing
Nothing received, resend whole request

Warum unter Fetch inverter das ganze in Dezimal (?) kodiert steht, kann 
ich noch nicht nachvollziehen.

Ansonsten muss ich isnoahoy zustimmen, dein Code ist sehr übersichtlich 
und aufgeräumt. Sehr gut! :)

Wenn du nochmal Beispiele für komplette Empfangspayload brauchst, kann 
ich gerne noch welche schicken.

88 63500316 63500316 00 03 00 00 00 00 00 00 8B D8 29
89 63500316 63500316 012D 0001 095D 1389 003D 085D 00FF E550 EF
91 63500316 63500316 012D 0001 095D 1389 003D 085D 00FF E550 EF
92 63500316 63500316 00 03 00 00 00 00 00 00 91 98 81
pid WR-ID    WR-ID   Payload

Das Grundgerüst ist, soweit ich gesehen habe, identisch zu meinem, nur 
die payload-ID's zum Abfragen und Empfangen sind unterschiedlich.

Wäre es einfach Möglich, in den inverters/xxx.h und xxx.cpp die commands 
und payload-ID's hinzuzufügen?
Etwa in dieser Form:

const uint8_t MI_2CH::getPayload()
{
    mainCmd = 0x09; //Ch0 request
    mainCmd = 0x11; //Ch1 request
    PayloadID = 0x88; //Event Ch0
    PayloadID = 0x89; //PV-DATA Ch0
    PayloadID = 0x91; //PV-DATA Ch1
    PayloadID = 0x92; //Event Ch1
}

Zum genauen Ablauf von Sende/Empfangsdaten müsste Ziyat was sagen, 
mainCmd hier sind:
Ch0=0x36
Ch1=0x37
Ch2=0x38
Ch3=0x39

Leider gibt es zur Antwort keine Kommentare in der Version von Gitee.

Ein Zeit-Kommando gibt es nicht, eine CRC16 auf dem mainCmd gibt es 
nicht, nur das CRC8.
Eine CRC16 auf der Payload gibt es ebenfalls nicht, das letzte Byte auf 
0x89 und 0x91 ist Bestandteil der Gesamtproduktion des WR. Wie das 
aufgebaut ist, hab ich noch keine Ahnung. ES gibt Hinweise in der 
Gitee-Version, lass da später mal schauen.
Das einfachste dürfte sein, eine Bedingung: wenn HM-Inverter, dann 
CRC16, wenn MI, dann einfach die Payload mit (ID) nutzen.

Btw. ich habe 2 Kollegen mit Balkonkraftwerken angesteckt, ich habe 
heute 4 Module, der nächste 3 und der 3. 1 Modul abgeholt. Jeder wird 
einen HM-1500 verwenden.
Der MI-Klon wird natürlich weiterarbeiten und für Tests herhalten.

Danke für deine gute Vorlage, Thomas, ist das erste mal für mich, dass 
ich freudig durch VScode gewuselt bin :)

lg
Daniel M.

[Thomas B. (tbnobody)]

Daniel M. schrieb:

>

> HM_Abstract.cpp:
> 
>     payload->mainCmd = 0x09;
>     payload->subCmd = 0x00;
>     payload->timeout = 2000;
>     payload->len = 0;
>

Mein Plan war hier eine MI_Abstract.cpp Datei zu haben. Diese wird dann 
alle MI-Spezifischen Methoden enthalten.

> Der mainCmd 0x15 hat keine Auswirkungen auf die alten Modelle.
Ok, damit muss man wirklich das Legacy Protokoll Implementieren.

>

> #include "MI_2CH.h"
> 
> MI_2CH::MI_2CH(uint64_t serial)
>     : HM_Abstract(serial) {};
> 
> bool MI_2CH::isValidSerial(uint64_t serial)
> {
>     return serial >= 0x104100000000 && serial <= 0x104199999999;
> }
> 
>

Wir haben aktuell noch relativ wenige Seriennummern zu MI Invertern 
gesammelt. Ich würde annehmen die Nummernkreise verhalten sich ähnlich 
wie für die HM Inverter (also jeweils 1CH, 2CH und 4CH)?

> Leider komme ich mit dem Empfang der Payload nicht weiter.
> Log:
>

> Fetch inverter: 17872974971670
> TX 9 60 53 3 16 78 56 34 12 0 27
> RX Period End
> All missing
> Nothing received, resend whole request
> TX 9 60 53 3 16 78 56 34 12 0 27
> RX Period End
> All missing
> Nothing received, resend whole request
>

Du wirst hier aktuell auch noch nichts empfangen können. Die 
Empfangsroutine erwartet aktuell Fragmente die jeweils eine CRC usw. 
enthalten. Das muss ich an der Stelle noch umtippen (ggf. 2. 
Empfangsmodus für Pakete die nicht als Fragmente übertragen werden). 
Aber selbst wenn das nicht implementiert ist sollte zumindest ein "Frame 
kaputt" kommen da die Fragment CRC nicht geprüft werden kann: 
https://github.com/tbnobody/OpenDTU/blob/e9e5c715f57290d99048b15d15a4a8d7cd70d9b5/lib/Hoymiles/src/HoymilesRadio.cpp#L74

Ich habe aber noch im Hinterkopf das die DTU's für die MI's einen 
anderen Nummernkreis haben. Ggf. erfolgt deshalb keine Antwort. Da muss 
ich aber nochmal nachlesen bzw. den Code von Ziyat anschauen.

> Warum unter Fetch inverter das ganze in Dezimal (?) kodiert steht, kann
> ich noch nicht nachvollziehen.
Das scheint noch ein Problem bei mir zu sein. Muss in dieser Zeile die 
Ausgabe als Hex machen: 
https://github.com/tbnobody/OpenDTU/blob/e9e5c715f57290d99048b15d15a4a8d7cd70d9b5/lib/Hoymiles/src/Hoymiles.cpp#L27


> Zum genauen Ablauf von Sende/Empfangsdaten müsste Ziyat was sagen,
> mainCmd hier sind:
> Ch0=0x36
> Ch1=0x37
> Ch2=0x38
> Ch3=0x39
>
> Leider gibt es zur Antwort keine Kommentare in der Version von Gitee.
Die Antworten auf die entsprechenden Anfragen sind im Excel (siehe auch 
hier 
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?") 
auf dem 3. Blatt von links in Zeile
106 beschrieben (Anfrage in Zeile 104)


> Danke für deine gute Vorlage, Thomas, ist das erste mal für mich, dass
> ich freudig durch VScode gewuselt bin :)
Freut mich das es mit VSCode klappt. Wenn man erstmal weiß was es tut 
ist es imho viel schöner als die Arduino IDE.

[Daniel R. (daniel92)]

Thomas B. schrieb:
> Wir haben aktuell noch relativ wenige Seriennummern zu MI Invertern
> gesammelt. Ich würde annehmen die Nummernkreise verhalten sich ähnlich
> wie für die HM Inverter (also jeweils 1CH, 2CH und 4CH)?

Ich hab mal einfach im Internet zusammen gesucht, kein Gewähr auf 
richtigkeit. :)


MI-500
104021600117:https://www.youtube.com/watch?v=uqnoU9fCvOg

MI-1500
106160914811:https://www.alpha-solar.info/images/product_images/original_images/MI-1500%20Vorderseite%20freigestellt%20klein.png

105154003229:https://images.tcdn.com.br/img/img_prod/606124/kit_hoymiles_mi1500_4_paineis_440w_monocristalino_12351_6_5e3655b2364e9548a6376ae715afcf69.jpg

[Daniel M. (daniel_m821)]

Thomas B. schrieb:

Hallo Thomas,

> Mein Plan war hier eine MI_Abstract.cpp Datei zu haben. Diese wird dann
> alle MI-Spezifischen Methoden enthalten.

das war auch mein Gedanke, irgendwo muss man aber anfangen, daher bot 
sich diese Funktion an.

> Wir haben aktuell noch relativ wenige Seriennummern zu MI Invertern
> gesammelt. Ich würde annehmen die Nummernkreise verhalten sich ähnlich
> wie für die HM Inverter (also jeweils 1CH, 2CH und 4CH)?

Jup, der Nummernkreis ist gleich, startet aber mit 10 statt 11.


> Du wirst hier aktuell auch noch nichts empfangen können. Die
> Empfangsroutine erwartet aktuell Fragmente die jeweils eine CRC usw.
> enthalten. Das muss ich an der Stelle noch umtippen (ggf. 2.
> Empfangsmodus für Pakete die nicht als Fragmente übertragen werden).
> Aber selbst wenn das nicht implementiert ist sollte zumindest ein "Frame
> kaputt" kommen da die Fragment CRC nicht geprüft werden kann:
> 
https://github.com/tbnobody/OpenDTU/blob/e9e5c715f57290d99048b15d15a4a8d7cd70d9b5/lib/Hoymiles/src/HoymilesRadio.cpp#L74

Das ist eine gute Frage. Nachdem ich die CRC16 in der ahoy-version 
ausgeblendet habe und nicht verwende, bekomme ich zumindest valide 
Pakete.

> Ich habe aber noch im Hinterkopf das die DTU's für die MI's einen
> anderen Nummernkreis haben. Ggf. erfolgt deshalb keine Antwort. Da muss
> ich aber nochmal nachlesen bzw. den Code von Ziyat anschauen.

Die Nummer der DTU scheint dem WR relativ egal, ich bekomme mit der 
modifizierten Version von Hubi mit den den DTU-ID's antworten.

> Das scheint noch ein Problem bei mir zu sein. Muss in dieser Zeile die
> Ausgabe als Hex machen:
> 
https://github.com/tbnobody/OpenDTU/blob/e9e5c715f57290d99048b15d15a4a8d7cd70d9b5/lib/Hoymiles/src/Hoymiles.cpp#L27

Das eilt nicht :)
Wenn man es weiß, ist es ok, normal schaut aber keiner weiter darauf.

> Die Antworten auf die entsprechenden Anfragen sind im Excel (siehe auch
> hier
> Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?")
> auf dem 3. Blatt von links in Zeile
> 106 beschrieben (Anfrage in Zeile 104)

Jup, die Antworten sind so aufgebaut.

> Freut mich das es mit VSCode klappt. Wenn man erstmal weiß was es tut
> ist es imho viel schöner als die Arduino IDE.

VSCode ist schon angenehm im Handling, jemanden allerdings, der nicht so 
tief in der Entwicklung steckt, erschlägt es einen erstmal.
Viel schöner als die Arduino IDE ist es auf jeden Fall.

Danke und Respekt für deine Arbeit mit dem ESP32.
Natürlich auch Hubi und den anderen mit Raspi und ESP8266.
Das ganze ist nicht so einfach und trotzdem irgendwie faszinierend :)

[Ziyat T. (toe_c)]

Daniel M. schrieb:
Thomas B. schrieb:
>> Wir haben aktuell noch relativ wenige Seriennummern zu MI Invertern
>> gesammelt. Ich würde annehmen die Nummernkreise verhalten sich ähnlich
>> wie für die HM Inverter (also jeweils 1CH, 2CH und 4CH)?

Hallo zusammen
Die Frage wurde schon im Doku beantwortet:
https://github.com/lumapu/ahoy/blob/main/doc/Hoymiles-SerialNumbers.xlsx
HM beginnt mit 11
MI beginnt mit 10
250 Watt -> xx20
300 bis 400 Watt  -> xx21
500 Watt -> xx40
600 bis 800 Watt -> xx41
1000 Watt -> xx60
1200 bis 1500 Watt -> xx61

Die MI-1500 commands und antworten könnt ihr ja in meinen Beitraegen 
finden.

Hoffe bald auf eine Version mit MI1500;-)

Noch eine freche Frage: Könnt ihr bitte die Limitierung (CMD 0x51) auch 
einbauen, mit der mqtt-Abfrage des Smartzaehler-Wertes?

[Ziyat T. (toe_c)]

Thomas B. schrieb:

> du verwendest bei deinen Abfragen für den Status ja 0x36 - 0x39. In der
> Excel File RF通讯协议-V6.5.xlsx sind diese Commands ja unter Legacy Commands
> geführt. Hattest du auch mal versucht die Non-Legacy commands zu
> verwenden? (Also die, die oben auf dem Sheet "Data collection
> instructions" stehen? (Sollte MainCMD = 0x15 und SubCommand = 0x00 sein)

Bei MI-1500 gehen nur CMD=0x36-0x39
Alle Kombinationen für den MI-1500 wurde von mir bereits getestet.
Bitte siehe meine Beitraege.

[Ziyat T. (toe_c)]

Daniel M. schrieb:
Thomas B. schrieb:

>>Eine CRC16 auf der Payload gibt es ebenfalls nicht, das letzte Byte auf
>>0x89 und 0x91 ist Bestandteil der Gesamtproduktion des WR. Wie das

Doch, ohne CRC16 bekommt man auch die falschen Werte, z.B. ein PV 
5300Watt, das mach die Rechnung schwieriger;-).

[Ziyat T. (toe_c)]

@Thomas B.
@Daniel M.

Ich habe alle commands für den MI-1500 mit meiner DTU-Pro verifiziert. 
Ich habe die Kommunikation DTUPro-WR gesnifft und die cmd's und 
Antworten so herausgefungen, bevor die gite Dokus gefunden wurde. Die 
habe ich dann so implementiert.

[M. P. (matze7779)]

Hallo,

hoffentlich kann mir hier jemand helfen.
Ich habe die Software auf einem Wemos D1 mini.

Dazu dieses Modul:
https://www.amazon.de/gp/product/B09MKCZ7WT/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&th=1

Anbei Screenshots meiner Einstellungen. Leider bekomme ich keine 
Verbindung zum HM-800.
Angeschlossen ist es nach: 
https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md

Das ganze befindet sich momentan ca. 4m entfernt vom Wechselrichter.

[isnoAhoy (Gast)]

Hallo Matze M.P.,

Du verwendest noch die v0.4.17 versuche es mal mit 0.4.19 es gab da 
evtl. einige Verbesserungen (ich hab das Changelog nicht im Kopf).

Probiere mal eine andere Belegung für die IRQ und CSN / CE Pins. Siehe 
dem entsprechenden GitHub issue: 
https://github.com/grindylow/ahoy/issues/36
Es gabe Hinweise, daß die IRQ Leitung an D3 / GPIO0 teilweise Probleme 
macht. Andere haben D2 & D1 statt D3 & D4 verwendet und Erfolg gehabt.
Bitte also eine Rückmeldung im o.g. Issue falls das bei Dir ebenfalls 
erfolgreich ist.

Als Drittes kannst Du noch das Kleingedruckte auf Deinen Modulen 
überprüfen ob es auch tatsächlich ein nRF24L01+ Modul ist. Es gibt wohl 
auch Module ohne das + bei denen es nicht klappen kann. Ich weiß nicht 
ob die NRF24 Bibliothek beim Booten des ESP über die Serial Console eine 
Versionsnummer des NRF Chips mit ausgibt ? Eventuell gibt es auch noch 
ein eigenes Kommando in der NRF24 Bibliothek um die Version zu prüfen ?

[M. P. (matze7779)]

Die 0.4.19 (fertiges bin) hier aus dem Thread hab ich gerade als OTA 
aufgespielt.
Leider macht der Wemos jetzt kein WLAN auf um ihn zu konfigurieren.
Mist...Jetzt komm ich nicht mehr drauf.

[Heinz R. (heijz)]

Lukas P. schrieb:
> ja genau wir sind noch zu stark in den Kinderschuhen als dass man hier
> zu stark unbedarfte damit versorgen sollte (Support). Daher würde ich
> auch einen nachvollziehbaren Preis von 10-15€ akzeptieren / verstehen.

Ich verstehe zugegeben nicht was manche hier machen - aber vielleicht 
lese ich auch zu wenig mit?

Ich habe hier einen HM-1500 - für den habe ich vor ca. 3 Monaten hier 
was runter geladen, glaube von AHOY, auf einen ESP8266 geflasht, es 
läuft und macht genau was ich will
Viele sagen wir sind im Forschungsstatus - ihr habt es doch schon 
geknackt?

Das ganze rumgeeire was wie verkauft werden kan / soll - wozu?

Ich habe hier einige solcher ESP-Lösungen im Einsatz, YC-600, 
SML-Reader, Wärmepumpe, alle schicken brav über MQTT

Meiner Ansicht nach wird es Zeit das einer ausschert, einfach was 
fertiges präsentiert
Schaut euch gerne mal das hier an:

https://github.com/Egyras/HeishaMon

Es ist wie es ist, tut was es soll, reicht so

Sorry für mein Unverständnis an dieser Stelle und Viele Grüße

[Ziyat T. (toe_c)]

Heinz R. schrieb:
> Ich habe hier einen HM-1500 - für den habe ich vor ca. 3 Monaten hier
> was runter geladen, glaube von AHOY, auf einen ESP8266 geflasht, es
> läuft und macht genau was ich will
> Viele sagen wir sind im Forschungsstatus - ihr habt es doch schon
> geknackt?
>
Es gibt nicht nur die HM-Serie von hoylmoly! Und von HM's werden bisher 
"nur" die WR-Daten geholt, der WR wird noch nicht gesteuert. Also wenn 
du nur Daten von deinem HM möchtest ist es ok. für dich, ich und einige 
möchten mehr: Unterstützung der alle MI's,TSUN, Zuverlaessigkeit, MQTT, 
zero export etc.

> Das ganze rumgeeire was wie verkauft werden kan / soll - wozu?

Alleine ich habe ziemlich viel Zeit investiert für den MI-1500, die 
anderen hier sicher noch mehr. So dürfen wir doch bisschen 
"rumgeeiren";-)

Gruss

[Daniel R. (daniel92)]

Hallo zusammen,

so ich bin aktuell wieder dran HM die Limitierung zu testen.
Folgendes habe ich nun gesendet:

2022-06-29 14:09:39.966934 Transmit 14 | 15 74 40 33 29 78 56 34 12 80 5a 5a 02 b1
2022-06-29 14:09:40.012065 Received 27 bytes channel 75: f1 74 40 33 29 74 40 33 29 81 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb 9b
2022-06-29 14:09:40.516145 Payload: 80 00 00 00 00 00 00 00 00 00 00 00 00 01 81 eb

Jedoch steht in der Descr.: 
https://github.com/lumapu/ahoy/blob/main/doc/hoymiles-format-description.txt 
(Zeile: 520)

**CMD**:
     Befehl an den WR hat Bit 7 gesetzt
       0x80 "Zeit setzen"
       0x81 "Anfrage DC-Daten", erwartete Antwort: 0x01
       0x82 "Anfrage AC-Daten", erwartete Antwort: 0x02
       0x83 "?"
       0x85 "?"
       0xFF "?"
     Antworten vom WR haben Bit 7 gelöscht:
       0x01 "Aktuelle DC-Daten"
       0x02 "Aktuelle AC-Daten"

Habe ich es richtig verstanden, das damals Herausgefunden wurde das man 
die Zeit zuerst setzen muss und später auf Anfrage die eigentliche 
Nachricht zu schicken soll?

[Josef J. (jauntyjosef)]

Hallo!

Ich besitze einen HM-1500 und habe mich auch mal daran versucht. Leider 
scheitere ich ebenfalls. Ich habe auch schon D1&D2 anstatt D3&D4 und 2 
verschiedene nRF24L01+ Module probiert (zumindest auf einem steht das + 
dabei). Es handelt sich dabei um die Version 0.4.20.
Hat vielleicht jemand eine Idee, was ich falsch mache?

[Oswald S. (obmaroszi)]

Hallo,

ich habe dieses Forum durch Zufall gefunden und bin begeistert was Ihr 
alles erreicht habt.
Da ich noch auf meine Aufständerung für meine 2 Module warte, habe ich 
eines im Garten aufgestellt. Zum Test reicht es.(heute regnet es)
Bin noch aus der analog Zeit. Habe es jedoch geschafft das fertige bin 
File auf einen Wemos D1 mini zum laufen zu bringen.
Leider hab ich es nicht geschafft die Daten (MQTT) ins Openhab 3 
einzubinden.

Grosse Lob an alle die hier so hart Arbeiten.
Leider kann ich ausser testen nichts beitragen.

Gruß

[Daniel R. (daniel92)]

Habe mir nochmal das ganze aus Gitee angeschaut.
Mir ist was aufgefallen, kann aber nicht bestätigen ob das sinnig ist.

Mein Gedanke dazu: Der unten stehende Code beschreibt wie ein PowerLimit 
abläuft.
Ich glaube das der WR in der Lage ist sogar einzelne Strings 
kontrolliert abzuschalten, oder Einzuschalten.
Aus irgendeinen Grund wird bei der Übergabe dieser Funktion die 'SubCmd' 
mit Bit-Operatoren verarbeitet.
... Könnt ihr aber auch selbst unten lesen.

Was mich noch stutzig macht, was könnte 'Acq_Switch' genau bedeuten?

/***********************************************
** Function name:
** Descriptions:  set micro-inverter power instruction
** input parameters:
** output parameters:
** Returned value:
*************************************************/
uint8_t UsartNrf_Send_PackSetPowerLimitCommand(uint8_t *target_adr, uint8_t *rout_adr, int8_t MainCmd, uint16_t SubCmd)
{
    uint8_t i = 0;
    uint8_t temp_dat[UART_LEN];   //(#define UART_LEN 35)
    memset(temp_dat, 0, sizeof(temp_dat));
    Uart_SendBuffer[0] = STX;//head (#define STX 0x7e)
    temp_dat[0] = MainCmd;   //instruction
    memcpy(&temp_dat[1], target_adr, 4);
    memcpy(&temp_dat[5], rout_adr, 4);

    if(MIMajor[PortNO].Property.Acq_Switch == 0)
    {
        //1000w shutdown Micro-inverse control of 1-to-4 with the last 8 digits of the special control ID less than 0x50000000
        if((MIMajor[PortNO].Property.Id[0] < 0X50) && ((MIMajor[PortNO].Property.Pre_Id[1] == 0X60) || (MIMajor[PortNO].Property.Pre_Id[1] == 0X61)))
        {
            temp_dat[9]  = SubCmd & 0XFF00 >> 8;      //5a5a
            temp_dat[10] = SubCmd & 0XFF;
            temp_dat[11] = 11;
            //                  temp = 35*4*10=1400=0x0578;
            temp_dat[12] = 0X05;
            temp_dat[13] = 0X78;
            temp_dat[14] = Get_crc_xor(&temp_dat[0], 14); //CRC
            i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 15); // forward replacement
        }
        else
        {
            temp_dat[9]  = SubCmd  >> 8;      //5a5a
            temp_dat[10] = SubCmd ;
            temp_dat[11] = Get_crc_xor(&temp_dat[0], 11); //CRC
            i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 12); //forward substitution
        }
    }
    else
    {
        temp_dat[9]  = SubCmd & 0XFF00 >> 8;      //5a5a
        temp_dat[10] = SubCmd & 0XFF;
        temp_dat[11] = MIMajor[PortNO].Property.Power_Limit * 10 / (EVERY_PORT_POWER    * (UsartNrf_GetInvterType(MIMajor[PortNO].Property.Pre_Id))); //Power limit percentage
        temp_dat[12] = MIMajor[PortNO].Property.Power_Limit >> 8;    //High 8-bit power limit
        temp_dat[13] = MIMajor[PortNO].Property.Power_Limit & 0x00ff;            //Low power limit 8 bits
        temp_dat[14] = Get_crc_xor(&temp_dat[0], 14); //CRC
        i = ForwardSubstitution(&Uart_SendBuffer[1], &temp_dat[0], 15); //forward substitution
    }

    Uart_SendBuffer[(i + 1)] = ETX; //tail
    memset(temp_dat, 0, sizeof(temp_dat));
    return (i + 2);
}

[Holger S. (skusi)]

Auf der Suche nach der Reboot Ursache habe ich meine kompilierte 6x 
Inverter .bin zum testen auf einen NodeMCU Amica den ich hier noch 
rumliegen hatte geflasht. Damit wollte ich ausschliessen das es an den 
China Wemos Clones liegt.

Leider bekomme ich damit auch keine mehrstündigen Uptimes hin. 
Eigentlich ja nicht schlimm, da die Daten ja nicht verloren gehen. Aber 
irgendwie muß man das doch sauber zum laufen bekommen.

Läuft das bei euch über Tage ohne Reboot ???

[Daniel R. (daniel92)]

Ich kann nichts dazu beitragen. Ich nutze es über Raspberry Pi.
Zusätzlich läuft es aktuell noch nicht (warte immer noch auf die PVs).

[Sigi S. (sermon)]

Holger S. schrieb:
> Auf der Suche nach der Reboot Ursache habe ich meine kompilierte 6x
> Inverter .bin zum testen auf einen NodeMCU Amica den ich hier noch
> rumliegen hatte geflasht. Damit wollte ich ausschliessen das es an den
> China Wemos Clones liegt.
>
> Leider bekomme ich damit auch keine mehrstündigen Uptimes hin.
> Eigentlich ja nicht schlimm, da die Daten ja nicht verloren gehen. Aber
> irgendwie muß man das doch sauber zum laufen bekommen.
>
> Läuft das bei euch über Tage ohne Reboot ???

Ja, über mehrere Wochen stabil

[Sigi S. (sermon)]

Daniel R. schrieb:
> Ich kann nichts dazu beitragen.

Was soll dann der Beitrag?
Wenn das jeder macht.....

[Daniel R. (daniel92)]

Ok der Beitrag 
'Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"; ist 
doch erstmal hinfällig. Die Funktion macht nichts anderes als wie in der 
Excel im Blatt "Control instruction" Zeile 91.

Somit könnt ihr denn Teil erstmal überfliegen. ^^

Ist ja für MI, nicht für mich HM.

[Herbert K. (avr-herbi)]

@Holger S. (skusi)

Hallo, ich habe die uralt "hubi" Version für den ESP8266 ohne MQTT 
(Stromversorgung vom PC über USB ca. 2,5m Kabel, kleiner Elko am RF 
Modul, alles total einfach auf einem Steckbrett) und ich habe damit noch 
keinen eigenständigen Reboot erlebt.

Stört evt. was aus der Umgebung ?  Motoren ? Hohe plötzliche 
Stromaufnahme von Waschmaschine, Geschirrspüler, Staubsauger ? Anlauf 
von Kompressoren ? Bohrmaschinen (oder ähnliche Motoren) wo die Kohlen 
feuern ? Oder evt. einfach der WDT, der zuschlägt, weil die 
Stromversorgung nicht sauber ist ?
Kann ja evt. auch aus der Nachbarschaft kommen ? - nur so Ideen -

[Stefan T. (isnoahoy)]

Hallo Daniel R.,

danke daß Du Dir den Source vom Hersteller ansiehst und nicht die leider 
etwas überholten Informationen im hoymiles-format-description.txt/.md.
Es hat sich leider noch niemand gefunden, der das Format/Protokoll auf 
den aktuellen Wissensstand bringt, ich auch noch nicht =^/

Wenn Du dazu jetzt noch die hoymiles-DTU-PRO-GPRS mit der aktuelleren 
hoymiles-DTU-PRO-APP vergleichst wurde an der von Dir angesprochenen 
Stelle noch folgende Vorbedingung in User/NRF/usart_nrf.c eingebaut:

#ifdef DTU3PRO

     if((Dtu3Detail.Property.Zero_Export_Switch == 1) ||
            (Dtu3Detail.Property.DRM_Limit_Switch == 1) ||
            (Dtu3Detail.Property.Phase_Balance_Switch == 1) ||
            (Dtu3Detail.Property.SunSpec_Switch == 1))
    {
        if(MIMajor[PortNO].Property.Acq_Switch == 0)
        {
            //1000w¹Ø»ú ÌØÊâ¿ØÖÆ IDºó8λСÓÚ0x50000000µÄ1ÍÏËÄ µÄ΢Äæ¿ØÖÆ
            if((MIMajor[PortNO].Property.Id[0] < 0X50) && 
((MIMajor[PortNO].Property.Pre_Id[1] == 0X60) || 
(MIMajor[PortNO].Property.Pre_Id[1] == 0X61)))
...

Den chinesesischen Unicode Kauderwelsch aus den beiden aktuelleren Repos 
habe ich noch nicht übersetzt.

[Stefan T. (isnoahoy)]

Hallo Josef J.,

Bei Dir sind drei WR konfiguriert, zumindest will er die alle abfragen. 
Bitte entferne alle überflüssigen Werte aus der Setup Seite für die WR 2 
und 3. Dann sollte es m.E. nach einem Reboot funktionieren.

Je nach Version werden die Werte beim Erase EEPROM nicht mit sinnvollen 
Werten gefüllt. Ich glaube Lukas P. hat das in der v0.4.20 die Tage erst 
angepaßt / gefixt.

[Stefan T. (isnoahoy)]

Hallo Daniel R.,

im usart_nrf3.c findet sich übrigens noch der folgende Code:

void UsartNrf3_Send_NetCmdToNrfCmd(void)
{
    if((CurNetCmd >= NET_TURN_ON) && (CurNetCmd <= NET_ELE_ENERGY))
    {
        switch(CurNetCmd)
        {
            case NET_INVERTER_HW_INFOR:
                //case NET_TERMINAL_INFOR:
                SubCmd = InverterDevInform_Simple;
                MainCmd = REQ_ARW_DAT_ALL;
                break;

            case NET_POLL_GRID_ON_FILE:
                SubCmd = GridOnProFilePara;
                MainCmd = REQ_ARW_DAT_ALL;
                break;

            //////////////////////////////////////////////////////////////////////ÔËÐпØÖÆ

            case NET_TURN_ON:
                SubCmd = Type_TurnOn;//¿ª»ú
                MainCmd = DEVCONTROL_ALL;
                break;

            case NET_TURN_OFF:
                SubCmd = Type_TurnOff;//¹Ø»ú
                MainCmd = DEVCONTROL_ALL;
                break;

            case NET_LIMIT_ACTIVE_POEWR:
            case NET_LIMIT_POEWR:
                SubCmd = Type_ActivePowerContr ;//ÏÞÖÆÓйŠ¹ŠÂÊ
                MainCmd = DEVCONTROL_ALL;
                break;

            case NET_LIMIT_REACTIVE_POWER:
                SubCmd = Type_ReactivePowerContr ;//ÏÞÖÆÎÞ¹Š¹ŠÂÊ
                MainCmd = DEVCONTROL_ALL;
                break;

            case NET_PF_SET:
                SubCmd = Type_PFSet ;//ÏÞÖƹŠÂÊÒòÊý
                MainCmd = DEVCONTROL_ALL;
                break;

            case NET_CLEAN_GFDI:
            case NET_CLEAR_ALARM:
                SubCmd = Type_CleanState_LockAndAlarm ;//ËøËÀžæŸ¯Çå³ý
                MainCmd = DEVCONTROL_ALL;
                break;

            case NET_RESTART: //ÏÂÔسÌÐò/žŽÎ»
                MainCmd = DEVCONTROL_ALL;
                SubCmd = Type_Restart;
                break;

            case  NET_UNLOCK:
                SubCmd = Type_Unlock;
                MainCmd = DEVCONTROL_ALL;
                break;

            case NET_LOCK:
                SubCmd = Type_Lock;
                MainCmd = DEVCONTROL_ALL;
                break;

            //dong 2020-06-15
            case NET_SELF_INSPECTION:
                SubCmd = Type_SelfInspection;//×ÔŒì
                MainCmd = DEVCONTROL_ALL;
                break;

            ////////////////////////////////////////////////////////////////²ÎÊýÅäÖÃ
            case NET_ELE_ENERGY:
            case NET_SET_ENERGY:
                SubCmd = EleEnergySet;
                MainCmd = PARASET_ALL;
                break;

            case NET_SET_PASSWORD:
            case NET_CANCEL_GUARD:
                SubCmd = AntitheftParaSet;//ÉèÖÃÃÜÂë
                MainCmd = PARASET_ALL;
                break;

            ////////////////////////////////////////////////////////////////ÎÄŒþ¶à°üžüÐÂÎÄŒþ
            case NET_DOWNLOAD_PRO:
                MainCmd = DOWN_PRO;
                SubCmd = Type_Init;
                break;

            case NET_DOWNLOAD_DAT://²¢Íø±£»€ÎÄŒþ
                MainCmd = DOWN_DAT;
                SubCmd = Type_Init;
                break;

            default:
                break;
        }
    }
    else if(CurNetCmd == NET_INIT)
    {
        MainCmd = REQ_ARW_DAT_ALL;

        if(CurPollIsDebugDataTime == false)
        {
            SubCmd = RealTimeRunData_Reality;
        }
        else
        {
            SubCmd = RealTimeRunData_Debug;
        }
    }
    //dong 2020-06-15
    //    else if(CurNetCmd == NET_SELF_STAUS)
    //    {
    //        MainCmd = REQ_ARW_DAT_ALL;
    //        SubCmd = GetSelfCheckState;
    //    }
    //dong 2020-06-23
    //    else if(CurNetCmd == NET_GET_LOSS_RATE)
    //    {
    //        MainCmd = REQ_ARW_DAT_ALL;
    //        SubCmd = GetLossRate;
    //    }
    else if(CurNetCmd == NET_ALARM_DATA)
    {
        MainCmd = REQ_ARW_DAT_ALL;
        SubCmd = AlarmData;
    }
    else if(CurNetCmd == NET_RECORD_DATA)
    {
        MainCmd = REQ_ARW_DAT_ALL;
        SubCmd = RecordData;
    }
    else if(CurNetCmd == NET_ALARM_UPDATE)
    {
        MainCmd = REQ_ARW_DAT_ALL;
        SubCmd = AlarmUpdate;
    }
    else if(CurNetCmd == NET_MI_VERSION)
    {
        SubCmd = InverterDevInform_Simple;
        MainCmd = REQ_ARW_DAT_ALL;
    }
}

in der usart_nrf3.h stehen die Defines:

#define DEVCONTROL_ALL         0x51
...
typedef enum
{
    Type_TurnOn = 0,
    Type_TurnOff = 1,
    Type_Restart = 2,
    Type_Lock = 3,
    Type_Unlock = 4,
    Type_ActivePowerContr = 11, // 0x0b
    Type_ReactivePowerContr = 12, // 0x0c
    Type_PFSet = 13, // 0x0d
    Type_CleanState_LockAndAlarm = 20,
    //dong 06-15
    Type_SelfInspection = 40,//���������ļ��Լ�
    Type_Init = 0xff,
} DevControlType;

Aber ich dachte das hätten wir schon letzte / vorletzte Woche 
festgestellt.
Bitte schau Dir das doch auch mal an ...