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

isnoAhoy schrieb:
> Interessant ist hier vor allem auch der InitDataState 0xff den der
> Hoymiles immer wieder sendet um den Wechselrichter in einen definierten
> Zustand zu bringen. D.h. wenn eines der Kommandos keine richtige Antwort
> ergibt, wird ein NET_INIT ausgelöst, der das InitDataState schickt.
>
> @Daniel R.,
> Vielleicht ist das ja auch das fehlende Glied um z.B. die Power Limit
> Funktion zu nutzen ?

Ui, darauf habe ich gar nicht geachtet! Guter Punkt.
Lass mich das später nochmal anschauen, gibt es die Möglichkeit dich 
außerhalb von µC zu Kontaktieren?

Hallo

Wollte mal fragen, ob jemand auch den MI integriert oder überhaupt 
integrieren wird?

Ich befürworte es, das man versucht alle Versionen zu integrieren. :)

isnoAhoy schrieb:
> Dein Discord Invite ist expired. Kannst Du nochmal einen schicken ?

https://discord.gg/WzhxEY62mB bitte schön. :)

Daniel R. schrieb:
> Ich befürworte es, das man versucht alle Versionen zu integrieren. :)

Wenn es dir weiter hilft, kann ich dir meine Version für den MI geben, 
oder hab ich schon?

isnoAhoy schrieb:

> Interessant ist hier vor allem auch der InitDataState 0xff den der
> Hoymiles immer wieder sendet um den Wechselrichter in einen definierten
> Zustand zu bringen. D.h. wenn eines der Kommandos keine richtige Antwort
> ergibt, wird ein NET_INIT ausgelöst, der das InitDataState schickt.
>
> @Daniel R.,
> Vielleicht ist das ja auch das fehlende Glied um z.B. die Power Limit
> Funktion zu nutzen ?

Habe heute nochmals lange nach gesnifft, meine DTU-Pro sendet definitiv 
keine InitDataState 0xff zum MI.

wenn
#define DEVCONTROL_ALL 0x51
für alle gilt müsste ja auch für HM gehen, hmmm??

Ziyat T. schrieb:
> Wenn es dir weiter hilft, kann ich dir meine Version für den MI geben,
> oder hab ich schon?

Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" ist es das 
hier?
Hast du auch Github, dann könntest du es vorerst dort pflegen.

Vielleicht kann man später das ganze mergen. Bin aktuell heiß auf die HM 
Limitierung. :)

Moin,

gibt es eine Quelle wo man die Binarys der aktuellen Version downloaden 
kann?

schaue ein paar Beiträge zurück, da hab ich geschrieben wo in Github 
diese zu finden sind.

Ziyat T. schrieb:
> Daniel R. schrieb:
>> Ich befürworte es, das man versucht alle Versionen zu integrieren. :)
>
> Wenn es dir weiter hilft, kann ich dir meine Version für den MI geben,
> oder hab ich schon?

Wo liegt deine Version? Wenn es nicht allzu viel Aufwand ist und jemand 
sich zum Testen bereit erklärt würde ich es mir anschauen, habe selbst 
keinen MI.

Lukas P. schrieb:
> schaue ein paar Beiträge zurück, da hab ich geschrieben wo in Github
> diese zu finden sind.

Ok, das habe ich gelesen. Der Trick war nur, dass man auf Github 
eingeloggt sein muss um den Downloadlink zu sehen.

Danke!

Lukas P. schrieb:
Daniel R. schrieb:

> Wo liegt deine Version? Wenn es nicht allzu viel Aufwand ist und jemand
> sich zum Testen bereit erklärt würde ich es mir anschauen, habe selbst
> keinen MI.

Die Quick&Dirty für MI-1500, erwartet bitte keine Qualitaet, auf der 
Basis v. Hubi!

Laeuft auf ESP8266 und ArduiniUNO(ohne WiFi)

Im settings.h ist alles einzustellen
- Laeuft als Sniffer, wenns definiert (adr 0x00aa, 0x0055, hört alles 
mit).
- Channel hopping auch beim RX
- Mit/Ohne Interrupt,CRC zum Testen
- hat MQTT (auf meine Art) wenn Wifi, bekommt SmartMeterPower über MQTT
- kann über Serielle-SS gesteuert werden:
  * Befehl 1-1000: Leistungs Limitierung in Watt/ 0:stop limiting
  * Befehl 2000: serial help
  * Befehl 2001: WR-Info
  * BEfehl 2002-2004 : set PA_LEVEL

Kann eure SW testen wenn sie auf esp8266 laeuft.

Ziyat T. schrieb:
> isnoAhoy schrieb:
>
>> Interessant ist hier vor allem auch der InitDataState 0xff den der
>> Hoymiles immer wieder sendet um den Wechselrichter in einen definierten
>> Zustand zu bringen. D.h. wenn eines der Kommandos keine richtige Antwort
>> ergibt, wird ein NET_INIT ausgelöst, der das InitDataState schickt.
>>
>> @Daniel R.,
>> Vielleicht ist das ja auch das fehlende Glied um z.B. die Power Limit
>> Funktion zu nutzen ?
>
> Habe heute nochmals lange nach gesnifft, meine DTU-Pro sendet definitiv
> keine InitDataState 0xff zum MI.
>
> wenn
> #define DEVCONTROL_ALL 0x51
> für alle gilt müsste ja auch für HM gehen, hmmm??

Hallo Ziyat T.,

ja Du hast Recht.

Das CurRecSendPackageDataType = InitDataState setzt er nur in zwei 
anderen Fällen und einmal initial.

Das mit dem SubCmd = Type_Init (0xff) scheint nur bei
* MainCmd = DOWN_PRO (0x0e)
oder
* MainCmd = DOWN_DAT (0x0a)
verwendet zu werden.

Bei allen anderen Anfragen erfolgt vorher ein CurNetCmd = NET_INIT, also
* MainCmd = REQ_ARW_DAT_ALL (0x15) und
* SubCmd = RealTimeRunData_Reality (0x0c) bzw.
* SubCmd = RealTimeRunData_Debug (0x0b).

Wir verwenden ja schon länger den zweiten Fall 0x0b für die Status 
Meldungen.

Tobias schrieb:
> Sehe ich das richtig, dass ich ohne die Seriennummer meines HM-600
> nichts empfangen kann?

So sieht es aus !  Vielleicht hast Du Glück und es hat die S/N jemand 
eingescannt und sie steht auf Rechnung / Lieferschein.

Hallo Hubi,
habe mit Zufriedenheit die SW-Varianten vom 13.04.22 und 5.06.22 an 
einem HM800 erprobt.
Finde die SW-Lösung vom 13.04.22 wegen der expliziten Darstellung der 
Werte übersichtlicher als die vom 5.06.22.
Habe heute beim Übernehmen der Daten für die E-Woche festgestellt, das 
auf Grund der 4 Bytes nur maximal 65535 W angegeben werden können.
Bei der Aufsummierung der Werte > 65535 springt der Zähler wieder auf 0 
und beginnt von neuem. Frage : Ist irgend eine der 4Byte in der Abfrage 
ein Zähler für die Summierung der Überläufe?

weiterhin gutes Gelingen.
Fritsche

@Tobias, laut Hersteller soll es eine Scan Funktion geben.
Wenn wir das nach Entwickeln können und eingebaut haben, sollte es dann 
kein Problem mehr sein. :)

Das ist richtig, da wir Thema Scan noch nicht implemtiert haben/können.

Ich bin gerade die Alarme auszulesen und konnte schonmal Erfolg 
verbuchen! :)

Habe mit isnoahoy folgende Beiträge durchgesichtet und diese auch 
probiert:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Und tatsächlich  konnte ich Payloads erhalten. Es gibt nur ein Problem:
Wenn ich auf Kanal 3 oder 75 sende, bekomme ich bessere Ergebnise.
Bei zuvielen Retransmits, bricht der skript ab und fängt von neu an...

Hier jetzt mal mein Ergebnis (noch nicht analysiert!):

1

Poll inverter 116174403329

2

Transmit 27 | 15 74 40 33 29 78 56 34 12 80 11 00 62 7b 69 fe 00 00 00 00 00 00 00 00 47 d7 bc

3

Received 27 bytes channel 40: 95 74 40 33 29 74 40 33 29 01 00 01 80 01 00 01 62 26 62 26 00 00 00 00 00 d1 c4

