NEWS
Node-Red: Node zum Abfragen eines ioBroker State im Flow
-
Hallo,
wenn man längere Zeit mit ioBroker und Node-Red arbeitet hat man gelegentlich den Wunsch, in einem Flow auf Werte aus ioBroker-States zuzugreifen.
Die ist zum Beispiel erforderlich, wenn man Konfigurationsparameter über VIS einstellbar machen möchte oder wenn mehrere Werte benötigt werden.
Der aktuelle Node-Red-Adapter bietet nur die Node-Typen in und out. Da der in-Node nur dann auslöst, wenn der State beschrieben wird, ist es relativ aufwendig, die Werte jeweils im context.global zwischenzuspeichern, damit diese dann im relevanten Flow verwendet werden können.
Ich habe in den beigefügten Dateien den bestehenden ioBroker-Node um einen zusätzlichen ioBroker get node erweitert.
Die beiden Dateien ersetzen die gleichnamigen im Verzeichnis````
:/opt/iobroker/node_modules/iobroker.node-red/nodesDieser kann als function-Node in einem normalen Flow eingebettet werden. im Bei den Einstellungen kann der Attribut-Name im zurückgegebenen msg-Objekt angegeben werden, damit man mehrere Attribute ohne umkopieren laden kann (Vorgabe msg.payload). Sollte Interesse an diesem Node-Typ bestehen, würde ich vorschlagen, die Änderungen in den Node-Red-Adapter zu übernehmen. Die Abbildung zeigt beispielhaft den Abruf einer größeren Anzahl von ioBroker states:   Mfg Markus -
Nochmal ich,
also zum Austauschen mit deiner Anleitung ist es Idiotensicher!
Hab sogar ich hinbekmmen :-)
Ich denke das wäre wirklich etwas zum Standart mäßigen einbinden.
Wie es sich in der Praxis verhält muss ich jetzt erst mal ausprobieren.
Kleines Problem habe ich aber jetzt schon….
siehe Bild
irgendwas ist da passiert bzw passt noch nicht ganz...
aber jetzt probiere ich es erst mal aus….
FETTES DANKE schonmal.
Tobi
-
Hallo Tobi,
danke für die Rückmeldung.
Scheint ein Bug in älteren node-red Versionen zu sein, dass man in der html-Datei das Icon alignment nur auf right, nicht aber explzit auf left setzen darf. Mit 0.12.4 und 0.12.5 war die Anzeige korrekt.
Ich hab im ersten Post die ZIP-Datei ausgetauscht. Kannst du die nochmal testen?
Klappt bei dir die Abfrage der Daten korrekt?
Ich hab in der neuen Version der iobroker.js auch maxListeners auf 100 gesetzt, weil mich die Warnmeldungen im Log bei jedem Start genervt hat, wenn man mehr als 11 iobroker Nodes verwendet hat.
Gruß
Markus
-
Hallo apollon77,
schön, dass auch das Team von node-red weiterentwickelt.
Wenn man sich unter https://github.com/node-red/node-red/bl … -switch.js die Änderungen anschaut, macht der neue switch node aber auch nichts anderes, als den letzten Wert im Node Objekt zwischen zu speichern. Somit kann er erstmal auch nicht mehr als der rbe node jetzt schon. Eigentlich sogar weniger, weil sich der Node immer den Wert der letzten msg speichert und nicht nur die, die tatsächlich weiter geleitet wurden. Somit taugt das schon nicht mehr für Abweichungen, da schleichende Änderungen dann zu keiner Weiterleitung führen.
Gesendet von meinem GT-N8000 mit Tapatalk
9656_20181220_1.jpg
9656_20181220_2.jpg -
Solche Prüfungen direkt in den iobroker in node einzubauen sollte eigentlich auch kein großes Problem sein.
Aus meiner Sicht sinnvoll wären die folgenden Optionen:
Auslösen nur bei bestätigten Werten (ack==true)
Auslösen nur bei Wert Änderungen zum letzten weitergeleiteten Wert.
Auslösen nur bei einer Mindeständerung zum letzten weitergeleiteten Wert analog rbe.
Optional Konvertierung von string nach boolean, int, float, datetime zur einfachen Weiterverarbeitung.
Ich kann die Erweiterung vornehmen, hab aber noch keine Ahnung, wann ich dazu komme.
Gesendet von meinem GT-N8000 mit Tapatalk
-
Hi,
wenn man das direkt einbauen kann cool :-) Da ich es nicht selbst kann warte ich gern bis es bei Dir passt.
Mir geht es (ok, neben dem ausprobieren ob man node-red so nutzen könnte das ich von ccu.io mit ScriptGUI zu iobroker mit node-red wechseln kann) auch darum für iobroker ein Featureset zu haben was denke auch anderen Nutzern hilft.
So wie ich es verstehe kann Switch dann schon ein bissl mehr als RBE, weil RBE aktuell nur "!=" kann … Switch kann von Hause aus ja auch die anderen Vergleichsoperatoren ...
-
Hi appollon77,
der rbe Node kann auch jetzt schon auf absolute und relative Abweichungen zum Vorwert prüfen. Nennt sich Deadband mode und kann über die Node-Eigenschaften konfiguriert werden.
In der aktuellen node-red-Version 0.12.5 ist das schon drin.
Der node-red-Adapter erzwingt zurzeit nicht die Version 0.12.5. Im zweifel muss man die manuell upgraden.
Deadband mode
In deadband mode the incoming payload should contain a parseable number and is output only if greater than + or - the band gap away from the previous output.
The deadband value can be specified as a fixed number, or a percentage. E.g. 10 or 5% . If % mode is used then the output will only get sent if the input payload value is equal or more than the specified % away from the previously sent value.
For example - if last sent value was 100, and deadband is set to 10% - a value of 110 will pass - then the next value has to be 121 in order to pass (= 110 + 10% = 121).
This is mainly useful if you want to operate across multiple topics at the same time that may have widely differing input ranges.
Will only accept numbers, or parseable strings like "18.4 C" or "$500"
-
Hi,
eine erweitere Version des node-red Adapters ist nun als pull Request auf github.
Man kann jetzt im in-Node auf acknowledge==true filtern und hat zusätzlich wie im rbe node die Möglichkeit auf Wertveränderung oder Mindestabweichung zu filtern.
Die Konvertierung des Datentyps ist nach nochmaliger Überlegung doch nicht so sinnvoll, weil insbesondere Boolean im Attribut payload sowieso wieder in String konvertiert wird.
-
Hi nobody, echt cool! Danke!
Denkst Du das weitere "Vergleichsoperatoren" noch sinn machen?
Was jetzt da ist ist "!=" (ala RBE) und "Abweichung mindestens X". Oder ist der Rest dann sinnvoll über die neuen "Switch"-Funktionen?
Ich denke das mindestens "==" noch Sinn macht auch wenn es RBE nicht hat :-)
-
Gleichheit zu festem Wert ist einfach per Switch machbar … von daher wäre es cool weil es ein Node spart, aber ob es Sinn macht weiss ich nicht.
Und ja ich habe gerade nochmal alle meine CCU.io Skripte durchgesucht und in nehme wirklich nur "bei Aktualisierung" und "bei Änderung" (!=) ... von daher passt so :-)
Update: Jain ... Am Ende wäre es manchmal Sinnvoll den Vorherigen Wert in der Message zu haben. Beispiel: Ich habe eine Anwesenheitserkennung gebaut nach einem Konzept was mal im HM-Forum beschrieben wurde. Das arbeitet mit einem Zähler und es sind auch Notifies drin zu Anwesenheit und Abwesenheit.
Ich habe hier die Logik drin das beim Wert 30 wenn der alte Wert <30 war (also der Wert wird gerade größer) ist es "Anwesenheit"... Wie kann ich das machen mit node-red? Da bräuchte man entweder Zugriff auf den "alten Wert" (per GetIoBrokerNode oder so?) oder ?!
-
Die Anforderung ist aus meiner Sicht schon so speziell, dass ich diese nicht mehr in einem in-Node sondern in einem function-Node sehe. Der Vergleich auf alterWert<30 setzt das Wissen über den alten Wert voraus, der aber nicht gesendet wurde. Für deathband wird aber genau der zuletzt weitergeleitete alte Wert benötigt.
Den zuletzt weitergegebenen Wert raus zu geben wäre technisch zwar möglich, würde aber ein wenig dem Konzept für in-Nodes widersprechen.
Die Logik im function-Node zu realisieren sind aber auch nur ein paar Zeilen JavaScript. Den alten Wert kann man ja einfach in context.global.[nameAlterWert] ablegen.
607
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge