MQTT NULL Werte about opendtu

[tbnobody]

Wollte auch einmal versuchen, die selbe DTU Seriennummer, die mein DTU Lite hat, zu vergeben.

Das wird auch gewaltig schief gehen. Eine Antwort von WR an DTU lässt sich nur korrekt bearbeiten wenn die DTU weiß welche Anfrage vorher gestellt wurde. Wenn die Eigenbau-DTU jetzt Statistiken abfragt und der WR eigentlich der "richtigen" DTU auf z.B. das setzen eines Leistungslimits antwortet würde OpenDTU versuchen diese Antwort als Statistik zu interpretieren. Weil es hatte ja nach Statistikdaten gefragt --> Korrekte Prüfsummen aber absolut unsinnige Payload. Gleiches gilt natürlich auch umgekehrt. Auch die "richtige" DTU wird Antworten falsch interpretieren die die von OpenDTU angefragt wurden.

Lösung bei mir war um nur noch alle paar Stunden mal einen 0 Wert zu bekommen...
...einen NRF24L01+ mit externer Antenne zu nutzen.

Wie weiter oben schon geschrieben, können die 0 Werte nicht aus Übertragungsfehlern entstehen. Der WR muss diese absichtlich verschicken. Werte werden nur von der Hardware (NRF24) und dem Parser bearbeitet wenn die Prüfsummen stimmen. Die Chance das während einer Falschübertragung die Prüfsummen "korrigiert" werden ist null.

Meiner Meinung nach ist ein 2-DTU-Betrieb so einfach nicht vorgesehen. Der WR muss sich auch intern abspeichern welche Anfragen als letztes geschickt wurden. Ansonsten könnte er auch die Retransmit Funktion (also das er bezogen auf die letzte Anfrage ein beliebiges Fragment nochmals sendet ohne das die DTU das komplette anfrage Paket nochmals sendet) implementieren.

[ahinrichs]

Meiner Meinung nach ist ein 2-DTU-Betrieb so einfach nicht vorgesehen. Der WR muss sich auch intern abspeichern welche Anfragen als letztes geschickt wurden.

Vielleicht sind das dann einfach Überschneidungen. Das der WR durcheinander kommt, wenn er zeitgleich zwei Anfragen bekommt.

[ahinrichs]

Hallo Hubsi,

freut mich, dass Du es ans laufen bekommen hast.

Null Werte im Sinne von "0", oder "NULL"? Und einzelne Werte, oder für alle?

[tbnobody]

Hallo,

es werden nur Werte weitergegeben die 1zu1 vom Wechselrichter kommen. Ich kann mir gerade nicht vorstellen wie da 0 Werte vorkommen sollen. Die Payload aus dem Wechselrichter ist mit 3 CRC's gesichert. 1 CRC wird durch die NRF24 Hardware geprüft. Die 2. hängt am einzelnen Fragment und die 3. CRC dient dazu alle Fragmente als Summe zu prüfen. Was ggf. helfen würde wäre ein mitschnitt des Seriellen Outputs zur entsprechenden Zeit wenn die 0 Werte kommen.

[hubsi5]

Ich bekomme öfter Werte mit 0 oder auch eine unrealistische Spannung wie 2880V oder so. https://bilderupload.org/bild/326f31733-opedtupic
Habe das selbe Problem auch mit ahoy.
Werte sind direkt 0 siehe Bild: https://bilderupload.org/bild/263330868-mqtt
Kann aber sein, dass mein DTU Lite da hinein pfuscht.
Oder der Wechselrichter kann nicht mit zwei DTUs sprechen und ist da überfordert.

Wollte auch einmal versuchen, die selbe DTU Seriennummer, die mein DTU Lite hat, zu vergeben.
Aber kann ich nicht, da die Seriennummer einen Buchstaben enthält, die kann ich bei OpenDTU nicht eingeben.

[hismastersvoice]

Diese 0 Werte gibt es tatsächlich, ich habe lange damit herum experimentiert

