Weihnachtsangebot 2025! 🎄

[eric2905]

Super - dann brauche ich am Wochenende nicht "basteln", sondern kann das Update ziehen.

Danke!

Gruß,

Eric

[nobody]

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

[nobody]

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

[apollon77]

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

[nobody]

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"

[apollon77]

Hi nobody,

ich hab die 0.12.5.

Das die RBE Node das kann hatte ich gesehen. Ist in meinen Augen aber halt was anderes als die Logiken die ich als nötig ansehe :-)

[nobody]

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.

[apollon77]

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 :-)

[nobody]

Gleichheit zum Vorwert oder zu einem konfigurierten festen Wert? Letzteres würde schon sinnvoll sein.

Gesendet von meinem SM-G900F mit Tapatalk

[apollon77]

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 ?!

[nobody]

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.

[apollon77]

Alles klar, dann versuche ich das mal so :-)

Danke!