Feature Request: Keine Daten über MQTT mehr wenn WRs offline

knickohr commented 1 year ago

Nach Sonnenuntergang liefert Ahoy keine Daten mehr an den Broker 😞

Es sollten zumindest die uptime, last_success und available_Text weiterhin ausgegeben werden.

Schön wäre es auch, wenn als letzte Datenpaket noch alle nicht aufsummierten Werte auf „0“ gesetzt werden.

Ach ja, Nachtrag : ich verwende die 35 DEV auf einem ESP32

lumapu commented 1 year ago

Danke für die Bestätigung, dass die uptime nach Sonnenuntergang nicht mehr aktualisiert wird. Ist ein guter Reminder, da ich in der letzten Version an dieser Stelle zu viel rationalisiert habe. Wir müssen dem MQTT noch einen Minuten Timer spendieren, um mit diesem gewünschte Funktionen umzusetzen. Ich würde hierfür gerne eine zentrale Struktur schaffen, da wir diese Anforderung praktisch in jeden Modul haben.

knickohr commented 1 year ago

Ist aber schon länger nicht mehr aktiv als nur bei 35. ich glaube es hat bei 2x irgendwann aufgehört. Da hat mich das noch nicht gehört, hatte noch kein MQTT-Broker.

Viel wichtiger sind mir aber die Ausgabe der restlichen verfügbaren Werte.

stefan123t commented 1 year ago

@knickohr bei aktiver Sundown Regelung sollte m.E. auch um 0:00 UTC ein aktiver Reset der Yield Daily Werte erfolgen. Man kann ggf. auch das Shutdown und Reboot Kommando mit einer eigenen Option (Reset Daily Yield at 0:00 UTC) an den Wechselrichter senden, dann gilt das auch für WR die ansonsten 24h am Batterie/Akku-Fläschchen hängen.

@lumapu für die Minuten Timer hat @tbnobody eine schöne Option mit den EVERY_XXX Makros geschaffen. Vielleicht willst Du die auch übernehmen, das macht den Code m.E. weitaus leserlicher.

knickohr commented 1 year ago

Da müßte ich ja gerade mal bis Mitternacht wach bleiben 🤪

nee, die Yields sind OK, mir geht es eher darum das andere Meßwerte (Beispiel P_AC) auf dem Letzten gelesenen Wert verharren bis Morgens wieder neu produziert wird.

stefan123t commented 1 year ago

@knickohr kannst Du die Liste der Werte bitte genau definieren, dann kann man das einfacher implementieren, wenn es klar spezifiziert ist :) Wie lange soll die AhoyDTU solche "kurzfristigen" Werte denn beibehalten bzw. ab wann sollen diese durch 0.00 überschrieben werden ? Bitte bedenke es kann auch zu Verbindungsstörungen kommen, sollen diese 0.00 Werte nur während der aktiven Sundown Funktion gesendet / ersetzt werden ?

knickohr commented 1 year ago

Es sollten zumindest die uptime, last_success und available_Text weiterhin ausgegeben werden.

😉

Sobald der WR offline geht (not available), könnten alle Werte bis auf die Yieldxxx auf Null gehen. Jepp, from dust till dawn 😊

knickohr commented 1 year ago

2F0F7D4E-44C1-43F6-9A65-7E1576E9188C

Spannend !

ich habe eben aus Versehen auf den „send“-Button in den MQTT-Settings gedrückt 😲

nun kommt im Broker die Meldung „offline“ bei uptime alle paar Sekunden 🤔

Egal ob die Stable-Version 28 oder die DEV 35. verhalten sich beide gleich.

haselchen commented 1 year ago

@knickohr

Ich finde das Last Success beim letzten Bezug stehenbleibt gar nicht verkehrt. So weiss ich, wann der WR zum letzten Mal gesendet hat, bevor der Ertrag zu minimal wird, um weiter online zu sein. Das deckt sich meistens mit der Sunset Zeit. Ich finde, dass sollte so bleiben.

@stefan123t @lumapu

knickohr commented 1 year ago

Jepp, und auch die Temperatur könnte neben den Yield-Werten stehen bleiben

Aber eben nicht Power, Spannung, Strom, .

und vor allem nicht der Status available.

Argafal commented 1 year ago