Der Zusammenhang sieht wie folgt aus...
Je schlechter der Empfang zwischen DTU und Inverter um so häufiger kommen die 0 Werte vor. (rechtes Bild)
Bei guter Verbindungsqualität und je häufiger man abfragt <5 Sekunden kommen diese Werte ab und zu vor. (linkes Bild)

Die 0 Werte gibt es auch bei der org. DTU Pro die ich im Einsatz habe.
Selbst wenn die DTU Pro nur ein paar Meter vom Inverter entfernt steht kommt alle paar Stunden mal ein 0 Wert.

Lösung bei mir war um nur noch alle paar Stunden mal einen 0 Wert zu bekommen...
...einen NRF24L01+ mit externer Antenne zu nutzen.
Seitdem sind die Werte bei mir nahezu verschwunden.

Wenn man das vermeiden wollte, dürfte man den 0 Wert nur durchreichen wenn zwei 0 Werte aufeinander folgen.
Es ist ja mehr als unwahrscheinlich das eine Anlage gerade noch 500W liefert und in den nächsten 10 Sekunden 0W.
Auch liefert der Inverter immer nur bei vollständiger Dunkelheit 0 Wert, ansonsten sind die kleinsten Werte so um die 2-4W.

Logik müsste für mich so aussehen...

Leistung < 10W und zwei 0-Werte in Folge, dann 0-Wert abliefern, ansonsten den zuletzt gelieferten Wert, oder gar keine abliefern. Kommen Anzahl X an 0-Werten dann wird auch 0 gesendet.
Das müsste aber dann im Eventlog vermerkt werden, damit man versteht warum evtl .keine Werte kommen.
Das müsste man eigentlich mit jedem einzelnen Wert so machen, nicht nur mit dem Wert Power.
Es kommen auch 0 Werte vor für alle anderen Werte, wobei der Power-Wert (AC/DC) sich die einzigen Werte sind die wirklich für die Steuerung und Eigenverbrauch-Optimierung wichtig sind.

Ich habe mir dazu eine Logik in Loxone eingebaut die das mach was ich beschrieben habe.
Wenn 0W kommt und vorheriger Wert <10W dann wird der 0-Wert im Analogspeicher überschrieben ansonsten nicht.
Sollte sich der Wert länger als 5 Minuten nicht ändern, wird 0 gesetzt zur Sicherheit.
Zwischen Sonnenuntergang und Aufgang wird immer 0 geschrieben, egal was kommt.

PS: Diesen Fehler hatte ich auch bei Ahoy mit dem ESP8266, nur war da das ganze System derart instabil das ich es nicht weiter verfolgt habe.

[ahinrichs]

Bei mir gab es das noch nie, ich habe keine zweite DTU. Könnte also tatsächlich am Parallelbetrieb liegen.

Fragt sich weiter, wie damit umgehen. Die von @hismastersvoice vorgeschlagene Logik klingt passend und ist ja schon erprobt.

Wenn, müsste es konfigurierbar sein.

[ahinrichs]

Ich hatte noch die Idee, dass das eine Art Handover ist. Über die Werte teilt der WR mit, dass er mit einer anderen DTU besser kommunizieren kann.

Edit: Blödsinn, dann müsste ja umgekehrt auch die originale DTU Nuller kriegen und dann irgendwie reagieren...

[hismastersvoice]

@tbnobody
Du hast wohl recht, es liegt am DTU-Pro.
Ich haben mal vom Strom genommen, und es kommen seit 3 Stunden selbst mit schlechtem Empfang keine 0-er mehr.

Jetzt muss ich wohl doch noch auf Influx/Grafana geht :(
Allerding würde ich für die 70% Limitierung die Möglichkeit benötigen das Limit zu setzten.
Habe gelesen das es schon Ansätze gibt, aber wie weit ist das schon?
So lange muss ich den Pro noch betreiben.

[hismastersvoice]

Nochmal zu Bestätigung...
Ich habe seit heue morgen keinen 0-Wert mehr bekommen, sobald ich den DTU jetzt wieder in Betrieb habe, kommen wieder vereinzelt die 0-er. Zwar nach wie vor selten, aber sie kommen wieder.

Also wäre tatsächlich eine Logik interessant die solche Ausreiser ausmerzt, da ja sicher der ein oder andere auch eine echte DTU für die Daten im Portal nutzen will.

[De-Ichirou]

Ich kann die 0er Werte bestätigen. Habe meinen HM jetzt via TSUN-Cloud mit integriert und hatte extra dafür eine DTU lite konfiguriert und seit dem die mitsendet, habe ich Ausfälle.
Intern sendet der Controller jede Sekunde einen Befehl an den NRF, der diesen jedoch nicht jede Sekunde aussendet. Gleiches dürfte für die Pro gelten.
Ich hab jetzt etwas Abstand dazwischen gebracht um zu schauen, ob das einen Effekt hat oder es eher an einer Störung gegenseitig liegt.
Wahrscheinlicher ist jedoch, dass der WR durcheinander kommt, wenn Befehle und Zieladressen kollidieren. Das werde ich im lauf der Woche verfolgen.
Hintergrund: Ich habe bisher noch kein Grafana fertig, dass mir die Daten aufbereitet, da ich noch den Mi-Klon habe, möchte ich die Auswertung vorerst im bekannten Portal haben.
Die Probleme, die dabei auftreten, sind interessant. Übrigens funktioniert Hoymiles mit der DTU und der Cloud vom Tsun, es ist also eine direkte Kopie.
Wenn noch irgendwelche weiteren Daten benötigt werden, gebt Bescheid. Ich habe auch noch ein paar DTU lite hier rumliegen.

[stefan123t]

Eventuell durch c6499e0 gefixt ?
Könnt Ihr das mit einem aktuellen Release der OpenDTU nochmal prüfen.
Hier wurden vom Inverter Frame IDs mit 0 anstelle von 84 (viertes und letztes Frame) geschickt mit korrekter CRC-16 und CRC-8 Summe. Das kann natürlich bei zwei DTUs die mit dem Wechselrichter kommunizieren gehäuft vorkommen, da bei zwei Master (DTU Lite/Pro und OpenDTU oder Ahoy DTU) die State Machine für die Antworten auf dem WR und beim Empfänger der/n DTU(s) durcheinander kommt.

[De-Ichirou]

Bei Verwendung von 1 oder mehr weiteren DTU tritt das Problem nach wie vor auf. Bin auf dem aktuellen Stand.

[stefan123t]

@De-Ichirou da Du mehrere DTU lite vorliegen hast wäre zu prüfen wie das die Originalsoftware löst ? Wenn Du zwei laufen hast wie können die die Kommunikation auseinander halten ? Reicht hierfür eine andere DTU ID aus ? Oder fragen die DTU lite nicht so häufig ab, vor allem wie ist eigentlich das Intervall bei drn Hoymiles Geräten ?

[De-Ichirou]

@stefan123t ich habe die TSUN-Variante der DTU-Lite, diese fragt jede Sekunde ab. Meisstens klappt es, da mit mehreren ID's je 1 WR abgefragt wird und entsprechend die Antwort kommt. Vereinzelt scheint was zu kollidieren, dann geht entweder die DTU-Pro von HM oder einer der Sticks auf Kommunikationsfehler. Das ganze ist nicht reproduzierbar.
Der ESP32 liefert unregelmäßig, allerdings häufiger falsche Werte. ESP32 und DTU-Pro sitzen direkt nebeneinander, das Problem bestand jedoch vorher auch schon. Eine räumliche Trennung bringt keine Veränderung.
Das Setup sieht so aus:
DTU-Lite 1 -> Inv. TSUN (jede Sekunde)
DTU-Lite 2 -> Inv. Hoymiles (jede Sekunde)
DTU-Pro -> beide Inv. (jede Sekunde)
ESP32 -> Inv. Hoymiles (alle 5s)

[tbnobody]

Ich schließe dieses Issue. Wie ich in anderen Issues schon geschrieben habe möchte ich keinen Multi-DTU support bieten wenn man nicht genau weiß was in dem Fall der Inverter macht und ob dort nicht intern etwas schief geht (und im schlimmsten Fall der NA Schutz nicht das tut was er soll)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.