4

Received 27 bytes channel 40: 95 74 40 33 29 74 40 33 29 02 00 04 62 2e 00 00 00 00 00 00 00 d2 00 05 62 2e 44

5

Received 27 bytes channel 23: 95 74 40 33 29 74 40 33 29 03 00 00 00 00 00 00 00 cf 00 06 63 5a 00 00 00 00 66

6

Received 27 bytes channel 23: 95 74 40 33 29 74 40 33 29 04 00 dc 40 8f 00 0c 62 2e 69 fd 00 03 07 a3 40 93 22

7

Received 27 bytes channel 3: 95 74 40 33 29 74 40 33 29 05 00 0d 62 2e 69 fd 00 00 00 00 80 02 00 22 6c a4 2d

8

Received 27 bytes channel 3: 95 74 40 33 29 74 40 33 29 06 6c a4 ff ff ff fa 80 02 00 23 6c ab 6c ab ff ff ff

9

Received 27 bytes channel 3: 95 74 40 33 29 74 40 33 29 07 ff f9 80 02 00 24 6c ec 6c ec ff ff ff bf 80 02 f0

10

Error while retrieving data: Missing packet: Last packet 7

11

12

Transmit 11 | 15 74 40 33 29 78 56 34 12 88 bb

13

Received 27 bytes channel 23: 95 74 40 33 29 74 40 33 29 08 00 25 6c f1 6c f1 ff ff ff fb 80 02 00 26 6c fb 8f

14

Error while retrieving data: Missing packet: Last packet 8

15

16

Transmit 11 | 15 74 40 33 29 78 56 34 12 89 ba

17

Received 27 bytes channel 23: 95 74 40 33 29 74 40 33 29 09 6c fb ff ff ff f6 80 02 00 27 6d 18 6d 18 ff ff a7

18

19

Error while retrieving data: Missing packet: Last packet 9

20

Transmit 11 | 15 74 40 33 29 78 56 34 12 8a b9

21

Received 27 bytes channel 23: 95 74 40 33 29 74 40 33 29 0a ff e3 80 02 00 28 6d 22 6d 22 ff ff ff f6 80 02 a2

22

Error while retrieving data: Missing packet: Last packet 10

23

24

Transmit 11 | 15 74 40 33 29 78 56 34 12 8b b8

25

Received 27 bytes channel 40: 95 74 40 33 29 74 40 33 29 0b 00 29 6d 27 6d 27 ff ff ff fb 80 02 00 2a 6d 32 44

26

Error while retrieving data: Missing packet: Last packet 11

27

28

Transmit 11 | 15 74 40 33 29 78 56 34 12 8c bf

29

Received 19 bytes channel 23: 95 74 40 33 29 74 40 33 29 8c 6d 32 ff ff ff f5 53 03 1c

30

31

Payload: 00 01 80 01 00 01 62 26 62 26 00 00 00 00 00 d1 00 04 62 2e 00 00 00 00 00 00 00 d2 00 05 62 2e 00 00 00 00 00 00 00 cf 00 06 63 5a 00 00 00 00 00 dc 40 8f 00 0c 62 2e 69 fd 00 03 07 a3 40 93 00 0d 62 2e 69 fd 00 00 00 00 80 02 00 22 6c a4 6c a4 ff ff ff fa 80 02 00 23 6c ab 6c ab ff ff ff f9 80 02 00 24 6c ec 6c ec ff ff ff bf 80 02 00 25 6c f1 6c f1 ff ff ff fb 80 02 00 26 6c fb 6c fb ff ff ff f6 80 02 00 27 6d 18 6d 18 ff ff ff e3 80 02 00 28 6d 22 6d 22 ff ff ff f6 80 02 00 29 6d 27 6d 27 ff ff ff fb 80 02 00 2a 6d 32 6d 32 ff ff ff f5 53 03

32

 payload has valid modbus crc

Das einzige was bei mir nicht passt:
Quelle: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

1

payload has valid modbus crc

2

80 01 00 01 62 26 62 26 00 00 00 00:

3

 uptime=6:58:46 a_count=1 opcode=128 a_code=1 a_text=Inverter start

4

 BBHHHHH: (128, 1, 1, 25126, 25126, 0, 0)

5

00 d1 00 04 62 2e 00 00 00 00 00 00:

6

 uptime=6:58:54 a_count=4 opcode=0 a_code=209 a_text=Port 1 no input

7

 BBHHHHH: (0, 209, 4, 25134, 0, 0, 0)

8

00 d2 00 05 62 2e 00 00 00 00 00 00:

9

 uptime=6:58:54 a_count=5 opcode=0 a_code=210 a_text=Port 2 no input

10

 BBHHHHH: (0, 210, 5, 25134, 0, 0, 0)

11

00 cf 00 06 63 5a 00 00 00 00 00 dc:

12

 uptime=7:03:54 a_count=6 opcode=0 a_code=207 a_text=Input port 1 & 2 undervoltage

13

 BBHHHHH: (0, 207, 6, 25434, 0, 0, 220)

14

40 8f 00 0c 62 2e 69 fd 00 03 07 a3:

15

 uptime=6:58:54 a_count=12 opcode=64 a_code=143 a_text=Grid undervoltage

16

 BBHHHHH: (64, 143, 12, 25134, 27133, 3, 1955)

17

40 93 00 0d 62 2e 69 fd 00 00 00 00:

18

 uptime=6:58:54 a_count=13 opcode=64 a_code=147 a_text=Power grid outage

19

 BBHHHHH: (64, 147, 13, 25134, 27133, 0, 0)

20

80 02 00 22 6c a4 6c a4 ff ff ff fa:

21

 uptime=7:43:32 a_count=34 opcode=128 a_code=2 a_text=DTU command failed

22

 BBHHHHH: (128, 2, 34, 27812, 27812, 65535, 65530)

23

80 02 00 23 6c ab 6c ab ff ff ff f9:

24

 uptime=7:43:39 a_count=35 opcode=128 a_code=2 a_text=DTU command failed

25

 BBHHHHH: (128, 2, 35, 27819, 27819, 65535, 65529)

26

80 02 00 24 6c ec 6c ec ff ff ff bf:

27

 uptime=7:44:44 a_count=36 opcode=128 a_code=2 a_text=DTU command failed

28

 BBHHHHH: (128, 2, 36, 27884, 27884, 65535, 65471)

29

80 02 00 25 6c f1 6c f1 ff ff ff fb:

30

 uptime=7:44:49 a_count=37 opcode=128 a_code=2 a_text=DTU command failed

31

 BBHHHHH: (128, 2, 37, 27889, 27889, 65535, 65531)

32

80 02 00 26 6c fb 6c fb ff ff ff f6:

33

 uptime=7:44:59 a_count=38 opcode=128 a_code=2 a_text=DTU command failed

34

 BBHHHHH: (128, 2, 38, 27899, 27899, 65535, 65526)

35

80 02 00 27 6d 18 6d 18 ff ff ff e3:

36

 uptime=7:45:28 a_count=39 opcode=128 a_code=2 a_text=DTU command failed

37

 BBHHHHH: (128, 2, 39, 27928, 27928, 65535, 65507)

38

80 02 00 28 6d 22 6d 22 ff ff ff f6:

39

 uptime=7:45:38 a_count=40 opcode=128 a_code=2 a_text=DTU command failed

40

 BBHHHHH: (128, 2, 40, 27938, 27938, 65535, 65526)

41

80 02 00 29 6d 27 6d 27 ff ff ff fb:

42

 uptime=7:45:43 a_count=41 opcode=128 a_code=2 a_text=DTU command failed

43

 BBHHHHH: (128, 2, 41, 27943, 27943, 65535, 65531)

44

80 02 00 2a 6d 32 6d 32 ff ff ff f5:

45

 uptime=7:45:54 a_count=42 opcode=128 a_code=2 a_text=DTU command failed

46

 BBHHHHH: (128, 2, 42, 27954, 27954, 65535, 65525)

Tobias schrieb:
> Daniel R. schrieb:
> Wechselrichter seine Seriennummer irgendwie "broadcasted".

Also mein bisheriges Sniffen zwischen DTU-Pro und MI-1500: hab noch nie 
ein braodcast vom MI gesehen, auch wenn die DTU ausgeschaltet war.
An welche Adresse soll broadcastet werden?

