Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[mickym]

@schmetterfliege Nein die Option hat nur die Datenpunkte in Strings beim Einlesen in NR gewandelt - hat aber die originalen Datenpunkte im iobroker nicht angefasst.

[Schmetterfliege]

@mickym

okay, danke! :)

[Schmetterfliege]

@mickym

Irgendwie scheint die Option alles in Strings zu verwandeln keine Wirkung gehabt zu haben.
Hier mal ein Beispiel, bei dem ich aus einer iobroker get node den Wert vom DP "occupancy" auslese.
In iobroker ist das definitiv ein Bool.
Mein Flow sieht so aus:

Ich lese alles aus, splitte es und je nach Datenpunkt dann in eine andere Funktion.
Die Funktionen sehen alle so aus:

Bei der Occupancy prüft der Switch dann Bool werte:

Und der Output wird dann an ein Template übergeben, das so aussieht:

Das funktioniert auch definitiv.
Wäre in dem Flow mein Bool Wert in einen String verwandelt worden, wäre das dann nicht an dem Switch der auf Bool prüft gescheitert? Oder ist es dem Switch egal ob das ein String oder Bool ist?

[mickym]

@schmetterfliege Das Problem ist leider bei dem Boolwerten immer, dass die implizit gewandelt werden. Sprich alle Strings werden als wahr interpretiert - lediglich 0 ist dann false. Wie gesagt überprüfe halt mit einer Debug Node was rauskommt.

Die sagt Dir auf jeden Fall immer welcher Datentyp rauskommt, so dass man sich darauf im weiteren verlassen kann:

[mickym]

@schmetterfliege Und wenn ich Deinen Flow so anschaue - also das Pollen ist unsinnig und belastet nur Dein System. Benutze iobroker -In Nodes die Triggern wenn sich was ändert - Du musst doch nicht alle 10 min fragen - und ausserdem bekommst ja dann gar nichts mit, innerhalb der 10 Minuten? Warum machst Du so was? Du nimmst ja die Vorteile, dass iobroker Dich aktiv über Zustandsänderungen informiert gar nicht wahr. Gerade bei Bewegungsmeldern ist ja der letzte Status überhaupt nicht wichtig.

[Schmetterfliege]

@mickym
Das war nur zur Veranschaulichung. Die eigentlichen Flows sehen so aus:

Die iobroker nodes sind alles list nodes.
Aber ja, die durch "in" nodes zu tauschen macht wahrscheinlich Sinn.
Zur Sicherheit, wäre dieser Tausch richtig?:

Ersetzen durch:

[mickym]

@schmetterfliege Im Prinzip ja - ich frag mich nur, warum Du immer die Objekte ausliest - bei den List Nodes geht es nicht anders - aber ansonsten ist das doch ebenfalls totaler Overhead - ich lese nur die Werte - bei den list Nodes gehts nicht anders aber in der Regel braucht man wie gesagt nur in Nodes und Wert. Ok aber in Deinem Subflow wirst wahrscheinlich dann auf payload.val auswerten.

[Schmetterfliege]

@mickym
Naja, bei den Multisensoren lese ich aktuell zb am meisten aus:
Verfügbarkeit, Hum, Temp und Volt.
So brauche ich nur eine Node und jage den Output durch 1 Subflow.

Wenn ich nur die Werte auslese, müsste ich für jeden Multisensor 4 eigene "flows" (keine Ahnung wie ein "Prozess" in einem Flow heißt^^) machen, oder?
Ich bastel mal die Alternative mit den Werten statt Objekten, dann kannst du mir ja sagen ob das richtig wäre :)

[mickym]

@schmetterfliege Nein - wenn Du

enthält die payload direkt den Wert. Allerdings geht dann der Auslesen zu Beginn nicht. Aber das triggern geht so.

Du musst halt wenn Du den Status einmal auslesen willst, nach Deiner List die payload.val in payload wandeln und dann kannst Du in Deinem subflow die payload direkt verarbeiten.

[Schmetterfliege]

@mickym

Das umwandeln von .val in payload mache ich ja im Subflow. Das Bild mit den ganzen Functions und dem Switch und split war der Inhalt vom Subflow.

Hab das jetzt mal mit IN nodes gemacht, das würde dann so aussehen im Vergleich:

Das Ergebnis wäre das gleiche, soweit ich das Beurteilen kann:

Was wäre denn für mein Raspi leistungstechnisch besser?
Die Subflows wäre ich dann alle los, finde das aber wenn man pro Flow 4 Sensoren hat irgendwie unübersichtlich, weil dann in jedem Flow 16+ IN nodes wären, statt 4 List Nodes :D

