search

lumapu / ahoy

Various tools, examples, and documentation for communicating with Hoymiles microinverters
https://ahoydtu.de
Other
953 stars 224 forks source link

Feature Request : weitere Anpassungen zum MQTT Topic status #522

Closed knickohr closed 1 year ago

knickohr commented 1 year ago

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.

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 commented 1 year ago

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 commented 1 year ago

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

roku133 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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

Gerri1 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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

@lumapu

lumapu commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 😉