V0.4.9 - HM-1500

[sude22]

Mit der V0.4.9 commit 01f1fab.... liefert mein HM-1500 leider keine Daten mehr.
Setup wurde neu eingestellt.

Receive success: 0
Receive fail: 171
Send Cnt: 611

Free Heap: 0x90e0

Inverter 'WR1' is not available and is not producing

[sude22]

Sehr merkwürdig. Ich bin jetzt auf meine letzte Version 0.4.3 zurück.
Auch da gibt es jetzt keine Daten mehr. Habe den ESP nochmal komplett gelöscht und Setup
neu.... Keine Daten mehr.
Liegt dann wohl am HM-1500 oder in dem Moment in dem ich das Update gemacht habe hat sich etwas von der Hardware verabschiedet..

[layeraccess]

Selbes Problem bei mir mit dem HM600 und einem ESP8266.

War vorher auf der Version 0.3.6 und die lief seit ca. 2-3 Wochen problemlos.

Habe vorhin auf die 0.4.9 geupdatet und seit dem:

Receive success: 0
Receive fail: 36
Send Cnt: 120

Free Heap: 0x91c8

Inverter 'HM600' is not available and is not producing
-> last successful transmission: 1970-01-01 00:00:00Inverter '����������������' is not available and is not producing
-> last successful transmission: 1970-01-01 00:00:00Inverter '����������������' is not available and is not producing
-> last successful transmission: 1970-01-01 00:00:00MQTT: connected

[layeraccess]

Nachdem ich die Seriennummer des Inverters neu reingeschrieben habe (stand vorher genau so drinnen), empfange ich wieder Daten:

Receive success: 8
Receive fail: 331
Send Cnt: 1093

Free Heap: 0x8e50

Inverter 'HM600' is available and is producing
Inverter '����������������' is not available and is not producing
-> last successful transmission: 1970-01-01 00:00:00Inverter '����������������' is not available and is not producing
-> last successful transmission: 1970-01-01 00:00:00MQTT: connected

Ist das Verhältnis zwischen erfolgreich empfangenen, fehlerhaften empfangenen und gesendeten Daten eigentlich normal?

[lumapu]

@layeraccess sieht so aus als wären bei den Invertern 2 und 3 noch Datenfragmente vorhanden, bitte mal alles unnötige rauslöschen und neu speichern. Dann sollte auch das Verhältnis von success zu fail wieder viel besser werden, also eher invertiert zu dem hier geposteten.

@sude22 sehr komisch was da los ist, auch bei dir nochmal die Setup Seite durchschauen und rauslöschen was nicht nötig ist. Bitte auch noch das Pinout gegechecken, nicht dass das durch den "Reset" falsch steht.

@ALL ist die WiFi Verbindung mit dieser Version wieder besser, d.h. ist der ESP durchgehend erreichbar und reagiert sofort?

[sude22]

Ja, neu eintragen hat geholfen. Danke für den Tipp

[sude22]

Auf mich macht die 0.4.9 in Bezug auf Erreichbarkeit und Reaktionszeit einen sehr guten Eindruck.
Die Uptime kommt gefühlt aber nicht über ein bis zwei Stunden, habe ich aber nicht genau gemessen....
[EDIT] Wollte noch anmerken, dass ich wirklich begeistert bin von der Software! In so kurzer Zeit so was hier auf die Beine zu stellen ist echt aller Ehren wert. Sollte nur nochmal gesagt sein.

[felix2RB]

Moin,
Danke für den Tip.
erase settings gemacht , neu eingetragen , geht. ;)

Hardware:
HM-1200
nodemcu v3

[layeraccess]

@layeraccess sieht so aus als wären bei den Invertern 2 und 3 noch Datenfragmente vorhanden, bitte mal alles unnötige rauslöschen und neu speichern. Dann sollte auch das Verhältnis von success zu fail wieder viel besser werden, also eher invertiert zu dem hier geposteten.

@sude22 sehr komisch was da los ist, auch bei dir nochmal die Setup Seite durchschauen und rauslöschen was nicht nötig ist. Bitte auch noch das Pinout gegechecken, nicht dass das durch den "Reset" falsch steht.

@ALL ist die WiFi Verbindung mit dieser Version wieder besser, d.h. ist der ESP durchgehend erreichbar und reagiert sofort?