[mickym]

@schmetterfliege trotzdem ist das aber die beste Lösung - wenn Du nämlich ohne Wildcards in den in Nodes arbeitest, kannst Du auch zu Beginn auslesen und damit Dein Dashboard initialisieren. Und sind wir mal ehrlich, wenn Du für jede Ausgabe eine Node hast, dann kann man auch jeder Eingabe eine Node spendieren und dies 1:1 zuordnen.

Und bezgl. Übersichtlichkeit - da gibt es die tolle Gruppenfunktion im Node Red

[Schmetterfliege]

@mickym

Wegen dir schmeiße ich noch sämtliche Flows um :D :D
Aber geschuldet der Tatsache dass dein Knowhow mein KnowHow um das 10.000-fache Übersteigt, mache ich das jetzt einfach mal für alle Sensoren in allen Flows!

Meine Subflows sind eh ein bisschen eskaliert...

[mickym]

@schmetterfliege Na dann bleiben ja trotzdem noch einige übrig. ;)

[Schmetterfliege]

@mickym

ist mir auch grade aufgefallen - im Prinzip fällt ja nur der raus der alle Zigbee Datenpunkte verarbeiten kann

[Schmetterfliege]

@mickym
Doofe Frage:
Ich wills mir einfach machen und per notepad die ganzen Nodes erstellen, statt alle einzeln zu setzen und konfigurieren.
Das hier ist der Export von einer IN node:

[
    {
        "id": "ea926d2c.f64e5",
        "type": "ioBroker in",
        "z": "9e290e9e.6c0fb",
        "name": "",
        "topic": "zigbee.0.00158d0005221c37.available",
        "payloadType": "value",
        "onlyack": "",
        "func": "all",
        "gap": "",
        "fireOnStart": "true",
        "x": 490,
        "y": 700,
        "wires": [
            []
        ]
    }
]

Reicht es wenn ich da einfach "topic" entsprechend setze, oder sind ID und Z auch relevant?

[mickym]

@schmetterfliege Die sind auch relevant - jede Node hat eine eigene ID. ;) Du kannst aber statt jedes Mal das Topic über das Fenster zu selektieren den Pfad aus dem iobroker kopieren und in die Node kopieren.

[mickym]

@schmetterfliege Du kannst aber auch gleich alle x Nodes kopieren und dann das topic im Editor editieren. Du musst halt nur die entsprechende Zahl an Nodes haben.

Also 4 InNode (occupancy, battery, available, ..) - die dann x Mal kopieren und dann im Editor die zigbee ID editieren. Generell würde ich aber dann lieber nodepad++ nehmen - du weisst ja dass Windows zu jedem LF noch ein CR oder umgekehrt anhängt.

[Schmetterfliege]

@mickym

Das mit aus Iobroker in die Node kopieren ist ja genau das was ich umgehen möchte, dann sitze ich ja noch morgen dran^^
Habe zumindest mal alle Pfade in eine Excel Liste gepackt und kann da easy für alle Geräte die entsprechenden Topics generieren.
Aber der copy-paste part.... uff.

Aber das mit Nodes erstellen, exportieren, in Notepad ändern und importieren ist auf jeden Fall eine gute Idee.

Notepad++ nutze ich auf jeden Fall dafür!
Aber was ist LF und CR?

[mickym]

@schmetterfliege LF = Line Feed, CR = Carriage Return

https://stackoverflow.com/questions/6521685/why-does-windows-use-cr-lf

[mickym]

@schmetterfliege sagte in Verfügbarkeit von Sensoren über Node Red überwachen:

@mickym

Das mit aus Iobroker in die Node kopieren ist ja genau das was ich umgehen möchte, dann sitze ich ja noch morgen dran^^
Habe zumindest mal alle Pfade in eine Excel Liste gepackt und kann da easy für alle Geräte die entsprechenden Topics generieren.
Aber der copy-paste part.... uff.

Aber das mit Nodes erstellen, exportieren, in Notepad ändern und importieren ist auf jeden Fall eine gute Idee.

Notepad++ nutze ich auf jeden Fall dafür!
Aber was ist LF und CR?

Das war nicht meine Absicht, dass Du nun alle Flows umschmeisst. Gibt ja oft viele Wege. die zum Ziel führen. Meine Flows die ich am Anfang gemacht habe, würde ich heute auch anders machen - aber solange es funktioniert bin ich zu faul. ;)