Node-RED Nodes für externe ioBroker Integration

[Marc Berg]

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

Ich bin gerade dabei, die diversen Funktionen (ioBroker, node-red, mariadb, etc.) auf einzelne ProxMox Nodes zu migrieren. Angefangen hab ich jetzt mit node-red und die Flows übersiedelt. In diversen Scripten musste ich natürlich Anpassungen vornehmen, aber jetzt laufen alle Flows am externen node-red.

Super! Ab besten jetzt noch fleißig testen, in zwei Wochen befinde ich mich eine Weile in einer praktisch internetfreien Zone.

[rewenode]

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

einer praktisch internetfreien Zone.

Genieß das, solange es da noch welche gibt

[SabineT]

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

Super! Ab besten jetzt noch fleißig testen, in zwei Wochen befinde ich mich eine Weile in einer praktisch internetfreien Zone.

Bis jetzt laufen alle Flows, so wie sie sollen. Hab inzwischen die Node-Red Instanz von IOB gestoppt...

[Marc Berg]

Die Version 1.1.0 bringt ein paar Erweiterungen, Verbesserungen und Fixes. Die kompletten Änderungen im Changelog, hier die Kurzform:

• Der iob-out Node kann jetzt benutzerdefinierte Timestamps setzen

Damit ist es ganz einfach möglich, komplette Zeitreihen in die History-Adapter zu schreiben.

• Custom Settings erstellen

Der iob-out Node kann nun bei der Objekterstellung auch Custom Settings wie History-Adapter oder MQTT-Client am Datenpunkt konfigurieren.

• UI wurde aufpoliert

Die Tree View scrollt automatisch zum ausgewählten State, zeigt den aktuell gewählten State direkt an und sieht insgesamt etwas aufgeräumter und kompakter aus. Die Konfiguration des iob-out Nodes wurde auf zwei bis drei Tabs verteilt.

• Performance-Verbessung beim Laden der Tree View

Es gab Probleme beim Laden von großen Objektlisten. Die Menge der übertragenen Daten wurde auf das unbedingt Notwendige reduziert. Danke an @MCU für's Testen.

• Fehler beim Subscribe

Gab es überlappende Subscriptions mit Wildcards, so konnte es (z.B. nach einem Neustart des ioBroker) dazu kommen, dass diese doppelt auslösten. Der Fehler ist beseitigt.

• Konsequente Benennung

Teilweise wurde noch "Adapter" verwendet, wo "Instanz" gemeint war. Das wurde bereinigt.

Darüber hinaus habe ich die Dokumentation überarbeitet, hier sollten langsam hoffentlich keine Fehler mehr drin sein.

Viel Spaß und Erfolg damit!

[rewenode]

@marc-berg Und läuft wie geschmiert
Ich hätte da mal ne Frage zum history.
Wäre es möglich, den cache Mechanismus auch hier einzubauen?
Bei Verwendung von charts in DB2 ist es schon nervig, dass das chart bei jedem Seitenwechsel leer ist.
Ich habe mir externes chaching drumrum gebastelt und das läuft auch. Ich dachte nur wo du das so genial im iob-In gelöst hast, könnte das vlt. auch im iob-history sehr hilfreich sein.

[Marc Berg]

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

Bei Verwendung von charts in DB2 ist es schon nervig, dass das chart bei jedem Seitenwechsel leer ist.

Das ich kann leider nicht nachstellen. Wenn ich einen Standard-DB2 Chart Node hernehme, so werden die Daten so lange gespeichert, bis Node-RED neu gestartet wird. Da kann ich Seiten wechseln, wie ich will. Hast du mal ein Mini-Flow für mich, in welchem das auftritt?

[rewenode]

@marc-berg Willkommen zurück Ich versuche das nochmal nachzustellen. Inzwischen habe ich da ein eigenes Custom Chart mit Echart gebastelt, weil ich da ein paar Sachen haben wollte, die ich mit dem Standard-Chart nicht hin bekommen habe (Y-Achse links und rechts bei 2 Kurven, min/max Markline)
Da hab ich das gleiche Problem. Kann also durchaus sein, dass das ein hausgemachtes Problem ist.

[SabineT]

@Marc-Berg Ich habe heute mal über den Palettenmanager von 0.15.2 auf 1.1.1 upgedated, danach ist aber die CPU-Auslastung gewaltig in die Höhe geschossen:

Ich hatte da dann nochmal Node-RED neu gestartet, daher die Zacken.
Anbei der Flow, der vermutlich die Probleme verursacht:
flows.json
Dabei wird bei der iob-out Node rechts in der Mitte unter der Node ein Text angezeigt, der so schnell wechselt, dass man nicht wirklich etwas lesen kann, obwohl nur alle paar Sekunden von den Shellies etwas über MQTT als Input daher kommt. Mit der alten Version ändert sich der Text auch eben nur alle paar Sekunden.
Hier mal ein Beispiel, was in die iob-out Node geschickt wird: debug.json
Ich bin jedenfalls wieder auf die alte Version zurück gegangen (dank Proxmox geht das recht einfach).

[rewenode]

@marc-berg Ja, das war wohl mein Fehler im EChart. Liegt an meinem vue-code im html-Template.
Das Problem liegt daran, dass beim Unmounting die Daten zwar im chartData gespeichert werden, aber diese Daten beim erneuten Mounting verloren gehen - der chartData Proxy ist dann wieder leer.
Ich hab das nicht hinbekommen. Jetzt hat mir Cloude eine localStore-Lösung reingebastelt Das sieht sehr gut aus. Jetzt muss ich nur noch Testen, ob meine restliche Funktionalität erhalten geblieben ist.
Ist schon irre, was die LLMs so können. Ich habe von vue noch keinen Schimmer. Das wird Wochen dauern, bis ich da so einigermaßen durchgestiegen bin.
Na jedenfalls brauche ich jetzt kein externes Caching mehr für den history Adapter.