In meinen Augen ist es falsch, Power, Spannung, Strom auf 0 zu setzen. Der Inverter hat nie gesendet, dass diese Werte null sind. Meiner Meinung nach sollte eine DTU einfach nur die Werte vom Wechselrichter empfangen und weitergeben. Last_success bleibt demnach bei den letzten Daten des Wechselrichters stehen. Bei mir funktioniert das gut so: Domoticz merkt nach einer Weile, dass keine neuen Daten mehr gekommen sind, und markiert die Wechselrichter-Devices rot für "not available". Macht für mich gut Sinn so.

Wo ich @knickohr vollkommen zustimme ist der Status available. Der sollte in der Tat auf "not available" gesetzt werden. Dafür ist auch schon ein Issue offen. Kann man diesen Status dann nicht verwenden um Spannung/Strom/Power auf Null zu setzen (wenn man das wirklich will)? Das wäre in node-red recht einfach. Ich könnte mal versuchen einen entsprechenden Flow zu bauen. Wenn dir das weiterhilft - oder vielleicht verwendest du was anderes als Empfänger?

roku133 commented 1 year ago

@Argafal: Ich finde es für spätere Auswertungen einfacher, wenn die Werte für Power, Spannung und Strom bei der Abschaltung des Wechselrichters auf 0 gesetzt werden. Die Messwerte sind zu diesem Zeitpunkt bereits veraltet und müssen dann immer zusammen mit dem Parameter "available" interpretiert werden. Ein Setzen auf 0 gibt dagegen den tatsächlichen Stand wieder. Die Werte für "YieldDay" und "YieldTotal" sollen wie bisher den letzten Stand beinhalten.

knickohr commented 1 year ago

Ja genau. Ein abgeschalteter oder nicht vorhandener WR liefert nun mal Null, da ist es doof wenn die Anzeige bei irgendeinem andren Wert hängen bleibt,

Argafal commented 1 year ago

@roku133: Ich versteh schon, was du meinst. Aber das stimmt halt nur in der Nacht. Es gibt aber viele andere Fälle, wo ein Inverter tagsüber nicht erreichbar ist (obwohl er produziert!). Dann sind die Nullwerte schlichtweg falsch. "Not available" kann viele Gründe haben.

Ein Beispiel ist ein Inverter, der ein bisschen weiter weg steht, und daher je nach Setup nicht immer gut antwortet. Schickt ahoy jetzt lauter Nullen, weil der Inverter nicht antwortet, dann sind diese Nullen falsch. In Node-RED ist dieser Fall aber viel schwerer zu erkennen, denn jetzt musst du die Null gleichzeitig mit der Status-Nachricht zusammen interpretieren. Die zwei Nachrichten kommen aber asynchron - und jetzt hast du ein noch viel größeres Problem.

Deswegen meine Meinung, dass nur tatsächlich empfangene Werte geschickt werden dürfen.

Side note: Wenn du willst, dass Spannung, Strom, und Power null sind, wenn ein Inverter nicht erreichbar ist. Dann ist es doch in Node-Red super einfach: Vergleiche die Status-Nachricht mit "not available". If true, dann schickst du eine MQTT-Nachricht Spannung = 0, Power = 0, Strom = 0. If not true, dann machst du nichts. Löst das dein Problem?

Argafal commented 1 year ago

Ja genau. Ein abgeschalteter oder nicht vorhandener WR liefert nun mal Null, da ist es doof wenn die Anzeige bei irgendeinem andren Wert hängen bleibt,

Stimmt ja nicht. Der kann ja auch angeschaltet sein und produzieren und einfach nur nicht erreichbar sein. :-p

roku133 commented 1 year ago

Spannung, Strom, Power sowie weitere Messwerte und ihre direkten Ableitungen wie "Efficiency" und "Irradiation" sind nur aktuell zum jeweiligen Messzeitpunkt. Falls die Kommunikation zwischen Wechselrichter und DTU unterbrochen wird, sind diese Werte ohnehin nicht mehr gültig. Daher halte ich auch in diesem Fall Werte von 0 für angemessen - dies bedeutet dann, dass kein aktueller Messwert vorhanden ist.

Argafal commented 1 year ago

Ja, du hast Recht, die Werte sind nicht mehr gültig. Deswegen wird ja auch kein Wert mehr versendet. Das ist in meinen Augen genau das richtige Verhalten. Eine fake Null fände ich viel schlimmer.