Der WR ist ohne eine Abfrage quasi tot, zumindestens der MI-1500

(mein Sniffer hört auf "alles" wechselweise auf mehreren kanaelen)

@Ziyat T. Ich habe bisher nur im Manual gelesen das man via Webinterface 
in der DTU das Umfeld Scannen kann.  Damit man weitere Wechselrichter 
finden kann.

Quelle: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Daniel R. schrieb:
> Das einzige was bei mir nicht passt:
> Quelle: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
>
Die v. Jonas erwaenhte Quelle ist für die HMS Serie !

Daniel R. schrieb:
> @Ziyat T. Ich habe bisher nur im Manual gelesen das man via Webinterface
> in der DTU das Umfeld Scannen kann.  Damit man weitere Wechselrichter
> finden kann.
>
> Quelle: Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"

Das ist soweit korrekt, nur auf dem Android-Phone per Installer-APP.
Die APP fragt einfach mal alle WR Modelle ab, also es ist nicht 
richtiges broadcasting, der WR macht also nichts

In der Excel steht folgendes, kannst du das mal probieren für MI?
Siehe Anhang.

Target würde ich mal als DTU sehen, oder?

Gongfa steht für:
to attack
to raid

Tobias schrieb:
> Bei den
> nrf-Sniffern die ich hier verlinkt fand, war allerdings die Eingabe der
> Seriennummer Voraussetzung.

Wenn du auf esp8266 bist kannst du die nehmen als Sniffer, braucht keine 
WR/DTU Adresse:
Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?"
im settings.h "sniffer" einstellen

Daniel R. schrieb:
> In der Excel steht folgendes, kannst du das mal probieren für MI?
> Siehe Anhang.
>
> Target würde ich mal als DTU sehen, oder?
>
> Gongfa steht für:
> to attack
> to raid

Ich werde mir das Ding nochmals anschauen

Edit: habe vorher eine falsche Antwort geschrieben, ich habe die 0xf 
implementiert

Morgen zusammen,

@Jan-Jonas S.: Also den Python Code müssten man irgendwann mal 
optimieren. :D
ABER: Es läuft schonmal zwecks Logs auswertung ziemlich gut!

1

2022-07-14 20:08:34.249099 Payload: 00 01 80 01 00 01 4d 02 4d 02 00 00 00 00 00 d1 00 04 4d 0a 00 00 00 00 00 00 00 d2 00 05 4d 0a 00 00 00 00 00 00 00 cf 00 06 4e 36 00 00 00 00 00 dc 40 8f 00 0c 4d 0a 54 d9 00 03 07 a3 40 93 00 0d 4d 0a 54 d9 00 00 00 00 80 02 00 40 6c 85 6c 85 ff ff ff fb 80 02 00 41 6c 8b 6c 8b ff ff ff fa 80 24 00 42 6d 09 6d 09 09 06 eb ec 00 94 00 43 6d 0a 00 00 0f 06 00 00 80 02 00 44 6d 14 6d 14 ff ff ff 77 80 02 00 45 6d 3a 6d 3a ff ff ff da 80 02 00 46 6d 3f 6d 3f ff ff ff fb 80 02 00 47 6d 46 6d 46 ff ff ff f9 80 02 00 48 6d 50 6d 50 ff ff ff f6 06 28

2

 payload has valid modbus crc

3

80 01 00 01 4d 02 4d 02 00 00 00 00: 

4

 uptime=5:28:34 a_count=1 opcode=128 a_code=1 a_text=Inverter start

5

 BBHHHHH: (128, 1, 1, 19714, 19714, 0, 0)

6

00 d1 00 04 4d 0a 00 00 00 00 00 00: 

7

 uptime=5:28:42 a_count=4 opcode=0 a_code=209 a_text=Port 1 no input

8

 BBHHHHH: (0, 209, 4, 19722, 0, 0, 0)

9

00 d2 00 05 4d 0a 00 00 00 00 00 00: 

10

 uptime=5:28:42 a_count=5 opcode=0 a_code=210 a_text=Port 2 no input

11

 BBHHHHH: (0, 210, 5, 19722, 0, 0, 0)

12

00 cf 00 06 4e 36 00 00 00 00 00 dc: 

13

 uptime=5:33:42 a_count=6 opcode=0 a_code=207 a_text=Input port 1 & 2 undervoltage

14

 BBHHHHH: (0, 207, 6, 20022, 0, 0, 220)

15

40 8f 00 0c 4d 0a 54 d9 00 03 07 a3: 

16

 uptime=5:28:42 a_count=12 opcode=64 a_code=143 a_text=Grid undervoltage

17

 BBHHHHH: (64, 143, 12, 19722, 21721, 3, 1955)

18

40 93 00 0d 4d 0a 54 d9 00 00 00 00: 

19

 uptime=5:28:42 a_count=13 opcode=64 a_code=147 a_text=Power grid outage

20

 BBHHHHH: (64, 147, 13, 19722, 21721, 0, 0)

21

80 02 00 40 6c 85 6c 85 ff ff ff fb: 

22

 uptime=7:43:01 a_count=64 opcode=128 a_code=2 a_text=DTU command failed

23

 BBHHHHH: (128, 2, 64, 27781, 27781, 65535, 65531)

24

80 02 00 41 6c 8b 6c 8b ff ff ff fa: 

25

 uptime=7:43:07 a_count=65 opcode=128 a_code=2 a_text=DTU command failed

26

 BBHHHHH: (128, 2, 65, 27787, 27787, 65535, 65530)

27

80 24 00 42 6d 09 6d 09 09 06 eb ec: 

28

 uptime=7:45:13 a_count=66 opcode=128 a_code=36 a_text=N/A

29

 BBHHHHH: (128, 36, 66, 27913, 27913, 2310, 60396)

30

00 94 00 43 6d 0a 00 00 0f 06 00 00: 

31

 uptime=7:45:14 a_count=67 opcode=0 a_code=148 a_text=Grid disconnection

32

 BBHHHHH: (0, 148, 67, 27914, 0, 3846, 0)

33

80 02 00 44 6d 14 6d 14 ff ff ff 77: 

34

 uptime=7:45:24 a_count=68 opcode=128 a_code=2 a_text=DTU command failed

35

 BBHHHHH: (128, 2, 68, 27924, 27924, 65535, 65399)

36

80 02 00 45 6d 3a 6d 3a ff ff ff da: 

37

 uptime=7:46:02 a_count=69 opcode=128 a_code=2 a_text=DTU command failed

38

 BBHHHHH: (128, 2, 69, 27962, 27962, 65535, 65498)

39

80 02 00 46 6d 3f 6d 3f ff ff ff fb: 

40

 uptime=7:46:07 a_count=70 opcode=128 a_code=2 a_text=DTU command failed

41

 BBHHHHH: (128, 2, 70, 27967, 27967, 65535, 65531)

42

80 02 00 47 6d 46 6d 46 ff ff ff f9: 

43

 uptime=7:46:14 a_count=71 opcode=128 a_code=2 a_text=DTU command failed

44

 BBHHHHH: (128, 2, 71, 27974, 27974, 65535, 65529)

45

80 02 00 48 6d 50 6d 50 ff ff ff f6: 

46

 uptime=7:46:24 a_count=72 opcode=128 a_code=2 a_text=DTU command failed

47

 BBHHHHH: (128, 2, 72, 27984, 27984, 65535, 65526)

Meiner Meinung nach müsste man die Log auswertung etwas leserlicher 
gestalten.
Es soll sich so lesen als würde man einfach ein Log AUszug aus dem 
Webinterface geben. :)

Kann jemand mal ein Screenshoot aus einer echten DTU-Webinterface von 
der Log bereitstellen?

@Jan-Jonas S.: Was fehlt hier eigentlich noch, wo müsste man noch etwas 
analyzieren?

Daniel R. schrieb:
> Kann jemand mal ein Screenshoot aus einer echten DTU-Webinterface von
> der Log bereitstellen?

Ich habe eine DTU Pro. Lokales Webinterface gibt es da keines und in der 
Cloud sehe ich bei meinem Installer Account keine Möglichkeit ein Log zu 
sehen.

DTU-Pro hat kein Webinterface?
Das ist ja schwach. ^^

