change node reicht anscheinend msg.payload durch

[Fred Freund]

Hallo,
ich habe die schedex Node misbraucht um eine Toggle funktion zu machen. Diese funktioniert, aber manchmal muss man zweimal druecken um zu toggeln da sie den status vergisst.
Mir ist eingefallen das es einfacher geht:
Habe den STatus der Lampe abgefragt und moechte diesen invertieren.
Leider scheint es die change node gibt den retournierten Status der Lampe einfach durch.
Rechts im Debug sieht man die node ist die Gleiche fuer beide Debug Eingaenge.
ausserdem aendert sich true auf false nicht

Weiters habe ich eine Frage zur msg.reset , konnte nicht finden wie diese definiert ist.
ist die Payload dann reset?
Habe beim Trigger den reset jetzt mit der msg off geloest aber dennoch wuerde ich gerne wissen was
msg.reset ist ?

Wie immer herzlichen Dank!

[mickym]

@fred-freund
Kann beide Fragen beantworten.

1. Ja Du musst eine Nachricht mit der Eigenschaft msg.reset definieren - hat mit der payload nichts zu tun.

kannst Du natürlich auch mit einer Inject Node testen:

2. Du musst Dir grundsätzlich das Funktionieren der Change Node verstehen - das heißt alle Regel werden nacheinander abgearbeitet.

Was Du machst: Du änderst in der 1.Regel true = > false, dann wird die 2. Regel ausgeführt und Du änderst false => true und wunderst Dich dann, dass nichts passiert wenn true ankommt, false dürfte ja gehen, da dann ja nur die 2. Regel ausgeführt wird. Also Dein Titel, dass die Change Node, reicht nicht durchreicht ist deshalb völlig falsch. Sie arbeitet hingegegen so wie Du das definiert hast und übt eine doppelte Verneinung aus. - sozusagend: nicht (nicht richtig) = richtig

Entweder Du sicherst ein Status weg - geht auch indem Du den Typ änderst.
Also true => false (string), dann false in true und dann false (string) in true.
Noch einfacher geht es allerdings bei booleans:
Einfach statt Change ein Set auf einen JSONATA Ausdruck, in dem Du den eingehenden Status einfach verneinst. Das macht man mit $not(payload) wie folgt:

[Fred Freund]

@mickym Danke!

UI, dachte die change ist ein if then else nicht eines nach dem anderen

JSonata hab ich schon gelesen das das maechtig ist...

Danke nochmals, werde mir das LERNEN
LG und schoenen Abend

[mickym]

@fred-freund Wenn Du in den JSONATA Nodes auf die 3 Punkte klickst - bekommst Du eine Funktionsreferenz mit einer kleinen Erklärung. Ansonsten kannst Du die mathematische Operatoren verwenden bzw. mit & strings miteinander verketten.

[Fred Freund]

@mickym Danke...cool

Weiss jetzt natuerlich warum meine anderen change multi-nodes funktionierten..da viel in string auf bolean und wieder zureuck gingen ....

Also der schedex als toggle Befehl hatte auch seine Vorteile : wenn das licht mit dem Sensor eingeschaltet wurde und der Trigger resetted wurde blieb das licht an ,, da schedex dachte es ist ja AUS...
also ein Befehl Ein und Reset

jetzt da der Status abgefragt wird geht die Lampe natuerlich aus ...cancled die zeitliche Abschaltung und muss wieder Ein geschalten werden.

[mickym]

@fred-freund Du musst halt aufpassen, dass Du Deine Logik auch noch in mehreren Monaten verstehst und es ist immer etwas problematisch, wenn man verschiedene Logiken auf das gleiche Device anwendet.

Ich kenne das schedex nicht - hab mir mal kurz die Beschreibung angeschaut. Mit dem Toggle Befehl in dem schedex schaltest ja auch nicht die Lampe, sondern Deinen manual Zustand ein oder aus.

Ich nutze inzwischen 3 andere Scheduler - alle mit bestimmten Vor- und Nachteilen, Ich glaube der schedex ist fast identisch mit meinem eztimer. Du kannst Dir auch noch den light scheduler anschauen, den kann man zwar nicht von aussen konfigurieren, aber man kann sehr komfortabel wöchentliche AN AUS Intervalle eingeben und auch genial, der liefert Dir noch eine filter Node - die nichts direkt rausschickt, aber Deine Nachrichten zeitabhängig durchlässt.

