Shellys ("Alt und Plus") über MQTT Adapter
-
@hotspot_2 Wenn ich jetzt den Debug an die beiden Switches (oben dran mache) dann krieg ich bei Tasterdruck drei Events.
- btn_down
- btn_up
- single_push
-
@hotspot_2 Ok dann machen wir es ganz sicher:
Damit wird nur auf notify Events beim Drücken des Tasters gefiltert.
-
@hotspot_2 sagte in Shellys ("Alt und Plus") über MQTT Adapter:
@hotspot_2 Wenn ich jetzt den Debug an die beiden Switches (oben dran mache) dann krieg ich bei Tasterdruck drei Events.
- btn_down
- btn_up
- single_push
Ja ich hab Dir nun ein Filter geschickt - der nur noch btn_down bei Input:0 durchlässt.
-
@mickym Passt. Jetzt gibt es bei Tastendruck noch ein Event. Wenn das Licht ausgeschalten oder eingeschalten wird über Node RED gibt es auch kein Event mehr.
Noche eine Frage zum Trigger:
Mit dieser Einstellung sollte er doch die eingestellte Zeit (die über ein Objekt kommt) übernehmen beim Start des Triggers und dann stumpf die Zeit ablaufen lassen und Licht geht aus, oder? Auch wenn die Zeit z.B. eine Minute ist.
-
@hotspot_2 Du musst den anderen Haken reinmachen, sonst hast Du wieder Kuddelmuddel.
Wenn Du den Haken nicht rein machst. Dann wird nach der 1. Nachricht nach 2 Minuten das Licht ausgemacht auch wenn zwischenzeitlich Taster oder BWM sendet. Die 2 Minuten sollen aber erst dann ablaufen, wenn 2 Minuten lang keine Nachricht angekommen ist!!
Die Zeit überschreibst ja mit Deinen Minuten über Jarvis. ABER die Zeit darf erst loslaufen, wenn KEINE Nachricht mehr eingeht. Sonst wird das nichts.
-
@mickym Und was ist der Unterschied zwischen der Zeit im Trigger und der die ich über das msg.delay übergebe?
-
@hotspot_2 Die Zeit im Trigger gilt solange bis eine msg.delay ankommt. Jetzt ist es halt so, dass wenn Du den Wert nicht neu setzt - wird die Zeit halt in der Node genommen. Sobald Du aber in Jarvis den Wert neu setzt - sollte die Trigger node die neue Zeit nehmen - aber wie gesagt immer nach Eingang der letzten Nachricht. Also jetzt zum Test wird meist die Zeit der Node genommen - kannst ja auch auf 1 Minute oder 30 s einstellen. Später wird das was in der Node steht ignoriert wenn eine msg.delay ankommt.
Aber wie gesagt wichtig ist, dass beide Haken drin sind.
Hier mal eine Demo - was passiert wenn Du den Haken nicht drin hast:
Sprich nach der 1. Nachricht laufen die 10s los - innerhalb dieser 10s werden alle Nachrichten ignoriert und erst nach den 10s, wenn die 2. Nachricht geschickt wurde - ist die trigger Node wieder aktiv.
Wenn du also den Haken nicht reinmachst, dann kannst Du mit Deinem Taster das Licht einschalten und weitere Nachrichten der BWM werden ignoriert - sprich das Licht wird nach 2 Minuten ausgeschaltet - auch wenn der BWM zwischenzeitlich Bewegungen regisitriert. Dann wird das Licht wieder eingeschaltet. Das möchtest Du nicht.
-
@mickym Ok, jetzt scheint alles zu laufen. Ich teste das jetzt mal. Aber sieht sehr gut aus jetzt.
-
@mickym Wollte mich mal melden. Also der mosquitto und der umgestellte ioBroker MQTT-Adapter laufen einwandfrei. Nicht eine Warnung mehr seit der Umstellung. Vorher hatte ich sehr viele an einem Tag.
Beide Skripte laufen auch sehr gut bis jetzt! Tip Top.
Ich schau mir jetzt mal an wie ich die anderen umsetzen kann. Muss noch klären wie das pushover Node funktioniert und wie ich Sprachausgaben auf Alexa machen kann. Habe auch noch Skripte (Blockly) wo ich zu bestimmten Zeiten (täglich 0 Uhr, einmal im Monat, einmal im Jahr) bestimmte Aktionen und Berechnung mache z.B. Heizölverbrauch und Solarthermie.
-
@hotspot_2 Gut mit der pushover Node musst nachlesen - vielleicht liefert die aber auch Beispiele mit - musst halt mal unter Beispiele beim Import schauen. Auch immer die Hilfe zur Node anschauen.
Alexa würde ich ggf. nicht oder zum Schluss umstellen - ausser es gibt Datenpunkte, die Du direkt beschreiben kannst, das kannst natürlich auch aus NodeRed machen. Alles was mit SendTo machst geht halt im NodeRed nicht direkt. Wenn Du alles umstellen willst, kannst Du mein JS nehmen, das läuft immer und das simuliert (agiert quasi als Proxy) für SendTo. Es gibt natürlich auch verschiedene Alexa Nodes - aber da bin ich raus. Da gibts inzwischen von mir keine Empfehlung mehr. Meine früheren Empfehlung hat leider das Kostenmodell einfach umgestellt und unterstützt nur noch 5 Geräte. So was finde ich generell ein NoGo - wenn man plötzlich für Dinge zahlen muss, die vorher kostenlos waren. Dann lieber gleich einen Preis verlangen und dann kann ich mir das überlegen, bevor ich etwas nutze, aber nicht im laufenden Betrieb Funktionen plötzlich abschneiden. Absolut
Für einfache Zeitpunkte täglich oder an bestimmten Wochentagen oder für kleine Intervalle bis zum Stundenbereich kannst Du die InjectNode nutzen. Für tägliche Task zu verschiedenen Zeiträumen (also nicht nur ein Trigger sondern an und aus) in der Woche den Lightscheduler. Ansonsten der meines Erachtens mächtigste zeit Trigger, den Du in ähnlicher Form aus dem Blockly kennst ist die cronplus-Node (kann sogar noch etwas mehr als der Javascript Adapter) - aber wie gesagt geh sparsam mit den Zeittriggern um. Auf bestimmte Situationen zu reagieren ist in der Hausautomation wesentlich sinnvoller, als zeitliche Trigger zu verwenden. Ich würde hier alles nochmal auf den Prüfstandstellen. Zeitliche Trigger belasten ein System nur unnötig. -
@mickym Danke für die Anregungen ich werde das Thema Alexa mal auf den Prüfstand stellen.
Für die Ansagen (über Blockly) nutze ich aktuell den Alexa2 Adapter. Das sollte ja möglich sein über ioBroker Out auf das jeweilige Objekt (speak).
Fürs steuern mit der Alexa in den ioBroker (meistens auf die Shellys) nutze ich den iot Adapter (da war was mit Kosten, glaub jährlich). Aktuell steuere ich damit auf die Objekte der Shellys die wir angelegt haben. Wie das dann aussieht wenn ich eigentlich die Objekte nicht mehr erstellen lassen möchte, muss ich mir dann anschauen. Bin ja bei Dir mit deinem Grundsatz: Keine Verdopplung von Informationen!
Ausserdem ist Node-RED eh viel besser ;-).
-
@hotspot_2 sagte in Shellys ("Alt und Plus") über MQTT Adapter:
Ausserdem ist Node-RED eh viel besser ;-).
Tja damit gehörst Du nun zu einer erlesenen Minderheit hier im Forum, die das inzwischen gecheckt haben.
- Die meisten legen gleich mit Blockly los und haben dann den Aufwand. Auch die alten Hasen pushen hier meist das Blockly. Ich bin gerade der Meinung, dass sich Einsteiger die 3 wichtigsten Logikmaschinen (also Blockly, Javascript und NodeRed) anschauen sollten und die gleiche Aufgabe mit allen Tools lösen sollten, bevor sie eine Entscheidung treffen. Machen aber leider die wenigsten. -
@hotspot_2 sagte in Shellys ("Alt und Plus") über MQTT Adapter:
Wie das dann aussieht wenn ich eigentlich die Objekte nicht mehr erstellen lassen möchte, muss ich mir dann anschauen. Bin ja bei Dir mit deinem Grundsatz: Keine Verdopplung von Informationen!
Es macht nichts erstmal die Infos in die Objekte weiter schreiben zu lassen. Parallel - und Du kannst ja auch mehrere mqtt-In Nodes auf das gleiche Topic machen, kannst Du neue Flows erstellen und dann die Blocklies Stück für Stück deaktivieren . Ein Teil der Datenpunkte wirst Du ja auch für Dein Jarvis brauchen. Das kann glaub immer noch schwer mit Objekten umgehen, ich hab das mal versucht und war da nur halb erfolgreich. Ich bin ja nicht so der super kreative Mensch, der diese tollen grafischen Seiten macht. Für mich muss es schnell und funktionell sein.
-
@mickym Guten Morgen! Ich bin gerade am überlegen wie ich einen Flow hinbekomme um alle Batteriemeldungen (< 5%) über einen Flow einzusammeln und dann ein Pushover zu versenden. Kriegt man das hin das man quasi jeden MQTT-in auswertet und wenn <5% den Text für die Pushover mitgibt (welches Element es ist) und dann den Text im Pushover-Node zusammenbaut?
Ähnliches Thema hätte ich auch bei Shelly Smoke Plus, habe davon mehrere, das ich quasi nur ein Node fürs Versenden habe und die Infos welcher Melder es war mitgebe.
Mir würde erst mal nur ein Tipp reichen musst nicht den ganzen Flow machen
Natürlich muss ja auch erstmal so funktionieren.
Wie kann ich dem einen bereits befüllten Payload einen weiteren Text dranhängen? Dann würde ich nämlich wie oben vorgehen im ersten Switch die Bezeichnung des Melders mitgeben und dann ale auf den zweiten Switch verbinden und die Message dort dann zusammenbauen. Ich hab aber beim googeln nix gefunden wie man die alte Payload verwenden und vorne hinten was dran machen kann an den String.
Mit der Vorgehensweise könnte ich ja dann Batteriemeldungen und Alarme managen mit einem großen Flow. Das wäre toll.
-
@hotspot_2 Ja Du kannst die topics einzeln auslesen, Du kannst Deine Datenpunkte verwenden, du kannst wenn Du Deine Struktur einheitlich aufgebaut hast auch mit Wildcards arbeiten, dann brauchst Du nicht für jede Eingabe eine eigene Node verwenden. Du kannst diese Zustände triggern lassen oder auch die Gesamtzustände in einem eigenen Datenpunkt oder in mqtt abspeichern.
Du hast zu jeder Nachricht ein topic, dass Du entweder extrahieren kannst oder modifizierst damit die Quelle leichter lesbar ist.
Du kannst eine payload wieder ganz einfach über eine Change Node modifizieren, indem Du JSONATA benutzt und Strings miteinander verkettest: https://docs.jsonata.org/other-operators
Also "string vorher " & payload & " string nachher". Du kannst aber auch die payload in einen Menge Text oder HTML Code über eine template Node formatieren, damit Du schöne Nachrichten bekommst. Keine Ahnung ob das von pushover unterstützt wird.Du kannst wie gesagt abwarten bis Du alle Zustände hast - mache ich meist bei zeitunkritischen Sachen - du kannst aber auch Objekte bilden und diese in Datenpunkte wegspeichern, um diese dann beim Neustart von NodeRed zur Verfügung zu haben.
Ich habe mir für Alarm zustände eigene Strukturen gebastelt (battery, online, Fenster auf, etc.) :
und arbeite nur mit true und false:
Also bist ja gar nicht so schlecht mit Deinem Anfang - aber du solltest bei allem Detail - immer Deine übergeordneten Ziele im Auge behalten.
Ich denke, dass damit Deine Fragen beantwortet sein sollten, damit Du mit Deinem Flow weiter kommst.
-
@mickym Super, das hilft erstmal.
Wenn ich das hier mache:
Dann kommt am Ende nur "Wasseralarm." raus obwohl der msg.payload vorher "Waschküche" war. Stimmt der Bezeichner nicht?
-
@hotspot_2 Dann war die payload leer oder undefined.
-
Zurück zur allgemeinen Betrachtung:
Wenn im Status beispielsweise auch die Batteriewerte enthalten sind und der Aufbau gleich ist, kann man im mqtt sowas auch mit einer Node vereinfachen - indem man für bestimmte Hierarchielevel Wildcards benutzt und somit kannst Du einzelne Nodes sparen.
In dem abgebildeten Beispiel ist die Struktur wunderbar gleich und unterscheidet sich im vorletzten level also bwm_wk und bwm_flur_keller.
Sowas kannst Du auch durch abonnieren des topics mit einer Node erreichen in dem Du als topic folgendes angibst:
shellies/sonstiges/+/status -
@mickym Ja, stimmt. Ich muss die Payload vorher auch in Anführungszeichen setzen. Dann klappt es perfekt.
-
@hotspot_2 Nein die payload selbst nicht - das ist eine Variable die darf nicht in Anführungszeichen. Probiere halt mit Inject NOdes aus.