Ok aber an sich müsste das Log auslesen irgendwie gehen. Hmm..

Hallo Jan-Jonas,

uptime ist tatsächlich ein Zeitstempel also WTime1 / AlarmStartTime, 
wobei das Bits 13 (Start) des long WCode (d.h. opcode<<8 | a_code) also 
Bit 5 des opcode bestimmt ob es AM = 0 / PM = 1 ist.

Der long Wert hinter uptime ist die WTime2 / AlarmEndTime, hier bestimmt 
Bit 12 (End) also Bit 4 des opcode ob es AM = 0 / PM = 1 ist.
Bit 15 und 14 bestimmen (also Bit 7 und 6 des opcode) wie der RunStatus 
des Wechselrichters ist (siehe oben).

Wir sollten also uptime in starttime umbenennen, die endtime hinzunehmen 
und die AM/PM Berechnung einbauen.

Den RunStatus habe ich noch nicht ganz durchschaut, der wird offenbar 
auch per ModBus486 und NetProtocol an den Server weitergegeben.

Was die WData1 und WData2 in den beiden longs ganz rechts sind, weiß ich 
auch nicht. Das hängt bestimmt von dem von Dir so genannten a_code ab.

BTW: die a_code's können übrigens noch bis zu 12 Bit groß sein. Aber ich 
denke die Übersetzungstabelle die Du eingebaut hast scheint ganz gut zu 
funktionieren und die höchsten vier Bit sind offenbar noch nicht 
vergeben worden.

isnoAhoy schrieb:
> und anhand des Bit 13 / 12 im WCode entschieden ob der
> AlarmStartTime / AlarmEndTime vormittags oder nachmittags liegt/lag.

Wo im Sourcecode siehst du das? Das war mir so anhand der 
UsartNrf3_Process_DevInform_Alarm Funktion nicht klar.

Hallo Thomas B.,
Hier mal der erste Teil für die Alarm Start Time mit Bit 13 des WCode 
(erster long/double Wert einer 12 byte Zeile), der Block wiederholt sich 
für die Alarm End Time und Bit 12.

1

                //Pending alarm afternoon

2

                if(((pRealAlarm[RealAlarmDataNO].Data.WCode >> 13) & 0x01) == 1)

3

                {

4

                    AlarmTime = 12 * 60 * 60 + (u32)(((u16)pProBuffer[i * 12 + 6] << 8) | ((u16)pProBuffer[i * 12 + 7])) + DateToSec(calendar);

5

                }

6

                //Pending alarm morning

7

                else

8

                {

9

                    AlarmTime = (u32)((u16)pProBuffer[i * 12 + 6] << 8) | ((u16)pProBuffer[i * 12 + 7]) + DateToSec(calendar);

10

                }

11

12

                //Alarm start time

13

                pRealAlarm[RealAlarmDataNO].Data.WTime1[0] = AlarmTime >> 24;

14

                pRealAlarm[RealAlarmDataNO].Data.WTime1[1] = AlarmTime >> 16;

15

                pRealAlarm[RealAlarmDataNO].Data.WTime1[2] = AlarmTime >> 8;

16

                pRealAlarm[RealAlarmDataNO].Data.WTime1[3] = AlarmTime;

D.h. die ersten beiden Bits 15 & 14 des WCode bestimmen den RunStatus 
und die Bit 13 & 12 bestimmen AM/PM der AlarmStartTime / AlarmEndTime 
Angaben.

Hallo Stefan,

aus welchem Repo kommt das? Bei mir ist die Bedingung:

1

if((calendar.hour * 60 * 60 + calendar.min * 60 + calendar.sec) / (12 * 60 * 60) > 0)

statt

1

if(((pRealAlarm[RealAlarmDataNO].Data.WCode >> 13) & 0x01) == 1)

@Thomas B.,
das ist aus dem iotloves bzw. dem m.W. identischen andycao1860 repos.
Im älteren michel_individual_organization war m.W. keine usart_nrf3.c 
Implementierung aber ich kann mich auch täuschen und die war einfach nur 
älter.
Ich habe mir deswegen den aktuelleren Code angesehen, da dort auch 
AntiReflux.c und andere schöne Funktionen implementiert sind.

Die usart_nrf[3].c/.h Dateien aus dem iotloves hatte ich gestern 
übersetzt und hier angehängt. Die aus dem michel_individual_organization 
schon vor einer ganzen Weile ebenfalls hier im Forum.

Hallo allerseits, ich bitte um Nachsicht wenn ich so reinplatze, ich 
habe diesen Thread zwar schon öfters durchkämmt, konnte aber mein 
Problem bzw. mein Anliegen nicht so richtig finden, deshalb meine Frage:
ich hab die wlan Datenpakete von einem Stick (DTU100W) mitgeschnitten 
und erhoffe mir darüber die mir wichtigen Informationen, wie Temperatur 
des Wechselrichters (HM-800) und die PV-Module-Power der einzelnen 
Panels, auszulesen. Ich bin mir ziemlich sicher, dass die Struktur der 
Datenpakete schon analysiert worden ist, doch wo könnte ich die finden?
Vielen Dank,
Hans
Ps: der screenshot zeigt eines der typischen Pakete, das sich pro Minute 
wiederholt. Es geht nicht um den Datenverkehr zwischen WR und irgend 
einen HW-Client, sondern  um den Datenverkehr zwischen DTU und Cloud, 
den ich abtrennen möchte.

Java L. schrieb:
> Hallo allerseits, ich bitte um Nachsicht wenn ich so reinplatze, ich
> habe diesen Thread zwar schon öfters durchkämmt, konnte aber mein
...
Hier analysieren wir die Kommunikation zwischen DTU... und HM-xxxx, 
MI-xxxx.

Hier wird NICHT analysiert der Netzwerktraffic zwischen DTU und der 
S-Miles-Cloud. Bitte mach dafür einen neuen Thread auf falls Dich das 
Interessiert. Das ist eine ganz andere Baustelle. Danke.

Daniel R. schrieb:
> DTU-Pro hat kein Webinterface?
> Das ist ja schwach. ^^
>
> Ok aber an sich müsste das Log auslesen irgendwie gehen. Hmm..

Wenn wer weiß wie, könnte ich dann, falls es hilft, dahingehend gerne 
was dazu beitragen

@isnoAhoy
@Daniel R. schrieb:
> In der Excel steht folgendes, kannst du das mal probieren für MI?
> Siehe Anhang.
>
> Target würde ich mal als DTU sehen, oder?
>
> Gongfa steht für:
> to attack
> to raid

Ich hab es probiert, bekomme nichts vom MI.

Meine DTU-Pro hat sowas auch nie geschickt, besser gesagt hab nie 
gesichtet.

Was ich nicht ganz verstehe ist, wie soll diese 0x2 als 
broadcast/search_packet gelten? Normalerweise ist die routing_adress ist 
ja die WR-Adresse, dann ist ja WR bekannt! Oder welche routing_adress 
sollte es sein?
target_adress ist DTU, das ist klar.

Für mich ist die 0x2 einfache WR Abfrage, oder?

A.D. schrieb:
> gibt es Wechselrichter bei denen es nicht funktioniert?
> Hab hier ein HM-600 der irgendwie nicht will.


An diesem Problem hab ich jetzt auch 2 Tage gehangen.
Keine Ahnung warum aber mein HM-600 wollte partout nicht
antworten wenn er nur auf Kanal 40 angefunkt wird.
Mit Kanal 3 und 23 funktioniert es.

Ich nehme an du verwendest Ahoy für den ESP8266?
Probiere mal ob es funktioniert wenn Du in der hmRadio.h
mTxChLst[0] = 40; änderst in Kanal 3 oder 23.

Hallo,

bin schon seit einer Weile mit Begeisterung den Thread am verfolgen. Da 
ich momentan ziemlich eingespannt bin kann ich leider nicht aktiv 
mitwirken.

Hätte folgende Fragen:

a) Ist die Einspeiselimitierung schon implementiert (z.B. 70%)?

b) Wurde schon die Modbusverbindung zu einem Smartmeter (z.B. CHINT 666) 
eingebunden zwecks z.B. Null-Einspeisung, alternativ z.B. auch Shelly 
oder andere?

Solong B.

tom schrieb:
> hat jemand eine fertige bin Datei von der aktuellen Version für mich?