Das heißt Du schaltest das Licht nicht über den Scheduler, sondern über den Bewegungsmelder, Lichtsteuerung und was auch immer. Mit der Filternode anschließend kannst Du dann zustätzlich über die Zeit steuern. Also eigentlich Bewegung - schalte Licht an - nein doch nicht, da ja 12 Uhr mittags.

Noch ein Wort zur Change Node.

If then Abfragen macht man eher mit der Switch Node.

Die Change Node ist bewußt kein if - then node, da Du viel mehr als Ändern machst. Du veränderst (wie in JSONATA), selektierst via RegEX, setzt Variablen usw. - Es ist eigentlich ein kleines Unterprogramm ohne dass Du eine Zeile schreiben musst.

[Fred Freund]

@mickym Also den light scheduler hatte ich schon auf dem Radar...jedoch hab ich mich fuer die fuer mich einfachere Method entschieden...schedex

im Prinzip ist eine Funktion schreiben zu koennen super genuegend.
Benutze moementan viel die switch nur um True auszufiltern da diese Druckschalter true/false immer liefern.

naechster Schritt ist jetzt mich ein mal fuer eine Visualisierung zu entscheiden ...Vis,.Material Vis oder Dashboard.

Vielen Danke fuer Deine Muehe und Zeit!!

[mickym]

@fred-freund Eine Meinung muss ich doch noch zum Besten geben. Vermeide "function" Nodes soweit wie möglich. Alles in Function Nodes zu verstecken und herkömmlich zu programmieren, macht den Sinn und die Vorteile die dieses einzigartige System bietet zu nichte. In einer Function Node ist es wesentlich schwerer zu debuggen.

Jedenfalls würde ich für solche Aktionen - die Du als Code implementiert hast , nie function Nodes benutzen.

Zu Deiner Visualisierung kann ich nur sagen, dass Du Dich nicht entscheiden musst, sondern man kann Beides nutzen.
Das Node-Red Dashboard ist superschnell um etwas zu steuern und schnell Ergebnisse zu erreichen. Vis hingegen ist für optisch anspruchsvolle Visualisierungen besser geeignet. Bei VIS gestaltest Du also zu erst und platzierst dann Deine Schalter - mit dem Dashboard möchtest Du möglichst schnell Deine Geräte steuern und legst nicht soviel Wert auf Optik.

Ich habe 95% im Dashboard - aber habe mal angefangen so eine animierte Grundrisssteuerung im VIS realisiert.

Hier siehst Du meine Hauptseite im NodeRed Dashboard und eingebette mein animierter Grundriss in VIS. Und hier mal die Hauptseite im Dashboard und ein weiteres Beispiel zur Heizungssteuerung.

[Fred Freund]

@mickym
Bin fuer jede Zeile Erklaerung Dankbar!
echt liege ich so falsch mit der Benutzung der Funktion?
Muss mir das ansehen wie ich das anders machen koennte ...aber ich dachte das kuerzt den Code ab und wuerde den Flow verkuerzen welches sicher das Ziel ist ??

[mickym]

@fred-freund Hier mal das was Du mit Deiner Function Node machst als Flow:

Was ist übersichtlicher? - Wo kannst Du leichter sehen, wenn was falsch läuft? Nein in meinen Augen ist nicht das Ziel den Flow zu verkürzen, sondern ihn einfach und logisch darzustellen um auch schnell zu sehen, wie der Fluß der Nachrichten verläuft. Alles was in einer Function Node abläuft mit allen If und Thens und was weiß ich sind ja auch alles Flows, die in der function Node versteckt werden.

Machen allerdings viele. Wenn Du sowas verkürzen willst, weil Du sowas immer wieder brauchst, könntest Du obigen Flow auch in einen Subflow packen . und dann hast nur noch eine Node und kannst quasi immer alle Werte um 10 erhöhen bis max. 100!!

Hier kannst mal importieren - ist der Flow nur ohne Function Node:

Spoiler

