<![CDATA[iOBrokerIn - Get/FilterBy NodeName]]>Hallo,

daheim steht ein Raspi 4B, dort läuft im Docker ein Deconz sowie drumherum eine iOBroker Instanz. Läuft alles prima, zum Beispiel mehrere Tradfri Schalter steuern die Rollläden oder Bewegungsmelder das Licht. Soweit also alles in Ordnung :-)

Aber Potenzial gibt es immer. Hab pro Zimmer/Rollladen dedizierte Flows, in Summe bald 20. Pro Flow spielt meistens ein bestimmter Schalter die Hauptrolle, liefert sein LastUpdated Event, das ButtonPressed Event oder den BatteryState. Jeder einzelne iOBrokerIn Node innerhalb eines Flows nutzt also die gleiche Basisadresse, etwa /deconz/0/sensors/12/* für den Bewegungsmelder mit Index 12 auf der ersten Deconz Adapter Instanz. Fragt man nun meine eingangs genannten Beispiele mit einzelnen Nodes im Flow ab, dann muss in jedem Node redundant und immer wieder die gleiche Adresse hinterlegt werden. Da fragt man sich, ob das nicht anders geht?

Mir ist klar, dass ich bei einem Get-Node (mit Eingang und Ausgang) das Topic mitgeben kann, damit könnte ich die gewünscht Dynamic erreichen. Der In-Node aber (nur ein Ausgang, reagiert aktiv auf Events) kann diese Dynamic freilich nicht unterstützen, da das Topic/die Adresse des Sensors/Schalters dort hart drinsteht. Ändert sich jetzt meine Umgebung (neuer Sensor, Reihenfolge der Sensoren verändert) dann muss jedes Mal jeder einzelne Node angefasst werden um die Adressen zu kontrollieren/zu ändern. Schlecht, vermeidbarer Aufwand. Und denkt man seine Flows mal ein wenig objektorientiert, dann wünscht man sich doch so oder so eine zentrale Stelle im Flow, wo man die Basisadresse eines Deconz Gerätes einmalig pflegen will, oder?

Soweit die Erwartungshaltung. Hab aus dem Forum schon gelernt, dass ich die Adresse mit Wildcards versehen kann, wusste ich gar nicht. Prima, gleich ausprobiert. Mit /deconz/0/sensors/*/buttonevent kann ich praktisch auf alle Buttonevents lauschen. Danach möchte ich dann Filtern, welcher konkrete Schalter mich gerade im Flow interessiert. Was fehlt hierfür? Klar, der Name des Schalters, denn ich will ja nicht wieder von der (veränderlichen) numerischen ID abhängig sein.

Hat da jemand einen Tipp? Kann man dem Deconz Adapter / iOBrokerIn Node beibringen, dass bitte neben der Adresse (also dem Topic im Format /deconz/0/sensors/12/buttonevent/ auch der NAME des Gerätes mitgeschickt wird, welches den Event verursacht hat? Denn dann kann ich flexibel nach dem Namen filtern, müsste meine Flows nie wieder anfassen, egal welche Reihenfolge die Geräte im Deconz Tree haben...

Hoffe das ist soweit verständlich rübergekommen. Tipps sind willkommen!

Grüße - Frank

]]>https://forum.iobroker.net/topic/57482/iobrokerin-get-filterby-nodenameRSS for NodeMon, 18 May 2026 00:02:47 GMTFri, 26 Aug 2022 09:40:46 GMT60<![CDATA[Reply to iOBrokerIn - Get/FilterBy NodeName on Sat, 08 Oct 2022 17:39:13 GMT]]>@ft Wenn die List Node es nicht hergibt - dann musst wahrscheinlich selbst eine Javascript Proxy Funktion schreiben oder ein Issue aufmachen - oder selbst den Namen der Shellies ändern.

]]>https://forum.iobroker.net/post/870286https://forum.iobroker.net/post/870286Sat, 08 Oct 2022 17:39:13 GMT<![CDATA[Reply to iOBrokerIn - Get/FilterBy NodeName on Sat, 08 Oct 2022 17:10:09 GMT]]>Guten Abend,

darf ich das nochmal rauskramen bitte?

Mit meinen via deConz an iOBroker angebundenen Zigbee Komponenten habe ich nun die gewünscht Flexibilität über den IOB-List Node erreicht. Werte basierend auf dem Objektnamen auslesen ist damit sowas von praktisch, nirgends mehr Abhängigkeiten von der Object-ID im Objektbaum der IOB Instanz.

Aber - geht das auch irgendwie für meine Shellies? Da hilft mit der IOB-List Node bislang gar nicht. Will ich etwa die Position meines Rollladens wissen (Shelly 2.5 im Shutter Mode) dann spuckt mir der IOB-Liste Node das schon aus, aber eben nicht mit dem Human Readable Name des Shellies, sondern dessen kryptischer ID. Und im Object-Common-Name steht nochmal POSITION drin - danke, das wei ich doch schon 🙄

Also gleiches Thema, nur bitte nochmal für die Shellies aufgewärmt.

Danke für die Unterstützung!

Grüße - Frank

]]>https://forum.iobroker.net/post/870280https://forum.iobroker.net/post/870280Sat, 08 Oct 2022 17:10:09 GMT<![CDATA[Reply to iOBrokerIn - Get/FilterBy NodeName on Fri, 26 Aug 2022 17:59:52 GMT]]>@mickym Besten Dank für diesen Tipp, hätte ich in der Art nie ausprobiert.

Funktioniert einwandfrei. So kann ich per Wildcard auf bestimmte Ereignisse lauschen, etwa deconz.0.Sensors.*.buttonevent

Danach mit dem IOB-List Node so wie von Dir gezeigt den Namen anreichern. Im resultierenden Message Object habe ich dann alles, um auf den Namen zu filtern und so die für den jeweiligen Flow interessanten Nachrichten/Ereignisse rauszufischen.

Besten Dank! 👏

]]>https://forum.iobroker.net/post/848213https://forum.iobroker.net/post/848213Fri, 26 Aug 2022 17:59:52 GMT<![CDATA[Reply to iOBrokerIn - Get/FilterBy NodeName on Fri, 26 Aug 2022 10:15:29 GMT]]>@ft Du musst Dich in diesem Fall mit einem kleinen Trick behelfen.

Wie Du richtig sagst - kann man mit der iobrokerIN Node auch wildcards benutzen, um das flexibel zu gestalten. Um an den Namen des Objektes zu bekommen - benötigt man das GESAMTE OBJEKT - das kann nur die list node. In Kombination ein gutes Gespann:

Nehmen wir mal an Du willst den Wert und den Namen eines Datenpunktes ermitteln - dann musst Du den Namen aus dem Common Objekt holen.

98b948f7-f14a-425b-b395-e73c779930e5-image.png

Nehmen wir mal den Wert aktiv - der hängt bei mir unter 0_userdata.0.Test - Triggern tut also die iobrokerIN Node:

e8b557d9-7d7a-49ec-9eaf-8766e563b24c-image.png

]]>https://forum.iobroker.net/post/847990https://forum.iobroker.net/post/847990Fri, 26 Aug 2022 10:15:29 GMT