Und ich hab noch ein bisschen weiter nachgedacht: Nimm zum Beispiel die Spannung. Wenn du die ganze Nacht über Null verschickst, machst du deine Spannungs-Statistik am anderen Ende kaputt: keine der automatisch berechneten Werte wie min, average, median stimmt jetzt mehr, weil die jetzt alle die ungültige Null mit einbeziehen. Jetzt musst du also am Empfänger weitere Logik einbauen, diese Null wieder zu ignorieren. Ich sehe da echt den Vorteil nicht. Gleiche Logik für die Temperatur.

Was ist denn das eigentliche Problem, das du lösen möchtest? Ich versteh's nämlich nicht.

Und um auf die Frage von @stefan123t zurück zu kommen: Wie schlägst du vor zu unterscheiden, wann ein Kommunikationsproblem vorliegt (und der Inverter fein produziert und Strom, Power etc definitiv nicht null sind), wann der Inverter kaputt gegangen ist hat, wann der Inverter sich bei 253V automatisch abgeschaltet hat, und wann der Inverter nicht mehr produziert, weil die Sonne untergegangen ist?

knickohr commented 1 year ago

Was ist denn das eigentliche Problem, das du lösen möchtest? Ich versteh's nämlich nicht.

eine fehlerhafte Anzeige

Zur 2. Frage : Ganz easy, es werden nur Null ausgegeben wenn die Sonne untergegangen ist (Sunrise/Sunset)

roku133 commented 1 year ago

Zunächst stört es mich, wenn Basisdaten wie Messwerte, die während des Normalbetriebs regelmäßig aktualisiert werden, für längere Zeit auf einem veralteten Wert bleiben. Bei deinem Vorschlag kann ich diese Anzeigewerte durch Auswertung von "available" entsprechend anpassen. Das ist eine mögliche Lösung.

Ich würde bei Nichtverfügbarkeit dieser Messdaten jedoch so vorgehen: wenn die Kommunikation unterbrochen wird oder sich der Wechselrichter, warum auch immer, verabschiedet hat, würde ich einmal oder zur Sicherheit mit wenigen (drei?) Wiederholungen alle Messwerte und ihre Ableitungen auf 0 setzen. Anschließend würde ich im Zustand "not yet available" nur noch regelmäßig folgende MQTT-Parameter senden: uptime, last_success und available_text YieldDay kann optional um Mitternacht zurückgesetzt werden, das ist für mich ein Goodie. Der Vorteil ist für Anwender, die nicht mit IFTTT oder anderer Logik umgehen können, dass für sie Messwerte mit 0 (nicht vorhanden) angezeigt werden.

Letztlich lassen sich jedoch alle Implementierungen verwenden und darstellen.

Argafal commented 1 year ago

@roku133: Wenn man deinem zweiten Vorschlag folgt, hat man jetzt auf der Empfänger-Seite ein Problem. Eine Null bedeutet jetzt nämlich manchmal "kein Wert vorhanden" und manchmal tatsächlich null. Zum Auswerten müsste der Empfänger also jetzt die Korrelation mit Status available/non available verwenden, um die Daten erst auf ihre Gültigkeit zu testen. Beispiel: Bedeutet die Temperatur 0 dass keine Temperatur gemessen wurde, oder dass es draußen null Grad hatte? Und dazu kommt dann noch dass der Status asynchron verschickt wird... ich weiss nicht, ob ich das für unbedarfte Anwender wirklich einfacher finde.

Btw, ich hab ja hier zugegebenermaßen eine recht starke Meinung: Ich hab nämlich einen von meinen Invertern so weit weg, dass er nicht immer stabil antwortet. Verschickt ahoy jetzt zwischen drin mal ein paar Nullen, wird die Auswertung für mich ein echter Albtraum. Weil diese Nullen halt einfach keine korrekten Messwerte sind. Für mich gibt eine DTU (data transfer unit) einfach nur weiter was sie empfängt. Hat sie keinen neuen Wert, dann teilt sie das mit: "not available". So seh ich das, macht das Sinn? :)

Zur 2. Frage : Ganz easy, es werden nur Null ausgegeben wenn die Sonne untergegangen ist (Sunrise/Sunset)

@knickohr: Das wäre natürlich nicht so dumm. Schickt denn der Inverter am Ende des Tages ein Alarm-Signal, eine Art von "switching off"? Könnte man das verwenden um genau zum Sonnenuntergang einmal Power 0W und Strom 0A zu schicken, so dass die Anzeige nicht auf 0.1W hängt über Nacht? Würde das das Ursprungsproblem denn lösen?