Hier ist sie.

Ich habe in der AHOY 0.4.20 etwas experimentiert und schreibe die 
"inverter data" Ausgabe die normalerweise nur über die serielle 
Schnittstelle kommt zusätzlich auf eine SD Karte.

So können Laptop und Router beim loggen ausgeschaltet bleiben.
Ich würde gerne für jeden Tag eine neue Datei erstellen, verstehe aber 
nicht wie ich das aktuelle Datum aus der main.cpp in der app.cpp 
erhalte.

String logFilename = "log";
logFilename += date();
ergibt:
'date' was not declared in this scope


String logFilename = "log";
logFilename += year();
ergibt:
1970

Entweder ich bekomme "date" welches in der main.cpp schon berichtigt 
wird in die app.cpp, oder oder ich schaffe es die NTP Zeit auf die 
"Arduino time" zu übertragen damit year(), month() etc stimmen.

Ja, da scheitert es an Grundlagen, ist mir klar ;-)

Wäre trotzdem nett wenn mich jemand in die richtige Richtung schubsen 
würde.

Habe es jetzt mit meinem WEMOS D1 mini hinbekommen und werde es morgen 
testen.
Ein diff zum Head 0b9ab0100a9cf2b428911dfbe3f79d82886109e3 (0.4.20) 
hänge ich an.

CS Pin ist wie im Quellcode ersichtlich auf D0, der Rest MISO MOSI CLK 
VDD und GND ist wohl selbsterklärend.

Ich habe den D1 mini V2 von Reichelt, der ist bei mir noch nie 
ausgefallen.
https://secure.reichelt.at/at/de/d1-mini-esp8266-v2-0-d1-mini-p253978.html?&nbc=1

Markus schrieb:
> Hallo Zusammen,
>
> finde ich toll was ihr da so angestellt habt.
> ich versuche mich daran das auf einen ESP32 zu laden habe mich an die
> Anleitung gehalten in https://github.com/tbnobody/OpenDTU aber Probleme
> beim aufspielen auf den ESP32.
> habe 9immer die Fehlermeldung "Der Terminalprozess
> "C:\Users\Markus\.platformio\penv\Scripts\platformio.exe 'run',
> '--target', 'upload'" wurde mit folgendem Exitcode beendet: 1. "
>
> gruß Markus

Hallo Markus,

da sollten davor noch mehr Meldungen erscheinen. Diese dürften 
aussagekräftiger sein.

Ihr seit echt der Hammer!
Habe mir nen Wemos d1 mini und das Funkmodul gekauft, verkabelt, die 
220713_ahoy_0.4.25_esp8266.bin von Günther H. geflasht, dann per Wifi AP 
die Werte eingetragen und zack... alles läuft!
Vielen Dank!

Ich hoffe, dass die Leistungsbegrenzung noch kommt.

Hallo zusammen,

ich bin froh verkünden zu können, dass die Leistungsreduzierung / 
Leistungseinstellung für den HM300 funktioniert.
In den nächsten Tagen werde ich das Ganze dokumentieren und hier 
bereitstellen.
DanielR92 testet gerade seinen HM1500.

Auch ich werde noch Weiteres testen, wenn die Sonne wieder scheint ;-)

Viele Grüße
Klaus

Kla H. schrieb:
> DanielR92 testet gerade seinen HM1500.

Genau.
Habe für Python (RPi) denn Modbus CRC16 schon hinterlegt.
Das ganze möchte ich sauber noch ziehen, da es probleme beim Paket bauen 
gibt.

@Jan-Jonas: Da müsste man nochmal was anpassen. :)

Aktuell ist 0x80 immer fest als Sub-CMD sowie CMD.
Dies muss man abändern.

PS: Aktuell läuft die HM-1500 auf ~25W! =)

Hallo zusammen,

hier die erste Version des Protokolls:

https://github.com/tbnobody/OpenDTU/issues/35

https://github.com/grindylow/ahoy/issues/31

Vielen Dank an die tolle "Vorarbeit" hier im Forum.

Besonders Stefan T. Beitrag "Re: Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" 
und Daniel R. für die hilfreichen Hinweise.

Erste Version quick and dirty mit dem openDTU implementiert und 
getestet:

limit = zwei Byte, eine Dezimalstelle. Z.B: 30W = 300dez = 0x01 0x2c

1

<0x51> <WR>     <DTU>    <0x81>   <0x0b 0x00> <0x01 0x2c> <0x01 0x00>            <crc16/modbus> <crc8>

2

<Cmd>  <target> <source> <subcmd> <ctrlmode>  <limit>     <?desc?-fix 0x01 0x00> <crc16/modbus> <crc8>

Log:

1

22:28:13.964 > Fetch inverter: 112172615582

2

22:28:13.964 > sendPackSetPowerLimitCommand

3

22:28:13.966 > sendEsbPacket

4

22:28:13.969 > TX 51 72 61 55 82 78 56 34 12 81 0B 00 01 2C 01 00 C5 C0 3E 

5

...

6

22:28:14.897 > Interrupt received

7

22:28:14.897 > 

8

22:28:14.897 > >> RX  OK: D1 72 61 55 82 72 61 55 82 81 00 00 0B 00 14 07 48 

9

22:28:14.903 > 

10

22:28:15.271 > RX Period End

11

22:28:15.271 > getLastRequest() == RequestType::Cmd

12

22:28:15.275 > Success

Siehe auch :

1

usart_nrf3.cpp

2

UsartNrf_Send_DevControlUpdate()

3

...

4

                    MIMajor[PortNO].Property.Pass.PowerPFDev.SetValut[0] = (u8)(relative_value >> 8);

5

                    MIMajor[PortNO].Property.Pass.PowerPFDev.SetValut[1] = (u8)(relative_value);

6

                    MIMajor[PortNO].Property.Pass.PowerPFDev.Desc[0] = 0;

7

                    MIMajor[PortNO].Property.Pass.PowerPFDev.Desc[1] = 1;

...Happy coding...

VG
Klaus

Kla H. schrieb:
> Vielen Dank an die tolle "Vorarbeit" hier im Forum.
> limit = zwei Byte, eine Dezimalstelle. Z.B: 30.0W = 300dez = 0x01 0x2c

1

<0x51> <WR>     <DTU>    <0x81>   <0x0b 0x00> <0x01 0x2c> <0x01 0x00>            <crc16/modbus> <crc8>

2

<Cmd>  <target> <source> <subcmd> <ctrlmode>  <limit>     <?desc?-fix 0x01 0x00> <crc16/modbus> <crc8>

Danke fürs Ausprobieren und die Lösung, daß das Limit mit einer 
Dezimalstelle angegeben wird war mir bisher nicht klar. Das ist die 
Wucht, Gratuliere!

Mit besten Grüßen,
Stefan T.

Einfach genial.
Danke an die Hirnis hier!

locke987 schrieb:
> Wie erkennt man eigentlich wenn eine neue Version der OpenDTU verfügbar
> ist?
> Aktuell habe ich:
> SDK Version      v4.4.1-1-gb8050b365e
> Firmware Version    0.1.18
> Git Hash      g63ccf38
>
> Die habe ich heute gebuilded und die *.bin per Firmware Upgrade Funktion
> eingespielt. Erkennt man im Git irgenwo welche Version gerade aktuell
> ist?
> Vielen Dank!

Es gibt keine Versionsnummern. Alles was im Git ist ist stabil (nach 
bestem Wissen und Gewissen).
Die einzelnen Git Commits sieht man ja hier: 
https://github.com/tbnobody/OpenDTU/commits/master

Bei jedem Commit steht rechts der Git Hash. Im aktuellen Fall 63ccf38. 
Das ist auch der Git Hash den du in der System Overview siehst. Damit 
lässt sich exakt bestimmen welche Version man aktuell am laufen hat.

Hoyle schrieb:
> Mal eine Frage bezüglich der Leistungsreduzierung:
> Was genau bezweckt ihr denn damit? Ich für meinen Teil wäre eher
...
> Klärt ihr mich auf? Danke

Hier geht es um das Reverse Engineering des Protokolls und nicht ob 
etwas sinnvoll ist oder nicht. Wer es braucht und warum findest Du in 
den 1679 Beiträgen hier.
Wenn Du eine Diskussion über Deine Wünsche möchtest, mach bitte ein 
eigenen Thread auf und kapere nicht diesen. Da könnt Ihr dann auch über 
zu tauschende MOSFETs im WR diskutieren. Danke.