Danke! Ich bin davon ausgegangen, dass die "fffffffffff" als Placeholder stehen. Das Rauslöschen der beiden anderen WR hat massive Verbesserungen gebracht und die Signale kommen jetzt deutlich öfter an:

Receive success: 279

Receive fail: 1
Send Cnt: 323

Free Heap: 0x8df8

Inverter 'HM600' is available and is producing
MQTT: connected

[layeraccess]

@ALL ist die WiFi Verbindung mit dieser Version wieder besser, d.h. ist der ESP durchgehend erreichbar und reagiert sofort?

Also bei mir war das Webportal nach einigen Stunden nicht mehr erreichbar und auch die MQTT-Verbindung ist abgebrochen:

2022-05-25 11:14:38.595 | info | Client [ESP-9f64] connection closed: timeout

Per Ping war der ESP weiterhin erreichbar, am WLAN liegt es also nicht.

Ich werde weiter beobachten und berichten.

[sude22]

Das ist bei mir leider auch so. Eben zum 2. mal heute Nachmittag Web Oberfläche nicht mehr erreichbar. Hilft nur ein Reset per Taste.

[DanielR92]

Moin zusammen,
welche Version nutzt ihr Aktuell und was für Einstellungen habt ihr gesetzt?
Könnt ihr es reproduzieren?

[sude22]

Moin zusammen, welche Version nutzt ihr Aktuell und was für Einstellungen habt ihr gesetzt? Könnt ihr es reproduzieren?

Ich nutze die 0.4.13. Im Moment hängt der ESP an einem Notebook zur Aufzeichnung des seriellen Logs in eine Datei.
Gestern konnte ich den Fall mit dem "Nicht-Erreichbar-Sein" nicht beobachten. Dafür aber die bekannten Resets von Zeit zu Zeit.
Ich hab mal die Uptime ins MQTT gebracht und über den Tag aufgezeichnet, da sieht man die Resets ganz gut.

Bei Reset immer das gleiche:
free: 0x9d08 - max: 0x9cc0 - frag: 1%
free: 0x9d08 - max: 0x9cc0 - frag: 1%
dev 1163

ets Jan 8 2013,rst cause:4, boot mode:(3,7)

wdt reset

cause:4 --> Hardware-Watchdog, soweit ich das ermitteln konnte....

[hismastersvoice]

Kann ich genau so bestätigen.

ESP ist immer erreichbar mit 0.4.13, reboot durch watchdog ausgelöst kommt fast jede Stunde.

Updateintervall aktuell alle 10 Sekunden, auch Erhöhung des Wert auf 30 und 60 Sekunden verbessert das Verhalten nicht.

So lange der ESP immer erreichbar bleibt sind die reboots auch wenn unschön für mich zu ohne Problem.

[sude22]

Ich nutze die ESP8266 zwar schon länger, bin aber leider kein Experte was die "Innereien" angeht.
Trotzdem habe ich versucht mal etwas zu den Resets zu ermitteln.
Was bei meinem Log vor dem Reset steht ist evtl. wichtig: "dev 1163"
Google findet ein paar wenige Treffer, z.B. hier
Scheinbar kann eine zu lang laufende Interupt-Routine den Fehler auslösen. Ist aber mehr oder weniger geraten.
Eine Option wäre dann, die Aktionen aus der Interupt-Routine auszulagern und dort nur einen Trigger zu setzen.
Aber da können Experten wahrscheinlich mehr zu sagen.

[lumapu]

das klingt auf jeden Fall sehr vernünftig. Deshalb habe ich auch dass break in der hmRadio.h eingefügt. Mir war / ist (und jetzt noch mehr) die while Schleife ein Dorn im Auge. Ich habe schon Ideen und werde versuchen.

[stefan123t]

Die 0.4.15 bzw. 0.4.15 behebt die while Schleife und optimiert den kritischen Code Block im Interrupt Handler weitestgehend.
Bei mir seit über 4 Stunden ohne Abstürze, so kann das gerne bleiben!

[lumapu]

ich glaube nicht, dass wir den Fehler schön gefunden haben - aber wo versteckt er sich nur?

[stefan123t]

Hallo @lumapu,
habe nochmal ein bißchen gemessen, mit Sonnenlicht geht das besser und schöner =^)

