Moin,
ich suche nach einer Möglichkeit aus FHEM heraus ein Relais, mit Rückmeldung zurück zu Fhem, zu steuern.
Es geht schon bei der Auswahl der Module los. Nimmt man einen DUMMY als "Schalter" und verbindet diesen dann mit einer MQTT_BRIDGE oder arbeitet man direkt mit einem MQTT_DEVICE?
Auf der Hardwareseite steht ein Device zur Verfügung der mit einem Topic
/setRelay | set_on:set_off ein Relay EIN/AUS-schaltet.
Nachdem das Relay geschatet wurde wird über ein weiteres Topic
/state | is_on:is_off der aktuelle Zustand als Rückmeldung published wird.
Der folgende Funktionsablauf soll damit erreicht werden:
- FHEM - Switch_DEVICE on
- FHEM - Switch_DEVICE state "set_on" (befehl ist raus, aber noch nicht bestätigt) /li]
- FHEM - Switch_DEVICE RückmeldeIcon auf "gelb"
- FHEM - MQTT_DEVICE -> publish "set_on"
- Hardware - Relay ON
- Hardware - publish /state is_on
- FHEM - Switch_DEVICE RückmeldeIcon auf "rot" (Hardware hat befehlt quittiert)
Die Steigerung wäre jetz natürlich noch eine Laufzeitüberwachung.
Wie würdet ihr diese Funktionalität umsetzen?
Gruß
Pf@nne
Hi Pf@nne,
ich habe das über ein MQTT_DEVICE gelöst.
Dazu brauchst du hauptsächlich etwas, was ein "set device on" auf dein "set_on" umsetzt, und die Antwort "is_on" zurück in ein "on":
eventMap { dev=>{"is_on" => "on", "is_off" => "off"}, usr=>{"on"=>"set_on", "off"=>"set_off"} }
Dann brauchst du natürlich die Publish und Subscribing-Definitionen (Attribute):
publishSet set_on set_off MYTOPIC/setRelay
subscribeReading_state MYTOPIC/state
Ich habe mir dann noch ein paar Attribute definiert, die den Schalter auf der Oberfläche schaltbar macht:
webCmd on:off
devStateIcon off:taster_ch_aus_rot:on on:taster_ch_an_gruen:off set_.*:taster_ch:on
retain 1
stateFormat state
Das Retain sorgt dafür, daß der letzte Befehl an das Relais wiederholt übermittelt wird, wenn die Verbindung mal abgebrochen sein sollte...
Grüße
Reinerlein
Moin Reinerlein,
werde ich morgen gleich mal testen, danke für deine Unterstützung!
Die Topics auf der Firmwarseite kann ich anpassen, ich hatte "set_on" nur zum besseren Verständnis gewählt.
An welcher Stelle deines Vorschlages wird denn das "RückmeldeIcon" gelb gesetzt und wartet auf die "echte" Rückmeldung vom Device?
Gruß
Pf@nne
Hi Pf@nne,
das passiert beim DevStateIcon mit dem Ausdruck "set_.*". In meinem Beispiel ist das einfach der An/Aus Kasten ohne Inhalt... Kannst du aber ja Anpassen...
Grüße
Reiner
Moin Rainer,
kaum macht man es richtig, schon funktioniert es! 8)
Vielen Dank!
Würdest du an dem set_on / set_off noch etwas ändern?
Ein "Zwischenbefehl" für "gesendet aber noch nicht rückgemeldet" muss ja erhalten bleiben
oder hast du hier noch eine elegantere Variante?
Wie sieht es mit einer Laufzeitüberwachung aus?
Würdest du die über ein notify realisieren oder bekommt man die auch noch mit in den MQTT_DEVICE mit rein?
Ziel soll es sein nach z.B. 500ms den state auf "error" zu setzen.
Gruß und schönes WE
Marco
Hi Marco,
ich weiß nicht, was du mittels MQTT angebunden hast. Bei mir sind es ESP8266-Komponenten.
Dort habe ich ESPEasy geflasht (mit einer eigenen MQTT Implementierung für die saubere Rückmeldung des gesetzten Zustands).
Dort gibt es eine sogenannte Last-Will Message; Wenn der MQTT-Broker feststellt, dass der ESP "verschwunden" ist, dann wird diese Last-Will Nachricht versendet, die ich dann in meinem MQTT-Device in Fhem subscribe und somit ein "Connection Lost" dort auswerten kann.
Ich mache keine weitere Error-Auswertung. Mir reicht der Setz-Zustand "set_on" (der ja mit einem leeren Kasten symbolisiert wird und im Fehlerfall bestehen bleibt), und an einem "Zentral"-MQTT-Device den Connection Status. Ich habe meistens viele Kanäle an so einem ESP in Benutzung, sodaß ich z.B. wie bei Homematic ein "Hauptdevice" habe und zum Schalten die einzelnen Kanäle...
Da gibt es aber natürlich viele Lösungen zu :) Aber mit dem Last-Will braucht man zumindest keine zeitliche Überprüfung mehr, sondern nur ein Topic-Subscribe, welches diese Nachricht empfängt und auf die Oberfläche bringt...
Grüße
Reiner
Moin Reiner,
OK, ich habe jetzt einen zentralen MQTT_DEVICE für die Überwachung aller ESP8266-Device-Verbindungen angelegt.
In dem Device kann ich dann sehen wer fehlt......gute Idee!
So wie es aussieht hast du dir ja schon abschließende Gedanken gemacht........
Welchen QoS setz du beim ESP-Device, vieleicht noch deinen Standpunkt dazu.
Nutzt du beim ESP-Device den retain?
Ich nutze MQTT auch in Verbindung mit diversen ESP8266-Devices zum Messen und Steuern.
Die kleinen Dinger machen in Verbindung mit MQTT echt Spaß.... 8)
Gruß
Pf@nne
Hi Marco,
ich verwende keinerlei QOS, da es meiner Meinung nach keinen Vorteil bietet. Retain sichert mir zu, dass ich in Richtung der ESPs grundsätzlich den letzten Stand neu zugestellt bekomme (falls da mal das WLAN kurz weg ist, wie bei mir z.B. beim Anschalten des Gast-WLANs).
Ich bin mir nicht sicher, ob QOS da einen Mehrwert bietet, eher das Gegenteil. Nach der Definition von QOS wird sichergestellt, dass *jede* Nachricht sicher zugestellt wird (also mindestens einmal bei 1, bzw. genau einmal bei 2). Wenn das in der falschen Reihenfolge am ESP ankommt, werden nicht nur alle Zwischenschritte geschaltet (was zu einer Lichtorgel führen kann :) ), sondern u.U. auch der falsche letzte Schritt.
Für Retain in Richtung FHEM gibt es keinen guten Grund. Für beide Varianten (also Retain bzw. kein Retain) gibt es Zustände, wo die jeweilige Einstellung ungünstig ist. Meiner Meinung nach alles sehr akademisch :) .
Ich habe das durch einen zusätzlichen Befehl in meinem ESP gelöst: "statusrequest". Dieser liefert als Ergebnis den aktuellen Zustand als Status zurück, schaltet aber selber natürlich nichts. Das habe ich in meinem FHEM-Neustart als Startaktion drin (wie bei Homematic auch).
Grüße
Reiner
Zitat von: Reinerlein am 19 Februar 2017, 01:06:25
Hi Marco,
ich verwende keinerlei QOS, da es meiner Meinung nach keinen Vorteil bietet. Retain sichert mir zu, dass ich in Richtung der ESPs grundsätzlich den letzten Stand neu zugestellt bekomme (falls da mal das WLAN kurz weg ist, wie bei mir z.B. beim Anschalten des Gast-WLANs).
Ich bin mir nicht sicher, ob QOS da einen Mehrwert bietet, eher das Gegenteil. Nach der Definition von QOS wird sichergestellt, dass *jede* Nachricht sicher zugestellt wird (also mindestens einmal bei 1, bzw. genau einmal bei 2). Wenn das in der falschen Reihenfolge am ESP ankommt, werden nicht nur alle Zwischenschritte geschaltet (was zu einer Lichtorgel führen kann :) ), sondern u.U. auch der falsche letzte Schritt.
Für Retain in Richtung FHEM gibt es keinen guten Grund. Für beide Varianten (also Retain bzw. kein Retain) gibt es Zustände, wo die jeweilige Einstellung ungünstig ist. Meiner Meinung nach alles sehr akademisch :) .
Ich habe das durch einen zusätzlichen Befehl in meinem ESP gelöst: "statusrequest". Dieser liefert als Ergebnis den aktuellen Zustand als Status zurück, schaltet aber selber natürlich nichts. Das habe ich in meinem FHEM-Neustart als Startaktion drin (wie bei Homematic auch).
Grüße
Reiner
Würdest du uns an deinem Statusrequest teilhaben lassen? Ich schaffe es nicht, mir den GPIO status via MQTT übermitteln zu lassen. Danke im Voraus!
Moin Reiner,
ich habe es jetzt so umgesetzt:
Sensoren-Devices:Firmware:
- LastWill - aktiviert [Dead|Alive]
- QoS - 0
- retain - off
FHEM:
Bei denn Sensoren-Devices ist es nur von Interesse ob die überhaupt noch am Leben sind,
von daher reicht die Implementierung des LastWill auf der Device-Seite.
Eine Sendewiederholung ist hier nicht notwendig, ist in der Regel nicht schlimm, wenn mal ein Messwert fehlt.
Aktoren-Devices:Firmware:
- LastWill - aktiviert [Dead|Alive]
- QoS - 0
- retain - off
FHEM:
Bei den Aktoren habe ich jetzt einen zentralen ESP8266-MQTT_DEVICE angelegt.
Jeder Device sendet beim Start ein "Alive" an das Topic "ESP8266/Devices/DeviceName".
Als LastWill wird "Dead" hinterlegt.
# ---------------------------------------------------
# ESP8266 StatusWatcher
# FHEM:
# ---------------------------------------------------
define ESP8266_Devices MQTT_DEVICE
attr ESP8266_Devices IODev MQTT_Broker
attr ESP8266_Devices autoSubscribeReadings ESP8266/Devices/#
attr ESP8266_Devices group Relay
attr ESP8266_Devices room ADE7953
attr ESP8266_Devices stateFormat transmission-state
attr ESP8266_Devices subscribeReading_ESP8266_1032096 ESP8266/Devices/ESP8266_1032096
Ein QoS ist gemäß deiner Philosophie auch hier nicht definiert.
Auf der FHEM-Seite ist jedoch "retain" aktiviert um sicherzustellen, dass der Device nach dem Starten den FHEM-Zustand annimmt.
Wobei das aber auch zu ungewolltem Einschalten führen kann! Also Obacht.
Zusätzlich sollte noch die von dir erwähnte "getState"-Routine im FHEM-Start implementiert werden.
An der hätte ich auch Interesse..... 8)
Schöne Sache, so langsam wird es Rund.....
Hast du hier noch Ergänzungen?
Gruß
Marco
Hallo,
ich muss dazu erstmal wieder an meinen Rechner kommen. Ich habe wie gesagt ein eigenes MQTT-Plugin für ESPEasy gebastelt, welches mir diesen generischen MQTT Einsatz ermöglicht.
Defaultmäßig wurde immer so eine JSON Struktur gesendet. Das war mir zu viel des guten :)
Außerdem habe ich das Ansprechen der Ports auf die Tasknamen umgebaut. Ich brauche im Fhem also nicht mehr die Portnummern wissen und verwenden, sondern nur den Tasknamen (z.B. "Channel1"). Damit sieht bei mir eine MQTT-Sendung z.B. so aus:
Topic: "sensors/cmd/aussen_Vorgarten/Channel1"
Message: "set_on"
Die Antwort ist dann bei mir direkt "on" auf dem Topic "sensors/aussen_Vorgarten/Channel1", wenn es geschaltet wurde.
Und für den Status:
Topic: "sensors/cmd/aussen_Vorgarten/Channel1/statusrequest"
Message: "" (beliebig)
Antort ist dann der aktuelle Zustand des Tasks auf dem Topic "sensors/aussen_Vorgarten/Channel1"
Außerdem meldet sich mein MQTT-Plugin beim Hochfahren des ESP mit "Connected" und der IP-Adresse, die er erhalten hat. Damit kann ich auch sehr schnell auf die Oberfläche des ESP zugreifen, ohne im DHCPD immer die aktuelle IP Adresse des von mir gesuchten ESP mühsam herauskramen zu müssen... Da kommen ja schon mal mehrere Zusammen :)...
Naja, die Last-Will Message hatten wir ja schon, die wird mit "Connection Lost" ausgesendet...
Kommt die Tage...
Grüße
Reiner
Cool ich freue mich schon 😀
Zitat von: Reinerlein am 19 Februar 2017, 21:11:48
Naja, die Last-Will Message hatten wir ja schon, die wird mit "Connection Lost" ausgesendet...
Mal eine vielleicht blöde Frage, wie kommt die Last-Will denn an wenn die Verbindung weg ist?
Hi,
Last Will ist eine Nachricht die man beim Anmelden am MQTT-Broker mitsendet. Das bedeutet, der Broker speichert diese und sendet diese dann auch aus, wenn er einen Verbindungsabbruch feststellt.
Der Client selbst ist ja dann weg :)
Grüße
Reiner
Hi,
ich habe hier jetzt mal meine angepasste ESPEasy-Version. Sie basiert auf der offiziellen R147, wurde aber an einigen Stellen signifikant angepasst, um diese StatusRequests durchführen zu können...
Ich habe auch ein fertiges, kompiliertes und flashbares Image für den NodeMCU dazugepackt...
Grüße
Reiner
Moin Reiner,
kannst du bitte deine Abfrage mal Posten?
Zitat von: Reinerlein am 19 Februar 2017, 01:06:25
.... Das habe ich in meinem FHEM-Neustart als Startaktion drin .....
Hier hat Marco einen ähnlichen Vorschlag gemacht, den bekomme ich aber nicht zum Laufen......
https://forum.fhem.de/index.php/topic,67664.msg592098.html#msg592098 (https://forum.fhem.de/index.php/topic,67664.msg592098.html#msg592098)
Gruß
Marco
Hi Marco,
ich habe mir folgendes Notify gebaut:
define global_Init notify global:INITIALIZED define global_Init_AT at +00:00:10 set a:publishSet_statusrequest=.+ statusrequest
Das basiert aber darauf, dass die zu aktualisierenden MQTT-Devices das Attribut "publishSet_statusrequest" haben.
Als Erweiterung zu den schon mal geposteten Definitionen:
attr device eventMap { dev=>{}, usr=>{"on"=>"set_on", "off"=>"set_off", "statusrequest" => "statusrequest ."} }
attr device publishSet_statusrequest MYTOPIC/Taskname/statusrequest
Grüße
Reiner
Moin Reiner,
den notify habe ich bereits eingepflegt, jetzt ist die Sache rund!
Vielen Dank für deine Unterstützung.
Gruß
Marco