Hoyle schrieb:
> Mich interessiert der Anwedungsfall für die gewünschte
> Leistungsreduzierung - nicht mehr nicht weniger.

Ich war hier Anfangs auch etwas skeptisch was man denn mit diesem 
Feature möchte. Aber stelle dir vor, du möchtest nicht mehr einspeisen 
als du verbrauchst (weil in dem Moment der Zähler ja nicht rückwärts 
läuft und man es dem Netzbetreiber schenkt). Dann könnte man den WR 
limitieren und den Rest in eine Batterie speisen. Im Umkehrschluss 
könnte man Nachts z.B. den WR auf 50W begrenzen, den Input auf die 
Batterie legen und somit nur seinen Standby Verbrauch einspeisen. Das 
ist nur ein Beispiel. Weis nicht was es sonst noch für Use-Cases gibt.

Claus T. schrieb:
> Zum Anschluss des WR an eine Batterie, statt den Solarpanels, würde mich
> interessieren, ob es einen Befehl zum deaktivieren der MPPT-Regler für
> die Panels gibt, bzw. Batterie-Betrieb umschalten?
> Ist da bei der DTU-Pro was vorgesehen?

Moin,

ein Befehl dafür ist mir nicht aufgefallen. Der MPPT läuft automatisch 
ab eine bestimmten Spannung mit und versucht einfach, den Leistungspunkt 
zu optimieren.
Meine Erkenntnisse aus der DTU zeigen nur den "normalen" Leistungsumfang 
wie die 0-Einspeisung in Verbindung mit dem CHiNT Meter, die restliche 
Leistungsreduktion wurde durch Daniel R. dahingehend auf Basis dieser 
Befehle erfolgreich getestet.

Wenn du mehr darüber wissen willst, wir haben mittlerweile auf dem 
Discord einen Speichersysteme-Channel, wo wir sowas genauer besprechen 
können. Dort gibt es bereits mehrere Ansätze, bei denen du dich gerne 
mit Einbringen kannst, keine Idee ist verrückt genug :)

Turn On/Turn Off/Restart sind ebenfalls seit eben bekannt.

Das ganze werde ich für die MI-Version nachher noch anschauen, 
Leistungsreduktion auf der MI-Serie (bei mir MI-600) habe ich auch 
mitgeschnitten, ist nur noch nicht ausgewertet.
Controls muss ich extra machen, war leider schon zu dunkel dafür.

lg

Hier die drei o.g. Commands für das Ein-/Ausschalten bzw. den Reset des 
Wechselrichters.

1

51 76543210 78563412 81 0000 B001 A5 ------ Type_TurnOn 0x00

2

51 76543210 78563412 81 0100 2000 55 ------ Type_TurnOff 0x01

3

51 76543210 78563412 81 0200 D000 7B ------ Type_Restart 0x02

4

^^-------------------------------------- MainCmd 0x51 DEVCONTROL_ALL

5

   ^^^^^^^^----------------------------- WR Serial ID

6

            ^^^^^^^^-------------------- DTU Serial ID

7

                     ^^----------------- SingleFrameID

8

                        ^^-------------- SubCmd siehe oben

9

                        ^^^^------------ Control Mode ? immer zwei Byte im Gen3 Protokoll

10

                              ^^^^------ CRC16 / CRC-Modbus über die Daten, excl. Frame ID!

11

                                   ^^--- CRC8

Die CRC16 und CRC8 läßt sich ggf. online berechnen, falls es jemand mal 
schnell kontrollieren will:

CRC-16/CRC-Modbus Input Data: 0x0200
Result CRC-16/CRC-Modbus value: 0xD000
https://crccalc.com/?crc=0x0200&method=CRC-16/MODBUS&datatype=hex&outtype=0

CRC-8 Input value: 0x51 76543210 78563412 81 0200 D000
Result CRC-8 value: 0x7B
https://crccalc.com/?crc=0x517654321078563412810200D000&method=CRC-8/ITU&datatype=hex&outtype=0

---

Und hier das Power Limit setzen

1

51 76543210 78563412 81 0B00 012C 0000 55C1 0F ----- Power Limit 0x0B

2

^^--------------------------------------------- MainCmd 0x51 DEVCONTROL_ALL

3

   ^^^^^^^^------------------------------------ WR Serial ID

4

            ^^^^^^^^--------------------------- DTU Serial ID

5

                     ^^------------------------ SingleFrameID

6

                        ^^--------------------- SubCmd bzw. DevControlType: 0x0b = Type_ActivePowerContr

7

                        ^^^^------------------- Control Mode

8

                             ^^^^-------------- PowerPFDev.SetValut 0x012C = 30.0 W

9

                                  ^^^^--------- PowerPFDev.Desc 0x0000 oder 0x0001 ?

10

                                       ^^^^---- CRC16 / CRC-Modbus über die Daten, excl. Frame ID!

11

                                            ^^- CRC8

CRC-16/CRC-Modbus Input Data: 0x0B00 012C 0000
Result CRC-16/CRC-Modbus value: 0x55C1
https://crccalc.com/?crc=0x0B00012C0000&method=CRC-16/MODBUS&datatype=hex&outtype=0

CRC-8 Input value: 0x51 76543210 78563412 81 0B00 012C 0000 55C1
Result CRC-8 value: 0x0F
https://crccalc.com/?crc=0x517654321078563412810B00012C000055C1&method=CRC-8/ITU&datatype=hex&outtype=0

Die Antwort Pakete haben wir noch nicht entschlüsselt, aber es kommt 
immer (MainCmd | 0x80) also ANSWER_DEVCONTROL_ALL 0xD1 zurück. Bei 
Fehlern in der Nachricht oder der CRC-16/CRC-Modbus Checksumme kommt 
0xF1 oder 0xFF als Fehlercode je nachdem ob es sich um eine SingleFrame 
oder MultiFrame Anfrage gehandelt hat.

Stefan T. schrieb:
> Hier die drei o.g. Commands für das Ein-/Ausschalten bzw. den Reset des
> Wechselrichters....
Hallo Stefan T.,
sind die für für MI-xxxx oder HM-xxxx ?
SUPER Arbeit von Dir !

Tobi schrieb:
> Kurze Frage: muss es ein NRF24L01+ sein oder funktioniert auch ein
> NRF24L01?
Es MUSS ein "+"  sein

> Der WR hat genau einen Ausgang, und zwar die Netzeinspeisung (50Hz
> 230V). Wenn ich jetzt das limitiere, wie genau bekomme ich den Überfluss
> an Leistung aus dem PV panelen in meine Batterie?
>
Hallo,

ich denke die Idee dahinter ist, den WR (nicht nich bestimmungsmässem 
Gebrauch) an eine Batterie zu hängen (z.B. LiFePo mit 24, 36 oder 48V) 
und über die Begrenzung dann die Ausgangsleistung passend zum 
Hauverbrauch zu regeln. Das wäre eine sehr preisgünstige Sache mit einem 
Netzsetig konformen WR.

Gruß

Carsten

PS: vieleich hierzu ein Seperates Thema aufmachen, wenn es mehr Leute 
interessiert?

Herbert K. schrieb:
> sind die für für MI-xxxx oder HM-xxxx ?

Das betrifft die HM-Serie.

Mein TSUN ist eigentlich ein MI-600, daher habe ich für MI
folgendes direkt an der DTU Pro mitgeloggt:
OFF-CMD: 51 63500316 63500316 AA55 AE
ON-CMD:  51 63500316 63500316 55AA AE
Reboot: 0E 63500316 63500316 1000 0000 12EE E2

Leistung:
51 63500316 63500316 5A5A 2C0A 86F1
51 63500316 63500316 5A5A 1C06 C08B

Was aus der Leistung rauslesbar ist, weiß ich noch nicht, aber ihr habt 
erstmal wieder Futter für die 2-Kanal MI :)

Anbei außerdem diverse Logs direkt am NRF-Modul der Pro, drin zu finden 
Powerlimits in Verbindung mit dem CHiNT-Zähler, Limitierung des HM-1500 
und des MI-600, Reboot-, ON- und OFF- Commands.

