Hallo,
wenn ich das Diagramm auf dieser Seite richtig interpretiere, wird ein von FHEM einmalig an ein Tasmota-Device gesendeter Befehl nicht wiederholt gesendet, sollte es seitens des Tasmota-Devices nicht zu einer Umschaltung gekommen sein (z.B. bei gestörtem Wlan-Empfang):
https://github.com/arendst/Sonoff-Tasmota/wiki/MQTT-Overview (https://github.com/arendst/Sonoff-Tasmota/wiki/MQTT-Overview)
Mit "Umschaltung" meine ich das Schalten eines Relais an einem mit Tasmota-Firmware geflashten Gerätes (z.B. einer S20).
Gerne würd ich jedoch zu jedem Zeitpunkt sicher sein, dass das, was FHEM anzeigt auch dem realen Schaltzustand entspricht.
Wie begegnet Ihr diesem Unterfangen, oder hat es bisher einfach immer bei Euch auch so funktioniert (set .. on)?
Gruß Chris
Zitat von: chq am 08 Juli 2018, 20:43:30
Wie begegnet Ihr diesem Unterfangen, oder hat es einfach bisher einfach immer bei Euch so funktioniert?
Hallo Chris,
Ich werte das "RESULT" aus. Wenn Du das subkribierst, liefert Dein Tasmota-Device den Erfolg zurueck - oder eben nicht.
ZitatRESULT {"POWER":"ON"}
Gruss Helmut
D.h., dass so eine "Abfragelogik" ganz grundsätzlich von Hand selber programmiert werden muss?
Gruß Chris
Zitat von: chq am 08 Juli 2018, 21:00:56
D.h., dass so eine "Abfragelogik" ganz grundsätzlich von Hand selber programmiert werden muss?
Hallo Chris,
nein, das haette ich gleich dazuschreiben sollen. Zur korrekten Anzeige gehoert stateFormat, so in der Art:
attr <device> stateFormat {(ReadingsVal($name,"LWT", "") eq "Online") ? ReadingsVal($name,"RESULT_POWER", "error") : 'offline'} Damit ich das Ergebnis eindeutig ist, habe ich beim entsprechenden expandJSON-Device das Attribut "addReadingsPrefix 1" gesetzt.
Gruss Helmut
Vielen Dank, Helmut.
Ich verstehe die von Dir angegebene Zeile zwar noch nicht (liegt an meinem Kenntnisstand), aber ich werd mich reinfuchsen. ;D
Ich verwende jedenfalls bereits ebenfalls (begeistert) expandJSON.
Gruß Chris
Hallo Chris,
das ist der richtige Ansatz ;-)
Zur Erlaeuterung noch: LWT (The Last Will) must Du auch subkribiert haben und der zeigt Dir, ob das Device ueberhaupt lebt. Den Teil habe ich auch nur "ausgeliehen" ;-)
Gruss Helmut
Hallo Helmut,
wenn ich die Informationen, die Du mir geschrieben hast richtig interpretiere, bekomme ich so eine Rückmeldung, ob er entsprechende Befehl ankam oder nicht.
Ich konnte jedoch keine Logik entdecken, die bei einem nicht geglückten Sendeversuch den Befehl erneut "in Hintergrund" sendet, bis er ankommt. Das wäre dann ja theoretisch der nächste Schritt, aber vermutlich denke ich da viel zu kompliziert, da man in diesem Fall ja auch diverse Parameter wie Wiederholrate, Timeout usw. definieren müsste. :-\
Mal anders gefragt: Was bewirkt denn Deine Schaltvorgehensweise? Lediglich dass Du eine negative Rückmeldung bekommst, wenn der Befehl nicht ankam?
Wie kann man denn ein ankommendes s_regexp in ein anderes lautendes t_regexp "wandeln"? Ist dafür eventMap gedacht? Das wäre dann für meine expandJSON-Devices, da ich mehrere S20 mit DHT22s habe. ;D
Gruß Chris
Wenn du die Tasmota Devices nur aus FHEM steuerst solltest du dir mal das Attribut "retain" anschauen, damit wird der Schaltbefehl auf dem MQTT Broker dauerhaft gespeichert. Wenn nun ein kurzzeitig verschwundenes Tasmota Device zurückkehrt wird er dieses Kommando umsetzen.
Der Nachteil ist, dass ein manuelles schalten des Devices (also am Sonoff selber) unter umständen nicht lange "überlebt"
Zitat von: chq am 08 Juli 2018, 20:43:30
Gerne würd ich jedoch zu jedem Zeitpunkt sicher sein, dass das, was FHEM anzeigt auch dem realen Schaltzustand entspricht.
Hallo Chris,
das war Deine urspruengliche Frage. Die korrekte Anzeige wird unter Einbeziehung von RESULT sichergestellt.
Zitat von: chq am 09 Juli 2018, 07:31:32
wenn ich die Informationen, die Du mir geschrieben hast richtig interpretiere, bekomme ich so eine Rückmeldung, ob er entsprechende Befehl ankam oder nicht.
indirekt ja, darueber hinaus auch, ob er ausgefuehrt wurde. Eine negative Rueckmeldung kommt nicht, auch wenn der Vorgang, aus welchem
Grund auch immer, schiefgegangen sein sollte.
Zitat von: chq am 09 Juli 2018, 07:31:32
Ich konnte jedoch keine Logik entdecken, die bei einem nicht geglückten Sendeversuch den Befehl erneut "in Hintergrund" sendet, bis er ankommt. Das wäre dann ja theoretisch der nächste Schritt, aber vermutlich denke ich da viel zu kompliziert, da man in diesem Fall ja auch diverse Parameter wie Wiederholrate, Timeout usw. definieren müsste. :-\
Da habe ich noch keine Notwendigkeit gesehen, aber dazu hat MarkusN ja eben eine Moeglichkeit aufgezeigt. Je nachdem, wie wichtig Dir das
ist, kannst Du es natuerlich auch ausprogrammieren und bei Misserfolg entsprechende Aktionen ausfuehren.
Zitat von: chq am 09 Juli 2018, 07:31:32
Wie kann man denn ein ankommendes s_regexp in ein anderes lautendes t_regexp "wandeln"? Ist dafür eventMap gedacht? Das wäre dann für meine expandJSON-Devices, da ich mehrere S20 mit DHT22s habe. ;D
Dafuer reicht ein expandJSON-Device. Die Readings landen ja beim richtigen Device. Die Device-Namen meiner Sonoff Switches beginnen alle mit "sonoff"
defmod sonoff_ej expandJSON sonoff.*:(SENSOR|STATE|RESULT):.{.*} Gruss Helmut