07:09:25.615 -> Requesting Inverter SN 114173104111
07:09:25.615 -> Transmit 27 | 15 12 34 56 78 78 56 34 12 80 0B 00 62 99 B3 84 00 00 00 05 00 00 00 00 0D 63 02 
07:09:28.635 -> Error while retrieving data: last frame missing: Request Retransmit
07:09:28.635 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 83 AD 
07:09:29.896 -> app::showIndex
07:09:29.929 -> Main::showCss
07:09:30.260 -> Error while retrieving data: last frame missing: Request Retransmit
07:09:30.260 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 83 AD 
07:09:31.787 -> Error while retrieving data: last frame missing: Request Retransmit
07:09:31.787 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 83 AD 
07:09:33.281 -> Error while retrieving data: last frame missing: Request Retransmit
07:09:33.314 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 83 AD 
07:09:34.807 -> Error while retrieving data: last frame missing: Request Retransmit
07:09:34.807 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 83 AD 
07:09:36.334 -> Error while retrieving data: last frame missing: Request Retransmit
07:09:36.334 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 83 AD 
07:09:37.860 -> Error while retrieving data: last frame missing: Request Retransmit
07:09:37.860 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 83 AD 
07:09:39.392 -> Error while retrieving data: last frame missing: Request Retransmit
07:09:39.392 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 83 AD 
07:09:40.919 -> Error while retrieving data: last frame missing: Request Retransmit
07:09:40.919 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 83 AD 
07:09:42.445 -> Error while retrieving data: last frame missing: Request Retransmit
07:09:42.445 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 83 AD 
07:09:43.972 -> Error while retrieving data: last frame missing: Request Retransmit
07:09:43.972 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 83 AD 
07:09:45.465 -> Error while retrieving data: last frame missing: Request Retransmit
07:09:45.498 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 83 AD 
07:09:46.992 -> Error while retrieving data: last frame missing: Request Retransmit
07:09:46.992 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 83 AD 
07:09:48.518 -> Error while retrieving data: last frame missing: Request Retransmit
07:09:48.518 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 83 AD 
07:09:48.584 -> Received 23 bytes channel 75: 95 12 34 56 78 12 34 56 78 83 00 00 00 10 03 E8 00 BA 00 0B CF AC 3F 
07:09:50.044 -> Error while retrieving data: Frame 1 missing: Request Retransmit
07:09:50.044 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 81 AF 
07:09:50.077 -> Error while retrieving data: Frame 2 missing: Request Retransmit
07:09:50.077 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 82 AC 
07:09:51.604 -> Error while retrieving data: Frame 1 missing: Request Retransmit
07:09:51.604 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 81 AF 
07:09:51.638 -> Error while retrieving data: Frame 2 missing: Request Retransmit
07:09:51.638 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 82 AC 
07:09:53.164 -> Error while retrieving data: Frame 1 missing: Request Retransmit
07:09:53.164 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 81 AF 
07:09:53.197 -> Error while retrieving data: Frame 2 missing: Request Retransmit
07:09:53.197 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 82 AC 
07:09:54.724 -> Error while retrieving data: Frame 1 missing: Request Retransmit
07:09:54.724 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 81 AF 
07:09:54.757 -> Error while retrieving data: Frame 2 missing: Request Retransmit
07:09:54.757 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 82 AC 
07:09:56.251 -> Error while retrieving data: Frame 1 missing: Request Retransmit
07:09:56.284 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 81 AF 
07:09:56.284 -> Error while retrieving data: Frame 2 missing: Request Retransmit
07:09:56.317 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 82 AC 
07:09:57.811 -> Error while retrieving data: Frame 1 missing: Request Retransmit
07:09:57.811 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 81 AF 
07:09:57.844 -> Error while retrieving data: Frame 2 missing: Request Retransmit
07:09:57.844 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 82 AC 
07:09:59.371 -> Error while retrieving data: Frame 1 missing: Request Retransmit
07:09:59.371 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 81 AF 
07:09:59.404 -> Error while retrieving data: Frame 2 missing: Request Retransmit
07:09:59.404 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 82 AC 
07:10:00.930 -> Error while retrieving data: Frame 1 missing: Request Retransmit
07:10:00.930 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 81 AF 
07:10:00.964 -> Error while retrieving data: Frame 2 missing: Request Retransmit
07:10:00.964 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 82 AC 
07:10:02.490 -> Error while retrieving data: Frame 1 missing: Request Retransmit
07:10:02.490 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 81 AF 
07:10:02.523 -> Error while retrieving data: Frame 2 missing: Request Retransmit
07:10:02.523 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 82 AC 
07:10:02.556 -> Received 27 bytes channel 75: 95 12 34 56 78 12 34 56 78 02 57 6C 00 00 53 6E 00 13 00 13 08 FA 13 8B 01 67 9D 
07:10:04.050 -> Error while retrieving data: Frame 1 missing: Request Retransmit
07:10:04.050 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 81 AF 
07:10:05.543 -> Error while retrieving data: Frame 1 missing: Request Retransmit
07:10:05.576 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 81 AF 
07:10:07.069 -> Error while retrieving data: Frame 1 missing: Request Retransmit
07:10:07.103 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 81 AF 
07:10:08.596 -> Error while retrieving data: Frame 1 missing: Request Retransmit
07:10:08.596 -> Transmit 11 | 15 12 34 56 78 78 56 34 12 81 AF 
07:10:08.662 -> Received 27 bytes channel 75: 95 12 34 56 78 12 34 56 78 01 00 01 01 48 00 3B 00 C3 01 4A 00 37 00 B5 00 00 ED 
07:10:10.122 -> Payload (42): 00 01 01 48 00 3B 00 C3 01 4A 00 37 00 B5 00 00 57 6C 00 00 53 6E 00 13 00 13 08 FA 13 8B 01 67 00 00 00 10 03 E8 00 BA 00 0B 

Hier wird zuerst immer das vermeintlich letzte Paket 0x83 angefordert und dann die fehlenden Pakete dazwischen.
Laut den Aufzeichnungen aus der DTU W-Lite von martin (Gast) findet dort das Retransmit der Reihe nach statt, d.h. wenn Paket 0x01 nicht empfangen, dann wird auch dieses zuerst mit 0x81 angefordert, dannn 0x02 mit 0x82 und so weiter.
Wenn ich mich recht entsinne, dann hat der HM-1500 und die anderen vier Input Channel Inverter bis zu fünf Pakete also bis 0x84 ?

[lumapu]

Das Anfordern der Pakete liegt an der Logik, das zuerst bekannt sein muss welches das letzte Paket ist. Erst wenn dieses bekannt ist können die anderen per for loop angefragt / geprüft werden.
Evtl. müssen wir sowas wie ein 'predict' für das letzte Paket einführen - wir wissen ja was wir erwarten. Ich wollte es nur hier nicht ändern, da wir in Zukunft hoffentlich wie in der Python-Version auch noch größere bzw. andere Anfragen stellen.

[sude22]

Leider mit der 0.4.15 keine Verbesserung, im Gegenteil.
Nochmal kurz mein Setup:
WemosD1mini/nRF24L01+auf Shield gelötet/per USB am Laptop
2xHM-1500 (in config.h auf MAX 2)

Die Uptime ist nicht über 10 Minuten gekommen, wieder der bekannte "dev 1163"-Fehler.
Der Empfang der Pakete hat sich gefühlt auch stark verschlechtert, zum Teil für einen WR keine Werte nach 5min.

Bin zurück zur 0.4.13, diese läuft für den "Produktiv-Einsatz" deutlich stabiler.
Wenn ich irgendwas an Logs oder so sinnvoll beisteuern kann bitte Bescheid sagen.

[stefan123t]

@lumapu ich verstehe das nicht:

Das Anfordern der Pakete liegt an der Logik, das zuerst bekannt sein muss welches das letzte Paket ist.

Man kann doch einen Zähler bei 0x01 starten und so lange inkrementieren bis als Antwort ein 0x8y zurückkommt. Das ist dann das letzte Paket der Nachricht.
Also solange die Antwort nicht > 0x80 ist haben wir noch nicht das finale Paket. Dann Retransmit und noch mal lauschen.
Eine gesamte Payload kann also max. 0x7F Pakete enthalten. Dann sind wir bei 0xFF angekommen.

[lumapu]

gute Idee, so kann man es auch lösen. Vor allem ist man dann komplett unabhängig von der tatsächlichen Länge der Payload.

[stefan123t]