knickohr commented 1 year ago

Hmmm, Man könnte da ja auch „Not available“ senden statt der Null.

roku133 commented 1 year ago

@knickohr: Das ist auf jeden Fall korrekt und besser. Probleme könnte es bei der Weiterverarbeitung geben, wenn statt des Strings "Not available“ jeweils ein Zahlenwert erwartet wird.

knickohr commented 1 year ago

Es kommt eh schon als String raus 🤪

Bei uptime ist es ja eh schon so, das offline kommt wenn die Wechselrichter nicht mehr Wechsel richten. Dann bleibt das Feld in der Visualisierung einfach leer.

Es würde auch N/A reichen.

stefan123t commented 1 year ago

Also ich versuche das mal zusammenzufassen:

Nachts werden teilweise veraltete Werte verschickt obwohl keine Kommunikation mit dem Wechselrichter stattgefunden hat. Mit der Sundown Funktion könnte man noch ein Flag setzen, das dann in dieser Zeit Null-Werte verschickt. Gibt es bei MQTT eigentlich Null (= n/a) vs. 0 ?
Wenn der WR tagsüber nicht erreichbar ist soll der letzte Wert noch für 3-5 Abfrageperioden wiederholt werden weil ein 0.00-Wert sich in den Graphen / Daten nicht so toll macht.
Die gesammelten Werte Yield Total und Yield Daily sollen weiter gesendet werden unabhängig davon ob der WR erreichbar ist oder nicht. Ggf sollte der Yield Daily durch einen Shutdown / Reboot Kommando der DTU an den WR einmal um 0:00 Uhr (+/- Zeitzone) auf 0.00 gestellt werden damit Geräte am Akku/Batterie auch einen definierten Tageswert liefern.

Habe ich das soweit richtig zusammengefasst oder fehlt noch was ?

knickohr commented 1 year ago

Aaalsoooo:

nachts werden gar keine Werte geschickt, das ist ja das Problem. Es sollten weiterhin gültige Werte geschickt werden, also die Yield, Uptime, eben alle gültigen und plausiblen Werte. Statt den fehlenden oder nicht gültigen eine Null (oder Nichts, ein leerer String, oder N/A), so das man zumindest erkennt das was kommt.
Ja, und wenn länger nichts von den WRs kommt, eben das N/A
korrekt
Der Status Text solle immer korrekt sein ! Also Availsble (& prodicing) und Not available, auch Nachts, alsoimmer, so wie die Uptime (was leider nur sporadisch der Fall ist).

roku133 commented 1 year ago

Meine Ergänzung ist, bei den fehlenden oder ungültigen Werten zwischen Situation 1 und 2 nicht zu unterscheiden: in beiden Fällen einheitlich N/A (oder leer). Im Fall 2 kann man überlegen, die alten Messwerte für einige Abfragen zu wiederholen, um kürzere Unterbrechungen zu überbrücken.

Argafal commented 1 year ago

2. Wenn der WR tagsüber nicht erreichbar ist soll der letzte Wert noch für 3-5 Abfrageperioden wiederholt werden weil ein 0.00-Wert sich in den Graphen / Daten nicht so toll macht.

Nein, bitte nicht. Wenn tagsüber ein WR nicht erreichbar ist, ist es viel besser einfach keine Daten zu schicken, als Fake-Daten. Auf der Empfänger-Seite wird das sonst ein totales Chaos die echten von den Fake Daten wieder zu unterscheiden.

Nachtrag: "N/A" kann ich als Kompromiss gut akzeptieren und auf der Empfänger-Seite leicht wegfiltern. Aber mit 0 oder blind wiederholten Werten tue ich mich schwer.

Argafal commented 1 year ago

Noch ein Gedanke: Ist denn das eigentliche Kern-Problem, dass die Watt-Anzeige und Strom über Nacht bei einem kleinen Wert hängen bleiben und nicht auf 0 gehen?

Kann denn die Sun-Down Funktion nicht einmal 0W und 0A schicken, wenn der WR zur Sonnenuntergangszeit wegfällt?

roku133 commented 1 year ago

Das ist ein Vorschlag für die Nachtzeit, verhindert aber nicht, dass tagsüber veraltete Messdaten angezeigt werden. Mein Wechselrichter hat gestern bei schlechten Lichtverhältnissen 40 Minuten vor dem Sunset-Zeitpunkt abgeschaltet. In diesem Fall würden wieder für eine längere Zeit alte Daten angezeigt, bevor mit deinem Vorschlag die Nullwerte für Strom und Leistung gesendet würden.

Wenn keine Pseudo-Daten gesendet werden sollen, muss aus meiner Sicht bei Unterbrechung der Kommunikation von Anfang an N/A gesendet werden.

Argafal commented 1 year ago

Ich find das Verhalten (tagsüber) genau richtig: Wenn kein neuer Messwert vorhanden ist, wird auch keiner gesendet. Das Feld "last_success" gibt mir den Timestamp der letzten gültigen Werte. Kommt lange nichts reagiert mein Empfänger und benachrichtigt mich, dass der Sender nichts mehr schickt und wohl ein Problem vorliegen muss. Das verhält sich in meinen Augen genau richtig und leicht verständlich.

Vielleicht diskutieren wir in diesem Issue zu viele verschiedene Themen gleichzeitig... Frage an die Runde: Wer hat denn tagsüber sonst noch gelegentlich Kommunikationsschwierigkeiten mit seinen Wechselrichtern? Gibt es jemand, der es wirklich wichtig findet, dass in diesem Fall dann n/a geschickt wird, an Stelle vom heutigen Verhalten, dann nichts zu schicken? Oder geht es den meisten hier eigentlich allein um das Verhalten bei Sonnenuntergang, dass Strom und Power bei einem kleinen Wert hängen bleiben?

Edit: In der Zwischenzeit hat @roku133 seinen/ihren Beitrag angepasst und meine Antwort passt nicht mehr gut zu seinem/ihrem Beitrag. Unfortunate timing :) Mit dem letzten Teil-Satz " bei Unterbrechung der Kommunikation von Anfang an N/A gesendet werden." kann ich gut leben, wenn das jemand so implementieren möchte.

roku133 commented 1 year ago

sorry für die zeitliche Überschneidung 😉

Nebenbei: bei mir hat der MQTT-Parameter last_success noch nie einen vernünftigen Wert angezeigt (z.B. 1882652152). Er verändert sich tagsüber auch nicht, aber das ist eine andere Baustelle und unabhängig von unserer Diskussion.

Argafal commented 1 year ago

Nebenbei: bei mir hat der MQTT-Parameter last_success noch nie einen vernünftigen Wert angezeigt (z.B. 1882652152). Er verändert sich tagsüber auch nicht, aber das ist eine andere Baustelle und unabhängig von unserer Diskussion.

Na, vielleicht sollten wir da mal anfangen, und auch die Status-Meldung richten. Da wäre doch schon mal viel geholfen, oder?

Können wir ein bisschen brainstormen: Wie kann man denn zuverlässig erkennen, dass ein Inverter sich auf Grund von Sonnenmangel abgeschaltet hat? In deinem Fall war das ja 40 Minuten früher als vielleicht sonst erwartet. Die Betriebsspannung des Inverters kommt von den Solarmodulen - sagt die Betriebsanleitung. Gibt der Inverter denn kein Signal "switching off", das wir abgreifen können?

haselchen commented 1 year ago

Also ich verarbeite das Ganze über Iobroker im Zusammenspiel mit der API der Ahoy Software. LastSuccess bekomme ich mit der letzten Sendung eines Watt-Wertes. Das ist vollkommen okay. Die Werte 1234567890 bei Sunset, Sunrise etc kann man ganz normal umwandeln in einen Zeitwert (im Blockly vom Iobroker zum Beispiel). Mein Problem war/ ist nur das mit dem "is online und producing" in der GUI. Das war nicht aktuell oder wurde falsch dargestellt. Ansonsten kann ich alles mit der momentanen 0.5.28 auswerten.

haselchen commented 1 year ago

Nebenbei: bei mir hat der MQTT-Parameter last_success noch nie einen vernünftigen Wert angezeigt (z.B. 1882652152). Er verändert sich tagsüber auch nicht, aber das ist eine andere Baustelle und unabhängig von unserer Diskussion.

Na, vielleicht sollten wir da mal anfangen, und auch die Status-Meldung richten. Da wäre doch schon mal viel geholfen, oder?

Können wir ein bisschen brainstormen: Wie kann man denn zuverlässig erkennen, dass ein Inverter sich auf Grund von Sonnenmangel abgeschaltet hat? In deinem Fall war das ja 40 Minuten früher als vielleicht sonst erwartet. Die Betriebsspannung des Inverters kommt von den Solarmodulen - sagt die Betriebsanleitung. Gibt der Inverter denn kein Signal "switching off", das wir abgreifen können?

Ich bin da technisch nicht so versiert, aber wenn ich den letzten Wert mir ansehe, wo der Datenpunkt stehenbleibt, dann ist ist das unter 1Watt. Ich gehe davon aus, dass der WR mehr als 1 Watt zum Betrieb braucht. So gesehen finde ich das nicht so schlimm , wenn der letzte gesendete Wert stehenbleibt. Problematisch wird es für mich vermutlich, wenn da N/A stehen sollte. Das kann ich über Iobroker vermutlich nicht mehr so einfach weiterverarbeiten.

roku133 commented 1 year ago

Mein Problem war/ ist nur das mit dem "is online und producing" in der GUI. Das war nicht aktuell oder wurde falsch dargestellt.

Das sehe ich genauso: Die MQTT-Parameter available bzw. available_text müssen stimmen, last_success ist für mich für eine Weiterverarbeitung weniger wichtig.

knickohr commented 1 year ago

Also mein primäres Problem ist:

Wir reden jetzt von Nachts, also nach Sonnenuntergang !

Es wird keine uptime mehr gesendet, allenfalls hin wieder offline. Das ist in meinen Augen inakzeptabel da man daraus nichts mehr lesen kann
Es werden eigentlich gar keine Daten mehr gesendet, ich erwarte aber zumindest den Status von jedem WR, also Not yet available
stehenbleibende Werte sind schlicht und einfach falsche Werte. Dann entweder Nichts „“ leer empty, oder N/A senden

Tagsüber könnten die letzten Werte gesendet werden. In meinen Augen sind die aber auch falsch ! Hier ist es besser genau zu wissen, welchen Status der einzelne WR hat (Available, Not available, Not producing …) und da sollte man einen Watchdog drauf ansetzen falls jemand einen Alarm braucht, nicht auf hängen gebliebene oder gar falsche Werte.

Meine Meinung 😉

haselchen commented 1 year ago

Also mein primäres Problem ist:

Wir reden jetzt von Nachts, also nach Sonnenuntergang !
* Es wird keine uptime mehr gesendet, allenfalls hin wieder offline. Das ist in meinen Augen inakzeptabel da man daraus nichts mehr lesen kann

* Es werden eigentlich gar keine Daten mehr gesendet, ich erwarte aber zumindest den Status von jedem WR, also Not yet available

* stehenbleibende Werte sind schlicht und einfach falsche Werte. Dann entweder Nichts „“ leer empty, oder N/A senden
Tagsüber könnten die letzten Werte gesendet werden. In meinen Augen sind die aber auch falsch ! Hier ist es besser genau zu wissen, welchen Status der einzelne WR hat (Available, Not available, Not producing …) und da sollte man einen Watchdog drauf ansetzen falls jemand einen Alarm braucht, nicht auf hängen gebliebene oder gar falsche Werte.

Meine Meinung 😉

Wenn dann schon lieber den Wert 0 Alles andere, N/A z.B. kann ich nicht verarbeiten. Man könnte auch eine Wenn/Dann Funktion ja einbauen. Wenn LastSuccess länger als 5 oder 10min nicht aktualisiert dann Wert 0

roku133 commented 1 year ago

@haselchen: vorab: ich kenne das Verhalten von ioBroker nicht. falls bei einer Kommunikationsunterbrechung oder nach einer Abschaltung des Wechselrichters statt eines numerischen Werts N/A übertragen würde, würde dies im ioBroker vermutlich nicht als gültige Zahl interpretiert werden und ioBroker müsste dann von sich aus den Wert auf ungültig setzen. Das wäre eigentlich das gewünschte Ergebnis. Ob dies tatsächlich so funktioniert, müsstest du testen.

Bei einer Unterbrechung tagsüber könnten sonst für längere Zeit hohe, veraltete Messwerte angezeigt werden.

knickohr commented 1 year ago

Jepp genau, bei mir kommt im Node-Red dann NaN (not a number). Das ist besser als ein falscher Wert. Das kann man dann auch sauber abfragen und ggf. filtern.

lumapu commented 1 year ago

close war automatisch durch neues Release - wir sind aber noch nicht feritg =)