[Marc Berg]

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

Dabei wird bei der iob-out Node rechts in der Mitte unter der Node ein Text angezeigt, der so schnell wechselt, dass man nicht wirklich etwas lesen kann,

Wenn der Text schnell wechselt, dann wird der Node wahrscheinlich mit ständig wechselnden Daten beschossen. Ich kann das unmöglich nachstellen, ohne deinen Mosquitto und die Shellies. Ich weiß nicht mal, welcher der beiden Out Nodes der "in der Mitte" sein sollte.

Ohne Debug-Log komme ich da nicht weiter. Am besten einen Debug-Node vor den / parallel zum Out Node klemmen und mal die Ergebnisse posten. Oder alternativ das Debug-Log von Node-RED.

[SabineT]

@marc-berg ich hab jetzt mal mit beiden Versionen Logfiles mittels flogger (die rosa nodes im Bild unten) mit geschrieben. Dabei verhält sich seltsamerweise die mqtt-in node "shellies/+/status/#" anders, wenn ich deine aktuelle node-red-contrib-iobroker Version installiere. Es geht hier um den mit der Ellipse eingekreisten Teil des Flows:

Hier die Logfiles mit der alten Version:
mqtt-in: input-old.log
iob-out: iob-out-old.log

Und hier mit deiner aktuellen Version:
mqtt-in: input-new.log
iob-out: iob-out-new.log

Ich verstehe da einfach nicht, warum mit dem Update von node-red-contrib-iobroke auf 1.1.1 sich dann die mqtt-in node anders verhält. Die sollte sich ja durch das Update nicht ändern.

[Marc Berg]

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

Ich verstehe da einfach nicht, warum mit dem Update von node-red-contrib-iobroke auf 1.1.1 sich dann die mqtt-in node anders verhält. Die sollte sich ja durch das Update nicht ändern.

Ehrlich gesagt verstehe ich es auch nicht. Zwischen 0.15.2 und 1.1.1 gab es keine signifikanten Änderungen, die eine Erklärung liefern könnten, und Auswirkungen auf den MQTT Node kann ich ausschließen.

Scheinbar gibt es ja nun eine Schleife, die die hohe Last hervorruft. Du abonnierst ziemlich breit unter "shellies", machst im Subflow eine Zauberei und schreibst unter "userdata_0." Datenpunkte. Über irgendeinen Mechanismus gibt es wieder eine Rückkopplung zu "shellies".

Vielleicht könntest du mal folgendes testen:

• auch mal die Zwischenversionen kleiner 1.1.1 installieren: https://github.com/Marc-Berg/node-red-contrib-iobroker/releases
• die Objekterstellung in iob-out abschalten
• die anderen relevanten Flows einen nach dem anderen deaktivieren, um auszuschließen, dass die Schleife daher kommt.

EDIT: es betrifft die Topics shellies/+/status/+/command und damit auch shellies/+/status/+/output

[SabineT]

@marc-berg nach einigem herumprobieren tuts jetzt auch mit der aktuellen Version!

Die Änderung im Verhalten war zwischen 1.0.2 und 1.1.0. Irgendwie reagiert da ab 1.1.0 der MQTT-Teil der objects offenbar anders, ich hatte ja in meinem Flow nichts geändert. Das Konstrukt mit dem Subflow hab ich übrigens aus dem Forum (glaub von @mickym, bin mir aber nicht sicher).

Wobei das eigentliche Problem die eigenwillige Ansteuerung der Shellies über MQTT ist. Die verwenden bei Schalten z.B. "on" und "off", iQontrol verwendet aber true/false.
Bisher hatte ich da beim jeweiligen output object dann den Wert über MQTT gepublisht, weil der true oder false ist wärend command eben den String erwartet, wobei ich aber "changes only" aktiviert hatte.

Wenn ich jetzt die object Liste im ioBroker abschaue, ändert sich aber der Zeitwert für "Letzte Änderung" auch bei Objekten, die nicht geändert werden. Im changelog für 1.1.0 schreibst du da "lc (last changed) always uses current time". Meiner Meinung nach sollte lc aber nur geändert werden, wenn sich der Wert des objects auch geändert hat!

Jetzt hab ich aber den iQontrol-Teil vom output object erweitert (Target-Value-List) und wandle da true/false in "on"/"off" um und schicke den Wert an das command object.

Jedenfalls ist die CPU-Auslastung jetzt auf mit 1.1.1 im normalen Bereich!

Danke für deine Mithilfe und deine Intergration!

[Marc Berg]

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

Wenn ich jetzt die object Liste im ioBroker abschaue, ändert sich aber der Zeitwert für "Letzte Änderung" auch bei Objekten, die nicht geändert werden. Im changelog für 1.1.0 schreibst du da "lc (last changed) always uses current time". Meiner Meinung nach sollte lc aber nur geändert werden, wenn sich der Wert des objects auch geändert hat!

Kopf --> Tisch!

Mit der Einführung der manuellen Anpassbarkeit des "ts" habe ich das mit einbaut, was natürlich in 99% aller Fälle so nicht gewünscht ist. Die V1.1.2 hat den Fix. Danke für's Herausfinden.

[SabineT]

@marc-berg danke für die schnelle Korrektur! Hab eben das update eingespielt.