UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[rewenode]

@marc-berg Also zu meckern gibt es immer noch nichts;-) Inzwischen habe ich weite Teile meiner Flows migriert.
Bei einer Sache habe ich echt an meinem Verstand gezweifelt.
Ich habe mir vor langer Zeit so einen Flow gebastelt, der rein im function node per WS meine PV abfragt.
Da abboniere ich viele Datenpunkte gemäß deren API, die sehen dann z.B. so aus:

"_sum/EssActiveDischargeEnergy"

Die reinkommenden Daten schreibe ich dann in states mit dem Topic:

      msg.topic = "node-red.0/fems/" + fems_request_channels[i][requestKey];

Das läuft mit den alten nodes ok. Nicht aber mit den neuen.
Hab dann irgendwann endlich gemerkt, dass die neuen nodes zwingend den "." als Property-Trenner verlangen.
Das ist natürlich ok und sicher auch besser.
Will nur darauf hinweisen, falls noch jemand in diese Falle tappst;-)

Macht echt Spass, seine Flows mit den neuen Möglichkeiten gleich mal zu überarbeiten.

[Marc Berg]

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

Das läuft mit den alten nodes ok. Nicht aber mit den neuen.
Hab dann irgendwann endlich gemerkt, dass die neuen nodes zwingend den "." als Property-Trenner verlangen.

Um ehrlich zu sein, habe ich mir nicht viel Mühe dabei gegeben, die Umstellung so einfach wie möglich zu gestalten. An dieser Stelle hatte ich eine Weile überlegt, wie ich es mache. Insbesondere beim "in" Node konnte man ja auch das "MQTT" Format mit "/" wählen. Ich hab's dann weggelassen weil ich es nicht verwendete (dachte ich). Bei der Umstellung hab ich dann gemerkt, dass ich doch eine Stelle drin hatte.

Will nur darauf hinweisen, falls noch jemand in diese Falle tappst;-)

So wie ich selbst.

[MartyBr]

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

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

Das läuft mit den alten nodes ok. Nicht aber mit den neuen.
Hab dann irgendwann endlich gemerkt, dass die neuen nodes zwingend den "." als Property-Trenner verlangen.

Um ehrlich zu sein, habe ich mir nicht viel Mühe dabei gegeben, die Umstellung so einfach wie möglich zu gestalten. An dieser Stelle hatte ich eine Weile überlegt, wie ich es mache. Insbesondere beim "in" Node konnte man ja auch das "MQTT" Format mit "/" wählen. Ich hab's dann weggelassen weil ich es nicht verwendete (dachte ich). Bei der Umstellung hab ich dann gemerkt, dass ich doch eine Stelle drin hatte.

Will nur darauf hinweisen, falls noch jemand in diese Falle tappst;-)

So wie ich selbst.

Planst du das Verhalten noch zu ändern? Wo finde ich die Doku dazu? Ich verwende eine Menge mqtt-Nodes. Wenn ich das richtig??? gelesen habe, betrifft es den in und den out-Node?

[Marc Berg]

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

Planst du das Verhalten noch zu ändern?

Ich sehe im Moment keinen Grund dafür. Hier geht es ja lediglich darum, in welchem Format die Topics durch den Flow geschleust werden. Da es sich hier um ioBroker Nodes handelt, verwende ich natürlich die ioBroker Notation, und die ist mit Punkten.

Wo finde ich die Doku dazu?

Ich verstehe nicht. Die Nodes sind schon umfangreicher dokumentiert als 99,9% vergleichbarer Projekte. Soll ich jetzt auch noch dokumentieren, was ich NICHT mache?

Ich verwende eine Menge mqtt-Nodes. Wenn ich das richtig??? gelesen habe, betrifft es den in und den out-Node?

Ja. Beim "in" Node konnte man wählen, dass man statt der Punkte im Topic "/" hat. Und beim out-Node konnte man AUCH "/" als Trenner angeben. Das hat aber aus meiner Sicht Fehlerpotential, weil auch solche Bezeichner wie

möglich sind.

[rewenode]

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

Da es sich hier um ioBroker Nodes handelt, verwende ich natürlich die ioBroker Notation, und die ist mit Punkten.

Ich würde es ehrlich gesagt auch so lassen. Ist weniger fehleranfällig und in stateID Pattern sind die Beispiele ja auch mit Punkt. Da könnte man zur Not ja noch
"only dot notation is permitted" drunterschreiben.

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

Die Nodes sind schon umfangreicher dokumentiert als 99,9% vergleichbarer Projekte.

Würde ich mal zu 100% unterschreiben. Kann mich nicht erinnern schon mal so gut dokumentierte nodes gesehen zu haben. Danke dafür.

[MartyBr]

@marc-berg
Ich habe die Doku auf Github gefunden. Sie ist wirklich ausgesprochen umfangreich.

[rewenode]

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

[Marc Berg]

@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]

@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]

@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]

@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]

@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]

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

[rewenode]

@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]

@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

[Marc Berg]

@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]

@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]

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

[MartyBr]

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

[Marc Berg]

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