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

[mickym]

@hotspot_2 Nein du sollst nicht mehr in den Keller laufen - wir simulieren direkt in Node Red und Du nutzt eine Inject Node mit diesem Objekt.

[hotspot_2]

@mickym Alles gut, ich war nur im Keller da ich eine komplette Meldung vom Bewegungsmelder haben wollte. das mit den Debugs, den Nodes deaktivieren usw. sitzt jetzt komplett bei mir.

Wie kann ich die flow Variabel debuggen? Geht das auch? Ob sie da ist und einen Wert hat wäre interessant zu wissen.

[mickym]

Wie kann ich die flow Variabel debuggen? Geht das auch? Ob sie da ist und einen Wert hat wäre interessant zu wissen.

Sehr gut - Du brauchst also weder Programmieren noch function nodes. - Du schaffst das ja.

Den Kontext findest Du im Menü

Du musst aber immer selbst aktualisieren:

Das aktualisiert sich nicht selbst.

[hotspot_2]

@mickym

Passt. Danke!

So, und die kann ich jetzt vergleichen und dann die Werte ändern (lux) und schauen ob das Licht angeht.

[mickym]

@hotspot_2 Ja und was vergleichst Du nun in der switch Node?

[hotspot_2]

@mickym Stimmt, das haut auch noch nicht hin, glaub ich. Ich darf ja nicht die payload verändern die den Shelly dann aus oder an macht. Da muss ich dann vermutlich auch erst eine Flow Variable draus machen.

[mickym]

@hotspot_2 Nein - lass mal - Du hast etwas nicht verstanden. Wenn Du in der getNode das attribut änderst - dann änderst Du nicht die payload - sondern eine msg. Eigenschaft.

Das hier

ist also nicht payload.lux_wk, sondern msg.lux_wk

Wie gesagt ich finde es doof, dass Du beides lux_wk nennst, denn das Eine ist die tatsächliche lux_wk und das andere ist das von Dir gesetzte limit_lux_wk. Das sind 2 Paar Stiefel.

[hotspot_2]

@mickym Da hast Du völlig Recht!

So klappt es. Ich teste mal ein paar Werte durch usw. Aber sieht sehr gut aus!

[mickym]

@hotspot_2 Ok - nun scheinst Du es verstanden zu haben. - Auch wenn ich Dein Flow trotzdem komplex finde und ich ggf. den Waschküchen BWM komplett eigenständig behandelt hätte, so hast Du nun die Fehler im Flow selbst ausgebessert. Nur wenn Du halt behauptest, es hätte am Anfang alles funktioniert, dann war das sicher nicht richtig.

Aber ich denke, Du hast heute eine Menge gelernt.

[hotspot_2]

@mickym Ja, auf jeden Fall. Die herangehensweise und wie man das simuliert und auch durchtestet. Das war für mich so nicht greifbar.

Dankeschön!

[mickym]

@hotspot_2 Ok - nun scheinst Du es verstanden zu haben. - Auch wenn ich Dein Flow trotzdem komplex finde und ich ggf. den Waschküchen BWM komplett eigenständig behandelt hätte, so hast Du nun die Fehler im Flow selbst ausgebessert. Nur wenn Du halt behauptest, es hätte am Anfang alles funktioniert, dann war das sicher nicht richtig.

Aber ich denke, Du hast heute eine Menge gelernt.

UND function Nodes und JS Programmierung sind für Dich erst mal tabu. - Dann kannst Du ja gleich wieder Javascript im Javascript Adapter programmieren. - Du wirst sehen, dass Du sehr lange ohne function Nodes auskommst - und kopiere nicht Flows aus dem Netz. Die meisten nehmen function Nodes und fangen wieder das herkömmliche Programmieren an.

Wir können Deinen kompletten Flow in einer Function Node unterbringen. Willst Du das etwa????

Dann lernst Du lieber erst mal JSONATA und Du wirst sehen - wie mächtig das sein kann und wieviel Codeschreiberei Du Dir sparen kannst.

[dos1973]

@mickym

mein 2PM Plus als Schalter läuft. Danke Dir.

[mickym]

@dos1973 Das nur ACK=False kannst Du direkt in der iobroker-IN Node einstellen bzw. filtern.

[hotspot_2]

@mickym Hallo mickym,

ich habe mal ne Frage zum Thema msg und flow Payload. Ich würde gerne den msg. Payload der von dem MQTT in kommt an mehreren Stellen im Flow auslesen bzw. verschiedene Items (alarm, mute usw.) prüfen. Am Ende muss aber ein msg Payload an eine Pushover Node gehen damit eine Nachricht verschickt wird.

