Daten von MQTT nutzen

[SvenPausH]

Hallo, würdest du dein Script erweitern das die Daten aus einem MQTT Broker genutzt werden können?
Hintergrund ist folgender.

Ich habe beobachtet das Geräte die mal nicht ereichbar sind den Cerbo zu stressen weil das Script versucht diese Geräte zu erreichen und das treibt den Load nach oben.
Der MQTT Broker auf dem Cerbo ist aber immer erreichbar und würde die Latenzen deutlich verringern.
Ich habe das mit einem PHP Script gemacht. Ich Abonniere dort ein Topic und der MQTT Broker meldet jede Veränderung.
So müsstest du das Script auch nicht für verschiedene Geräte anpassen, es würde reichen wenn die Geräte ihre Daten an den MQTT Broker senden.

[henne49]

Moin, ich verstehe noch nicht genau die Message Architektur, wir wissen dass das Polling nicht optimal ist. Aber die OpenDTU. kann nur einen mqtt broker als Ziel. sollen wir dann den internen Cerbo mqtt auslesen?

[SvenPausH]

Moin, ja genau der interne mqtt vom Cerbo ist ja schon da. Warum sollte man ihn dann nicht auch nutzen.
Ich habe in meinem Sonoff und dem Growatt Stick den Cerbo mqtt als Ziel angegeben und übertrage die Daten dann in eine Influx.
Nutzen würde ich dann lieber die Daten von dem Growatt Stick da diese genauer sind als die Sonoff Messungen.
Das Auslesen funktioniert, das habe ich auf dem Cerbo getestet.
mqtt_python.py.txt

Die Nachrichten sind json.

[henne49]

https://github.com/freakent/dbus-mqtt-devices wäre das nicht das Projekt, das das Problem löst?

[SvenPausH]

Ich glaube der Ansatz ist so dass das Format der mqtt Daten vorgegeben ist.
Das unterscheidet sich aber von dem Format das sonoff etc. ausgeben.
Du liest schon genau den gleichen json String ein den die Geräte auch als mqtt ablegen.
Nur das Einlesen ist ein wenig anders.
Du fragst regelmäßig die Webseite ab und verarbeitest den json String.
Mit mqtt würdest du etwas abonieren und dein Script reagiert wenn Daten einfließen.

[henne49]

wenn du einen PR dazu liefern könntest, dann würden wir uns das anschauen. Ich sende eben alle Daten per MQTT an home-assistant und daher kommt nichts per mqtt, aber wie du schreibst, kann es für andere Use Cases sinnvoll sein.

Schauen wir uns gerne mal an

[SvenPausH]

Ok jetzt verstehe ich deine Aussage das du in den Geräten nur ein Ziel eingeben kannst.
Das HA mqtt empfangen kann wusste ich nicht.
Du meinst ein Pull request?
Ich habe von Python leider nicht so viel Ahnung.
Das python Script zum Auslesen von Sonoff hatte ich dir weiter oben angehängt.
Hast du das gesehen?
Du musst nur das topic, ip Adresse anpassen dann läuft es direkt auf dem Cerbo.

[SvenPausH]

Moin, ich habe mir die Doku von HM einmal durchgelesen.
Du hast dort einen vollwertigen MQTT Broker installiert.
Im Prinzip nichts anderes als das was der Cerbo hat.
Somit kannst du in dem Script auch die IP deines HM angeben.
Der Vorteil ist für dich dann auch nutzbar. Das Script empfängt dann push Nachrichten statt zu pollen.

[henne49]

In welcher Hoymiles Doku? Du meinst opendtu oder ahoy? Wir sprechen nur diese ESP basierten Geräte an, wenn die auch mqtt können, dann würde das Sinn machen was du schreibst. Freue mich über den Link zur Doku

[SvenPausH]

Sorry unwuchtige Finger heute Morgen. HA also Home Assisstant.
https://www.home-assistant.io/integrations/mqtt/

[0x7878]

Du kannst dir einen wrapper auch selbst bauen mit node-red. Der läuft auf den cerbo und hat Zugriff auf mqtt und das dbus system.

Ein großen Mehrwert bietet es nicht sich auf die Nachrichten zu subscriben. Die Werte ändern sich nicht binnen Sekunden soviel Overhead hat eine http message auch nicht.

Wenn du die Daten in Homeassistent haben möchtest (habe ich auch eingebunden) kannst du dir diese per modbus aus deinen cerbo holen. Läuft bei mir alles reibungslos.

[henne49]

Genau, Mehrwert wäre mqtt Server im OpenDTU oder ahoy, die Daten aus HA zu nehmen, wäre auch möglich über template und REST Calls. Was wir hier gebaut haben ist eine direkte Integration zwichsen den DTUs (ahoy und OpenDTU) zu Victron, daher bleiben wir bei den Rest Calls.

Aber ich glaube es wäre eine gute Idee, bei nicht Verfügbarkeit den Reconnect zu delayen, so wie bei Tasmota, wo nach einiger Zeit nur noch alle 30 Minuten abgefragt wird, was die Last ziemlich reduziert.

Das würde deinem Use Case helfen und in unsere Architektur passen? Falls machen wir hier nen issue draus und wir schauen uns das an.

[Head]

https://github.com/Telekatz/venus.dbus-hoymiles arbeitet mit MQTT, falls es hilft.

[henne49]

das liest die Daten in der Tat aus dem Venus mqtt und packt sie in den dbus.

[SvenPausH]

Sieht interessant aus. Ich denke ich werde es einmal mit einem Pi4 testen und schauen ob es funtioniert.