Argafal commented 1 year ago

Wir reden jetzt von Nachts, also nach Sonnenuntergang !

Ok. Bei Sonnenuntergang wäre es schon schön, wenn nach dem letzten minimalen Wert (1W oder so) noch einmal 0W kommt. Deswegen ja mein Vorschlag, in diesem Issue zu brainstormen, wie man diese Situation zuverlässig erkennen kann.

* Es wird keine uptime mehr gesendet, allenfalls hin wieder offline. Das ist in meinen Augen inakzeptabel da man daraus nichts mehr lesen kann

Ok. Das ist glaub ich jetzt gelöst, wenn ich lumapu's commit richtig lese.

* Es werden eigentlich gar keine Daten mehr gesendet, ich erwarte aber zumindest den Status von jedem WR, also Not yet available

Ok. Da stimme ich vollkommen zu. Ich glaube, auch das ist in der letzten Development-Version gelöst, oder nicht?

* stehenbleibende Werte sind schlicht und einfach falsche Werte. Dann entweder Nichts „“ leer empty, oder N/A senden

Das sehen wir unterschiedlich. Es wird ja nichts momentan nichts versendet, wenn keine neue Werte vorliegen. Auf der Empfänger-Seite lässt sich die fehlgeschlagene Wechselrichter-Kommunikation durch einen von den folgenden drei Mechanismen erkennen:

ein Watchdog/timeout, der merkt, dass keine neuen Werte empfangen wurden. So macht es zum Beispiel Domoticz: Ein Device das länger nichts mehr mitteilt wird automatisch rot als "nicht verfügbar" markiert.
Das Status Flag des Wechselrichters geht von "available" auf "not available". Das kann man aktiv abfragen.
Der "last_success" Wert ist zu alt. Das kann man auch aktiv überprüfen.

Die erste Möglichkeit ist sehr robust: diese Logik funktioniert nämlich sowohl bei Verbindungsproblemen zwischen DTU und WR, als auch wenn die DTU komplett ausfällt, und sogar wenn der MQTT Server komplett aufgibt.

Tagsüber könnten die letzten Werte gesendet werden. In meinen Augen sind die aber auch falsch ! Hier ist es besser genau zu wissen, welchen Status der einzelne WR hat (Available, Not available, Not producing …) und da sollte man einen Watchdog drauf ansetzen falls jemand einen Alarm braucht, nicht auf hängen gebliebene oder gar falsche Werte.

Ich stimme dir vollkommen zu.

knickohr commented 1 year ago

Also fassen wir mal zusammen:

uptime offline kommt offenbar nur beim ESP32 als Folge einer schlechten/fehlerhafte/verlorenen Verbindung zum Borker -> muß weg, darf nicht mehr als uptime kommen oder einen anderen Topicnamrn bekommen
ab der v0.5.41 werden jetzt die uptime und wifi rssi auch Nachts übertragen 👍
Available Status muß Nachts auch übertragen werden, so kann man eine Plausibilitätdprüfung oder einen Watchdog programmieren ob die ausgegebenen Werte noch stimmen oder ob die WRs offline sind
Als letzten gesendeten Wert vor Sonnenuntergang sollten meiner Meinung nach die nicht kumulierenden Werte auf Null gezogen werden, danach keine Werte mehr ausgeben
Yield Day kann bis Mitternacht stehen bleiben, dann nullen
Yield-Werte und der Status jedes WRs muß wie uptime und wifi rssi immer ausgegeben werden, alle anderen können nach Sonnenuntergang ausbleiben

Habe ich was vergessen ?

MisterBJ commented 1 year ago

Mal im Raum geschmiessen...wenn Wifi RSSI angezeigt wird ist es auch Möglich wie gut der Empfang zwischen dem WR und dem NRF ist? Und vielleicht auch eine Art Statustext/Statuscode good/schlecht/ usw. für beide Signalwege wie es beim Errorcode vom WR gibt?

knickohr commented 1 year ago

Das wurde glaube ich schon mal gefragt. Aber meines Wissens gibt das nrf-Modul sowas nicht aus. Vielleicht kann einer der Entwickler genaueres sagen.

lumapu commented 1 year ago

Es gibt nur ein Bit Signal Info. Diese wird noch nicht ausgewertet. Gibt hierzu auch einen extra issue, kram ...

... hier ist er #320

joba-1 commented 1 year ago