Carsten B. schrieb:
> PS: vieleich hierzu ein Seperates Thema aufmachen, wenn es mehr Leute
> interessiert?

Die Thematik haben wir u.a. auf dem Discord. Ich denke, hier ist es 
sinnvoll, später ein extra Thema zu starten, wenn die Erkenntnisse 
soweit sind, dass man es verwenden kann, zumal div. Zähler/Messgeräte 
zusätzlich benötigt werden.
Aktuell ist es noch so, dass zwar grundlegende Funktionen bekannt sind, 
jedoch noch nicht überall integriert.

Derzeit hat Daniel R. ein Labornetzteil und einen Raspi zum Testen, mir 
fehlen Programmierkenntnisse um das ganze in AHOY und OpenDTU 
einzubauen, damit kann ich nur Daten abfischen und bereitstellen.

Die weitere Problematik ist die Berechnung der Limits anhand der 
benutzten Eingänge über mehrere Geräteklassen hinweg (1- und Mehrkanal 
HM/MI), was nicht ganz trivial ist.

Klar ist: Eine netzkonforme Ausspeisung aus einem Akku ist der Weg, den 
einige hier wünschen :)

lg

Hallo,

ich habe ein Problem mit dem Accesspoint den der ESP32 generiert, der 
wird für ca. 10 Sekunden angezeigt und verschnwindet dann. Kurz später 
ist er wieder da. Ebenso kommt ein Dialogfenster hoch in dem steht dass 
das Wlan eine Anmeldung benötigt, man sieht dann kurz die OpenDTU Seite 
die dann aber kurz später nicht mehr erreichbar ist.

Hat jemand eine Idee was das sein könnte?

Solong B

Update Leistungsregulierung MI-Serie (hier MI-600 & Kompatibel)

An der Schnittstelle zum NRF abgegriffene Daten sehen so aus:
<51> <63 50 03 16> <63 50 03 16> <5A 5A> <2D> <0A 9E> <E8>
Main-CMD 0x51, WR-ID, WR-ID, Sub-CMD 0x5A 0x5A, Limit %, Limit Absolut, 
CRC8

Die CRC8 über den ganzen Block.
Meine DTU sendet das Powerlimit basierend auf 1%=6W (100%=600W),
0x2D = 45%, 0x0A 0x9E = 271,8W (DEC 2.718)

51 63500316 63500316 5A5A 2D 0AA0 D6 -> 45% 272,0W
51 63500316 63500316 5A5A 65 17CC EF -> 101% 609,2W
51 63500316 63500316 5A5A 3F 0EF0 90 -> 63% 382,4W

Ich weiß nicht, ob ein Limit von 100% mit einem absoluten Wert 
funktioniert, für die 2-Kanal MI könnte das aber ein Ansatz sein.

Viel Spaß beim Testen :)

lg

Chris schrieb:
> Kann man irgendwie prüfen ob der NRF24L01+ richtig arbeitet? Also
> gibt es einen Log-Output auf dem ESP32?

Schau auf welchem COM Port dein ESP32 hängt und geh einfach mit einem 
Serial Monitor drauf (mit 115200 Baud).

Dort findest du dann Zeilen wie:

1

Starting OpenDTU

2

...

3

Setting Hostname... Configuring WiFi STA using new credentials... done

4

...

5

Initialize Hoymiles interface... Connection successfull

6

...

Im Fehlerfall, also falls die Initialization vom NRF gar nicht klappt, 
sollte da das hier stehen:

1

Initialize Hoymiles interface... Connection error!!

locke987 schrieb:
> Ich hatte gestern und heute 2 "Unknown" events im Log, einmal Event ID
> 12 und einmal ID 47. Weiß Jemand welche Fehlermeldung das sein könnte?
> Bzw. ist es geplant in der OpenDTU die Loginformationen zu erweitern?
> Ich speichere alle verfügbaren Werte momentan über mqtt in einer
> influxdb und Werte diese über Grafana aus, konnte aber keinerlei
> Zusammenhang zu den Zeitpunkten der Fehlermeldungen erkennen.

Das Eventlog kommt 1zu1 aus dem Inverter. Hier Dinge zu erweitern wird 
also eher nichts werden. Was dagegen noch machbar ist, ist die 
Interpretation der enthaltenen Daten. ID 12 bzw. 47 hatte ich bisher 
noch nicht. Manchmal sehe ich Abends eine 36. Aber auch nicht jeden Tag.

Ich habe gerade das erste mal versucht eine Verbindung aufzubauen. Wenn 
ich außerhalb der Reichweite bin, dann kommt:

1

TX 15 81 10 4 20 78 56 34 13 80 B 0 62 DA 4C 23 0 0 0 5 0 0 0 0 4C D2 6E 

2

RX Period End

3

All missing

4

Nothing received, resend count exeeded

Wenn ich innerhalb der Reichweite bin kommt laufend:

1

Fetch inverter: 116181100420

2

Fetch inverter: 116181100420

3

Fetch inverter: 116181100420

4

Fetch inverter: 116181100420

5

...

Ich vermute mal, dieses "Fetch" bedeutet, dass die Verbindung klappt.

Problem: Ich bekomme trotzdem keine Werte, im Web Interface sind 
sämtliche Werte auf 0. Das "Event Log" hat auch 0 Einträge.

Was könnte das Problem sein?

Daniel M. schrieb:
> Update Leistungsregulierung MI-Serie (hier MI-600 & Kompatibel)
>
> An der Schnittstelle zum NRF abgegriffene Daten sehen so aus:
> <51> <63 50 03 16> <63 50 03 16> <5A 5A> <2D> <0A 9E> <E8>
> Main-CMD 0x51, WR-ID, WR-ID, Sub-CMD 0x5A 0x5A, Limit %, Limit Absolut,
> CRC8
>
> Die CRC8 über den ganzen Block.
> Meine DTU sendet das Powerlimit basierend auf 1%=6W (100%=600W),
> 0x2D = 45%, 0x0A 0x9E = 271,8W (DEC 2.718)
>
> 51 63500316 63500316 5A5A 2D 0AA0 D6 -> 45% 272,0W
> 51 63500316 63500316 5A5A 65 17CC EF -> 101% 609,2W
> 51 63500316 63500316 5A5A 3F 0EF0 90 -> 63% 382,4W
>
> Ich weiß nicht, ob ein Limit von 100% mit einem absoluten Wert
> funktioniert, für die 2-Kanal MI könnte das aber ein Ansatz sein.
>
> Viel Spaß beim Testen :)
>
> lg

Ok, der MI600 ist ja scheinbar gleich was ich vom MI-1500 berichtet 
hatte.

Das mit % oder abs. Wert funktioniert entweder oder, wenn du % eingibst 
wird nach der %-Wattzahl der Nennleistung limitiert, wenn du abs. Wert 
eingibts, also 2. byte nach 0x5a5a, wird die % Zahl ignoriert.

Joni N. schrieb:
> Ich vermute mal, dieses "Fetch" bedeutet, dass die Verbindung klappt.
>
> Problem: Ich bekomme trotzdem keine Werte, im Web Interface sind
> sämtliche Werte auf 0. Das "Event Log" hat auch 0 Einträge.

Das Fetch bedeutet, dass versucht wird was vom Inverter zu lesen. Aber 
wenn darauf keine TX Nachrichten kommen (was bei dir ja nicht der Fall 
ist) scheint keine valide Uhrzeit vorzuliegen. Hier scheint der ESP 
keine Internet Verbindung zu bekommen um die Zeit vom NTP Server zu 
holen.

Thomas B. schrieb:

> Das Fetch bedeutet, dass versucht wird was vom Inverter zu lesen.

Ah, OK. Pollst du die Werte für ein bestimmtes Zeitfenster? Muss 
deswegen die Zeit genau stimmen?

Haben die Hoymiles eine RTC eingebaut?

Joni N. schrieb:
> Ah, OK. Pollst du die Werte für ein bestimmtes Zeitfenster? Muss
> deswegen die Zeit genau stimmen?
>
> Haben die Hoymiles eine RTC eingebaut?

Die Zeit wird mit jedem Anfragepaket an den WR geschickt. Was der WR 
intern damit alles macht ist nicht bekannt. Fest steht, dass die Zeit 
anschließend im Eventlog auftaucht. Ob über diese Zeit auch die tägliche 
Produktion (also der Tageswechsel) ermittelt wird ist nicht bekannt aber 
möglich.

