NEWS
mqtt programmatisch publish topic zufügen
-
Hallo mqtt Experten.
Eine Frage zum MQTT Adapter.
Ich setze den als Client ein und würde gern eine Möglichkeit finden, per Programm ein topic zum publischen hinzuzufügen. Also nicht irgend etwas an ein im Adapter hinterlegtes topic zu senden, sonder das topic selbst zum Adapter zuzufügen.
Gibt es da eine Möglichkeit? -
Nutzt du noch Node-RED mit den externen Nodes? Ich werde in den nächsten Tagen eine Version mit einer Lösung für dich in der Beta veröffentlichen.
-
Nutzt du noch Node-RED mit den externen Nodes? Ich werde in den nächsten Tagen eine Version mit einer Lösung für dich in der Beta veröffentlichen.
@Marc-Berg Na unbedingt. Die möchte ich nicht mehr missen.
Inzwischen laufen eigentlich alle meine NR Flows mit deinen nodes. Und das sind nicht Wenige;-)
Bin nach wie vor happy damit. Danke nochmal. -
Ich hatte es schon länger in der Schublade, aber selbst noch keinen Anwendungsfall gesehen. Es gibt nun einen neuen Node "iob-setObject", hiermit kann man die Metadaten entweder komplett neu schreiben, oder selektiv ändern.
Hier als Beta:
https://github.com/Marc-Berg/node-red-contrib-iobroker/releases
Beispiel-Flow:
[ { "id": "57da8d56c3521445", "type": "inject", "z": "tab_mqtt_config", "name": "Trigger: Config ändern", "props": [ { "p": "payload" } ], "repeat": "", "crontab": "", "once": false, "topic": "", "payload": "", "payloadType": "date", "x": 160, "y": 100, "wires": [ [ "beeb75e9c4d8fd64" ] ] }, { "id": "beeb75e9c4d8fd64", "type": "iobgetobject", "z": "tab_mqtt_config", "name": "Get Adapter Config", "objectId": "system.adapter.mqtt.0", "outputProperty": "payload", "outputMode": "single", "objectType": "", "useWildcard": false, "includeEnums": false, "enumTypes": null, "includeAliases": false, "aliasResolution": null, "server": "5661ccf2a79ab23e", "x": 370, "y": 100, "wires": [ [ "71e771ae51e53631" ] ] }, { "id": "71e771ae51e53631", "type": "change", "z": "tab_mqtt_config", "name": "native.publish", "rules": [ { "t": "set", "p": "payload.native.publish", "pt": "msg", "to": "mqtt.0.test,mqtt.0.test2", "tot": "str" } ], "x": 560, "y": 100, "wires": [ [ "9d14c67202871683" ] ] }, { "id": "9d14c67202871683", "type": "iobsetobject", "z": "tab_mqtt_config", "name": "Write Config", "objectId": "system.adapter.mqtt.0", "objectSource": "payload", "objectProperty": "payload", "mergeMode": "merge", "validateObject": true, "server": "5661ccf2a79ab23e", "x": 730, "y": 100, "wires": [ [ "7463f3be3f5843b7" ] ] }, { "id": "7463f3be3f5843b7", "type": "debug", "z": "tab_mqtt_config", "name": "debug 2", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "false", "statusVal": "", "statusType": "auto", "x": 900, "y": 100, "wires": [] }, { "id": "5661ccf2a79ab23e", "type": "iob-config", "name": "config2", "iobhost": "iobroker", "iobport": "8081", "usessl": false } ]Test und Änderungswünsche willkommen.
EDIT: Flow aktualisiert, kein Restart notwendig
-
Ich hatte es schon länger in der Schublade, aber selbst noch keinen Anwendungsfall gesehen. Es gibt nun einen neuen Node "iob-setObject", hiermit kann man die Metadaten entweder komplett neu schreiben, oder selektiv ändern.
Hier als Beta:
https://github.com/Marc-Berg/node-red-contrib-iobroker/releases
Beispiel-Flow:
[ { "id": "57da8d56c3521445", "type": "inject", "z": "tab_mqtt_config", "name": "Trigger: Config ändern", "props": [ { "p": "payload" } ], "repeat": "", "crontab": "", "once": false, "topic": "", "payload": "", "payloadType": "date", "x": 160, "y": 100, "wires": [ [ "beeb75e9c4d8fd64" ] ] }, { "id": "beeb75e9c4d8fd64", "type": "iobgetobject", "z": "tab_mqtt_config", "name": "Get Adapter Config", "objectId": "system.adapter.mqtt.0", "outputProperty": "payload", "outputMode": "single", "objectType": "", "useWildcard": false, "includeEnums": false, "enumTypes": null, "includeAliases": false, "aliasResolution": null, "server": "5661ccf2a79ab23e", "x": 370, "y": 100, "wires": [ [ "71e771ae51e53631" ] ] }, { "id": "71e771ae51e53631", "type": "change", "z": "tab_mqtt_config", "name": "native.publish", "rules": [ { "t": "set", "p": "payload.native.publish", "pt": "msg", "to": "mqtt.0.test,mqtt.0.test2", "tot": "str" } ], "x": 560, "y": 100, "wires": [ [ "9d14c67202871683" ] ] }, { "id": "9d14c67202871683", "type": "iobsetobject", "z": "tab_mqtt_config", "name": "Write Config", "objectId": "system.adapter.mqtt.0", "objectSource": "payload", "objectProperty": "payload", "mergeMode": "merge", "validateObject": true, "server": "5661ccf2a79ab23e", "x": 730, "y": 100, "wires": [ [ "7463f3be3f5843b7" ] ] }, { "id": "7463f3be3f5843b7", "type": "debug", "z": "tab_mqtt_config", "name": "debug 2", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "false", "statusVal": "", "statusType": "auto", "x": 900, "y": 100, "wires": [] }, { "id": "5661ccf2a79ab23e", "type": "iob-config", "name": "config2", "iobhost": "iobroker", "iobport": "8081", "usessl": false } ]Test und Änderungswünsche willkommen.
EDIT: Flow aktualisiert, kein Restart notwendig
@Marc-Berg Große Klasse. Werde ich die Tage gleich mal testen.
Wenn du dir jetzt noch wohlwollend mein eigenbau iob-in-inject iob-in-Inject.zip ansehen würdest, müße ich da gar nichts mehr selber pflegen;-) Das Ding ist für mich leider unverzichbar geworden, weil ich viel mit dynamischan subscriptions arbeite. -
@Marc-Berg Große Klasse. Werde ich die Tage gleich mal testen.
Wenn du dir jetzt noch wohlwollend mein eigenbau iob-in-inject iob-in-Inject.zip ansehen würdest, müße ich da gar nichts mehr selber pflegen;-) Das Ding ist für mich leider unverzichbar geworden, weil ich viel mit dynamischan subscriptions arbeite.@rewenode sagte in mqtt programmatisch publish topic zufügen:
Wenn du dir jetzt noch wohlwollend mein eigenbau iob-in-inject iob-in-Inject.zip ansehen würdest,
Sorry, komplett verdrängt. In der Zeit war wohl anderes wichtiger ... Ich schau mal.
-
@rewenode sagte in mqtt programmatisch publish topic zufügen:
Wenn du dir jetzt noch wohlwollend mein eigenbau iob-in-inject iob-in-Inject.zip ansehen würdest,
Sorry, komplett verdrängt. In der Zeit war wohl anderes wichtiger ... Ich schau mal.
@Marc-Berg Alles gut, ist ja eh nur ein Vorschlag. Und läuft bei mir ja seit längerer Zeit ohne Probleme produktiv. muss halt immer aufpassen, dass ich deinen aktuellen main Zweig merge.
-
@Marc-Berg Große Klasse. Werde ich die Tage gleich mal testen.
Wenn du dir jetzt noch wohlwollend mein eigenbau iob-in-inject iob-in-Inject.zip ansehen würdest, müße ich da gar nichts mehr selber pflegen;-) Das Ding ist für mich leider unverzichbar geworden, weil ich viel mit dynamischan subscriptions arbeite.@rewenode sagte in mqtt programmatisch publish topic zufügen:
wohlwollend mein eigenbau iob-in-inject
Um ganz ehrlich zu sein, bin ich kein großer Fan dieser Lösung
- viel Code-Duplizierung mit iob-in
- das dynamische Switchen zwischen Single- und Multi-Subscription finde ich riskant (die ganze Mechanik der Subscriptions, Konsolidierungen, Resubscriptions in allen möglichen Fehlerfällen war schon eine Herausforderung)
- es fehlt der "grouped" Output des iob-in Nodes
- keine Kontrolle über die "initial values" (ja/nein)
Das passt für deinen Use Case, aber ich würde es gern etwas universeller haben. Grundsätzlich finde ich die Idee mit den dynamischen Subscriptions gut. (Gibt es sowas eigentlich bei Blockly?)
Könntest du darauf verzichten, zur Laufzeit zwischen Single- und Multistate-Subscriptions zu switchen? Dann würde ich es mit in die "external Trigger" Funktionalität einbauen.
-
@rewenode sagte in mqtt programmatisch publish topic zufügen:
wohlwollend mein eigenbau iob-in-inject
Um ganz ehrlich zu sein, bin ich kein großer Fan dieser Lösung
- viel Code-Duplizierung mit iob-in
- das dynamische Switchen zwischen Single- und Multi-Subscription finde ich riskant (die ganze Mechanik der Subscriptions, Konsolidierungen, Resubscriptions in allen möglichen Fehlerfällen war schon eine Herausforderung)
- es fehlt der "grouped" Output des iob-in Nodes
- keine Kontrolle über die "initial values" (ja/nein)
Das passt für deinen Use Case, aber ich würde es gern etwas universeller haben. Grundsätzlich finde ich die Idee mit den dynamischen Subscriptions gut. (Gibt es sowas eigentlich bei Blockly?)
Könntest du darauf verzichten, zur Laufzeit zwischen Single- und Multistate-Subscriptions zu switchen? Dann würde ich es mit in die "external Trigger" Funktionalität einbauen.
@Marc-Berg sagte in mqtt programmatisch publish topic zufügen:
Könntest du darauf verzichten, zur Laufzeit zwischen Single- und Multistate-Subscriptions zu switchen? Dann würde ich es mit in die "external Trigger" Funktionalität einbauen.
Das ist kein Problem. Ich schicke zur Laufzeit generell ein array of states.
Falls 1
Bei mir tummeln sich die iob-in-inject nodes innerhalb von Subflows. z.B Eine Zimmer-Card für das dashboard.
Die benötigten zu abbonierenden IDs werden als Env-Variable in der Flow Konfiguration administriert (array). Vorteil, ich kann die karten für ein anderes Zimmer kopieren und muss den subflow nicht mal öffnen, weil die Konfig außerhalb erfolgt.Fall 2
Ich füge zur Laufzeit z.B. eine Lampe auf einer card zu. Das geht bei mir, weil ich da universelle template-nodes gebastelt habe, denen ich ein array of objets geben kann und die werden halt dargestellt (zur Laufzeit änderbar) Bild
Zu den Objekten gehören natürlich states die ich dank iob-in-inject auch dynamisch abbonieren kann.
Also um ein Object mehr darzustellen muss nicht mal der Flow gestoppt werden. Kann alles über das dashboard gemacht werden.
Hört sich komplizierter an als es ist. Voraussetzung ist aber die Möglichkeit states dynamisch abbonieren zu können.Wenn du die node nicht integrieren willst ist das ja auch kein Problem, läuft ja in meinem use case. Ich bin mir nicht sicher, ob das über den external Trigger so einfach machbar und nötig ist.
Was ich nicht schön fände, wenn das in die iob-in integriert werden würde. Das wäre dann nicht mehr kompatibel. Als Extra node wie bei mir stört das ja niemanden, der sowas nicht braucht.
Inzwischen habe ich eigentlich alle wichtigen dashboard nodes in Template nodes nachgebaut und erweitert. Da bin ich dann doch flexibler. Die speichern selber, wodurch ich das external triggern gar nicht mehr nutze. Wichtiger waren aber andere Einschränkungen der dashboard nodes.
Aber das führt hier zu weit.