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 Daniel R., Dein Discord Invite ist expired. Kannst Du nochmal einen schicken ?
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.
Hallo und vielen Dank für die super Arbeit! Sehe ich das richtig, dass ich ohne die Seriennummer meines HM-600 nichts empfangen kann? Irgend ein Depp hat nämlich alles montiert und vorher kein Foto vom Wechselrichter gemacht bzw. das Etikett abgezogen......
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
Auf der Rechnung/Lieferschein finde ich leider keine Seriennummer :-( Na dann, Dummheit muss bestraft werden, also wieder rauf auf's Garagendach ;-) Herbert K. schrieb: > 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.
@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. :)
Daniel R. schrieb: > @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 wäre natürlich was. Ich kapiere das mit den shockburst vom nrf zwar nicht, aber ich könnte mir als Laie schon vorstellen, dass der Wechselrichter seine Seriennummer irgendwie "broadcasted". Bei den nrf-Sniffern die ich hier verlinkt fand, war allerdings die Eingabe der Seriennummer Voraussetzung.
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 |
@friedhelm E. hol dir die neuste Version von git-hub hm-soft/hoydtusim. Das sollte klappen.
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?"
:
Bearbeitet durch User
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
Angehängte Dateien:
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
:
Bearbeitet durch User
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
Beitrag #7127175 wurde vom Autor gelöscht.
Beitrag #7127181 wurde vom Autor gelöscht.
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
:
Bearbeitet durch User
Daniel R. schrieb: > @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. :) Anbei die ins Englische übersetzten Versionen der usart_nrf.c/.h und usart_nrf3.c/.h aus dem iotloves Gitee repo. Endlich hab ich mal die Zeit gefunden das mal für mich abzuschließen. Ähnlich interessant sind m.E. noch die AntiReflux.c/.h und DRM.c/.h Dateien. Für das G{o,ua}ngfa / Such-Kommando wird folgendes gesetzt:
1 | void UsartNrf_Send_NetCmdToNrfCmd(void) |
2 | ... |
3 | case NET_SEARCH_ID: //Search ID |
4 | MainCmd = BROADCAST; // 0x02 |
5 | SubCmd = 0; // 0x00 |
6 | break; |
1 | void UsartNrf_Send_PackNrfCmd(void) |
2 | ... |
3 | case NET_SEARCH_ID://Search Id (Guangfa command) |
4 | {
|
5 | if(UsartNrf_HasSetCurrentInverterOk()) |
6 | {
|
7 | for(j = Dtu3Detail.Property.PortNum; j < PORT_LEN; j++) |
8 | {
|
9 | memset((u8 *)MIMajor[j].Property.Pre_Id, 0, 2); |
10 | memset((u8 *)MIMajor[j].Property.Id, 0, 4); |
11 | MIMajor[j].Property.Port = MI_NO; |
12 | } |
13 | |
14 | Uart_SendBufferLen = UsartNrf_Send_PackBaseCommand((u8 *)MIMajor[PortNO].Property.Id, (u8 *)MIMajor[PortNO].Property.Id, MainCmd, 0); |
15 | } |
16 | |
17 | break; |
18 | } |
1 | u8 UsartNrf_Send_PackBaseCommand(u8 *target_adr, u8 *rout_adr, u8 cmd, u8 dat) |
2 | {
|
3 | vu8 i = 0; |
4 | vu8 temp_dat[UART_LEN]; |
5 | memset((u8 *)temp_dat, 0, sizeof(temp_dat)); |
6 | Uart_SendBuffer[0] = STX;//start // 0x7e |
7 | temp_dat[0] = cmd; //command // MainCmd |
8 | memcpy((u8 *)&temp_dat[1], target_adr, 4); |
9 | memcpy((u8 *)&temp_dat[5], rout_adr, 4); |
10 | temp_dat[9] = dat; |
11 | temp_dat[10] = Get_crc_xor((u8 *)&temp_dat[0], 10); //CRC |
12 | i = ForwardSubstitution((u8 *)&Uart_SendBuffer[1], (u8 *)&temp_dat[0], 11); //Forward Substitution |
13 | Uart_SendBuffer[(i + 1)] = ETX; //end |
14 | memset((u8 *)temp_dat, 0, sizeof(temp_dat)); |
15 | return (i + 2); |
16 | } |
Es sollte also mit z.B. als Search Paket gehen: 02 74 40 33 29 78 56 34 12 00 CRC8
Daniel R. schrieb:1 | > 00 01 80 01 00 01 62 26 62 26 00 00 00 00 00 d1 00 04 62 2e 00 00 00 00 |
2 | > 00 00 00 d2 00 05 62 2e 00 00 00 00 00 00 00 cf 00 06 63 5a 00 00 00 00 |
3 | > 00 dc 40 8f 00 0c 62 2e 69 fd 00 03 07 a3 40 93 00 0d 62 2e 69 fd 00 00 |
4 | > 00 00 80 02 00 22 6c a4 6c a4 ff ff ff fa 80 02 00 23 6c ab 6c ab ff ff |
5 | > ff f9 80 02 00 24 6c ec 6c ec ff ff ff bf 80 02 00 25 6c f1 6c f1 ff ff |
6 | > ff fb 80 02 00 26 6c fb 6c fb ff ff ff f6 80 02 00 27 6d 18 6d 18 ff ff |
7 | > ff e3 80 02 00 28 6d 22 6d 22 ff ff ff f6 80 02 00 29 6d 27 6d 27 ff ff |
8 | > ff fb 80 02 00 2a 6d 32 6d 32 ff ff ff f5 53 03 |
Die Routine um die o.a. Alarm Payload zu dekodieren findet sich in UsartNrf3_Process_DevInform_Alarm(). Es wird immer in 12 byte zusammengefaßt, wobei die ersten beiden die Alarm Version number darstellen:
1 | 00 01 <-- Alarm Version number |
2 | 80 01 00 01 62 26 62 26 00 00 00 00 |
3 | 00 d1 00 04 62 2e 00 00 00 00 00 00 |
4 | 00 d2 00 05 62 2e 00 00 00 00 00 00 |
5 | 00 cf 00 06 63 5a 00 00 00 00 00 dc |
6 | 40 8f 00 0c 62 2e 69 fd 00 03 07 a3 |
7 | 40 93 00 0d 62 2e 69 fd 00 00 00 00 |
8 | 80 02 00 22 6c a4 6c a4 ff ff ff fa |
9 | 80 02 00 23 6c ab 6c ab ff ff ff f9 |
10 | 80 02 00 24 6c ec 6c ec ff ff ff bf |
11 | 80 02 00 25 6c f1 6c f1 ff ff ff fb |
12 | 80 02 00 26 6c fb 6c fb ff ff ff f6 |
13 | 80 02 00 27 6d 18 6d 18 ff ff ff e3 |
14 | 80 02 00 28 6d 22 6d 22 ff ff ff f6 |
15 | 80 02 00 29 6d 27 6d 27 ff ff ff fb |
16 | 80 02 00 2a 6d 32 6d 32 ff ff ff f5 |
17 | |...| |...| |...| |...| |...| |...| |
18 | +2 +3 +4 +5 +6 +7 +8 +9 +10.. +12.. |
19 | <WCode> | | | | |
20 | <WNum>| | | | |
21 | <WarnSerNub>| | | |
22 | <AlarmStartTime> | |
23 | <AlarmEndTime> |
24 | <AlarmData1> |
25 | <AlarmData2> |
Hier die Dekodierung der o.a. Felder:
1 | AlarmId: Alarm_Id[0]), (u8 *)MIMajor[PortNO].Property.Pre_Id, 2); |
2 | Alarm_Id[2]), (u8 *)MIMajor[PortNO].Property.Id, 4); |
3 | |
4 | WCode: WCode = (u16)pProBuffer[i * 12 + 2] << 8 | pProBuffer[i * 12 + 3]; |
5 | WNum: WNum), &(pProBuffer[i * 12 + 4]), 2); |
6 | WarnSerNub: WarnSerNub[PortNO] = (u16)pProBuffer[i * 12 + 4] << 8 | (u16)pProBuffer[i * 12 + 5]; |
7 | WTime1=AlarmStartTime: //Alarm start time |
8 | AlarmTime = (u32)((u16)pProBuffer[i * 12 + 6] << 8) | ((u16)pProBuffer[i * 12 + 7]) + DateToSec(calendar); // AM |
9 | AlarmTime = 12 * 60 * 60 + (u32)(((u16)pProBuffer[i * 12 + 6] << 8) | ((u16)pProBuffer[i * 12 + 7])) + DateToSec(calendar); // PM WCode >> 13) & 0x01) == 1) |
10 | WTime2=AlarmEndTime : //Alarm end time |
11 | AlarmTime = (u32)((u16)pProBuffer[i * 12 + 8] << 8) | ((u16)pProBuffer[i * 12 + 9]) + DateToSec(calendar); // AM |
12 | AlarmTime = 12 * 60 * 60 + (u32)(((u16)pProBuffer[i * 12 + 8] << 8) | ((u16)pProBuffer[i * 12 + 9])) + DateToSec(calendar); // PM WCode >> 12) & 0x01) == 1) |
13 | AlarmData1: Data1[0]), &(pProBuffer[i * 12 + 10]), 2); |
14 | AlarmData2: Data2[0]), &(pProBuffer[i * 12 + 12]), 2); |
Es wird offenbar immer das aktuelle Datum des Tages in Sekunden dazu gezählt und anhand des Bit 13 / 12 im WCode entschieden ob der AlarmStartTime / AlarmEndTime vormittags oder nachmittags liegt/lag. Aus Bit 14 & 15 des WCode wird noch ein sog. Run_Status[0] und [1] extrahiert. Was auch immer das aussagt?
1 | WCode >> 14) & 0x03)) == 0) |
2 | Run_Status[0] = 0x00; |
3 | Run_Status[1] = 0x08; |
4 | |
5 | WCode >> 14) & 0x03) == 1) |
6 | Run_Status[0] = 0x00; |
7 | Run_Status[1] = 0x03; |
@Jan-Jonas S., kannst Du die Punkte mal mit Deinen bisherigen Annahmen (a_code, etc.) überprüfen.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Angehängte Dateien:
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.
:
Bearbeitet durch User
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
Hallo zusammen, gibt es Wechselrichter bei denen es nicht funktioniert? Hab hier ein HM-600 der irgendwie nicht will. Bei meinem anderen (auch HM-600) funktioniert es ohne Probleme. "Inverter 'TEST' is not available and is not producing" kann evtl eine falsche Seriennummer auf dem WR sein? Kann man die irgendwie anders auslesen? Danke schon mal.
Hallo Java L. wie Herbert schon geschrieben hat geht es hier vorragig um die HM-Wechselrichter <-> DTU lite/Pro Kommunikation. Die Modbus485 und die NetProtocol Kommunination zwischen DTU und Hoymiles Cloud ist hier Off-Topic. Du kannst gerne einen Hinweis/Link auf den Thread hier posten. Das Protokoll sollte mE im NetProtocol.c/.h der einschlägigen gitee Repos definiert sein. Ich habe nur bisher keinen Endpoint entdecken können. Aber vielleicht willst Du ja Deine Ergebnisse mit Wireshark / mitmproxy o.ä. in dem neuen Thread publizieren ?
@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.
A.D. schrieb: > gibt es Wechselrichter bei denen es nicht funktioniert? > Hab hier ein HM-600 der irgendwie nicht will. Hat sich erledigt. Irgendwann konnte ich ihn dann doch zum "reden" überzeugen :)
Thomas G. schrieb: > 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. Ja, verwende ich. Warum auch immer fing er dann nach nem halben Tag an doch zu kommunizieren. Aber danke trotzdem für den Tipp!!
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, 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.
SM D. schrieb:
> Hätte folgende Fragen
Einfach Strg F bemühen, ggf. Seitenaufteilung abschalten.
hat jemand eine fertige bin Datei von der aktuellen Version für mich?
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.
Könnten Sie bitte eine Quelle für die Bibliothek "dbg.h" für Arduino bereitstellen
Günter H. schrieb: > tom schrieb: >> hat jemand eine fertige bin Datei von der aktuellen Version für mich? > > Hier ist sie. Vielen Dank
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.
macht es einen unterschied ob ich einen normalen d1 mini oder einen d1 mini pro verwende? aktuell hab ich einen d1 mini und der fällt immer wieder aus
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
Hallo an Alle und als erstes ein herzliches Dankeschön für eure Arbeit. Ich lese hier schon eine Weile mit und habe auch schon so einige Versionen auf meinem ESP8266 geflasht. Habe einen HM-600. Bekomme mit der Version 4.24 bzw. 4.25 folgende Ausgabe im Terminal:
1 | I: Requesting Inverter SN 1141xxxxxxxx |
2 | I: Transmit 27 | 15 63 90 59 00 78 56 34 12 80 0B 00 62 D4 02 1C 00 00 00 05 00 00 00 00 74 90 75 |
3 | E: while retrieving data: last frame missing: Request Retransmit |
4 | I: Transmit 27 | 15 63 90 59 00 78 56 34 12 80 0B 00 62 D4 02 1C 00 00 00 05 00 00 00 00 74 90 75 |
5 | E: while retrieving data: last frame missing: Request Retransmit |
6 | I: Transmit 27 | 15 63 90 59 00 78 56 34 12 80 0B 00 62 D4 02 1C 00 00 00 05 00 00 00 00 74 90 75 |
7 | E: while retrieving data: last frame missing: Request Retransmit |
8 | I: Transmit 27 | 15 63 90 59 00 78 56 34 12 80 0B 00 62 D4 02 1C 00 00 00 05 00 00 00 00 74 90 75 |
9 | I: Inverter #0 I: no Payload received! (retransmits: 3) |
Nach einem zurück auf Version 4.22 (hatte ich als .bin noch), wurden sofort wieder Daten empfangen. Auch ein Wechsel auf Kanal 3 oder 23 brachte keine Verbesserung. Habe die beiden Versionen (4.25 zu 4.22) verglichen soweit ich den Code verstanden habe, aber nichts gefunden, welches das unterschiedliche Verhalten der beiden Versionen erklärt. Vielleicht kann jemand mal darüber schauen, der mehr Ahnung hat als ich? Danke und einen schönen Sonntag.
Falcon81 schrieb: > Bekomme mit der Version 4.24 bzw. 4.25 folgende Ausgabe im Terminal: Von 4.22 auf 4.25 wurden die Pins für CE und IRQ wieder getauscht - eventuell liegt da der Hase im Pfeffer? "Reverted the default settings to CE=D4 and IRQ=D3 so it matches the pinout diagrams for the time being." 4.25 // PINOUT (Default, can be changed in setup) //------------------------------------- #define RF24_CS_PIN 15 #define RF24_CE_PIN 2 #define RF24_IRQ_PIN 0 4.22 / PINOUT (Default, can be changed in setup) //------------------------------------- #define RF24_CS_PIN 15 #define RF24_CE_PIN 0 #define RF24_IRQ_PIN 2
Vielen, vielen Dank. Das war es. Nach dem Tausch von CE und IRQ läuft es wieder
Beitrag #7130649 wurde von einem Moderator gelöscht.
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.
Angehängte Dateien:
-
hm1500.jpg
240 KB -
hm1500.jpg
240 KB
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! =)
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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!
Hallo, besteht da nicht die Gefahr, das man seinen WR völlig und unwiderruflich verstrubbelt? Oder hat der ne Resettaste? Mein HM1200 nicht.
Angsthase schrieb: > Hallo, > > besteht da nicht die Gefahr, das man seinen WR völlig und unwiderruflich > verstrubbelt? > > Oder hat der ne Resettaste? > Mein HM1200 nicht. Die Gefahr besteht immer :-) Zur Resettaste: Vielleicht hilft kpl. stromlos machen, also DC (Solarpanel/Netzteil/Batterie) und AC-Stecker ziehen für eine gewisse Zeit. Ist das schon jemandem der Tester aufgefallen? Bleiben die Total-Werte immer erhalten?
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!
Mal eine Frage bezüglich der Leistungsreduzierung: Was genau bezweckt ihr denn damit? Ich für meinen Teil wäre eher interessiert bei meinem HM-600 die 600W Begrenzung aufzuheben und alles rauszuholen, was die Module hergeben ;) Klärt ihr mich auf? Danke
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.
:
Bearbeitet durch User
Herbert K. schrieb: > 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 1678 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. Hohoho was ist denn für ein Umgangston? Ich würde behaupten, ich lese den Thread schon länger mit als du... Aber darum geht es nicht. Und den Mund verbieten lasse ich mir von dir schon garnicht. Mich interessiert der Anwedungsfall für die gewünschte Leistungsreduzierung - nicht mehr nicht weniger. Dass ich mir eher die Möglichkeit wünschen würde, die Leistung aufzubohren (bzw. die willkürliche 600W Begrenzung für DE) soll nur mein Unverständnis /-wissen diesbezüglich verdeutlichen. Wenn du dazu nichts beizutragen hast, dann überlies doch bitte einfach meinen Post. Danke Hoyle
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.
Thomas B. schrieb: > 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. Vielen Dank!!!
Thomas B. schrieb: > 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. Aha! Danke für die Ideen dazu. Mir hat sich diese Frage bisher noch garnicht gestellt, da hier noch ein alter Ferraris-Zähler (ggf. auch mal ein paar Umdrehungen rückwärts) läuft. So lange den keiner wechseln will, komme ich noch nicht in die Versuchung, über Batterien und verschenkte kWh nachzudenken :) Danke Thomas!
Stefan T. schrieb: > 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. Wirst Du das auch in Deine Software mit einbauen?
Thomas B. schrieb: > 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. 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?
Hallo, ich lese schon einige Zeit hier mit und sage erstmal Danke für die ganze Arbeit. Ich habe mir kürzlich ein ESP8266 und Funkmodul zusammengebaut und die bin von Günter H. geflasht. Geht super, nochmals Danke. Eine Sache ist mir in der V0.4.25 aufgefallen: wenn das WLan wiederkehrt (nach Nachtabschaltung) verbindet sich MQTT nicht wieder, erst nach Neustart. In der V0.4.22 schien das zu gehen. Schöne Grüße Heiko
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
Hallo, erstmals ein großes Dankeschön an alle, die geholfen haben, dieses Projekt weiter zu bringen. Es ist immer schön zu sehen was eine Hand voll kluger Köpfe erreichen kann. :) Ich bin auf den Thread gestoßen, nachdem wir bei einem Freund eine HM-1200-Anlage mit einem HM-1500 erweitert haben, und auf das Vier-Platten-Limit des DTU-Lite gestoßen sind. Zudem war uns die Cloud-Geschichte schon immer ein Dorn im Auge. Beim Zusammenlöten und Testen bei mir vor Ort habe ich spaßeshalber die SN meines TSUN TSOL-M350 eingegeben, da diese wie bei den Modellen HM-300, HM-350 und HM-400 mit "1121" beginnt. Und siehe da: es funktioniert ohne Probleme. Nachdem die Integration in mein Grafana gebaut wurde, bleibt wohl ein ESP bei mir. :) Viele Grüße, Kev
Thomas B. schrieb: > 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. 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? VG
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.
:
Bearbeitet durch User
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 !
Kurze Frage: muss es ein NRF24L01+ sein oder funktioniert auch ein NRF24L01?
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
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.
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
Kann man irgendwie prüfen ob der NRF24L01+ richtig arbeitet? Also gibt es einen Log-Output auf dem ESP32? Ich hab alles verlötet, den ESP32 geflasht, die Weboberfläche startet - aber ich bekomme keine Daten vom Hoymiles. Darum würde ich gerne wissen ob mein NRF24L01+ Board "am Leben" ist.
Beitrag #7135179 wurde vom Autor gelöscht.
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?
:
Bearbeitet durch User
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?
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!
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.
Joni N. schrieb: > Welche/wo NRF24L01+ hast Du denn bestellt? Ich bin zwar nicht Frank aber diese beiden funktionieren bei mir beide in Verbindung mit einem ESP8266 und aktueller OpenDTU Version: https://www.amazon.de/gp/product/B07PQPFTWZ/ref=ppx_yo_dt_b_asin_title_o07_s00?ie=UTF8&psc=1 https://www.amazon.de/gp/product/B06XJN417D/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1 Gruß Stefan
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.
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
@Tobias G. Einfach 5 Beiträge zurück. Da sind Links. UND nirgends steht, das ein "nrf24l01" ausreicht ! Es muß !!! ein "+" sein !
@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?
Hallo, hat sich schon mal jemand das Thema Blindleistung einstellen angeschaut?
Tobias G. schrieb: > @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? Wie auch immer, ich hab die Dinger beide im Einsatz und Sie funktionieren stabil seit ca. 2 Wochen, und wenn nicht schickst Du sie einfach wieder kostenlos zurück.
locke987 schrieb: > Wie auch immer, ich hab die Dinger beide im Einsatz und Sie > funktionieren stabil seit ca. 2 Wochen, und wenn nicht schickst Du sie > einfach wieder kostenlos zurück. auf dem Chip ist ein + drauf
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
Daniel M. schrieb: > 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 Ich wollte mir mit 3x HM 1500 eine PV Anlage bauen und vor allem Anmelden. Der Elektriker bzw der Enegergieversorger haben auf Ihrer Checkliste stehen, dass der Wechselrichter die Möglichkeit haben muss, die Blindleistung einzustellen. 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. 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.
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Tobias: Das funktionsfähige Teil habe ich bei MAKERSHOP.DE bestellt, Artikelbezeichnung "2x NRF24L01+ 2.4GHz Funkmodul Raspberry Pi Arduino Modul nrf2401 Antenne".
Hallo zusammen, erst mal vielen Dank für die super Leistung !!! Hab meinen ESP mit Empfänger verlötet und alles funktioniert ... Mir ist nur aufgefallen das der MQQT in der aktuellen Version 0.4.25 nur beim Neustart verbunden wird. Wenn Wlan kurz weg ist oder der MQQT Server nicht erreichbar ist ( weil er eine Datensicherung nachts macht ) wird keine Verbindung mehr hergestellt. Erst nach einem Neustart geht es wieder.
Hab ich auch so beobachtet. Sehr nervig, ist das bei der .24 besser?
Holger S. schrieb: > Hab ich auch so beobachtet. Sehr nervig, ist das bei der .24 > besser? Nein, ist bei mir auch bei der .24 so gewesen. Eine gute Version mit stabilerem MQTT war bei mir die 0.4.5
Hallo in die Runde. Ich habe ein Problem und zwar ich bekomme auf meinem D1 mini von berrybase, nichts hochgeladen, weder mit der Arduino IDE noch mit Visual Studio Code und der Platform.io. Mein Setup ist wie folgt: 1x D1 Mini von berrybase.de https://www.berrybase.de/d1-mini-esp8266-entwicklungsboard per USB Kabel am Laptop. Auf dem Board ist ja so ein USB to Serial Converter CH340 drauf verbaut. Der Treiber wird erkannt und setzt das Board auf COM6. Soweit so gut. Aber wenn ich mit dem VSC oder der Arduino IDE versuche zu D1 Mini zu connecten bricht der Uploade immer mit Fehlermeldung ab. Hat jemand von euch das Setup so am laufen mit dem CH340 USB to Serial Converter oder flasht ihr die Software über FTDI direkt verdrahtet auf die RX und TX Pins des ESP D1 Mini ? Danke für Eure Tips Gruss Esafreak
@esafreak: Verwende doch einfach eines der Flash- Programme! NodeMCU-PyFlasher ESP8266Flasher tasmotizer-1.2 Funktioniert tadellos! Grüße Gerri
esafreak schrieb: > Hat jemand von euch das Setup so am laufen mit dem CH340 USB to Serial Ich habe das Setup exakt so am laufen an meinem Mac. Keine Probleme; Weder unter Arduino noch unter VS-Code. Unter VS-Code finde ich es sogar komfortabler zu flashen (als Anfänger). Hast du schon mal ein anderes USB-Kabel verwendet?
Tausche das Kabel. Da gibt es mehr Schrott als vorstellbar! Viele sind gar nicht komplett belegt und taugen maximal zum Laden.
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
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
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, ich verfolge dieses Thema schon seit langen. Ich finde es echt cool wie das ganze hier sich entwickelt hat. Super Arbeit. Eine Frage hätte ich noch: wird es eventuell irgend wann eine Unterstützung für den HM-1800 (3 Phasig) geben ? Mit dem HM-800 läuft das ganze einwandfrei. Vielen Dank nochmal
Hallo Marius, so ein bisschen kann ich AVR Herbi schon verstehen wenn man nicht mal die letzten zwei Posts liest. Und nein HMT/HMS Wechselrichter sind nicht das Thema dieses Threads da es sich um komplett andere Gunktechnik handelt. Wenn Du die Funktechnik nachgebaut hast kannst Du Dich gerne im Source Code der DTU-Pro umsehen da steht auch einiges zum Regeln von drei Phasen drin aber die Ansteuerung von Deinem Wechselrichter wird über den von Hoymiles und uns verwendeten nRF24L01+ nicht funktionieren da die Frequenz und das Funkverfahren zwei ganz andere sind.
Hallo zusammen, könnte mir bitte jemand den Discord Link zukommen lassen Danke Sven
Hallo zusammen, Danke schon mal für eure Antworten. Habe es auf 2 Windows Rechnern probiert mit 3 verschiedenen USB Kabeln :-( Eine Frage noch. Muss man am wemos D1 Mini vor dem flashen immer den GPIO 0 auf Low legen oder etwas anderes beachten damit das wemos Board geflasht wird? Davon hab ich bisher nirgends etwas gelesen dass man am wemos d1 mini Board aktiv einen Pin jedesmal vor dem flashen high oder Low schalten muss. Kann das mein Problem sein dass der wemos d1 mini nie in den Flash Modus geht oder ist das eigentlich nicht notwendig Pins auf der Platine händisch auf high oder Low zu legen? Danke für euer Feedback. Gruss esa
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.
Beitrag "Wechselrichter Hoymiles HM-xxxx 2,4 GhZ Nordic Protokoll?" Hallo Friedhelm, da ich keine DTU und sniffen kann bin ich auf die Erkenntnisse von anderen in diesem Thread angewiesen. Aber, ja, ich habe das gefragte vor, aber eher n Richtung volle Ausnutzung meiner Panele.
Hi zusammen, jetzt hat es endlich geklappt mit dem flashen. das esp board hatte einen Schuss weg. habe noch ein anderes originalverpackt liegen gehabt, und das liess sich dann mit platform.io flashen. jetzt hab ich aber das nächste folgende problem. der esp macht ein wlan auf mit dem namen ahoy-dtu und nach eingabe des wlan passworts für ahoy-dtu connected mein laptop auch kurz aufs wlan des Esp. allerdings werde ich nicht automatisch zu den configuration seiten weitergeleitet sondern das wlan des esp ist mal da, mal weg, mal da mal weg. die IP des esp lässt sich pingen, aber es werden nicht die configurationsseiten geladen. Hat jemand eine Idee von euch, woran das liegen könnte, dass die configuration seiten des ESP nicht geladen werden, nachdem ich auf das ahoy-dtu WLAN connected habe. ? Wie gesagt, es ist auch nicht ständig da sondern das ahoy-dtu kommt und geht. danke schon mal für eure kommentare. gruss esafreak
Hast Du mal nen Browser aufgemacht und die IP des Wemos eingegeben ? Also 192.168.1.1
Hallo Zusammen, mein Passwort fpr das AHOY-DTU WLAN wird nicht akzeptiert. Könnt Ihr das Start PW bitte noch mal posten? Vielen Dank
Hallo zusammen, hab ständig die Meldung MQQT : not connected. Nach Neustart funktioniert es kurz dann wieder der Fehler. Ich verwende die Version 0.4.25 auf einem ESP. GUI funktioniert alles. Jemand ne Idee zur Lösung ? Besten Dank schon mal ... :-)
Axel H. schrieb: > 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? Genau das gleiche Problem bei mir. Stromversorgung ist stabiles raspberry Netzteil Hat sich das Problem bei euch schon gelöst und wenn ja wie? Gruss esafreak
Hallo zusammen,
wir sind bald fertig. Natührlich muss viel noch überarbeitet werden.
Aktuell haben wir ein kleines Problem das später das ganze
Python-Scrippt imemr wieder zum crashen bringt.
File "/home/dtu/hoymiles/decoders/__init__.py", line 108, in unpack
return struct.unpack(fmt, self.response[base:base+size])
struct.error: unpack requires a buffer of 2 bytes
Wenn jemand eine Idee hat, sagt bescheid.
PS: Ja Google ist mein aller aller ... bester Freund. ;)
Angehängte Dateien:
-
loeschen.png
75 KB
83775 schrieb: >Jemand ne Idee zur Lösung ? Besten Dank schon mal ... :-) Ich hatte mit Ahoy ähnliche Probleme als ich noch mit Arduino geflasht habe. Es werden ja Partitionen definiert, wenn das nicht stimmt können seltsame Dinge passieren. Ich würde vorschlagen vor dem flashen alles zu löschen. Kann man in Arduino einstellen, ich denke das geht in Plattform IO bestimmt auch. Habs gefunden, siehe Anhang.
:
Bearbeitet durch User
Esafreak schrieb: > > Genau das gleiche Problem bei mir. Stromversorgung ist stabiles > raspberry Netzteil > Hat sich das Problem bei euch schon gelöst und wenn ja wie? > Gruss esafreak Also, das Problem kam bei mir von einer schlechten USB Buchse auf dem ESP32 Board, die ging mal und mal ging sie nicht, zumindest nicht ausreichend(Übergangswiderstand). Das gleiche könnte natürlich auch ein Problem des USB Kabels sein. Solong B
Hallo Daniel, > Aktuell haben wir ein kleines Problem das später das ganze > Python-Scrippt imemr wieder zum crashen bringt. > > File "/home/dtu/hoymiles/decoders/__init__.py", line 108, in unpack > return struct.unpack(fmt, self.response[base:base+size]) > struct.error: unpack requires a buffer of 2 bytes > > > Wenn jemand eine Idee hat, sagt bescheid. Wenn das nur sporadisch auftritt (gelegentliches, vorüber gehendes Empfangsproblem?), wäre meine Methode per Python, das mittels eines try:/except:-Konstrukts abzufangen und erst mal nicht weiter drüber nachzudenken, bis andere wichtigere Sachen organisiert sind. Bei grundsätzlich unsicheren Datensituationen ist so was wahrscheinlich sogar die einzige solide Lösung, da raus zu kommen. Tschüssi, Petra
Hallo zusammen. Mein setup läuft jetzt. Danke nochmal an alle. Tolles Projekt!! Gruss esafreak
Hallo. Ich habe eine Frage zum HM-400 WR Ich nutzte die Arduino IDE mit der HoyDtuSim.ino. Hardware: WEMOS D1 Mini + 1x NRF24L01+ verkabelt nach der Anleitung von github. Im Seriellen Monitor sehe ich, dass sich der Wemos mit dem Wifi verbindet. Ich komme auch per Browser rauf. Es gibt in diesem Sketch keine Möglichkeit den 400er WR auszuwählen. Ich sehe hier nur den 600er und 1200er? Ist das korrekt? Kann ich die "Vorlage" für den 600er lassen? Meine Seriennummer lautet: 112173109786 (Kann gern in die Tabelle mit übernommen werden) Wird diese in genau dieser Form unter #define DUMMY_RADIO_ID eingetragen? Oder muss das 0x am Anfang und das ULL am Ende bleiben?
Esafreak schrieb: > Hallo zusammen. Mein setup läuft jetzt. Danke nochmal an alle. ... und woran hatte es dann gelegen? Grüße Gerri
Daniel R. schrieb: > File "/home/dtu/hoymiles/decoders/__init__.py", line 108, in unpack > return struct.unpack(fmt, self.response[base:base+size]) > struct.error: unpack requires a buffer of 2 bytes try:-except: drumrum bauen und im Fehlerfall fmt und self.response bzw. deren len anzeigen lassen! Gruß... Bert
K. J. schrieb: > Hallo. Ich habe eine Frage zum HM-400 WR > Ich nutzte die Arduino IDE mit der HoyDtuSim.ino. > Hardware: WEMOS D1 Mini + 1x NRF24L01+ verkabelt nach der Anleitung von > github. > Im Seriellen Monitor sehe ich, dass sich der Wemos mit dem Wifi > verbindet. > Ich komme auch per Browser rauf. > Es gibt in diesem Sketch keine Möglichkeit den 400er WR auszuwählen. Ich > sehe hier nur den 600er und 1200er? > Ist das korrekt? Kann ich die "Vorlage" für den 600er lassen? > Meine Seriennummer lautet: 112173109786 > (Kann gern in die Tabelle mit übernommen werden) > Wird diese in genau dieser Form unter > #define DUMMY_RADIO_ID eingetragen? Oder muss das 0x am Anfang und das > ULL am Ende bleiben? 0x und ULL verbleiben so.
Noch eine Frage.
Ich erhalte folgende Fehlermeldung:
'getSerialNoTxt' was not declared in this scope'getSerialNoTxt' was not
declared in this scope
out += "<h3>S/N " + String (getSerialNoTxt(wr)) + "</h3>";
Man kann das auskommentieren dann wird der Sketch hochgeladen.
Aber wieso taucht der Fehler auf. Bzw wie kann ich das beheben?
Gerri schrieb: > Esafreak schrieb: > >> Hallo zusammen. Mein setup läuft jetzt. Danke nochmal an alle. > > ... und woran hatte es dann gelegen? > Grüße > Gerri Hi Gerri, ich hatte verschiedene Probleme gleichzeitig. Am Anfang war der esp defekt und liess sich nicht flashen.Als ich dann einen andern genommen hatte ging es.dann hatte ich Probleme die config Seiten aufzurufen weil der access point immer nach paar Sekunden weg war und nicht auf die settings Seite weitergeleitet wurde. Nach ewigem rumprobieren war der esp dann im WLAN angemeldet und der Webserver hat die seiten zuverlässig angezeigt und ich konnte den hoymiles WR konfigurieren. Allerdings hat das funkmodul nicht mit dem WR kommuniziert. Ich musste dann noch zwei GPIOS am Esp umlöten und in den settings umkonfigurieren und dann lief das ganze. Schönes Projekt. Viele Grüße esafreak
Esafreak schrieb: > Gerri schrieb: >> Esafreak schrieb: >> >>> Hallo zusammen. Mein setup läuft jetzt. Danke nochmal an alle. >> >> ... und woran hatte es dann gelegen? >> Grüße >> Gerri > > Hi Gerri, ich hatte verschiedene Probleme gleichzeitig. Am Anfang war > der esp defekt und liess sich nicht flashen.Als ich dann einen andern > genommen hatte ging es.dann hatte ich Probleme die config Seiten > aufzurufen weil der access point immer nach paar Sekunden weg war und > nicht auf die settings Seite weitergeleitet wurde. Nach ewigem > rumprobieren war der esp dann im WLAN angemeldet und der Webserver hat > die seiten zuverlässig angezeigt und ich konnte den hoymiles WR > konfigurieren. Allerdings hat das funkmodul nicht mit dem WR > kommuniziert. Ich musste dann noch zwei GPIOS am Esp umlöten und in den > settings umkonfigurieren und dann lief das ganze. Schönes Projekt. Viele > Grüße esafreak Was für ein wirres Geschwurbel, völlig sinnbefreit und nutzlos. Bitte versuche es nochmal und etwas strukturiert.
So, alles zusammengelötet, lief auf Anhieb! Danke an alle Verantwortlichen, die dieses Projekt vorantreiben! Ich habe 4 Fragen: 1. Der ESP8266 hat eine Antenne (geschlängelte Kupferbahn auf der Platine) und der NRF24 hat ebenfalls eine Antenne (geschraubt). Welche wird nun benutzt und ist genau wofür? Wenn beide benutzt werden, ist dann ein mögl großer Abstand zwischen beiden sinnvoll? geht ja nur um cm, aber man könnte es ja einrichten. 2. Wenn ich den "Amplifier Power Level" von MIN auf irgendwas anderes (HIGH, MAX..) stelle, verliere ich die Verbindung zu den beiden HM-1500. Hat jemand eine Vermutung, woran es liegen könnte? 3. MQTT - was genau muss ich tun, damit ich alles im Home Assistant sehen kann? Muss ich die komplette MQTT-Broker Integration hinzufügen oder reicht auch irgend ein kleines Adaptertool? 4. AHOY vs Open DTU Konkurrenz? Was ist besser? Haben beide die gleichen Funktionen? Viele Grüße Tobias
Tobias G. schrieb: > Ich habe 4 Fragen: > 1. Der ESP8266 hat eine Antenne (geschlängelte Kupferbahn auf der > Platine) und der NRF24 hat ebenfalls eine Antenne (geschraubt). > Welche wird nun benutzt und ist genau wofür? > Wenn beide benutzt werden, ist dann ein mögl großer Abstand zwischen > beiden sinnvoll? geht ja nur um cm, aber man könnte es ja einrichten. Die eine auf dem ESP ist für die WLAN Verbindung zum Router. Darauf finden die normalen Datensignal austausch statt (Webinterface,...). Auf dem NRF24 funkt zwar auch auf 2.4GHz, aber hat ein komplett anderen Protokoll aufbau (die Datenpakette sind nicht gleich wie die vom TCP). Da hier beide auf den gleicheren "Grundfrequenz" senden/empfangen, jedoch eine leichte Verschiebung aufweisen (kommt vom Kanal). Kann es ab und zu dazu kommen, das gewisse Daten nicht korrekt übertragen wurden. - Man kann es nicht ausschließen. Wenn man diese so Positioniert das beide Antennen in die jeweilige Richtung zeigen, sollte es ausreichen. ;) > 2. Wenn ich den "Amplifier Power Level" von MIN auf irgendwas anderes > (HIGH, MAX..) stelle, verliere ich die Verbindung zu den beiden HM-1500. > Hat jemand eine Vermutung, woran es liegen könnte? Kann mehrere Gründe haben, je lauter so ein Ding schreit, umso mehr stört man andere Kommunikation. Oder das Modul stört sich selbst (Mutmassung)? > 3. MQTT - was genau muss ich tun, damit ich alles im Home Assistant > sehen kann? > Muss ich die komplette MQTT-Broker Integration hinzufügen oder reicht > auch irgend ein kleines Adaptertool? Das kann jeder selbst entscheiden. Ich nutze es direkt am Raspberry Pi und MQTT. Darauf läuft gleichzeit auch mein HomeAssistant (aber noch nicht eingebunden). > 4. AHOY vs Open DTU > Konkurrenz? Was ist besser? Haben beide die gleichen Funktionen? Das ist Geschmackssache. Beides hat Vor/Nachteile. OpenDTU nutzt hier nur ein ESP. Ahoy, nutzt ESP und Raspberry Pi (in Python -> nutze ich, somit habe ich kein weiteren Client im Netzwerk).
K. J. schrieb: > 'getSerialNoTxt' was not declared in this scope'getSerialNoTxt' was not > declared in this scope Ich habe mir die Source neu runtergeladen und habe keinen Fehler. Da musst du eine ältere Version haben. K. J. schrieb: > Kann ich die "Vorlage" für den 600er lassen? > Meine Seriennummer lautet: 112173109786 Nein, denn HM400 haben 1 Kanal, HM600 2 Kanäle. Somit ist die Kommunikation bzw Auswertung der Telegramme unterschiedlich. Ich werde versuchen noch heute die Tabelle für den HM400 (gilt auch für 300 und 350) zur Verfügung zu stellen.
@K.J. Die Tabelle für HM400 (HM300, HM350) ist jetzt in HoyDtuSim. Da ich es nicht testen kann, bitte Probleme in meinem Github melden.
Hubi schrieb: > K. J. schrieb: >> 'getSerialNoTxt' was not declared in this scope'getSerialNoTxt' was not >> declared in this scope > > Ich habe mir die Source neu runtergeladen und habe keinen Fehler. Da > musst du eine ältere Version haben. > > K. J. schrieb: >> Kann ich die "Vorlage" für den 600er lassen? >> Meine Seriennummer lautet: 112173109786 > > Nein, denn HM400 haben 1 Kanal, HM600 2 Kanäle. Somit ist die > Kommunikation bzw Auswertung der Telegramme unterschiedlich. > Ich werde versuchen noch heute die Tabelle für den HM400 (gilt auch für > 300 und 350) zur Verfügung zu stellen. Das Problem wurde zwischenzeitlich gelöst auf Discord. Verwendet wurde die Ur-Version, jetzt läuft die AHOY in der aktuellen Version und das zuverlässig auf dem D1 mini. Danke trotzdem für die Meldung Hubi :) lg
Angehängte Dateien:
Hallo Hubi, vielen Dank für die neue Version. Mit einem HM-300 passen noch nicht alle Werte - siehe angehängter Screenshot. Leider stirbt recht schnell das Webinterface weg, die Debugausgabe via USB/Seriel-Monitor läuft dann weiter bis irgendwann ein Stracktrace kommt und neu gestartet wird. Mein Setup: Wemos D1 mini vom Makershop mit nRF24L01+.
Hallo Zusammen, keine Frage und kein Problem ;-) Ich wollte Eu nur ein kurzes Feedback geben. Habe einen Hoymiles HM800 mit 2 Pannels. Ich hatte zuerst Schwierigkeiten selbst zu kompilieren. Nachdem ich das .bin File entdeckt hatte war alles innerhalb von Minuten erledigt. Ein riesen großes Lob an alles hier beteiligten. Eure Arbeit ist sensationell. Alles läuft jetzt bei mir seid 2 Tagen perfekt. Nicht nur die Kommunikation mit dem Wechselrichter ist problemlos, auch die Übertragung an meinen ioBroker per MQTT. Hier wurden alle Datenpunkte perfekt angelegt. Ich bin so was von begeistert. Eine bitte hätte ich dann doch noch, bei neuen Versionen bitte auch das .bin File veröffentlichen. Vielen Dank uns weiter so.....
Hallo Zusammen, keine Frage und kein Problem ;-) Ich wollte Eu nur ein kurzes Feedback geben. Habe einen Hoymiles HM800 mit 2 Pannels. Ich hatte zuerst Schwierigkeiten selbst zu kompilieren. Nachdem ich das .bin File entdeckt hatte war alles innerhalb von Minuten erledigt. Ein riesen großes Lob an alles hier beteiligten. Eure Arbeit ist sensationell. Alles läuft jetzt bei mir seid 2 Tagen perfekt. Nicht nur die Kommunikation mit dem Wechselrichter ist problemlos, auch die Übertragung an meinen ioBroker per MQTT. Hier wurden alle Datenpunkte perfekt angelegt. Ich bin so was von begeistert. Eine bitte hätte ich dann doch noch, bei neuen Versionen bitte auch das .bin File veröffentlichen. Vielen Dank und weiter so.....
Angehängte Dateien:
-
IMG_20220727_200723.jpg
220 KB
Hi Leute, ich habe jetzt alles hin bekommen was das Flashen usw. angeht. Jetzt suche ich die Seriennummer von meinem Hoymiles 1500 Wenn ich die 11617.... eingebe sagt er mir immer das der Wert nicht stimmt. Ich habe aber keinen anderen Aufkleber auf meinem Wechselrichter. Könnt ihr helfen ? (Bild hängt dran) Hostname OpenDTU-%06X SDK Version v4.4.1-1-gb8050b365e Firmware Version 0.1.18 Git Hash 725d482 Reset Reason CPU 0 Vbat power on reset Reset Reason CPU 1 for APP CPU, reseted by PRO CPU Config save count 4 Uptime 0 days 00:54:12
habs eben immer unter DTU Settings eingetragen.....ich Dussel....Was muss ich bei DTU settings eintragen ? Einmal Hilfe hierzu bitte
PeterL schrieb: > Eine bitte hätte ich dann doch noch, bei neuen Versionen bitte auch das > .bin File veröffentlichen. Die .bin-Files sind jetzt schon unter https://github.com/grindylow/ahoy bzw. https://github.com/tbnobody/OpenDTU jeweils unter dem Menüpunkt "Actions" chronologisch aufgelistet. Zum Herunterladen muss man bei GitHub angemeldet sein.
kleine Frage hätte ich noch. Kann das den Wechselrichter auch ohne Module testen ? oder kommt dann nix? Ich war mal so frei und habe ihn eben so angeschlossen ohne alles und es hat keine Lampe oder der gleichen geleuchtet. Auch kam im OpenDTU nix an :( Danke Eike
Die Wechselrichter arbeiten nur, wenn sie mit Gleichspannung versorgt werden. Auch mit angeschlossenen Modulen sind sie nach Einbruch der Dunkelheit nicht mehr erreichbar. Im Blog gibt es Hinweise, dass man die Module zu Testzwecken durch ein geeignetes Labornetzteil ersetzen kann.
ahhhhh danke das erklärt einiges....na dann baue ich den Mist mal zusammen und die Tage aufs Carport. eike
@github Programmierer Hubi, Daniel(s), .... betrifft im Prinzip alle Sourcen ESP8266, ESP32, Raspi, phyton Heute und auch die letzten Tage sind extrem viele Fragen zu div. Dingen gekommen. S/N eintragen, muss das "ULL" stehen bleiben (im Source) ? Format Beispiel direkt im Souce als Kommentar z.B. Wo und wie kommt man direkt ohne Entwicklungsumgebung an die .bin ? Wo liegen die verschiedenen Versionen der .bin´s ? Muß es ein nrf24L01+ sein oder funktioniert auch ein nrf24L01 (ohne Plus) ? Werden hoymiles HMT und HMS auch unterstützt ? Wird DTU-Pro-S auch unterstützt ? Wird Modbus für Zähler auch unterstützt ? Stabile Stromversorgung ... Ich habe mehr als 3 hoymiles HM-..., wird das auch Unterstützt ? (muss im Source geändert werden - ich weiss - aber neue Nutzer eher nicht) Antwortet der HM-.... auch ohne angeschlossene PV Module bzw. Nachts ? Reicht ein ESP8266 mit 1MB oder muss es unbedingt ein ESP8266 mit 4MB sein ? ... Vielleicht könnt Ihr Bitte mal so die letzten Beiträge durchgehen und einiges als FAQs mit aufnehmen in der Hoffnung, das es nicht täglich neu gefragt wird ? Das könnte vielleicht auch jemand machen, der aktuell nicht mit entwickelt, aber sich gut mit github auskennt ? Vielleicht auch 1 Dokument für alle Sourcen zusammen - denn einiges wäre ja Allgemeingültig ? Nur so als Anregung.
:
Bearbeitet durch User
Hallo Leute, Klasse Projekt und Zusammenarbeit, Hut ab. Aber auch ich hänge leider etwas und habe noch keinen 100% Erfolg. Hab es mit einem MINI D1 ESP32 und einem NRF24L01+ aufgebaut. Weboberfläche läuft alles. Allerdings bekomme ich keine Verbindung zum HM-600 und somit auch keine Daten. Es werden nur Nullwerte angezeigt. Nun habe ich bisher testweise nur ein Panel und keine zwei angeschlossen. Kann das vielleicht daran liegen? WR Adresse habe ich komplett (alle Stellen) unter Inverter eingegben. Das ganze lief jetzt 2 Tage und das eine angeschlossene Panel hat tagsüber auch Strom geliefert, aber wie gesagt keine Verbindung. Ich frage mich was ich da noch falsch mache. PS: Ein Problem das ich vorher noch hatte ist dass ich nicht die Typbezeichnung des WR unter dem Menüpunkt Inverter eingegeben hatte sondern einen "freien" anderen Text. Danach verabschiedet sich der ESP32 in einer Dauerbootloop und ist nur mit einem erease_flash wieder zu retten. (Ich hatte das mit esptool erledigt aber da geht nur eine Version > 3.0, ansonsten erscheint die Fehlermeldung "kann ROM nicht löschen", leider ist unter Ubuntu noch eine ältere Version esptool gebündelt.) Habe heute erst hier im Text gelesen dass das erase_flash auch direkt aus PlatformIO heraus gehen soll. Bin mit PlatformIO noch nicht so richtig vertraut. Ein Hinweis hierzu (falschen Textstring bei Inverter) könnte anderen vielleicht diesen falschen Weg ersparen. Sylvester
Sylvester D. schrieb: > Allerdings bekomme ich keine Verbindung zum HM-600 und > somit auch keine Daten. Es werden nur Nullwerte angezeigt. Nun habe ich > bisher testweise nur ein Panel und keine zwei angeschlossen. Kann das > vielleicht daran liegen? Ich betreibe einen HM-600 z. Z. mit einem Modul und erhalte plausible Werte. Die Anschlüsse für das zweite Modul am Wechselrichter sind offen. Es ist für die Funktion unerheblich, welches Paar von Modulanschlüssen am Wechselrichter benutzt wird. Ich würde einen Defekt des nRF24L01+ nicht ausschließen.
DerJens schrieb: > Mit einem HM-300 passen noch nicht alle Werte - siehe angehängter > Screenshot. Geänderte Tabelle ist in meinem Repo. Bei mir läuft das Webinterface schon seit Wochen durch. Versuch mal mit dem Stacktrace und dem Tool "ESP Exception Decoder" die Stelle zu finden wo's crashed. Wie man das macht ist hier im Thread irgendwo zu finden bzw auch im Netz beschrieben.
Hallo Hubi, ich bekomme im Log 82er Meldungen, die sehen so aus:
1 | 12 14 16 18 20 22 |
2 | Hz P_AC ? I_AC ? TEMP |
3 | 82 138A 0121 0000 000C 03E8 011E 0006 11A2 E35F 95 // Beispiel 1 |
4 | 82 1387 0108 0000 000B 03E8 0119 0006 B62A E8ED E6 // Beispiel 2 |
Demnach müsste die Tabelle für P_AC, I_AC, Hz und Temp so aussehen:
1 | { IDX_PAC, CH0, UNIT_W, CMD82, 14, BYTES2, DIV10 },
|
2 | { IDX_IPV, CH0, UNIT_A, CMD82, 18, BYTES2, DIV100 },
|
3 | { IDX_FREQ, CH0, UNIT_HZ, CMD82, 12, BYTES2, DIV100 },
|
4 | { IDX_WR_TEMP,CH0, UNIT_C, CMD82, 22, BYTES2, DIV10 }
|
Muss U_AC dann berechnet werden? U_AC = P_AC / I_AC? Src: https://github.com/grindylow/ahoy/blob/main/doc/hoymiles-format-description.md, Abschnitt CMD0x82
DerJens schrieb: > Hallo Hubi, ... > Muss U_AC dann berechnet werden? U_AC = P_AC / I_AC? U_AC muss nicht berechnet werden bei HM-3.. Es ist der letzte 16 Bit payload Wert /10 im Telegram 01 vor CRC. (ist im übrigen seit vor dem 10.05.2022 schon bekannt)
:
Bearbeitet durch User
Noja, dann sollte das whl so für Hubis HoyDtuSim passen:
1 | const measureDef_t hm400_measureDef[] = {
|
2 | { IDX_UDC, CH1, UNIT_V, CMD01, 14, BYTES2, DIV10 },
|
3 | { IDX_IDC, CH1, UNIT_A, CMD01, 16, BYTES2, DIV100 },
|
4 | { IDX_PDC, CH1, UNIT_W, CMD01, 18, BYTES2, DIV10 },
|
5 | { IDX_E_TAG, CH1, UNIT_WH, CMD01, 24, BYTES2, DIV1 },
|
6 | { IDX_E_TOTAL,CH1, UNIT_KWH, CMD01, 20, BYTES4, DIV1000 },
|
7 | { IDX_UAC, CH0, UNIT_V, CMD01, 26, BYTES2, DIV10 },
|
8 | |
9 | { IDX_IPV, CH0, UNIT_A, CMD82, 18, BYTES2, DIV100 },
|
10 | { IDX_PAC, CH0, UNIT_W, CMD82, 14, BYTES2, DIV10 },
|
11 | { IDX_FREQ, CH0, UNIT_HZ, CMD82, 12, BYTES2, DIV100 },
|
12 | { IDX_WR_TEMP,CH0, UNIT_C, CMD82, 22, BYTES2, DIV10 }
|
13 | }; |
DerJens schrieb: > Noja, dann sollte das whl so für Hubis HoyDtuSim passen: Wenn das dann so passt, vielen Dank. Ich habe das so dann in mein Repo übernommen.
Angehängte Dateien:
So passt es, siehe Screenshot :) Sobald ich aber einen zweiten oder dritten HM-300 dazunehme (mit #define MAX_ANZ_INV 3 und entsprechenden Werten) empfange ich gar keine Werte mehr - auch nicht mehr vom ersten, der ja eigentlich funktioniert...?!
Sylvester D. schrieb: > Hallo Leute, > Klasse Projekt und Zusammenarbeit, Hut ab. > Aber auch ich hänge leider etwas und habe noch keinen 100% Erfolg. Hab > es mit einem MINI D1 ESP32 und einem NRF24L01+ aufgebaut. Weboberfläche > läuft alles. Allerdings bekomme ich keine Verbindung zum HM-600 und > somit auch keine Daten. Es werden nur Nullwerte angezeigt. Hallo welches NRF24L01+ Modul hast du denn, mit externer Antenne, LNA (Low Noise Amplifier) ? Worauf man generell achten sollte dass der ESP mit seinem eigenen Wlan und der NRF24 körperlich etwas voneinander weg montiert werden, die Sendestufen von beiden Teilen können sich gegenseitig so taub machen, dass schlichtweg nichts mehr empfangen wird. Zustopfen nennt sich dass. Ebenso sollte man auf eine gute stabile Spannungsversorgung für den NRF24 achten. Die Pinbelegung muss man entweder so nutzen wie sie im Sourcecode verankert ist oder man muss sich eine eigene Version bauen und komplilieren. Hierbei muss man aufpassen dass man Pins verwendet die auch universell so zu nutzen sind. Was sagt die serielle Schnittstelle, gibts da einen Protokollmitschnitt? Viel Erfolg Solong B
Hallo herbert, das finde ich mega gut. gerade wenn man nicht mit dem vertraut ist was hier alles so passiert. ich zum beispiel habe es hinbekommen aber kann mit diesen zeilen null anfangen. es wahr wohl mehr glück als alles andere das es läuft. wie auhc immer ein howto wie man diese dinger einfach flashen kann.oder ein tool dazu was dies macht ohne eben 23 andere tools zu installieren wäre toll. und wenn jemand das geflshed anbietet wäre ja auch so ne idee. zumindest die amazon links zu den richtigen modulen wäre schon hilfreich ohne das man es wie ich dann 3 mal hin und her schicken muss weil das falsche kam. die idee ist geboren und sie ist gut nun sollten es aber auch mehr leute nutzen können und nicht nur ne hand voll eike
Vielen Dank für die Tips. NRF24L01 +PA LNA SMA und externer Antenne. Heute Abend hat das Teil doch plötzlich mal sporadisch mit dem HM-600 geredet. Zwar nicht viel und benötigte auch einmal einen Retransmit. Es war auch das erstemal dass ich an der seriellen Schnittstelle "Interrupt received" gesehen hab und nicht nur nach einem TX RX Period End > All missing > Nothing received, resend whole request Also prinzipiell funtioniert es wohl. Ich hatte, zumindest mir bewusst, nichts geändert, nur nochmal kontrolliert ob alle Verbindungen richtig sind. Nun, der NRF und der ESP32 könnten wirklich weiter auseinander sein. Sieht wirklich so aus als wäre die Funkverbindung bzw. insbesondere der Empfang nicht sonderlich stabil, oder anderweitig gestört. Jetzt habe ich zumindest mal die Sicherheit dass die Schaltung funktioniert und die Konfiguration richtig ist. Ist auch schon mal viel Wert. Morgen probiere ich mal einen größeren Abstand zwischen den beiden Modulen (ESP und NRF). Kann gut sein dass das das Problem ist. Wenn ich rausfinde was es war lasse ich es Euch natürlich wissen. Danke schon mal für Eure Hilfe. Es ist immer etwas schwierig wenn man nicht genau weiß unter welchen Bedingungen das System wie genau reagieren soll ob man auf dem richtigen oder einem abwegigen Pfad ist. Sylvester
DerJens schrieb: > Sobald ich aber einen zweiten oder dritten HM-300 dazunehme (mit #define > MAX_ANZ_INV 3 und entsprechenden Werten) empfange ich gar keine Werte > mehr - auch nicht mehr vom ersten, der ja eigentlich funktioniert...?! Sorry, aber das gibt meine SW leider noch nicht her. Ich habe leider nur eine Anlage auf dem Gartenhaus mit einem HM-600, das Testen mit mehreren WR also unmöglich. Ich sende zwar an alle "registrierten" Anlagen, aber die empfangenen Daten werden noch nicht korrekt zugeordnet. Da sind die Projekte OpenDTU und ahoy wohl etwas weiter. Wenn entsprechender Bedarf und auch Tester sich finden mache ich da gerne weiter.
Habe mal angefangen eine FAQ zu erstellen wie von AVR Herbi gewünscht und von Juergen vorgeschlagen im Wiki: Wie zu erwarten ist das ganze etwas Protokoll lastig geworden =^D # FAQ Häufig gestellte Fragen https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions
Stefan, danke für das Anlegen des FAQs, das ist ja schon sehr umfangreich. Mir ist aufgefallen, das oft aus der ich Perspektive geschrieben ist. Evtl. finden sich ja Freiwillige, die hier bisschen formulieren helfen :-) Finde es toll wie sich die Zusammenarbeit hier entwickelt hat.
isnoAhoy schrieb: > Habe mal angefangen eine FAQ zu erstellen wie von AVR Herbi gewünscht > und von Juergen vorgeschlagen im Wiki: > # FAQ Häufig gestellte Fragen > https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions War ja nur ein Vorschlag :-) Ich hoffe und würde es Allen, die hier schon länger und regelmäßig mitlesen wünschen, das alle Neuhinzugekommenen sich die Zeit nehmen, das zu lesen. TOP Arbeit für den Anfang ! Ich sage einfach mal Danke, auch wenn es weniger für mich ist, sondern für Andere.
Angehängte Dateien:
Rene M. schrieb: > Weiß jemand was das für Meldungen sind? > ID 12 und 46? ID 12 hatte ich auch in Zusammenhang mit Grid Overvoltage, schaut für mich wie eine wieder gut Meldung nach dem Fehler aus.
Kannst du mal ein Bild hochladen wie du das verdrahtet hast? Habe die gleiche Zusammensetzung aber die pin Belegung ist irgendwie anders an dem kleinen Board
Kannst du mal ein Bild hochladen wie du das verdrahtet hast? Habe die gleiche Zusammensetzung aber die pin Belegung ist irgendwie anders an dem kleinen Board Heinrich P. schrieb: > Hallo zusammen, > und vielen Dank für euere tolle Arbeit. > Hab mir vor 2 Tagen bei komputer.de die Chips bestellt: > 1 Stk. nRF24L01+ PA SMA mit Antenne 3.20EUR > 1 Stk. ESP32 Development board NodeMCU kompatibel 6.50EUR > Heute zusammengelötet, am Mac mini M1 programmiert und es läuft bestens > mit HM-1200. Dabei stellte ich fest, daß von meinen 4 Solarpanelen die > beiden „älteren“ von 2016 nur noch ein Fünftel der Leistung bringen. > Nach nur 6 Jahren! Gruselig… > Grüße, Matze
DerJens schrieb: > Sobald ich aber einen zweiten oder dritten HM-300 dazunehme (mit #define > MAX_ANZ_INV 3 und entsprechenden Werten) empfange ich gar keine Werte > mehr - auch nicht mehr vom ersten, der ja eigentlich funktioniert...?! Die SW HoyDtuSim aus meiner Repo [[https://github.com/hm-soft/Hoymiles-DTU-Simulation/ ]] sollte es jetzt auch mit mehreren WR können. Kann das aber leider nicht testen.
isnoAhoy schrieb: > Habe mal angefangen eine FAQ Vielen Dank, sehr gut! :) Edit: Sorry das ich hier nicht mehr so aktiv bin (mehr Discord GitHub), das hat hier teils überhand genommen und wenn ich am ReverseEngeneering dran bin kann ich nicht gleichzeitig Support spielen. :) https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#welche-modelle-werden-unterst%C3%BCtzt - Sollen hier noch die Modelle Aufgelistet werden, damit jeder weiß welche Modelle Unterstützt werden? Ich glaube nähmlich das neue User nicht ganz sonst durchsteigen?
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.