NEWS
Node-RED Nodes für externe ioBroker Integration
-
@Marc-Berg Vielleicht denke ich hier zu kompliziert.
Ich möchte per dashboard universelle Cards verschiedener Devices erstellen.
Beispiel:
Eine Tasmota - Steckdose mit Strommessung:
So eine Steckdose hat bei mir i.d.R 2 aliases: energy, power (können je nach devices auch mehr sein)
Um wirklich alle Daten auf der Card verwenden zu können, benötige ich also Die alias-daten sowie die state-daten von target und alias.
Die allermeisten Infos bekomme ich per WS ioB getObj bzw. WS ioB in wenn ich live Daten brauche.
Die state-daten des alias sind auch nicht problematisch, das sind wenige und dank WS ioB history sind die charts auch kein Problem.
Anders ist das mit den states des target.
Im Moment hole ich mir diese nach dem WS ioB getObj mit$.objects.$keys()in ein Array und muss die dann nacheinander irgendwie per WS ioB get holen.
In einem Rutsch geht das nicht, weil der WS ioB get nur singe-state macht. Ideal wäre wenn der WS ioB get genauso arbeiten würde wie der WS ioB in nur halt nicht automatisch.@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Ideal wäre wenn der WS ioB get genauso arbeiten würde wie der WS ioB in nur halt nicht automatisch.
Ich glaube, ich verstehe die Anforderung noch nicht. Geht es darum, dass die Topics dynamisch zusammengebaut werden müssen? Wenn nicht, könnte man den "-in" Node mit Trigger nutzen, oder?
-
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Ideal wäre wenn der WS ioB get genauso arbeiten würde wie der WS ioB in nur halt nicht automatisch.
Ich glaube, ich verstehe die Anforderung noch nicht. Geht es darum, dass die Topics dynamisch zusammengebaut werden müssen? Wenn nicht, könnte man den "-in" Node mit Trigger nutzen, oder?
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
Geht es darum, dass die Topics dynamisch zusammengebaut werden müssen?
Nicht ganz. Ich habe einen Subflow. Der gibt im Prinzip alle Informationen zu einem Device zurück.
Die states (target und alias) würde ich dann gern abonnieren. Jetzt hab ich sie mal per iob-get geholt (unteres Rechteck). Das ist aber suboptimal.
Abonnieren kann ich sie nicht. Dazu müßte ich dem iob-in ja irgendwie die IDs injizieren können, wie ich das beim iob-get kann. -
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Ideal wäre wenn der WS ioB get genauso arbeiten würde wie der WS ioB in nur halt nicht automatisch.
Ich glaube, ich verstehe die Anforderung noch nicht. Geht es darum, dass die Topics dynamisch zusammengebaut werden müssen? Wenn nicht, könnte man den "-in" Node mit Trigger nutzen, oder?
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
Wenn nicht, könnte man den "-in" Node mit Trigger nutzen, oder?
Da weis ich jetzt nicht wie du das meinst. Um den Trigger zu nutzen, muss der -in ja erst einmal da sein. Oder?
-
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
Geht es darum, dass die Topics dynamisch zusammengebaut werden müssen?
Nicht ganz. Ich habe einen Subflow. Der gibt im Prinzip alle Informationen zu einem Device zurück.
Die states (target und alias) würde ich dann gern abonnieren. Jetzt hab ich sie mal per iob-get geholt (unteres Rechteck). Das ist aber suboptimal.
Abonnieren kann ich sie nicht. Dazu müßte ich dem iob-in ja irgendwie die IDs injizieren können, wie ich das beim iob-get kann.@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Abonnieren kann ich sie nicht. Dazu müßte ich dem iob-in ja irgendwie die IDs injizieren können, wie ich das beim iob-get kann.
Muss ich mal drüber nachdenken, wie (und ob) ich das lösen kann. Und ob es für diese Fälle eine universelle Lösung benötigt.
-
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Abonnieren kann ich sie nicht. Dazu müßte ich dem iob-in ja irgendwie die IDs injizieren können, wie ich das beim iob-get kann.
Muss ich mal drüber nachdenken, wie (und ob) ich das lösen kann. Und ob es für diese Fälle eine universelle Lösung benötigt.
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
Muss ich mal drüber nachdenken, wie (und ob) ich das lösen kann.
Wenn ich da irgendwie hilfreich sein kann...
-
@Marc-Berg Vielleicht denke ich hier zu kompliziert.
Ich möchte per dashboard universelle Cards verschiedener Devices erstellen.
Beispiel:
Eine Tasmota - Steckdose mit Strommessung:
So eine Steckdose hat bei mir i.d.R 2 aliases: energy, power (können je nach devices auch mehr sein)
Um wirklich alle Daten auf der Card verwenden zu können, benötige ich also Die alias-daten sowie die state-daten von target und alias.
Die allermeisten Infos bekomme ich per WS ioB getObj bzw. WS ioB in wenn ich live Daten brauche.
Die state-daten des alias sind auch nicht problematisch, das sind wenige und dank WS ioB history sind die charts auch kein Problem.
Anders ist das mit den states des target.
Im Moment hole ich mir diese nach dem WS ioB getObj mit$.objects.$keys()in ein Array und muss die dann nacheinander irgendwie per WS ioB get holen.
In einem Rutsch geht das nicht, weil der WS ioB get nur singe-state macht. Ideal wäre wenn der WS ioB get genauso arbeiten würde wie der WS ioB in nur halt nicht automatisch.@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Ideal wäre wenn der WS ioB get genauso arbeiten würde wie der WS ioB in nur halt nicht automatisch.
Der iob-get Node wurde jetzt so angepasst, dass er als Input entweder:
- msg.topic = "single.state.id"
oder - msg.topic = ["state1", "state2", "state3"]
erwartet, oder den Output des "iob-getobject" Nodes. Und ihn so aufbereitet, um alle States (auch per Alias verknüpfte) auszuwerfen.
Der Output Mode des getObject Nodes muss dabei auf "Object Map" stehen.
- msg.topic = "single.state.id"
-
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Ideal wäre wenn der WS ioB get genauso arbeiten würde wie der WS ioB in nur halt nicht automatisch.
Der iob-get Node wurde jetzt so angepasst, dass er als Input entweder:
- msg.topic = "single.state.id"
oder - msg.topic = ["state1", "state2", "state3"]
erwartet, oder den Output des "iob-getobject" Nodes. Und ihn so aufbereitet, um alle States (auch per Alias verknüpfte) auszuwerfen.
Der Output Mode des getObject Nodes muss dabei auf "Object Map" stehen.
@marc-berg :+1: Is echt irre, wie fix du bist.
Habe mit der 15.1-3/-4 getestet. Arbeitet wie beschrieben.
Ein bug? ist mir beim WS ioB getObj aufgefallen. Wenn ich die StateID direkt im Node eingebe, wird das state Object erstellt.
Injiziere ich die als msg.topic ist das state Object null.
Also langsam ist es sicher Zeit, die 1.0 rauszubringen. Da muß man sicher erst mal die reichlichen neuen Möglichkeiten ausloten bevor neue Feature - Wünsche aufkommen.
Also mir fällt da erstmal nichts mehr ein, was es rechtfertigen würde, das du dir die Nacht... ;-) - msg.topic = "single.state.id"
-
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Ideal wäre wenn der WS ioB get genauso arbeiten würde wie der WS ioB in nur halt nicht automatisch.
Der iob-get Node wurde jetzt so angepasst, dass er als Input entweder:
- msg.topic = "single.state.id"
oder - msg.topic = ["state1", "state2", "state3"]
erwartet, oder den Output des "iob-getobject" Nodes. Und ihn so aufbereitet, um alle States (auch per Alias verknüpfte) auszuwerfen.
Der Output Mode des getObject Nodes muss dabei auf "Object Map" stehen.
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
Der iob-get Node wurde jetzt so angepasst, dass er als Input entweder:
msg.topic = "single.state.id"
oder
msg.topic = ["state1", "state2", "state3"]Das ist echt eine große Hilfe
- msg.topic = "single.state.id"
-
@marc-berg :+1: Is echt irre, wie fix du bist.
Habe mit der 15.1-3/-4 getestet. Arbeitet wie beschrieben.
Ein bug? ist mir beim WS ioB getObj aufgefallen. Wenn ich die StateID direkt im Node eingebe, wird das state Object erstellt.
Injiziere ich die als msg.topic ist das state Object null.Also langsam ist es sicher Zeit, die 1.0 rauszubringen. Da muß man sicher erst mal die reichlichen neuen Möglichkeiten ausloten bevor neue Feature - Wünsche aufkommen.
Also mir fällt da erstmal nichts mehr ein, was es rechtfertigen würde, das du dir die Nacht... ;-)@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Wenn ich die StateID direkt im Node eingebe, wird das state Object erstellt.
Injiziere ich die als msg.topic ist das state Object null.Das Problem war, dass das Topic, welches eigentlich für "iob-getobject" gedacht war, an "iob-get" weitergereicht wird. Und mit Wildcards möchte der "get" Node nix zu tun haben.
Ich habe die Priorisierung geändert, sollte mit "-5" jetzt in beiden Fällen laufen.
Übrigens ist Node-RED 4.1 draußen, Da wird man jetzt u.a. über Updates an Node-RED und in der Palette informiert.
-
@marc-berg :+1: Is echt irre, wie fix du bist.
Habe mit der 15.1-3/-4 getestet. Arbeitet wie beschrieben.
Ein bug? ist mir beim WS ioB getObj aufgefallen. Wenn ich die StateID direkt im Node eingebe, wird das state Object erstellt.
Injiziere ich die als msg.topic ist das state Object null.Also langsam ist es sicher Zeit, die 1.0 rauszubringen. Da muß man sicher erst mal die reichlichen neuen Möglichkeiten ausloten bevor neue Feature - Wünsche aufkommen.
Also mir fällt da erstmal nichts mehr ein, was es rechtfertigen würde, das du dir die Nacht... ;-)@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Also langsam ist es sicher Zeit, die 1.0 rauszubringen.
Steht schon auf der Agenda, wie man vielleicht am Changelog ablesen kann. Die 1.0.0 wird dann identisch mit der 0.15.1 werden.
-
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Wenn ich die StateID direkt im Node eingebe, wird das state Object erstellt.
Injiziere ich die als msg.topic ist das state Object null.Das Problem war, dass das Topic, welches eigentlich für "iob-getobject" gedacht war, an "iob-get" weitergereicht wird. Und mit Wildcards möchte der "get" Node nix zu tun haben.
Ich habe die Priorisierung geändert, sollte mit "-5" jetzt in beiden Fällen laufen.
Übrigens ist Node-RED 4.1 draußen, Da wird man jetzt u.a. über Updates an Node-RED und in der Palette informiert.
@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:
Übrigens ist Node-RED 4.1 draußen
Ja, wollte ich heute auch noch machen (docker) Hab i.M. die 4.09 am laufen.
-
@rewenode sagte in Node-RED Nodes für externe ioBroker Integration:
Wenn ich die StateID direkt im Node eingebe, wird das state Object erstellt.
Injiziere ich die als msg.topic ist das state Object null.Das Problem war, dass das Topic, welches eigentlich für "iob-getobject" gedacht war, an "iob-get" weitergereicht wird. Und mit Wildcards möchte der "get" Node nix zu tun haben.
Ich habe die Priorisierung geändert, sollte mit "-5" jetzt in beiden Fällen laufen.
Übrigens ist Node-RED 4.1 draußen, Da wird man jetzt u.a. über Updates an Node-RED und in der Palette informiert.
@marc-berg
Eine kurze Frage zum Update auf 4.1.Ich habe Node-Red mittels npm installiert. Mein System zeigt (noch) kein Update an. Dauert es noch einige Zeit oder muss ich das Update manuell anstoßen?
Gruß
Martin
Intel NUCs mit Proxmox / Iobroker als VM unter Debian
Raspeberry mit USB Leseköpfen für Smartmeter
Homematic und Homematic IP -
@marc-berg
Eine kurze Frage zum Update auf 4.1.Ich habe Node-Red mittels npm installiert. Mein System zeigt (noch) kein Update an. Dauert es noch einige Zeit oder muss ich das Update manuell anstoßen?
@martybr sagte in Node-RED Nodes für externe ioBroker Integration:
auert es noch einige Zeit oder muss ich das Update manuell anstoßen?
Das Paket steht seit zwei Tagen zur Verfügung:
https://www.npmjs.com/package/node-red
Die Anzeige eines vorhandenen Updates funktioniert erst ab 4.1. Oder welche Benachrichtigung meinst du?
-
@martybr sagte in Node-RED Nodes für externe ioBroker Integration:
auert es noch einige Zeit oder muss ich das Update manuell anstoßen?
Das Paket steht seit zwei Tagen zur Verfügung:
https://www.npmjs.com/package/node-red
Die Anzeige eines vorhandenen Updates funktioniert erst ab 4.1. Oder welche Benachrichtigung meinst du?
@marc-berg Genau diesen Hinweis auf das Update auf 4.1
Ich werde mal das System auf die 4.1 bringen. Danke für die Antwort.
-
@marc-berg Genau diesen Hinweis auf das Update auf 4.1
Ich werde mal das System auf die 4.1 bringen. Danke für die Antwort.
@Marc-Berg Ich möchte jetzt mal Danke sagen für die Arbeit!
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. -
@Marc-Berg Ich möchte jetzt mal Danke sagen für die Arbeit!
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.@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.
-
@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.
@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 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.
@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...
-
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!
-
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!
@marc-berg Und läuft wie geschmiert:+1:
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.
Support us
541
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge