Feature Request : weitere Anpassungen zum MQTT Topic status

[knickohr]

Feature Request !!!

und keine Eile mit der Anpassung, muß Erst Morgen fertig sein 🤪

Weitere Anpassung für den MQTT Topic < topicname >/status und nur für den, nichts anderes oder was anderes umbauen.

Hintergrund : Aus dem Status //available kann man prima in Verbindung des Sonnenauf- und Untergang einen weiteren Status „missing“ herleiten. Das ist z.B. unter Tags sinnvoll, falls ein Inverter seinen Dienst einstellt oder sonst wie ein Problem hat.

Das Ganze kann mathematisch gelöst werden:

Wir bilden immer die Summe aus den Stati < topicname >//available über alle Inverter.

• ist die Summe = 0, dann sind alle Inverter offline (oder keiner vorhanden, egal, kommt wohl eher selten vor) -> Ausgabe „offline“ im Status < topicname >/status
• Ist die Summe genau 2x der Anzahl aller vorhandenen Inverter, dann sind alle Inverter available und pruducing -> online
• Ist die Summe irgendwas dazwischen, dann fehlt einer oder mehrere oder einer oder mehrere produzieren nicht -> partial
• aaaber, ist ein Status von mindestens einem Inverter unter Tags = 0, dann gibt es ein Problem -> missing ausgeben

Doch eine kleine Änderung an den bereits vorhandenen Status available und available_ text 😵 Die Werte sollten sofort ausgegeben werden wenn sie sich ändern, vor allen der Wert 0 bzw. offline ! Nicht erst bei Sonnenuntergang. Also so machen wie das „not yet available“ in auf der Webseite. Ansonsten würde dieser Feature Request nicht funktionieren. Sorry wenn das schon wieder geändert werden muß 😇

Man könnte sogar noch einen weiteren 5. Status implementieren in Verbindung mit dem „Communication Start/Stop“. Ist es Nacht und alle Inverter sind offline (sind sie dann sowieso), dann den Status im Topic < topicname >/status auf „night time“ setzen. Dieser Status sollte natürlich sinnigerweise nur gesetzt werden wenn das auch erwünscht ist (Haken bei „disable night communication“ gesetzt ist).

Das sind alles Vorschläge und muß nicht zwingend gemacht werden, ich kann mir das Ganze auf über Node-Red zusammen schustern. Ich stelle das erst mal zur Diskussion und möchte Eure Meinungen dazu hören.

Also haut rein (in die Tasten) und weint euch aus 😂

[roku133]

Es ist ausreichend, für jeden Inverter den aktuellen Wert von available bzw. available_text sofort anzuzeigen wie es @knickohr vorgeschlagen hat.
Alle weiteren Verknüpfungen sind dann eine Sache der Auswertelogik (im SmartHome-System oder wo auch immer) und gehören nicht zur Funktion einer DTU als Daten-Gateway.
Jeder Anwender hat hier ohnehin andere Vorstellungen, was er wie darstellen will.

[knickohr]

@roku133
Widersprichst du dir da jetzt nicht selber in Bezug auf #500 ? 🤔

[roku133]

@knickohr - ganz im Gegenteil:
bei #500 geht es um eine Komfortfunktion, eine andere Darstellung für einen einzelnen Wert wie auch bei available und available_text.
Bei deinem Vorschlag oben geht es aber um die Weiterverarbeitung und Verknüpfung mehrerer Daten. Das ist ein signifikanter Unterschied.

[knickohr]

@roku133
Sorry, ich sehe da überhaupt keinen (signifikanten) Unterschied. Ob ich jetzt die Komfortfunktion der Zeitzonenumrechnung in der DTU oder im, bspw. Node-Red mache ist für mich genau das gleiche.

Oder anders herum, ob ich jetzt die Weiterverarbeitung und Verknüpfung des Staus in der DTU oder, auch wieder bspw. Node-Red zusammen baue, ebenso.

Das ist gehüpft wie gesprungen, nur das Kind hat einen anderen Namen.

[roku133]

@knickohr
ich versuche es noch einmal anders:
eine Datums-/Zeitangabe im Format unixtime an einer externen Schnittstelle ist etwas exotisch - es geht bei #500 um eine zusätzlich angebotene Umformatierung (user friendly und human readable), die sicher optional ist. Es handelt sich letztlich immer noch um ein und dieselbe Datums-/Zeitangabe.
Dein Vorschlag bedeutet eine Weiterverarbeitung und Verknüpfung mehrerer Daten, hier gibt es je nach Anwendungsfall auch andere Möglichkeiten einer Auswertung und Darstellung. Deshalb sollte dies außerhalb der DTU erfolgen.

[roku133]

Die Diskussion ist zur Zeit offensichtlich nur auf uns beide beschränkt - vielleicht warten wir noch andere Kommentare ab
😉

[Gerri1]

Dürfte ich mich mal mit einklinken?
Wenn der Status im MQTT erweitert (geändert) werden soll, würde ich das im Zahlenformat ausgeben, wäre doch besser zum verarbeiten! 😉
Das Gleiche mit dem Status MQTT >connected< true/false bei zwei und bei mehreren dann wieder im Zahlenformat.
Spart vor allem Speicherplatz in der Datenbank! 😁

[knickohr]

@Gerri1
Ja, damit habe ich kein Problem. Wenn wir aber wie roku133 vorschlägt, dann müßten wir einige Topics auch wieder entfernen und konsequenterweise alle berechenbaren Values auch wieder weg nehmen.

Wäre auch kein Beinbruch für mich, aber etwas weniger Bewandte könnten dann nicht mehr solche Komfortfunktionen nutzen oder sich damit schwer tun. Nicht böse sein, @roku133 , aber eine Umrechnung der Zeitzone ist ebenfalls eine Berechnung und kann mit den Visualisierungstools mehr oder weniger einfach erledigt werden, zumal man eh schon aus dem Timestamp in ein human readables Format umrechnen muß.

Der eigentliche Sinn von MQTT ist, mit möglichst wenig Informationen möglichst viel Informationen zu übertragen. Wenn wir die DTU als „Durchlauferhitzer“ ansehen dann macht sie eh schon viel zu viel 😲

[Gerri1]

Ich finde das Projekt >Ahoy-DTU< bis jetzt absolut genial (Hut ab) und meine Meinung ist, die sollte eigentlich auch nur als "Brücke" verwendet werden. Der ESP ist auch irgendwann am Ende und das sollte nicht bis ans Limit gefahren werden.
@knickohr

Der eigentliche Sinn von MQTT ist, mit möglichst wenig Informationen möglichst viel Informationen zu übertragen. Wenn wir die DTU als „Durchlauferhitzer“ ansehen dann macht sie eh schon viel zu viel

Dieser Meinung bin ich auch und es kann jeder die gesendeten Daten nach seinen Wünschen Visualisieren!

[knickohr]

Was wurde bei der 61 umgesetzt ? Nur der minütliche Update oder mehr ?

@lumapu

[lumapu]

genau, ich habe vorsichtig angefangen um nichts zu zerstören. Jetzt wird jede Minute der Status geprüft und bei Änderung sofort übertragen.
Wenn das gut funktioniert würde ich available_text entfernen. Dann muss ich deine Ideen nochmal lesen und überlegen was ich davon umsetze

[knickohr]

@lumapu

Ohne jetzt sarkastisch zu werden, würde ich sagen schmeiß die ganzen Textfelder weg und übertrage nur noch den available als Nummer (so wie er eben schon ist). Ob wir da jetzt weitere Nummern hinzufügen stelle ich erst mal in den Raum. Wie bereits im Discord geschrieben, ich kann mir das auch selbst zusammen bauen (was auch schon teilweise funktioniert). Mir fehlt eigentlich nur noch der Zustand wenn Ahoy im Dornröschenschlaf ist.

[knickohr]

Ich schließe den Issue weil im Zuge der Optimierung es besser ist diese Stati selbst zu „errechnen“. Ich habe es ja auch schon preis gegeben im #413 Getestet und funktioniert 😉