Weiter zum Inhalt
  • Home
  • Aktuell
  • Tags
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • GitHub
  • Docu
  • Hilfe
Skins
  • Hell
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dunkel
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Standard: (Kein Skin)
  • Kein Skin
Einklappen
ioBroker Logo

Community Forum

donate donate
  1. ioBroker Community Home
  2. Deutsch
  3. ioBroker Allgemein
  4. iOBrokerIn - Get/FilterBy NodeName

NEWS

  • Neuer ioBroker-Blog online: Monatsrückblick März/April 2026
    BluefoxB
    Bluefox
    8
    1
    1.7k

  • Verwendung von KI bitte immer deutlich kennzeichnen
    HomoranH
    Homoran
    10
    1
    721

  • Monatsrückblick Januar/Februar 2026 ist online!
    BluefoxB
    Bluefox
    18
    1
    1.2k

iOBrokerIn - Get/FilterBy NodeName

Geplant Angeheftet Gesperrt Verschoben ioBroker Allgemein
5 Beiträge 2 Kommentatoren 177 Aufrufe 2 Beobachtet
  • Älteste zuerst
  • Neuste zuerst
  • Meiste Stimmen
Antworten
  • In einem neuen Thema antworten
Anmelden zum Antworten
Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
  • F Offline
    F Offline
    FT
    schrieb am zuletzt editiert von
    #1

    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

    mickymM 1 Antwort Letzte Antwort
    0
    • F FT

      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

      mickymM Online
      mickymM Online
      mickym
      Most Active
      schrieb am zuletzt editiert von mickym
      #2

      @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

      [
         {
             "id": "a800e87fb464dd11",
             "type": "ioBroker in",
             "z": "289f539dcc33814e",
             "name": "",
             "topic": "0_userdata.0.Test.*",
             "payloadType": "value",
             "onlyack": "",
             "func": "all",
             "gap": "",
             "fireOnStart": "false",
             "outFormat": "MQTT",
             "x": 250,
             "y": 3440,
             "wires": [
                 [
                     "2e15f069fc87f697"
                 ]
             ]
         },
         {
             "id": "7e560cc4e01f5b13",
             "type": "debug",
             "z": "289f539dcc33814e",
             "name": "vollständiges Objekt",
             "active": true,
             "tosidebar": true,
             "console": false,
             "tostatus": false,
             "complete": "true",
             "targetType": "full",
             "statusVal": "",
             "statusType": "auto",
             "x": 660,
             "y": 3400,
             "wires": []
         },
         {
             "id": "2e15f069fc87f697",
             "type": "ioBroker list",
             "z": "289f539dcc33814e",
             "name": "",
             "topic": "",
             "objType": "state",
             "regex": "",
             "asArray": "false",
             "onlyIDs": "false",
             "withValues": "true",
             "x": 450,
             "y": 3440,
             "wires": [
                 [
                     "7e560cc4e01f5b13",
                     "961b120cb09d6542"
                 ]
             ]
         },
         {
             "id": "961b120cb09d6542",
             "type": "change",
             "z": "289f539dcc33814e",
             "name": "New payload & topic",
             "rules": [
                 {
                     "t": "set",
                     "p": "topic",
                     "pt": "msg",
                     "to": "payload.common.name",
                     "tot": "msg"
                 },
                 {
                     "t": "set",
                     "p": "payload",
                     "pt": "msg",
                     "to": "payload.val",
                     "tot": "msg"
                 }
             ],
             "action": "",
             "property": "",
             "from": "",
             "to": "",
             "reg": false,
             "x": 660,
             "y": 3440,
             "wires": [
                 [
                     "2ec327a35017175e"
                 ]
             ]
         },
         {
             "id": "2ec327a35017175e",
             "type": "debug",
             "z": "289f539dcc33814e",
             "name": "New payload & topic",
             "active": true,
             "tosidebar": true,
             "console": false,
             "tostatus": false,
             "complete": "payload",
             "targetType": "msg",
             "statusVal": "",
             "statusType": "auto",
             "x": 920,
             "y": 3440,
             "wires": []
         }
      ]
      

      Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.

      F 1 Antwort Letzte Antwort
      0
      • mickymM mickym

        @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

        [
           {
               "id": "a800e87fb464dd11",
               "type": "ioBroker in",
               "z": "289f539dcc33814e",
               "name": "",
               "topic": "0_userdata.0.Test.*",
               "payloadType": "value",
               "onlyack": "",
               "func": "all",
               "gap": "",
               "fireOnStart": "false",
               "outFormat": "MQTT",
               "x": 250,
               "y": 3440,
               "wires": [
                   [
                       "2e15f069fc87f697"
                   ]
               ]
           },
           {
               "id": "7e560cc4e01f5b13",
               "type": "debug",
               "z": "289f539dcc33814e",
               "name": "vollständiges Objekt",
               "active": true,
               "tosidebar": true,
               "console": false,
               "tostatus": false,
               "complete": "true",
               "targetType": "full",
               "statusVal": "",
               "statusType": "auto",
               "x": 660,
               "y": 3400,
               "wires": []
           },
           {
               "id": "2e15f069fc87f697",
               "type": "ioBroker list",
               "z": "289f539dcc33814e",
               "name": "",
               "topic": "",
               "objType": "state",
               "regex": "",
               "asArray": "false",
               "onlyIDs": "false",
               "withValues": "true",
               "x": 450,
               "y": 3440,
               "wires": [
                   [
                       "7e560cc4e01f5b13",
                       "961b120cb09d6542"
                   ]
               ]
           },
           {
               "id": "961b120cb09d6542",
               "type": "change",
               "z": "289f539dcc33814e",
               "name": "New payload & topic",
               "rules": [
                   {
                       "t": "set",
                       "p": "topic",
                       "pt": "msg",
                       "to": "payload.common.name",
                       "tot": "msg"
                   },
                   {
                       "t": "set",
                       "p": "payload",
                       "pt": "msg",
                       "to": "payload.val",
                       "tot": "msg"
                   }
               ],
               "action": "",
               "property": "",
               "from": "",
               "to": "",
               "reg": false,
               "x": 660,
               "y": 3440,
               "wires": [
                   [
                       "2ec327a35017175e"
                   ]
               ]
           },
           {
               "id": "2ec327a35017175e",
               "type": "debug",
               "z": "289f539dcc33814e",
               "name": "New payload & topic",
               "active": true,
               "tosidebar": true,
               "console": false,
               "tostatus": false,
               "complete": "payload",
               "targetType": "msg",
               "statusVal": "",
               "statusType": "auto",
               "x": 920,
               "y": 3440,
               "wires": []
           }
        ]
        

        F Offline
        F Offline
        FT
        schrieb am zuletzt editiert von FT
        #3

        @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! 👏

        F 1 Antwort Letzte Antwort
        0
        • F FT

          @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! 👏

          F Offline
          F Offline
          FT
          schrieb am zuletzt editiert von
          #4

          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

          mickymM 1 Antwort Letzte Antwort
          0
          • F FT

            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

            mickymM Online
            mickymM Online
            mickym
            Most Active
            schrieb am zuletzt editiert von
            #5

            @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.

            Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.

            1 Antwort Letzte Antwort
            0

            Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.

            Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.

            Mit deinem Input könnte dieser Beitrag noch besser werden 💗

            Registrieren Anmelden
            Antworten
            • In einem neuen Thema antworten
            Anmelden zum Antworten
            • Älteste zuerst
            • Neuste zuerst
            • Meiste Stimmen


            Support us

            ioBroker
            Community Adapters
            Donate
            FAQ Cloud / IOT
            HowTo: Node.js-Update
            HowTo: Backup/Restore
            Downloads
            BLOG

            497

            Online

            32.9k

            Benutzer

            83.0k

            Themen

            1.3m

            Beiträge
            Community
            Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen | Einwilligungseinstellungen
            ioBroker Community 2014-2025
            logo
            • Anmelden

            • Du hast noch kein Konto? Registrieren

            • Anmelden oder registrieren, um zu suchen
            • Erster Beitrag
              Letzter Beitrag
            0
            • Home
            • Aktuell
            • Tags
            • Ungelesen 0
            • Kategorien
            • Unreplied
            • Beliebt
            • GitHub
            • Docu
            • Hilfe