Several alarms „DTU command failed“ #1202
Comments
|
|
|
Ist auch unter 0.7.63 der Fall. Der Inverter ist erst 3 Stunden wach, hab schon 23 Alarme "DTU command failed". |
|
Ist bekannt. Bis man genau weiß was der Fehler aussagt, müssen wir es erst mal akzeptieren. Und ein Bug ist es auf jeden Fall nicht, da die Meldung direkt vom Inverter kommt und somit uns was sagen will. |
|
habt ihr eine Art von Limitierung aktiv? Da ist bekannt, dass das der Fehler aus dem inverter kommt wenn man (ahoy) zu schnell den Wert zurückliest |
|
Ja und nein. Es kommt bei meinen HM-300ern sowohl bei dem limitierten als auch von den unlimitierten. |
|
Ich hatte es auch einmal die letzten Tage im unlimitierten HM-600... |
Ja in der Tat. Allerdings hatte ich bisher nie so viele Alarme. Bei den ganzen 0.7.5er Releases hatte ich vielleicht 8 Alarme den ganzen Tag, mit dem selben Zero Export. Habe heute nach 5 Stunden schon 39. Nachtrag: Grad mal die Logs vom Zero Export durchgesehen: Nach dem Senden des Limits wartet das Script auf das achknowledge vom Inverter, was eigentlich sofort zurückkommt. Der Timeout liegt bei 6 Sekunden. Es kommt hier seit einigen Versionen öfter zu einem Timeout. Die Zeitstempel im Log und in Ahoy passen da genau zusammen. |
Nein, bei mir ist nichts limitiert. Es ist auch definitiv erst seit 0.7.63 so. |
|
Das ist schon vorher so 😉 Kommt nur bei dem einen oder anderen früher oder später. |
|
Bei mir ähnliches Phänomen, die ganze Kommunikation ist sehr schlecht geworden? RX no answer und RX Fail schießen in die Höhe seit Update von .60 zu .65. Seit heute Morgen über 30 Alarme. Ich kann nachher noch Bilder liefern, bin gerade unterwegs. edit: auch über MQTT kommen nur noch sporadisch Werte: edit2: Downgrade auf .60 und alles läuft wieder problemlos. 0 Alarme und problemlose Kommunikation. |
|
ich sehe bei mir den Fehler auch, allerdings nur bei den inverter, bei den ich heute Morgen das neue Power-Limit-Popup getestet habe. |
|
Seit knapp 3 Stunden läuft bei mir wieder 0.7.59 mit laufendem ZeroExport. Beide Inverter seit dem kein Alarm mehr. |
Mir geht das schon ein paar Versionen so, mal einen Tag fast nichts bzw. nur Start und 2-3, und heute von 3 Invertern "947+717+156" Alarme also mal eben knapp über 1800.... Zu dem was ich sehen kann als Alarm ist es faktisch nur die die Zwei, frage aber auch mit 2 DTU die Wechselrichter ab, bzw nur 2 Wechselricheter mit Open und 3 mit Ahoy....trotzdem müsste es ja dann Jeden Tag auftreten...ist aber nicht so. Tagesende Nur 1240 Alarme auf dem HM-800 alleine, auf dem HM-400 waren es nur noch 1186 Alarme und der HM-300 belegt mit nur 200 Alarme den dritten Platz. Lass mir ja gefallen das es ab und zu Mal ne Anfrage gleichzeitig gibt bei den 2 DTU (was man ja nicht machen soll), aber komm ich überhaupt bei 9&11 sek auf die Chancen über 1000 gleichzeitige Abfragen, an einem Oktober Tag hinzubekommen? |
|
Es wäre schön, wenn ihr alle eure HW dazuschreibt, also ob ESP8266 oder ESP32 damit man das Problem, ich nenne es absichtlich nicht Bug, besser eingrenzen kann. Als Beispiel : Ich habe 13 Inverter an einem ESP32S3 (Fusion-Board) hängen und habe für heute genau 13 Fehler, alle lauten „Inverter Start“ 😉 |
|
ESP32 (30-PIN) Besonderheit, Abfrage von 2 Invertern parallel mit Open DTU. Hoffe das war richtig so. |
|
Hatte seit der Früh weg die 0.7.63 auf einem ESP32 am laufen (1xHM800). Abgesehen von der Inverter Start Meldung (nur einmal, zur richtigen Uhrzeit) sehe ich keine weiteren 'Alarme' in der Live View. Oder wo sollten die sein? |
|
Bin auf dem ESP32. Habe gerade die Logs vom ZeroExport nochmal angesehen. Heute bis Mittag hatte ich ja die 7.63 drauf, da kam quasi im Minutentakt ein Timeout bei ackknowledge nach dem Limitsetzen. Danach lief ab kurz nach Mittag wieder 0.7.59. Da hatte ich diesen Fehler den ganzen Tag nur noch 1x, und Ahoy hatte auch nur noch einen Alarm. |
|
ESP8266, 2 Inverter HM-600 und 350, Häufigkeit bei beiden ca. 10x , abwechselnd. Heute ist der andere betroffen als gestern, kein Power Limit Vielleicht hilft der Trace. Es ist zwar ein Offset von 2 Stunden im Log, aber sie sind definitiv zeitgleich aufgenommen. und die Alarme von inverter #0 Edit by lumapu: Übersichtlichkeit des Logs verbessert |
Bei mir gehts heute so weiter...bin schon bei >300
|
|
Ich finde das echt spannend ! Ich habe keinen einzigen Alarm, eben außer dem Inverter Start. Scheint wohl ein Ressourcenproblem zu sein ? Mein ESP32S3 arbeitet das sauber ab. |
|
I just tested with ESP-8266, new installed 0.7.65 and HM-inverter is working without any of such alarms. |
An welcher Ressource solls denn liegen, ist der ESP32 in 6 Monaten, vollkommen verschlissen? Oder NRF Modul abgenutzt? Hab sogar den Kondensator damals nachgerüstet als ich das 2.42er ins Gehäuse verbaut habe und es auf Low gestellt... Es ging ja bisher auch...und hätte man die Alarm anzeige nicht, würde es nicht mal auffallen...da ich eh nichts Steuer, oder Abfrage (bis auf Live View & Display) macht es auch keine schmerzen. Kann auch Testweise z.b. mal einen Tag die OpenDTU offline nehmen...wenn es an den Parallelen abfragen liegen sollte, aber der 300er wird ja nur von der Ahoy abgefragt und hat auch schon 157 Alarme drauf...gut der rest zusammen über 2000. Aber es war ja vorher auch nicht so, erst seit ein paar Versionen steigert sich das ja bis auf über 1000 am Tag. Was ich morgen auf jedenfall mal machen werde von Low weg auf High, ob es besser wird...heute lohnt es sich nicht mehr...bei zusammen unter 50w aus 4 Modulen... |
Nein, wird wohl an Ahoy liegen. Versuche mal ein Downgrade auf 0.7.59, die Version hat auch heute nur den Alarm für den Inverterstart angezeigt. Wie @reserve85 schon angemerkt hat, ab der 0.7.60 ist wohl der Wurm drin. |
|
Gerade spaßeshalber mal die 0.7.65 probiert. DTU Uptime ist jetzt bei knapp 15 Minuten. Inverter 1 zeigt nur den Startalarm, Inverter 2 zeigt knapp alle 30 Sekunden einen Alarm. Scheint, als ob 1 Inverter fehlerfrei funktioniert, ab zweien häufen sich dann die Fehler. Edit: Ich habe testweise den 1. Inverter (der keinen Alarm verursacht) in Ahoy deaktiviert. Der Übriggebliebene 2. Inverter verursacht jetzt keinen Alarm mehr, seit 20 Minuten. |
|
Bei mir sind diese „invalid“ Alarme immer zeitlich gruppiert. Wenn ein Alarm eingetragen ist, dann folgt immer ein zweiter Alarm nach 30s. Dann ist immer einer Pause/Lücke bis zum nächsten Alarmpäarchen. „alleine“ treten die Invalids nicht auf, auch nicht drei hintereinander. |
|
Habe den zweiten Inverter wieder aktiviert und Ahoy neu gestartet. Komischerweise seit 2,5 Stunden keinen Alarm mehr gehabt. Ganz kurios. Bin gespannt, was dann morgen passiert. Edit: |
|
Wie sieht denn bei dir die Radio Statistik aus? Bei mir ist mit der V0.7.65 fast kein RX-Paket mehr erfolgreich empfangen worden. |
|
TX count 3366 und TX count 3324 Ist im Rahmen denke ich. Allerdings fällt auf, dass der Obere mehr als 4x so viele "no answer" hat als der Untere. Das ist auch der, der seit einer Stunde wieder Alarme ausgibt. |
|
@lumapu |
|
das Log am besten aus der Webserial-Console kopieren, nachdem der Fehler |
|
ich habe das Gefühl, dass es mit den Retransmits zu tun hat, bin mir aber nicht sicher. Hier muss ich an einer saubereren Kommunikation arbeiten, sodass jeder Inverter einzeln verarbeitet wird, bis klar ist, ob man einen Timeout hat oder noch Retransmitted. Bisher durchlaufen wir die loop über alle Inveter von vorne und senden alles raus was noch offen ist - ein bisschen kuddelmuddel - historisch bedingt. |
|
Hier ist ein Debug-Log Logs_DTU_CommandFailed_075307.txt Um ~08:00 habe ich in der WebGui gesehen, dass für 07:53:xx drei (!) "DTU Command failed" eingetragen waren (+ 1x "Inverter Start"). Also 4 Alarme ingesamt. |
|
Ich habe gestern und heute mal 0.7.65 und 0.7.59 verglichen. Beide Tests mit exakt gleichen Einstellungen und laufendem Zero Export. ESP32, NRF mit externer Antenne, Kondensator verbaut. Power Level minimum, knapp 3 Meter Abstand und nur Dämmung dazwischen. 0.7.65: Uptime: 0 Days, 07:53:05 (wobei die Alarme sich erst nach drei Stunden Uptime häuften) HM-1500 Alarms: 45 HM-300 Alarms: 82 Manchmal mehrere Alarme in wenigen Minuten, dann wieder für längere Zeit kein Alarm. 0.7.59 (hier sind die TX/RX Counter noch kombiniert): Uptime: 0 Days, 07:54:54 HM-1500 Alarms: 1 (Startalarm) HM-300 Alarms: 1 (Startalarm) Morgen versuche ich mal eine 0.7.60er, dann mit höherem Power Level. |
|
Also das was @lumapu fordert, wenn Fehler auftreten ist ja auch ein Geduldsspiel, da es mal wie schon beschrieben, es Minuten lang Fehler hagelt, und dann auch wieder lange ruhe ist...natürlich bewegt sich wenn man es anschaut, ewig nichts an der Alarm anzeige...hab es aber nun an 2 Alarmen hinbekommen, und schicke die Mail mal raus, wenn mehr benötigt wird, einfach was sagen, dann mach ich es morgen nochmal. Schicke erstmal die Mail raus... |
|
Zuerst, @BastyESP hat scheinbar 3 Inverter, 2x 1-Kanalig und 1x 2-Kanalig. Meiner Analyse nach alle 3 HM-Wechselrichter, daher alles über das gleiche Funkmodul und kein Mischbetrieb. beim Log fällt auf, dass kurz vor der Message ein Kuddel-Muddel ist:
Wir müssen noch mehr Logs sehen, aber ich habe die Vermutung, dass ein Retransmit (evtl. auch nur der complete-Retransmit) nicht 10s später mit dem gleichen Timestamp nochmal erfolgen darf. |
|
@BastyESP evtl. kannst du einfach nebenher die Webserial laufen lassen und bei Gelegenheit einfach alles per |
|
@lumapu Hab noch viele Zeilen, denn das Notebook lief noch, und die Konsole war offen, allerdings hab ich alle ca 10sek eine abfrage, wo wieder kommt das es Nacht ist und keine Kommunikation läuft, wären wenn ich auf Seite suche wohl 74 Alarme...nur wie ich in 10 sek, alles markieren und wenigstens mal sichern kann, ist mir ein rätsel. Würde jetzt mal Anbieten, nach Alarm zu suchen, und soviel wie möglich in den 10sek die ich habe zu Kopieren, und dir das zu senden...wäre das OK? Also ich versuch es mal und schicks dir als Mail. Mail mit ca 30 Meldungen ist raus. Ansonsten genau richtig, HM-800, HM-400 und HM-300 (allerdings werden die ersten beiden von 2 DTU abgefragt) daher bin ich wohl auch nicht der Idealfall für Fehlerlogs. Aber auch der 300er der nur von Ahoy abgefragt wird steht bei 128 Alarmen, der HM-800 hat heute nur 904 gehabt, und der HM-400 immerhin 1237. |
|
nur 904 😂 |
|
Ich teile die Vermutung, dass die Inverter 2 identische Requests (= Retransmit mit der selben Payload inkl. dem Zeitstempel) nicht mögen. Vermutlich wird die erste Nachricht empfangen und sogar beantwortet. Die Antwort geht vollständig verloren. Die DTU sendet die identische Nachricht nochmal und der Inverter lehnt die Nachricht als „verbraucht/bereits geantwortet“ ab und trägt einen Fehler ein. vielleicht sollte ein Retransmit die Zeitstempel vor dem erneuten Senden aktualisieren. |
|
Der Tipp mit Strg+A war Spitze, damit ging es, hab es mir mal als txt gespeichert, aber hast ja erstmal wahrscheinlich Auswahl. |
|
ja dieser Kuddel-Muddel muss weg. So muss es sein:
zwischen 1. und 3. sollte max. ca. eine Sekunde sein und nicht wie jetzt teilweise 10s. @BastyESP super, ja dein letztes Log ist sehr umfangreich, das verdaue ich morgen 😉. Im Schnelldurchlauf habe ich gesehen, dass Fehlereinträge für alle 3 Inveter dabei sind, das ist perfekt. |
|
Habe auch mal mitgeloggt. Lief knapp eine Stunde ohne Alarm. ESP32, 0.7.66 |
|
@Ollipop030 danke für dein Log. Du hast scheinbar ein sehr kurzes Intervall. Was mir hier auffällt wäre die sofortige Abfrage des gesetzten Powerlimits schon nach einer Sekunde. Evtl. sollte man hier die Zykluszeit beachten (Ahoy). z.B. |
Das ist der wohl meiner Nulleinspeisung geschuldet, sieht dann so aus: Ist alles sehr schnell verarbeitet, war aber bisher unkritisch, siehe auch meinen Beitrag von gestern. |
|
keine Kritik am eingestellten Intervall, ich will nur verstehen wie es zu dem Fehlercode kommen könnte. War eher selbstkritisch gemeint 😉 |
Es sollte noch die Inverter Nummer #1..16 erkennbar sein oder noch besser die Modell Nummer und das Produktionsdatum also die ersten sieben/acht Stellen der Seriennummer stattdessen verwenden ? |
Wie kommt es dazu dass beim Retransmit nach 10 Sekunden der Timestamp immer noch gleich ist. Das würde für mich auch das Problem bei der Abfrage mit mehreren DTUs erklären, da ja beide DTUs ab und an mal eine Abfrage mit dem gleichen oder sogar einem “älteren” Timestamp als die andere DTU senden und dann der WR einen Protokollfehler mit der DTU vermerkt. @BastyESP Ich hatte das in der Vergangenheit ja auch oft zu Hauf mit den (2) DTU command errors. Nach Umstellen auf LOW am NRF +PA/LNA ( das Ding mit der externen Antenne ) wurde es mit plötzlich viel besser. Davor hatte ich lange Zeit MIN, MAX und HIGH probiert, weil ich auf Sende/Empfangsprobleme getippt hatte: aber das war dann eher kontraproduktiv trotz Kondensator! |
|
Hab gestern komplett verpasst das aufzunehmen, und als ich wieder dran gedacht habe, war es dann Dunkel -.- P.s. Uptime der OpenDTU sind mittlerweile 30 Tage, da komm ich mit Ahoy schon alleine weil ich die vielen Versionen Installiere nicht hin -.- Bin ja erst hochgegangen auf LOW auf HIGH, um es zu versuchen, hat aber nichts verbessert, das ich auf MIN besser fahre, bezweifel ich beinahe, der HM-400, war eher empfangstechnisch schon mein Sorgenkind, hatte früher als ich nur die 2 (HM-800 + HM-400) Aktiv hatte, immer HIGH, weil ich auf LOW, sonst teilweise nur alle 0,5-1min vom HM-400 antworten erhalten habe, nach dem ich ein Gehäuse gedruckt hatte, und die Verhältnisse besser wurden (War vorher nur in so einem kleinem Shelly 1PM Karton reingestopft + der Ort wo es jetzt steht ist minimal höher), hab ich den Kondensator verbaut und LOW versucht, lief bisher eigentlich bisher ganz gut, kann aber MIN auch gerne versuchen...will mich davor nicht streuben...hab eben nur die vorherigen Sorgen mit den Schlechten erreichbarkeiten schon gehabt. LOW lief bisher gut... Die beiden HM (800/400) liegen Quasi flach auf einem extra Blech, was sie abschirmt vor Sonnenstrahlung, auf einem Trapezblech Dach, das schränkt natürlich die Funkerei etwas ein, kann mal schauen auf was die OpenDTU funkt...die macht mir in den Sinne aber auch keinerlei sorgen, schaue selten ins Menü rein, und das Display (1,54" OLED) macht was es soll... 
Würde ich jetzt mal als LOW übersetzen... Mein Problem wäre jetzt auch einfach zu Lösen (Schalter womit man die Alarm anzeige ausschalten kann) ;) denn es läuft ja auch mit den Tausenden Alarmen...allerdings bin ich ja nicht der einzige der das hat, nur ich bin der einzige Pflegefall der nebenher noch ne zweit DTU mitlaufen lässt ;) |
Erledigt: #1211 |
|
@stefan123t beim retransmit muss der alte timestamp geschickt werden, sonst passt der CRC nicht. Falsch ist aus meiner Sicht der retransmit nach 10s, der muss viel eher kommen. Bin schon dran es zu reparieren. |
|
Mit 0.8.1 habe ich nach einem Tag keine Alarme „DTU command failed” mehr gehabt. |
|
Bisher nicht mehr aufgetreten, kann als gelöst geschlossen werden. 👍 |
|
Hab auch keine Alarme mehr. |
Platform
ESP8266
Assembly
I did the assebly by myself
nRF24L01+ Module
nRF24L01+ plus
Antenna
external antenna
Power Stabilization
Elko (~100uF)
Connection picture
Version
O.7.63
Github Hash
1bbe979
Build & Flash Method
AhoyDTU Webinstaller
Setup
ESP8266 with two inverter (HM-600 and -350), e-ink display
Debug Serial Log output
No response
Error description
After updating to 0.7.64 I had several alarms (~10 within one hour) inside inverter HM-350 which were never observed before „ DTU command failed”
The text was updated successfully, but these errors were encountered: