Mqtt - Variablen
-
@humidor sagte in Mqtt - Variablen:
im Cerbo Client eine Variable abfragen, erzeugt im Broker am ioBroker diese
Das ist übrigens ein Subscribe und legt im ioBroker gar nichts an, sondern wartet nur auf Nachrichten.
-
@haus-automatisierung ja das ist ein subscribe und legt mir die Variable im ioBroker Mqtt Broker an - diese war vorher nicht existent. Ich kann hier nicht definieren, ob es ein String, Num oder Bool... ist. im ioB ist es ein State.
ich habe im Cerbo diese Mqtt In Nodes angelegt:
danach sind die Variablen im ioB angelegt worden:
-
@haus-automatisierung ich bin auf der Suche nach der ID meines ioBroker Mqtt Master, hättest du ev. eine Info wie ich zu dieser komme?
-
@humidor Was ist denn ein „Mqtt Master“? Der Broker hat keine ID. Jeder verbundene Client schon (die ClientID)
-
@haus-automatisierung ja richtig, ok, wie subscribe ich dann vom Client (Cerbo) auf den Master, damit dieser zum polling angestoßen wird?
-
@humidor Ich verstehe dich nicht, wenn Du eigene Begriffe ausdenkst.
Den Prozess habe ich ja oben erklärt und auch schon etliche Lern-Inhalte zu MQTT erstellt. Gern mal reinschauen dann kann ich auch besser helfen
-
@haus-automatisierung wiso, der Client subscribed, der Broker published
-
@humidor nein. Polling existiert nicht. Nur publish/subscribe. Das ist ja gerade der Vorteil von MQTT gegenüber z.B HTTP
-
-
@humidor Kannst den Abschnitt zu „polling“ mal markieren?
-
@haus-automatisierung published...
der Client muss sich am Broker subscriben und das zyklisch
-
@humidor Nein. Subscribe passier einmalig (je topic oder per wildcard) und ist auch kein muss. Man kann als Client auch nur publishen.
Daher ja auch der Hinweis oben, dass ein einfaches subscribe in Node-Red keine Datenpunkte im MQTT-Adapter anlegen wird.
Aber wie gesagt, bitte Grundlagen anschauen.
-
@haus-automatisierung
ich folge der Beschreibung von Victron, auf deren Geräte ich Mqtt ja benutze
https://github.com/victronenergy/dbus-mqtt#keep-aliveder Client muss zyklisch am Broker subcriben, sonst ist nach 60s Schluss
das mache ich und funktioniert auch, sonst bekommt der Victron Cerbo keine Datenwie ich oben schon geschrieben habe, der Node Red am Cerbo ist ein Client, lege ich dort irgend eine Variable im Mqtt In Node an, wird diese im ioBroker Mqtt Master erzeugt.
veränder ich diese Variable/Wert , wird das im Node Red am Cerbo aktualisiert
das funktioniert.der neue flashMQ soll ja in der neuen FW vom Cerbo drin sein, meine Cerbos haben V3.20 (aktuell), dieser soll das aktualisieren bereits haben, mein Mqtt IN Node am Cerbo wartet aber mit der Weitergabe der Info auf eine Änderung und das ist mein Thema.
-
@humidor sagte in Mqtt - Variablen:
der Client muss zyklisch am Broker subcriben, sonst ist nach 60s Schluss
Nein, das ist ein Publish. Steht auch da:
To activate keep-alive, send a read request to R/<portal ID>/keepalive. The payload may be blank
Also brauchst Du eine Publish-Node und keine Subscribe-Node! Die nennen ihre Topics halt so (Ein Publish auf
R/ist eine "Read-Request" - das hat mit dem MQTT-Standard aber nichts zu tun. Da kennt man den Begriff "read" gar nicht.)@humidor sagte in Mqtt - Variablen:
wie ich oben schon geschrieben habe, der Node Red am Cerbo ist ein Client
Richtig. Habe nichts anderes gesagt. Genau wie dein MQTT-Adapter nur ein Client ist.
@humidor sagte in Mqtt - Variablen:
wird diese im ioBroker Mqtt Master erzeugt.
Nein. Nur wenn das Retain-Flag gesetzt wird sind die Payloads auf Topics persistent. Da wird nichts erzeugt. Das ist wie eine Broadcast-Nachricht. Alle, die abonniert haben, bekommen die Nachricht. Wer erst später abonniert, bekommt diese nicht (außer das Retain-Flag wurde beim publish gesetzt).
Es gibt in MQTT keine "Variablen"
@humidor sagte in Mqtt - Variablen:
der neue flashMQ soll ja in der neuen FW vom Cerbo drin sein
Richtig, hat Mosquitto abgelöst. Tut aber nichts zur Sache und verhält sich gleich.
-
@haus-automatisierung gut, dh zwischen Mqtt Standard und Victron ist ein Unterschied, das wird mich da wohl auch verwirren. Damit umschreibe ich ab jetzt nur noch. (lesen/holen/schreiben)
ich sage dem ioBroker Broker, er soll bitte seine Daten senden
ich mache das zyklisch alle 30s, sonst sendet er nach 60s nicht mehr.
das wird im Cerbo Node Red mit einer Mqtt Out Node gemacht
auf Mqtt In Node bekomme ich die Werte, die ich sehen will. -
@humidor Am Ende weiß ich nicht genau, was Du vor hast.
- Du hast einen MQTT-Broker (der läuft auf dem Cerbo).
- Dieser erwartet von einem Client (z.B. Node-RED auf dem Cerbo) einen regelmäßig "Read-Request".
- Dieser "Read-Request" ist aber eigentlich nur ein Publish auf
R/<portal ID>/keepalive. Das braucht also in Node-RED eine MQTT-Out-Node. Payload kann auch leer sein. Also total egal. Zyklisch senden geht z.B. mit einer Inject Node.
Jetzt ist die Frage, welche Rolle der ioBroker dabei spielt.
- Warum verbindet der sich nicht auch einfach mit dem MQTT-Adapter (im Client-Modus) gegen den MQTT-Broker im Cerbo?
- Was genau soll der ioBroker dann tun?
Um nochmal auf die Ausgangsfragen einzugehen:
@humidor sagte in Mqtt - Variablen:
kann ich aus dem Blockly Variablen im Mqtt Master (am Victron Cerbo) erzeugen?
Diese "Variablen" heißen Topics und sind nicht persistent. Um einen Datenpunkt im ioBroker zu erzeugen, muss einfach nur eine Nachricht auf einem abonnierten Topic gepublished werden. Dann wird diese automatisch angelegt.
Ein schreiben dieser Datenpunkte führt dann wieder zu einem Publish auf dem Topic (dies ist auf dem Objekt in ioBroker hinterlegt).
@humidor sagte in Mqtt - Variablen:
Was ich nun will, ist die Regelung / Steuerung vom ioBroker mittels Blockly zu realisieren
Am Ende schreibst Du damit einfach nur Datenpunkte. Wie jeden anderen Datenpunkt auch. Und der MQTT-Adapter macht aus diesem "steuere"-Befehl dann ein Publish auf MQTT.
Wie genau was verknüpft werden soll, welche Rolle Node-RED und welche ioBroker spielt, habe ich nach wie vor nicht verstanden und müsste genauer definiert werden.
-
Achso und es gibt noch einen MQTT-Cloud-Server, gegen welchen man sich auch verbinden könnte. Daher kommt scheinbar auch Deine Dokumentation. Dafür arbeitet der MQTT-Broker auf dem Cerbo als Relay und gibt alles an den Cloud-Server weiter.
Willst Du das wirklich über den MQTT-Broker in der Cloud machen? Sind das verschiedene Standorte? Oder warum nicht den lokalen MQTT-Broker des Cerbo nutzen?
Ich hatte die kompletten Zusammenhänge bei VenusOS und dem VRM mal hier dokumentiert: https://www.youtube.com/watch?v=QTDAZXycTlk
-
@haus-automatisierung nein, keine Cloud im Spiel.
in den Mqtt Out Nodes am Cerbo Node Red ist IP:Port hinterlegt, dh der Node kommuniziert hier nicht mit dem Cerbo Broker, sondern direkt mit dem ioBroker Broker.
so habe ich es verstanden.
Wenn der Cerbo Node Red Client mit dem Cerbo Broker kommunizieren soll, muss die lokale IP/hostname/127.xxxx hinterlegt sein.Bsp. Bilder zu einem anderen Cerbo
der ioBroker mqtt.0 Broker zeigt diese an, die am Cerbo mit dem Mqtt out ..
mqtt.1 Client ist ein Cerbo und mqtt.2 Client ist ein Cerbo
im Node-Red vom ioBroker wird auf diese Cerbo Broker ein request gesendet
die Topics sind dann im ioBroker Objektbaum aufgelistet -
@humidor sagte in Mqtt - Variablen:
dh der Node kommuniziert hier nicht mit dem Cerbo Broker, sondern direkt mit dem ioBroker Broker.
Also nutzt du Node-RED als "Middleware" zwischen dem MQTT-Broker vom Cerbo und dem MQTT-Broker von ioBroker? Du zeigst ja immer nur Ausschnitte von Flows. Und die Fragen oben werden auch nicht beantwortet. Skizzier das gerne mal, schildere was wo genau konfiguriert ist und dann kann ich helfen.
-
@humidor sagte in Mqtt - Variablen:
der ioBroker mqtt.0 Broker zeigt diese an, die am Cerbo mit dem Mqtt out ..
mqtt.1 Client ist ein Cerbo und mqtt.2 Client ist ein Cerbo
im Node-Red vom ioBroker wird auf diese Cerbo Broker ein request gesendetUnd wozu das Ganze? Ich würde mich für Node-RED oder ioBroker entscheiden. Wenn mqtt.1 und mqtt.2 doch alles bereits abonnieren und an alle Daten kommen, warum dann nochmal einen MQTT-Broker (mqtt.0) betreiben und diesen irgendwie aus Node-RED mit den gleichen Daten füttern?!