Frank K. schrieb:
> Heute kamen die originalen
> NRF24L01+ mit der Post und ich konnte auf Anhieb die Daten meines HM-600
> empfangen.

Welche/wo NRF24L01+ hast Du denn bestellt? Ich bin mir nicht sicher ob 
meine richtig funktionieren.

Ich würde gerne genau die selben wie Du bestellen.

skusi schrieb:
> Frank K. schrieb:
>> Kurze Erfahrung mit einem NRF24L01+ - Clone:
>> Er funktioniert nicht! Ich habe jetzt eine Woche keinen Erfolg gehabt
>> mit WEMOS D1 und ESP32 und dem Clone. Heute kamen die originalen
>> NRF24L01+ mit der Post und ich konnte auf Anhieb die Daten meines HM-600
>> empfangen.
>> Ans Entwicklerteam: 10 Daumen hoch, super cooles Projekt!
>
> Wo hast du die originalen gekauft? Meine China Dinger zicken auch nur
> rum. Ich würde auch gerne andere ausprobieren.

Sorry, hat sich erledigt, hab eben erst zu Ende gelesen...
Danke Stefan.

SM D. schrieb:
> Hallo,
>
> ich habe ein Problem mit dem Accesspoint den der ESP32 generiert, der
> wird für ca. 10 Sekunden angezeigt und verschnwindet dann. Kurz später
> ist er wieder da. Ebenso kommt ein Dialogfenster hoch in dem steht dass
> das Wlan eine Anmeldung benötigt, man sieht dann kurz die OpenDTU Seite
> die dann aber kurz später nicht mehr erreichbar ist.
>
> Hat jemand eine Idee was das sein könnte?
>

Es könnte Reboots wegen zu schwacher Stromversorgung sein. Was sagt das 
serielle Log?

Hallo,
ein tolles Projekt!
Was genau benötige ich nun für Teile?
ESP8266 + nrf24l01 ?
Muss es ein original Wemos ESP8266 sein? wemos ds1 mini?
Mal lese ich, es muss unbedingt ein nrf24l01+ sein, mal lese ich ein 
nrf24l01 reicht auch.
Kann jemand ggf. Links zu Amazon posten, von Teilen, die erfolgreich mit 
Hoymiles-Wechselrichtern funktionieren?
Ich bin ein wenig verwirrt, weil es nicht mein Tagesgeschäft ist ;-)
Danke.
Gruß, Tobias

@Return 5 Danke, aber deshalb frage ich ja, weil es m.E. in dem Link bei 
dem Artikel DollaTek 2Pcs NRF24L01 + PA + LNA nicht um den NRF24L01+ 
handelt, sondern hier nur das "+" geschickt als Ersatz für & im Rahmen 
einer Aufzählung verwendet wurde ... aber den Eindruck erwecken soll, 
dass es sich um den NRF24L01+ handelt. Oder liege ich falsch?

RM schrieb:
> Hallo,
> hat sich schon mal jemand das Thema Blindleistung einstellen angeschaut?

Hi,
ja, auch das haben wir bereits angeschaut und versuchen das 
nachzuvollziehen.
Bitte etwas Geduld und gerne direkt auf Github AHOY und OpenDTU 
verfolgen.

Wofür brauchst du es genau?

(Und wer votet solche Fragen runter? Meine güte...)

lg

Kann mir jemand helfen und sagen, ob ich diesen ESP hier nehmen kann 
oder lieber einen anderen?
https://www.amazon.de/AZDelivery-D1-Mini-Entwicklungsboard-kompatibel/dp/B0754N794H/ref=cm_cr_arp_d_product_top?ie=UTF8

Tobias G. schrieb:
> Kann mir jemand helfen und sagen, ob ich diesen ESP hier nehmen kann
> oder lieber einen anderen?
> 
https://www.amazon.de/AZDelivery-D1-Mini-Entwicklungsboard-kompatibel/dp/B0754N794H/ref=cm_cr_arp_d_product_top?ie=UTF8

Ja die sind Top und benutze sie auch.
4MB Flash sind wichtig

RM schrieb:
>
> Ich wollte mir mit 3x HM 1500 eine PV Anlage bauen und vor allem
> Anmelden.

Das ist eine ordentliche Größe, da lohnt sich auch der Aufwand.

> Der Elektriker bzw der Enegergieversorger haben auf Ihrer Checkliste
> stehen, dass der Wechselrichter die Möglichkeit haben muss, die
> Blindleistung einzustellen.

Bitte was? Mir wäre neu, dass das bei kleinen Anlagen gefordert ist.
Im Normalfall machen die das selber, wenn die Messung sagt, dass es 
nötig ist.
Bist du sicher, dass es sich dabei um die Blindleistung und nicht um die 
normale AC-Leistung handelt?
Ich bin kein Netzbetreiber, aber ich denke, im Netz haben die größere 
Sorgen als 1,5kW Mikrowechselrichter justieren zu müssen.
Frag da nochmal nach ob die dich verarschen wollen.

> Also einstellen will ich da nichts, aber bei der Abnahme muss ich Ihn
> demonstrieren, dass ich könnte.... In der DTU glaub ich gehts nicht,
> aber im Datenblatt ist was erwähnt, dass es gehen sollte.

Einstellen solltest du da als Anwender auch nichts, vor allem nicht, 
wenn du nicht weißt, was du tust.
In der DTU geht das nicht manuell, wie gesagt, es ist ein Automatismus, 
der da greift.

> Ich will die anmelden, es gibts zwar blos 6 cent aber besser als den
> Strom zu verschenken. Und ich brach weil alles so verwinkelt und
> verschattet ist 6 MPPT Tracker. Seit über 1,5 Jahren hab ich auch schon
> 2x HM 300 im einsatz und auch beim Amateurfunk keine merklichen Probleme
> damit, das hab ich mit meinen Nachbarn und SMA Wechselrichter schon.

Zuviel Input :)
Mach ruhig, gerade mit der neuen Einspeisevergütung gibts da ja mehr.
Amateurfunk, anderes Thema, nicht in diesem Thread. Oberwellen und 
Netzrückwirkungen gehen hier auch ein Stück zu weit in die falsche 
Richtung, da kommt maximal die Info: siehe Zertifikate und 
Laborberichte.

lg

Nachdem ich jetzt tagelang herumgelötet habe, alles doppelt und dreifach 
überprüft hab - und trotzdem nichts ging sind heute die bestellten 
Transceiver Module angekommen. Und damit klappte es auf Anhieb!

Ich hab diese hier bestellt: https://www.amazon.de/gp/product/B07VQ838KT

Tausend Dank an die Entwickler für dieses tolle Projekt.

Hab ich auch so beobachtet. Sehr nervig, ist das bei der .24 besser?

Hallo Hubi.
Aus den vielen Beiträgen habe ich die SW hoydtusim aus Deiner Schmiede 
gewählt und finde die gut.
Frage: Wird deine SW auch um die Einstellung der Leistungsbegrenzung 
bzw. Nulleinspeisung mit Smartmeter erweitert oder hast Du dies vor?
einen schönen Sonntag.
Fritsche

Mr.James schrieb:
> Hallo zusammen,
> Nach 3 Tagen intensiver Forschung hab ich den Datenlogger soweit gebaut.
> Firmware ist drauf, im WLAN sind wir auch, nur kann ich meine HMT-1800
> nicht verbinden mit der Seriennummer.
>
> Kann es sein, dass HMT-1800 nicht unterstützt wird bei der aktuellen
> Diskussion?
>
> Danke und VG
> James

Hallo James,

der HMT wird nicht unterstützt, da dieser ein anderes Funkprotokoll und 
einen andere Frequenzbereich verwendet.

lg

Hallo zusammen,

könnte mir bitte jemand den Discord Link zukommen lassen

Danke

Sven

Sven H. schrieb:
> Hallo zusammen,
>
> könnte mir bitte jemand den Discord Link zukommen lassen
>
> Danke
>
> Sven

Findest du hier:
https://discord.gg/mddnTPwu

lg

@ Esafreak

Beim Wemos D1 Mini müssen keine Pins auf bestimmte Potentiale gelegt 
werden, das geschieht durch die Beschaltung auf dem Board.