NEWS
Shellys ("Alt und Plus") über MQTT Adapter
-
@mickym Da hast Du völlig Recht!
So klappt es. Ich teste mal ein paar Werte durch usw. Aber sieht sehr gut aus!
-
@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.
-
@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!
-
@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.
-
mein 2PM Plus als Schalter läuft. Danke Dir.
-
@dos1973 Das nur ACK=False kannst Du direkt in der iobroker-IN Node einstellen bzw. filtern.
-
@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.
-
@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
-
@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?
-
@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/RPCChannelsIch 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.
-
@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 ;-).
-
@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.
-
@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.
-
@hotspot_2 Nein die Trigger Node kann auch unendlich oft in bestimmten Abständen triggern. Aber natürlich kannst Du auch Schleifen bauen - du musst ja nun den Ausgang mit dem Eingang verbinden.
Das macht sie solange, bis Du die Trigger Node zurücksetzt.
Wenn die Klingel zwischendrin wieder ausschalten musst, dann kannst auch wie bisher den trigger nehmen und über den 2.Ausgang die Schleife antriggern.
Du kannst dann über eine Flow-variable zählen oder in dem Fall auch über eine function-Node und JS - wenn Dir für einen stupiden Zähler die Variable im FlowKontext zu viel ist. Hier mal 2 Varianten.
Hier mal eine Variante mit Flow-Kontext:
Hier das gleiche mit einer function node und node context, falls Du lieber mit Javascript programmieren willst.
Falls nicht zwischen true und false gewechselt werden muss, kannst Du einfach eine function Node nehmen und eine Delay node:
So und hier nochmal das Gleiche ohne Javascript Programmierung und nur mit Change Node und Flow Kontext.
So keine Schleife - aber noch ein ganz anderer Lösungsansatz ist, Du machst Dir zum Beispiel ein Array mit Nachrichten die Du schicken möchtest und splittest die einfach auf . Später wirst Du die split Node mal kennenlernen, die eine Schleife der herkömmlichen Programmierung ersetzt.
Nehmen wir mal Du möchstest verschiedene Nachrichten einfach mit einer delay Node verschicken, dann geht zum Beispiel auch so was.
Du siehst die Möglichkeiten sind vielfältig.
Und natürlich kannst Du auch alles in JS programmieren mit einer function Node. - falls Du einfach codieren willst.
-
Node Red ist schon cool - aber ich finde sauschwer, daran liegts vielleicht. blockly bist schnell drin und lässt sich irgendwie leichter lesen.
-
@dos1973 Na ich finde es ganz und gar nicht schwer und eigentlich viel einfacher zu lesen, weil Du Dich nur an den Kabeln entlang hangeln musst. Blockly ist viel zu starr an die herkömmliche Programmierlogik angelehnt und du kannst keine Funktionsblöcke bilden.
-
@mickym
Du … bist ja von flows umschwungen
Bei dir sieht das immer so easy und logisch aus. -
@dos1973 sagte in Shellys ("Alt und Plus") über MQTT Adapter:
@mickym
Du … bist ja von flows umschwungen
Bei dir sieht das immer so easy und logisch aus.Na Du musst Dir doch nur vorstellen, wie ein Nachrichtenobjekt durch die Kabel flutscht und Dir dann jede Node betrachtest, was diese mit dem Nachrichtenobjekt anstellt. - Das schöne ist - Du kannst über Inject Nodes - Zwischenergebnisse in Deinen Flow injizieren, über debug Nodes Dich versichern, dass die Nachrichtenobjekte noch so aussehen, wie Du es erwartest. Mal ein Kabel kappen, um die Hardware nicht unnötig zu belasten und wie gesagt es gibt auch Nodes, die ganze Adapter ersetzen, wenn die mal nicht so wollen, wie man sich das vorstellt.
Du musst nur etwas Vorstellungskraft entwickeln - so ein Nachrichtenobjekt zu sein und durch die Kabel zu fließen.
-
Diese Variante:
Ist mir sehr sympatisch.
Würde ich damit auch so eine Folge hinbekommen:
True - 2 Sekunken Pause - False - 2 Sekunden Pause - True 2 Sekundnen Pause- False
Also quasi 2 mal klingeln mit Pause dazwischen? Im Moment wird ja wieder direkt nach false true geschickt.
-
@hotspot_2 dann nimm doch lieber die letzte Variante mit dem Array, da kommst auch ohne Variable und Flow Kontext aus. Das Array definierst einfach in einer Change-Node. Damit steuerst Du über ein Array einfach die Nachrichtenfolge und begrenzt die Nachrichtenrate über die delay Node.
Du siehst an den Zeitstempeln alle 2 s eine Nachricht. Außerdem siehst du an der Delay Node im Status gleich, wieviele Nachrichten noch kommen.Bei der Variante unten von dir müsstest Du noch eine delay Node mit 2s in die Schleife einfügen, da finde ich das ohne Flowkontext viel einfacher und intuitiver.