Interessante Diskussion - da mein Ahoy jetzt einen Tag läuft überlege ich natürlich, wie ich die Daten abgreife und verarbeite (Ziel: Influx -> Grafana).

Keine Fake-Werte zu bekommen wäre mir da auch wichtig - also nichts weiter senden was nicht neu ist. Wobei ich n*"keine Daten" auch gern ein Mal als 0 hätte. Dabei könnte man n aus dem durchschnittlichen Verhältnis von TX / Rx berechnen und evtl. auch höher ansetzen, wenn der letzte Ertrag >5% war. Damit berücksichtigt man gute und schlechte Empfangsverhältnisse, dunkle Gewitterwolken vor Sonnenuntergang und auch wenn jemand den Inverter mitten am Tag aussteckt bekommt man das immer noch relativ zeitnah mit.

Ausnahmen sind natürlich kumulierte Werte und Temperatur. Die bräuchte ich nur wenn sich was ändert, ansonsten einfach gar nicht.

Warum man rssi und uptime nachts braucht erschließt sich mir nicht - die Diskussion hab ich verpasst :) Meinetwegen könnte der ESP nachts, wenn der Inverter eine Weile nichts mehr gesendet hat, einfach schlafen gehen: beim Start mqtt status = "online", beim Schlafen gehen status = "sleeping until epochtime" und als LWT status = "offline", alles retained (als einziges Topic) und man weiß eigentlich immer Bescheid.

Wenn ich nichts übersehen hab, dann passt das sogar zum Anwendungsfall wenn der Inverter nachts von einem Akku gespeist wird (bei Nulleinspeisung oder Konstanteinspeisung).

Ist alles natürlich nur meine Meinung, im Sinne von Brainstorming, hoffe es hilft.

Argafal commented 1 year ago

Also fassen wir mal zusammen:

* uptime offline kommt offenbar nur beim ESP32 als Folge einer schlechten/fehlerhafte/verlorenen Verbindung zum Borker -> muß weg, darf nicht mehr als uptime kommen oder einen anderen Topicnamrn bekommen

* ab der v0.5.41 werden jetzt die uptime und wifi rssi auch Nachts übertragen +1

* Available Status muß Nachts auch übertragen werden, so kann man eine Plausibilitätdprüfung oder einen Watchdog programmieren ob die ausgegebenen Werte noch stimmen oder ob die WRs offline sind

* Als letzten gesendeten Wert vor Sonnenuntergang sollten meiner Meinung nach die nicht kumulierenden Werte auf Null gezogen werden, danach keine Werte mehr ausgeben

* Yield Day kann bis Mitternacht stehen bleiben, dann nullen

* Yield-Werte und der Status jedes WRs muß wie uptime und wifi rssi immer ausgegeben werden, alle anderen können nach Sonnenuntergang ausbleiben

Habe ich was vergessen ?

Das klingt nach einer ziemlichen guten Zusammenfassung, finde ich. :) Wäre für mich eine gute Lösung, wenn man das wie du vorschlägst implementiert.

Ein kleiner Kommentar zum letzten Punkt: Ein Yield-Wert kann nicht ausgegeben werden, wenn der Inverter nicht verfügbar ist. Du weisst ja in diesem Fall nicht, ob der Inverter produziert oder nicht. Produziert der Inverter, verändert sich der Yield-Wert intern, obwohl die DTU davon nichts mit bekommt. Wenn du jetzt also weiterhin den alten Yield-Wert als Fake-Wert überträgst, dann ist dieser potentiell falsch.

knickohr commented 1 year ago

Das ist ein guter Einwand ! Zwingend ist aber der Status, der darf nie fehlen 😉

knickohr commented 1 year ago

Könnt ihr den available_Status der WRs als retained Message aufnehmen ?

Würde helfen den letzten Status auch nach Abbruch/Neustart/… mitzubekommen.

Ach ja, welchen QoS habt ihr eigentlich eingestellt ?

knickohr commented 1 year ago

Meine Anforderungen habe ich in #468 neu definiert. Ist auch teilweise schon mit der 45 umgesetzt. Was ihr mit dem issue hier macht, müßte ihr jetzt selber ausbaldowern, im Prinzip ist meine Anforderung hier umgesetzt, da ich jetzt mit dem neuen Status mir die Werte selbst nullen kann 😉

lumapu / ahoy

Feature Request: Keine Daten über MQTT mehr wenn WRs offline #416