Ich würde nun gerne die Payload für den Pushover in flow.* aufbauen und den msg.* Payload nicht verändern. Am Ende dann quasi die flow. zur msg. Payload machen kurz vor der Pushover Node. Geht das? Ist das ein guter Ansatz?

Oder besser mit Variablen arbeiten und am Ende die msg.payload zusammenbauen?

Ich hoffe Du kannst nachvollziehen was ich meine.

[mickym]

@hotspot_2 sagte in Shellys ("Alt und Plus") über MQTT Adapter:

Oder besser mit Variablen arbeiten und am Ende die msg.payload zusammenbauen?

Nun im flow Kontext ist das eine Variable - klar geht das. Ob den zusammengefassten Status in einem Datenpunkt sammelst oder im flow-Kontext ist letztlich nur davon abhängig, ob die Informationen einen Neustart von NodeRed überleben sollen oder nicht.

Ansonsten allgemein zur Überwachung - kannst Dir ja mal mein Post von hier anschauen: https://forum.iobroker.net/post/625108

[hotspot_2]

@mickym Habe noch ein anderes Problem entdeckt wo ich nicht wirklich eine Lösung finden kann.

Im MQTT Adapter habe ich folgenden Eintrag gefunden unter mqtt/0:

Die ID die hier sichtbar ist in diesem Objekt ist die 199:

Die schreiben wir in einem Flow in Node RED:

Ich habe, extra um dem auf die Schliche zu kommen woher das kommt, die IDs verändert.

Muss das so sein? Oder habe ich da irgendwo einen Fehler drin?

[mickym]

@hotspot_2 der rpc kanal hotspot2 enthält alle Antworten auf alle Deine Befehle - also die Quittung. Das ist also kein Fehler - Du siehst das Gerät in src und das Ergebnis Deines Befehls. Die Beschreibung der RPC Kanäle findest Du hier:
https://shelly-api-docs.shelly.cloud/gen2/General/RPCChannels

Ich habe auch mal für Dich die entsprechende Stelle rausgesucht:

Du kannst aber seit Version 14 auch direkt ohne den RPC Kanal schalten. Das habe ich gesehen und siehst an den Beispielen von @dos1973. Ich würde, wenn ich DU wäre das nun alles auf command/switch umstellen. Du musst halt nur true und false in on und off wandeln. In der Generation 1 war es ja auch on und off.

Wenn Du viel von unterschiedlichen Quellen schaltest mag zwar das RPC Protokoll ganz praktisch sein da Du siehst woher ein Befehl kam. Musst Du wissen - ich finde das normale Schalten über den command Ast einfacher.

[hotspot_2]

@mickym Ok, schaue ich mir an. Tendenziell sehe ich es auch so das schalten über command einfacher ist ;-).

Macht richtig viel Spaß mit der Methode die JSONs zu analysieren, mit Injects und Debugs zu arbeiten. Man lernt einiges dabei. Baue mir gerade einen Flow für alle Alarme im Haus, Batteriemeldungen und sonstige Benachrichtigungen die über Pushover oder Email versendet werden.

Node Red ist einfach genial ;-).

[mickym]

@hotspot_2 Node Red ist einfach genial ;-). Na da rennst Du bei mir offene Türen ein. Leider beschäftigen sich die meisten erst gar nicht damit. Die, die auf den Geschmack gekommen sind, habe ich noch nie wieder auf Blockly zurück migrieren sehen.;)

Was Du halt noch machen kannst, wenn Du willst, deswegen habe ich Dir den anderen Thread verlinkt, dass Du selbst Objekte baust und mit true und false arbeitest. Aber mach erst mal - zur Optimierung und weiteren Idee ist ja immer noch Zeit.

Und wie Du siehst, wenn man einmal gelernt hat, mit Objekten umzugehen, dann ist das eigentlich ganz easy und lernt die Vorteile von Objekten kennen.

[hotspot_2]

@mickym Ich hätte noch mal eine Frage dazu wie Du sowas angehen würdest.

Ich habe im Garten eine elektrische Klingel die ich über einen Shelly ansteuere. Klingelt jemand an der Haustüre dann mache ich seither über einen Blockly die Klingel zweimal an und wieder aus mit kurzen Pausen dazwischen.

Wenn ich sowas jetzt in Node-Red machen möchte wie würde ich das angehen? Gibt es da sowas wie eine Schleife oder so?

Trigger wäre ein Ansatz gewesen aber der macht halt nur einmal an und wieder aus.