Ja genau, die Länge der Payload Antwort auf die 0x80 0x0B Anfrage ist ja m.W.
bei HM-300/400/500 jeweils zwei Pakete,
bei HM-600/700/800 jeweils drei Pakete und
bei HM-1000/1200/1500 sind es vier/fünf Pakete.

Bereits bekannte / identische Pakete, die eventuell mehrfach vom WR geschickt /empfangen werden,
können ja einfach verworfen werden.
Die müssen dann nicht in den Payload Buffer für die CRC_16/CRC_M Summe.

[lumapu]

Hallo Stefan,

ich denke es liegt an folgender Stelle, dass wir Pakete mehrfach sehen:
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/hmRadio.h#L271

Jan-Jonas (@Sprinterfreak) hat im Forum mal geschrieben, dass er schon alle Kombinationen ausprobiert hat und bei dieser gelandet ist. Durch die funktionierenden Retransmits wäre es meiner Meinung nach durchaus möglich hier die Retries zu reduzieren. Man muss aber weiterhin bedenken, das auch andere auf dem Band funken.

[stefan123t]

@sude22 ich denke es wäre sinnvoll mal ein paar Deiner Logs näher anzusehen. Ich habe leider nur einen WR HM-600. Dabei habe ich nur Nachts mit dem WiFi WebServer Probleme. Tagsüber läuft alles.
Ich habe die Vermutung, dass wenn die RX Routine keine Payload zusammen bekommt, dann verhungert der weniger priore WebServer „Task“. Wie das Verhalten bei zwei Wechselrichtern ist kann ich nicht sagen.

@lumapu vielleicht sollten wir doch eine State Machine einführen, die dafür sorgt dass alle „Tasks“ erledigt werden. Es geht ja um ein Neben-/Nacheinander von:

• WiFi Verbindung aufbauen
• NTP Zeit ermitteln oder aktualisieren (WiFi)
• WebServer Seiten ausliefern (WiFi)
• MQTT Nachrichten versenden (WiFi)
• TX/RX Aufgaben (nacheinander für alle definierten Wechselrichter) + Payload dekodieren (NTP)

Dabei ist wichtig dass einige Tasks nur mit WiFi funktionieren. Sollte der ESP die WiFi Verbindung verlieren muss er evtl. andere Tasks hinten anstellen.

Auch sollte er mE nicht die WR fragen so lange die NTP Zeit noch nicht gesetzt ist (> 0 unix epoch).
Wie gross die Abweichung der ESP Zeit von der NTP Zeit ist sollte er ggf. auch in regelmäßigen Abständen überprüfen. Aber das ist nicht so dringend, alle paar / 24 Stunden reicht vielleicht schon.

Wie häufig soll denn eigentlich der/die WR abgefragt werden, reicht das alle paar / 5 Minuten ?

Die MQTT Daten häufiger als die TX/RX Daten zu übermitteln macht auch keinen Sinn. Das könnte ggf. über ein Flag als nachgelagerter Task oder alle x Minuten erfolgen.

Die beiden wichtigsten Tasks bleiben mE TX/RX Daten an die WR übermitteln (weil zeitkritisch) und den ESP WebServer die Anfragen abarbeiten lassen, weil sonst keine Verbindung möglich ist und ggf auch der Eingangspuffer des ESP/WebServers überlaufen könnte.

Der bisher auch immer wieder geschedulete AccessPoint Task ist mE nicht ganz so wichtig. Der muss eigentlich nur zwingend nach einem Reboot zur Verfügung stehen. Eventuell kann man den AP auch gleichzeitig zum WebServer im Station Mode aufmachen, dann könnte man das über eine Option im WebServer Menü jederzeit zusätzlich aktivieren.
Dass er ggf. nach X Verbindungsversuchen mit dem WiFi auch wieder den AP aufmacht ist mE eine nützliche Convenience Funktion, nimmt aber bei mir viel Zeit in Anspruch, die nicht für den (Wieder-)Aufbau der WiFi Verbindung (NTP, WebServer & MQTT Client) zur Verfügung steht. Da meine WiFi Verbindung (im Keller) manchmal (tagsüber) von vielen anderen Funkteilnehmern einfach übersteuert wird. Aber mit dem AP kann ich ausser zum Setup nicht so viel anfangen. Dazu müsste ich mich ja jeweils direkt mit dem AP verbinden und habe dann kein Internet mehr am Rechner.

[sude22]

Anbei mal ein aktueller Log von mir.
ahoy_20220605.zip

[Sprinterfreak]

Jan-Jonas (@Sprinterfreak) hat im Forum mal geschrieben, dass er schon alle Kombinationen ausprobiert hat und bei dieser gelandet ist. Durch die funktionierenden Retransmits wäre es meiner Meinung nach durchaus möglich hier die Retries zu reduzieren.

Retries und Retransmits haben unterscheidliche Aufgaben. Retry hilft, wenn der WR die Anfrage nicht korrekt empfangen hat. Das erkenne ich daran, dass ich kein einziges Fragment der Antwort bekomme. Weil python eben auch ermöglicht custom payloads zu senden erhöht das einfach die Wahrscheinlichkeit, dass auch die erfolgreich abgesetzt werden.

Retransmits fordern fehlende Fragmente an, wenn mindestens ein Fragment Antwort empfangen wurde. Man kann kein 0x83 anfordern. Das letzte Paket fordert man immer mit 0x80 an. Wenn man das hat, weiß man wie lang die Payload sein muss.

[stefan123t]

Anbei mal ein aktueller Log von mir.
ahoy_20220605.zip

Hallo @sude22
Wie ich es vermutet habe das ESP Programm versucht alle drei WR gleichzeitig zu erreichen. Dann kommt so gut wie nichts zurück, weil die Empfangsroutine evtl. gerade auf die Antwort eines anderen WR wartet.
Kannst Du mal versuchen die zwei anderen WR aus der Konfiguration zu entfernen ? Dann sollte es eigentlich funktionieren.

[sude22]

Ich habe mal für mich den Code so geändert, dass pro "Sendeintervall" immer nur einer der drei Wechselrichter angefragt wird.
Der Interval ist auf 30 Sekunden eingestellt.
Ich sehe jetzt im Log ein deutlich besseres Verhalten, innerhalb der 30 Sekunden wird fast immer eine Payload empfangen.
Danke @stefan123t für den Tipp.
Den bösen "dev 1163" gab es aber auch schon wieder... Da der Irq ja jetzt entkoppelt ist wird es daran wohl nicht liegen. Da er aber so selten auftritt denke ich, dass es entweder doch an der nicht optimalen Spannungsversorgung über USB oder irgendwo in den tiefen der Web/Mqtt Libraries begründet ist.

[stefan123t]

@sude22 klasse, das freut mich dass es jetzt klappt. Kannst Du Deine Änderungen evtl. als Pull Request einschicken, damit auch andere davon profitieren ?
Bzgl. dev 1163 habe ich mal meine ca. 30 Stacktraces von den WDT Resets der letzten Tage/Woche durchforstet aber keine Treffer. Da kann ich Dir also nicht weiterhelfen. Bei mir läuft er mit der 0.4.15 und der neuen Interrupt Handler Routine "stabil" seit 1 Tag und 20:11 Stunden.

@lumapu vielleicht machen wir das Intervall ja noch konfigurierbar, bzw. verwenden dafür eines der bereits definierten Intervall Settings. Das Generelle Intervall mSendIntervalmacht aus meiner Sicht am meisten Sinn.
BTW: das MQTT Intervall sollte (bzw. muss ?) gleich oder größer sein wie die Anzahl der konfigurierten WR mal dem Generellen Intervall (also getNumInverters() * mSendIntervall).

[lumapu]

@sude22 super, finde ich toll, dass du es getestet und dabei noch verbessert hast. Habe selbst nur einen WR.

@stefan123t wie wäre es das MQTT Intervall automatisch zu berechnen anhand der Anzahl der WR und des SendIntervall und nicht mehr einstellbar machen?

Ich habe selbst auch schon eine Uptime von über 24h gehabt, aber immer wieder gibt's trotzdem einen Reset. Einfach weiter beobachten.

Was ist der "dev1163"?

[lumapu]

@sude22 Kannst du bitte die neueste Version 0.4.17 nochmal testen, ob das Multi-Inverter Setup jetzt besser klappt? Jetzt wird pro Loop nur ein Inverter angefragt.

Edit:
Achtung: Alle Einstellungen gehen verloren durch neues Memory-layout, außer WiFi

Verson aktualisiert

[hismastersvoice]

Danke für das schöne Projekt,

Ich habe 2x Wemos D1 für je einen HM1500 im Einsatz. (Inverter stehen zu weit aasender um nur einen zu nutzen)
Bei jeder Version wurde die Übertragung und das WebUI immer besser.

Folgendes ist mir noch aufgefallen.

• reboots kommen immer noch vor, aber deutlich seltener als bei früheren Versionen
• Werte sind immer wieder unplausibel mal geht er auf 12.000W hoch dann weider auf 0W um dann passt es immer wieder.
  Genau diese Genauigkeit bräuchte ich aber das ich Geräte wie Heizstab use. sauber steuern kann.
• WebUI ist sehr viel schneller als noch vor 3-4 Versionen, hängt hin und wieder immer noch für ein paar Sekunden. Vielleicht ist das aber der Leistung des 8266 geschuldet. Würde auch ein ESP32 funktionieren?
• MQTT - Interval kann nicht mehr eingestellt werden bei 0.4.17, ist immer gleich des Abfrage Wert der Inverter (gewollt?)

Da ich parallel immer mit einer DTU-Pro die Übertragung teste, kann ich sagen das obwohl die Wemos nur 2 Meter von den Invertern entfernt stehen DTU ~15 Meter), das es diese Fehlerwerte bei der DTU nicht gibt.

Freue mich schon weiter zu testen.
Danke für die tolle Arbeit!!

[Sprinterfreak]

Könnten die falschen Werte vielleicht daran liegen?
https://github.com/grindylow/ahoy/blob/10b3978fa32d9f2913ffd7920336d6c9aa9ee4d4/tools/esp8266/hmRadio.h#L89

Dann hatte ich noch in Erinnerung, dass mal Payloadfragmente aus unterschiedlichen Transaktionen zusammengewürfelt wurden. Das währe dann auch sichere Ursache für solche Werte.

[lumapu]

ist das falsch? Ich habe es unverändert von Hubi übernommen, muss man den NRF24 CRC aktivieren?

Beim HM1500 sollten die Daten nicht über mehrere Frames gehen und die Gesamtpayload ist jetzt doch schon einige Versionen implementiert. Ich kann bei mir keine Ausreißer erkennen, zumal ja der Payload CRC gecheckt wird bevor die Daten übernommen werden.

[Sprinterfreak]

Ohne dem bombardiert der NRF die CPU mit verrauschtem Datenmüll.

Siehe Python, habe damit gute Erfahrungen gemacht:
https://github.com/grindylow/ahoy/blob/10b3978fa32d9f2913ffd7920336d6c9aa9ee4d4/tools/rpi/hoymiles/__init__.py#L319

Ich unke jetzt mal rum und stelle in den Raum, dass auf die daraus resultierende Interrupt-Flut, der ein oder andere Crash zurückzuführen ist.

[lumapu]

danke für den Hinweis, das werde ich auch ausprobieren. Kann gut sein, dass der ESP überflutet wird, habe mir immer nur schon gefilterte Nachrichten angeschaut.

[hismastersvoice]

@Sprinterfreak
Das war es, ich habe //mNrf24.disableCRC(); auskommentiert und neu kompiliert.
Beide Systeme liefern seit seit 2,5 Stunden ohne einen fehlerhaften Wert.
Zuvor war alle paar Minuten ein 0 oder extrem hoher Wert zB 12000 dabei.

Werde mir das über die nächsten Tage anschauen, aber sieht soweit ganz gut aus.
Danke für den Input.

@lumapu
Selbst 5 Sekunden Abfrage läuft jetzt sauber und "Receive fail:" sind deutlich weniger als zuvor.
Ich werde das ganze auch nochmal beobachten ob die ggf. die reboots zurück gehen.

So gefällt mir das Ganze und ich kann damit arbeiten.
Dann drucke ich heute mal die Gehäuse ;)

Danke nochmal für das tolle Projekt.

[stefan123t]

Hallo @hismastersvoice

Ich habe 2x Wemos D1 für je einen HM1500 im Einsatz.

Kannst Du die Schaltung in #36 überprüfen und ggf einen Kommentar hinterlassen. Danke!

[stefan123t]

Ich glaube das Issue kann geschlossen werden, die o.g. Bedingungen für eine State Machine sollten evtl. noch anderweitig übernommen werden. Mit PR#76 0347a3df sollte auch das hier beschriebene Problem mit den erase settings behoben sein.