Navigation

    Logo
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Unread
    • Categories
    • Unreplied
    • Popular
    • GitHub
    • Docu
    • Hilfe
    1. Home
    2. Deutsch
    3. Skripten / Logik
    4. Node-Red
    5. Node-RED Nodes für externe ioBroker Integration

    NEWS

    • Neuer Blog: Fotos und Eindrücke aus Solingen

    • ioBroker@Smart Living Forum Solingen, 14.06. - Agenda added

    • ioBroker goes Matter ... Matter Adapter in Stable

    Node-RED Nodes für externe ioBroker Integration

    This topic has been deleted. Only users with topic management privileges can see it.
    • R
      rewenode @Marc Berg last edited by

      @marc-berg Hoffe, ich habs richtig exportiert.
      mqtt.0.stTasmota-8.json alias.0.Klima.office.Temperatur.json

      Marc Berg 1 Reply Last reply Reply Quote 0
      • Marc Berg
        Marc Berg Most Active @rewenode last edited by

        @rewenode sagte in Node-RED Nodes für externe ioBroker Integration:

        Hoffe, ich habs richtig exportiert.

        ja, sorry. Habe meinen letzten Post editiert.

        1 Reply Last reply Reply Quote 0
        • R
          rewenode @Marc Berg last edited by

          @marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:

          Als Quickfix diese Eigenschaft im letzen Change-Node einfach löschen.

          Ja passt so👍 Und keine Eile, das läuft ja noch nicht produktiv.

          1 Reply Last reply Reply Quote 0
          • Marc Berg
            Marc Berg Most Active @rewenode last edited by

            @rewenode sagte in Node-RED Nodes für externe ioBroker Integration:

            Sieht fast so aus, als hätte es mit dem msg-object zu tun, was ja komplett durchgeschleift wird.

            Die aufgeräumten Objekt-Eigenschaften sind in der v0.12. verfügbar. Bald in der Palette oder jetzt auf Github.

            Marc Berg 1 Reply Last reply Reply Quote 1
            • Marc Berg
              Marc Berg Most Active @Marc Berg last edited by Marc Berg

              @rewenode

              Da das Abfragen der Objekteigenschaften und der Aliase doch eng zusammenhängt, habe ich es gleich in den GetObject Node mit eingebaut.

              a944fd28-001b-4be6-b6b8-268276674dcf-grafik.png

              Damit müsstest du nicht mehr den Umweg über fünf Nodes nehmen.

              R 2 Replies Last reply Reply Quote 1
              • R
                rewenode @Marc Berg last edited by

                @marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:

                Da das Abfragen der Objekteigenschaften und der Aliase doch eng zusammenhängt, habe ich es gleich in den GetObject Node mit eingebaut.

                Das ist wirklich klasse und eine echte Erleichterung👍 Danke

                1 Reply Last reply Reply Quote 0
                • R
                  rewenode @Marc Berg last edited by

                  @marc-berg Kurze Zwischenfrage, habe gerade mal flüchtig die 12.0-4 getestet. Vlt. war ich da zu voreilig.

                  Ich frage ein Alias Object ab und bekomme neben dem aliasObject die aliasEnums UND das targetObject. Soweit perfekt!
                  Allerdings wird das targetObject ohne die targetEnums geliefert? Oder mach ich da was falsch?

                  2025-07-08_09-49-48.png

                  Marc Berg 1 Reply Last reply Reply Quote 0
                  • Marc Berg
                    Marc Berg Most Active @rewenode last edited by Marc Berg

                    @rewenode sagte in Node-RED Nodes für externe ioBroker Integration:

                    Oder mach ich da was falsch?

                    Nein, du machst nichts falsch. Eine Frage der Philosophie ist wahrscheinlich, ob man alias und target (in das dann wohl immer identische?) Enum legt.

                    Ich könnte jetzt die Enums von alias und target zusammenfassen und deduplizieren, besser ist es aber, wenn ich die Enums sauber dem jeweiligen Objekt zuordne.

                    R 1 Reply Last reply Reply Quote 0
                    • Marc Berg
                      Marc Berg Most Active last edited by

                      @rewenode

                      v0.12.0-5

                      Jetzt haben alle target objects in aliasInfo.aliasTarget.target (bzw. targets.read/targets.write) die gleichen enum assignments wie das ursprüngliche Objekt, wenn sie in entsprechenden enums eingetragen sind.
                      Die enum assignments erscheinen jetzt sowohl beim base-Objekt als auch bei allen alias target objects korrekt.

                      R 1 Reply Last reply Reply Quote 1
                      • R
                        rewenode @Marc Berg last edited by

                        @marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:

                        Ich könnte jetzt die Enums von alias und target zusammenfassen und deduplizieren, besser ist es aber, wenn ich die Enums sauber dem jeweiligen Objekt zuordne.

                        Die Enums von alias und target sind i.d.R unterschiedlich, jedenfalls bei mir.
                        Der Alias ändert sich nicht, ist einem festen Ort zugewiesen.
                        Das Target device kann irgendwas sein und hat je nachdem individuelle Enums (Batterie/Hardware etc). Hatte früher mal aus diesem Grunde den Ort am Target festgemacht. Das ist aber unpraktisch, weil dann auch der Ort am target geändert werden muss, wenn das Teil woanders eingesetzt wird.
                        Ob die Enums beim getObj bei einem Alias die Enums zusammenfasst sind ist eigentlich egal, Hauptsache, es werden sowohl die target und die alias Enums zurückgegeben. Zusammengefaßt wäre einfacher bei der Weiterverarbeitung, weil das alias-object ja in der Regel so betrachtet wird, als wäre es ein tatsächliches device.
                        Getrennt ist aber auch ok.
                        Hoffe, ich habe das nicht zu verworren ausgedrückt.

                        1 Reply Last reply Reply Quote 0
                        • R
                          rewenode @Marc Berg last edited by

                          @marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:

                          Die enum assignments erscheinen jetzt sowohl beim base-Objekt als auch bei allen alias target objects korrekt.

                          Grad mal reingeschaut. Das sieht perfekt aus! Da fällt mir erstmal nichts mehr ein👍 😀

                          R 1 Reply Last reply Reply Quote 0
                          • R
                            rewenode @rewenode last edited by

                            @Marc-Berg Ich hab da mal eine prinzipielle Frage

                            Ich habe jetzt mal etwas intensiver mit den nodes von einem externen NR gespielt. In meine Beispiel versuche ich mich gerade mit dem Dashboard 2 vertraut zu machen. Besonders die Verwendung von Subflows vereinfachen die Arbeit ungemein.
                            Mein Test sieht etwa so aus:
                            2025-07-14_08-31-13.png
                            Hier habe die WS-ioB-nodes alle in den Subflow gepackt, was den Hauptflow extrem vereinfacht.
                            Natürlich sind hier auch andere Szenarien denkbar.
                            Man könnte auch die zu abonnierenden states über einen einzelnen externen WS-ioB-IN realisieren, und die Daten den Subflow-Instanzen extern zuführen.

                            Was ich mich frage:
                            Wie verhalten sie diesbezüglich eigentlich die WS-ioB in Bezug auf Speicher/Performance?
                            Will fragen, was ist besser, die states einzeln zu abonnieren oder alle in einem node zu abonnieren.
                            Dabei lass ich mal außer acht, dass der externe Aufwand im Falle von mehreren states pro WS-ioB-IN steigen wird, weil die Daten i.d.R. wieder auseinanderklamüsert werden müssen.

                            In meinem Test mit den 3 Instanzen des Subflows gibt es keinerlei Probleme. Bin nach wie vor von den WS-ioB nodes begeistert.

                            Marc Berg 1 Reply Last reply Reply Quote 0
                            • Marc Berg
                              Marc Berg Most Active @rewenode last edited by Marc Berg

                              @rewenode sagte in Node-RED Nodes für externe ioBroker Integration:

                              Was ich mich frage:
                              Wie verhalten sie diesbezüglich eigentlich die WS-ioB in Bezug auf Speicher/Performance?
                              Will fragen, was ist besser, die states einzeln zu abonnieren oder alle in einem node zu abonnieren.

                              Speichertechnisch dürfte der "MultipleStates" Ansatz Vorteile bringen. Wenn ich das mal grob überschlage:

                              100 einzelne Nodes:

                              100 × Node-Instanz ≈ 100 × 5KB = 500KB
                              100 × Callback-Handler ≈ 100 × 1KB = 100KB
                              100 × State-Tracking ≈ 100 × 0.5KB = 50KB

                              Summe: ~650KB
                              ─────────────────────────────────────────

                              1 Multiple States Node:

                              1 × Node-Instanz ≈ 5KB
                              1 × Callback-Handler ≈ 1KB
                              100 × State-Tracking ≈ 50KB

                              Summe: ~56KB
                              ─────────────────────────────

                              Und auch die CPU-Belastung düfte etwas geringer ausfallen.

                              Ob in heutigen Hardware-Szenarien das wirklich relevant ist und den Mehraufwand rechtfertigt, muss man entscheiden.

                              In meinem Test mit den 3 Instanzen des Subflows gibt es keinerlei Probleme. Bin nach wie vor von den WS-ioB nodes begeistert.

                              Freut mich. Ich habe meine Prod umgestellt (noch ohne Optimierungen auf Basis der neuen Möglichkeiten), mit 600 Nodes (davon ca. 180 ioBroker WS Nodes) dümpelt der Container bei ca. 100MB und 0.1-0.2% CPU dahin.

                              In Summe (vor und nach der Umstellung) sehe ich keinen Unterschied bei Memory und CPU. Das geht im Grundrauschen unter.

                              R 1 Reply Last reply Reply Quote 0
                              • R
                                rewenode @Marc Berg last edited by

                                @marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:

                                Ich habe meine Prod umgestellt (noch ohne Optimierungen auf Basis der neuen Möglichkeiten), mit 600 Nodes (davon ca. 180 ioBroker WS Nodes) dümpelt der Container bei ca. 100MB und 0.1-0.2% CPU dahin.
                                In Summe (vor und nach der Umstellung) sehe ich keinen Unterschied bei Memory und CPU. Das geht im Grundrauschen unter.

                                Das klingt gut. Werde ich auch erst mal so machen. Falls es Engpässe gibt , kann ich ja immer noch nach Multistate umstellen.
                                In vielen Fällen ist das bei mir eh vorteilhafter. Ich arbeite ja nicht überall mit Subflows.

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post

                                Support us

                                ioBroker
                                Community Adapters
                                Donate

                                577
                                Online

                                31.9k
                                Users

                                80.1k
                                Topics

                                1.3m
                                Posts

                                communication node-red
                                5
                                83
                                1588
                                Loading More Posts
                                • Oldest to Newest
                                • Newest to Oldest
                                • Most Votes
                                Reply
                                • Reply as topic
                                Log in to reply
                                Community
                                Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen
                                The ioBroker Community 2014-2023
                                logo