[
   {
       "id": "756912e2.cd6a9c",
       "type": "change",
       "z": "dce8fa20.2e93c8",
       "name": "erhöhe um 10",
       "rules": [
           {
               "t": "set",
               "p": "payload",
               "pt": "msg",
               "to": "payload +10",
               "tot": "jsonata"
           }
       ],
       "action": "",
       "property": "",
       "from": "",
       "to": "",
       "reg": false,
       "x": 580,
       "y": 2460,
       "wires": [
           [
               "6b758fb5.08ea3"
           ]
       ]
   },
   {
       "id": "6b758fb5.08ea3",
       "type": "switch",
       "z": "dce8fa20.2e93c8",
       "name": "> 100 ?",
       "property": "payload",
       "propertyType": "msg",
       "rules": [
           {
               "t": "gt",
               "v": "100",
               "vt": "str"
           },
           {
               "t": "else"
           }
       ],
       "checkall": "true",
       "repair": false,
       "outputs": 2,
       "x": 790,
       "y": 2460,
       "wires": [
           [
               "8f9eb523.74b008"
           ],
           [
               "b1c726aa.a715a8"
           ]
       ]
   },
   {
       "id": "8f9eb523.74b008",
       "type": "change",
       "z": "dce8fa20.2e93c8",
       "name": "wenn > 100 setze 100",
       "rules": [
           {
               "t": "set",
               "p": "payload",
               "pt": "msg",
               "to": "100",
               "tot": "num"
           }
       ],
       "action": "",
       "property": "",
       "from": "",
       "to": "",
       "reg": false,
       "x": 1010,
       "y": 2440,
       "wires": [
           [
               "b1c726aa.a715a8"
           ]
       ]
   },
   {
       "id": "b1c726aa.a715a8",
       "type": "debug",
       "z": "dce8fa20.2e93c8",
       "name": "Mach was !",
       "active": true,
       "tosidebar": true,
       "console": false,
       "tostatus": false,
       "complete": "payload",
       "targetType": "msg",
       "statusVal": "",
       "statusType": "auto",
       "x": 1210,
       "y": 2480,
       "wires": []
   }
]

Du kannst theoretisch nach einer IN -Node den ganzen Flow in eine function Node packen. Function Nodes machen oft Sinn wenn man zum Beispiel Zustände sichern muss ... aber selbst das ist nicht zwingend.

Ich habe diese Thematik hier schon mal aus meiner Sicht erläutert:

https://forum.iobroker.net/topic/40242/msg-payload-werte-auslesen/21?_=1615326063144

Dort siehst Du das Gleiche einmal mit EINER Funcion Node oder als Flow implementiert.

Die Stärke von Node Red ist, Deine Logik grafisch zu veranschaulichen und das machst Du mit Programmcode alles wieder kaputt.

[Fred Freund]

@mickym Ah ok, ich versehe , es ist also egal wie lange der Flow ist , es geht nicht darum ihn abzukuerzen.

Danke fuer deine ERklaerungen!

Also das Erhoehe um 10 ist super geloest...

[mickym]

@fred-freund Wie gesagt ich nutze auch function Nodes - aber je länger ich das System nutze, desto weniger brauche ich sie. Manchmal lasst es sich nicht vermeiden oder es wird unübersichtlich - gerade bei Schleifen oder Iterationen oder rekursiven Aufrufen.

[Fred Freund]

@mickym ""gerade bei Schleifen oder Iterationen oder rekursiven Aufrufen.""

ja fuer diese Dinge fehlt mir noch die Vorstellungskraft einer Loesung...aber aller Anfang ist schwer.

Bin froh das man hier mit Triggern arbeiten kann...

[mickym]

@fred-freund Bin gerade dabei - eine wiederverwendbare function Node zu basteln, um einen laufenden Durchschnitt pro Zeiteinheit zu basteln. Es gibt zwar die aggregator Node - aber ich brauch etwas um zum Beispiel den Stromverbrauch der letzten Stunde zu ermitteln und die soll sich immer ändern.

Ich hab zum Beispiel im Node Red eine Tasterfunktion zu entwickeln, die im VIS einen Hardwaretaster abbildet. - da habe ich dann auch eine function Node genutzt.

So sieht mein VIS Taster (mit Node Red) realisiert aus um wie ein Hardwaretaster für einen Dimmer zu funktionieren:

Tasterimplementierung Dimmer - vis - NodeRed.mp4

So hier gabs eine zentrale function Node - mit mehreren Ausgängen um einen langen Tastendruck von einem kurzen zu unterscheiden.

[Fred Freund]

@mickym ah cool...ja Tastendruck mit timer abfragen ...?? damit du entscheiden kannst lange oder kurz...

hab das fuer einen Arduino mal programmiert...mit taster....