Hallo,
vorab, ich bin mir bewusst, dass das dieses "Problem" in der aktuellen Konfiguration völlig normal ist.
Ich weiß allerdings nicht, wie ich es lösen kann. Der Thread (https://forum.fhem.de/index.php?topic=78239.0) hat mir auch nicht weitergeholfen und etwas anderes habe ich nicht gefunden, zu dem Thema.
Ich abonniere bei einem TasmotaDevice (hier am Beispiel eines Sonoff DUAL) den Topic "stat/sonoff_wz_dual/POWER1" auf das Reading "POWER1"
Mit "stateFormat POWER1" gebe ich den aktuellen Zustand an "state" weiter. Schließlich möchte ich den wirkichen state, der ja auch mal extern ausgelöst werden kann (Knopfdruck etc.)
Wenn ich nun mit "set mqtt_sw_wz_holzlampe on" anschalten möchte, habe ich zwei Mal das Event auf state
2018-11-24 09:59:22 MQTT2_DEVICE mqtt_sw_wz_holzlampe on
2018-11-24 09:59:22 MQTT2_DEVICE mqtt_sw_wz_holzlampe on
... was ja auch völlig normal ist.
Wie kann ich aber nun das "set" ignorieren, sodass nur ein Event erzeugt wird, wenn der Rückgabewert aus "POWER1" erzeugt wird?
Falls die Frage aufkommt, warum ich überhaupt den Schritt über "stateFormat POWER1" gehe? Ich möchte später, den Onlinestatus des TasmotaDevice (LWT) abonieren und den möglichen Offlinezustand auch an "state" übergeben.
Internals:
DEVICETOPIC mqtt_sw_wz_holzlampe
IODev mqtt2_server
LASTInputDev mqtt2_server
MSGCNT 88
NAME mqtt_sw_wz_holzlampe
NR 260
STATE off
TYPE MQTT2_DEVICE
mqtt2_server_MSGCNT 88
mqtt2_server_TIME 2018-11-24 09:44:06
OLDREADINGS:
READINGS:
2018-11-24 09:44:06 POWER1 OFF
2018-11-24 09:44:06 state off
Attributes:
DbLogExclude .*
IODev mqtt2_server
alexaName Holzlampe
alexaRoom Wohnzimmer
eventMap { dev=>{ON=>'on',OFF=>'off'} }
genericDeviceType light
readingList DVES_9D7CEE:stat/sonoff_wz_dual/POWER1:.* POWER1
room 01_Wohnzimmer,Homekit,MQTT2_DEVICE,alexa
setList off:noArg cmnd/sonoff_wz_dual/POWER1 0
on:noArg cmnd/sonoff_wz_dual/POWER1 1
siriName Holzlampe
stateFormat POWER1
webCmd on:off:toggle
Schöne Grüße,
Patrick
ZitatWie kann ich aber nun das "set" ignorieren, sodass nur ein Event erzeugt wird
Ob es spezielle Mechanismen in den MQTT* Modulen gibt weiß ich nicht, aber allgemein gesehen würden die globalen Attribute event-on-change-reading und event-on-update-reading doch greifen, oder?
Zitat... doch greifen, oder?
Kurz und knapp,
ja! Manchmal sieht man den Wald vor lauter Bäumen nicht.
Danke fürs "wachrütteln". ;)
Zu früh gefreut.
Mit attr <dev> event-on-change-reading state wird state nicht mehr geloggt, wenn ich z.b. über die Tasmota-Weboberfläche schalte, obwohl der state eindeutig wechselt.
Edit:
attr <dev> event-on-change-reading POWER1.*
damit läuft es
Bin nicht sicher, aber mir kommt es so vor, als wäre es in dem Fall evtl. besser, ein event-min-interval zu definieren (kann eine kurze Spanne von z.B. nur 2 Sec. sein), und das auf alle Readings anzuwenden.
An sich müßte das Problem aber eigentlich bei allen bisherigen MQTT-Modulen bestehen, da viele Implementierungen auf der Client-Seite so gestrickt sind, dass sie eine Rückmeldung erzeugen, wenn der Befehl umgesetzt wurde. Von daher wäre zu überlegen, ob man nicht eine (deaktivierbare) set_xx-Logik einbauen könnte, so wie das z.B. bei CUL_HM der Fall ist? Ist aber vermutlich nicht ganz easy...
Zitat von: Beta-User am 24 November 2018, 13:27:13
An sich müßte das Problem aber eigentlich bei allen bisherigen MQTT-Modulen bestehen, da viele Implementierungen auf der Client-Seite so gestrickt sind, dass sie eine Rückmeldung erzeugen, wenn der Befehl umgesetzt wurde.
Die Lösung heißt - getrennte Topics für das Befehl und die Rückmeldung. Dann ändert sich der Zustand dann (und nur dann), wenn es wirklich geschaltet wurde. Unabhängig davon, woher das Schaltbefehl kam.
Beispiel für UI einer per Mqtt schaltbaren Lampe mit getrennten Topics:
defmod DG_WZ_Licht_Top dummy
attr DG_WZ_Licht_Top devStateIcon off:light_light_dim_00@gray on:light_light_dim_100@#FF5722 .*:hourglass
attr DG_WZ_Licht_Top eventMap {usr=>{'an'=>'on','aus'=>'off'},fw=>{'an'=>'an:noArg','aus'=>'aus:noArg'}}
attr DG_WZ_Licht_Top icon light_ceiling
attr DG_WZ_Licht_Top mqttForward none
attr DG_WZ_Licht_Top mqttPublish state|select:topic=/ha/dg/wz/licht/top/set
attr DG_WZ_Licht_Top mqttSubscribe state|select:topic=/ha/dg/wz/licht/top/state
attr DG_WZ_Licht_Top readingList select
attr DG_WZ_Licht_Top setList on:noArg off:noArg select:iconRadio,use4icon@000000,off,circle_percent_v1_off@808080,on,circle_percent_v1_on@808080
attr DG_WZ_Licht_Top webCmd select
attr DG_WZ_Licht_Top widgetOverride setList:textField-longEDIT: Das Beispiel setzt Nutzung von MQTT_GENERIC_BRIDGE voraus.
...an sich einleuchtend...
Paßt auch auf meine Beobachtungen zum Verhalten z.B. der Zigbee-Leuchten.
Ich meine das Problem ist leicht anders gelagert.
Tasmota meldet das Schalten ueber zwei getrennte Topics:
Zitatstat/sonoff/POWER1:OFF
stat/sonoff/RESULT:{"POWER1":"OFF"}
Das bisherige autocreate hat das mit
XX:stat/sonoff/RESULT:.* { json2nameValue($EVENT) }
XX:stat/sonoff/POWER1:.* POWER1
zu zweimal "POWER1:off" konvertiert, was wegen stateFormat zu zweimal "off" gefuehrt hat.
Ich habe autocreate jetzt erweitert, damit RESULT als
XX:stat/sonoff/RESULT:.* { json2nameValue($EVENT, 'RESULT_') }angelegt wird, d.h. Readings aus RESULT tragen den zusaetzlichen Praefix RESULT_. Damit steigt zwar die Zahl der Readings weiter (POWER1 und RESULT_POWER1), aber wenigstens gibt es keine doppelten Events.Wuerde mich freuen, wenn jemand das noch verifiziert.
Achtung: die Aenderung betrifft nur neu erweiterte ReadingList, die alten muss man manuell korrigieren.
Danke für das Feedback bisher.
Rudolf, ich habe mein Device schon "ausgemistet" und abonniere ja nur noch den Topic "readingList DVES_9D7CEE:stat/sonoff_wz_dual/POWER1:.* POWER1" daher schließe ich das Doppelte Event darüber mal aus.
Wenn der neue Status über MQTT reinkommt, sprich ich den Sonoff in der Tasmotaoberfläche schalte, oder den cmnd-Topic direkt anspreche, dann habe ich nur ein Event auf "state".
Daher gehe ich fest davon aus, dass wenn ich in FHEM direkt schalte, das zusätzliche "state" über "set mqtt_sw_wz_holzlampe on/off" kommt. Kann das so sein?
Ich teste deinen Vorschlag nachher aber gern, wenn ich wieder zu Hause bin.
ZitatAn sich müßte das Problem aber eigentlich bei allen bisherigen MQTT-Modulen bestehen, da viele Implementierungen auf der Client-Seite so gestrickt sind, dass sie eine Rückmeldung erzeugen, wenn der Befehl umgesetzt wurde. Von daher wäre zu überlegen, ob man nicht eine (deaktivierbare) set_xx-Logik einbauen könnte, so wie das z.B. bei CUL_HM der Fall ist? Ist aber vermutlich nicht ganz easy...
So ein bißchen ist das auch mein Mantra. "Bei CUL_HM funktioniert das ja" :-)
ZitatDie Lösung heißt - getrennte Topics für das Befehl und die Rückmeldung. Dann ändert sich der Zustand dann (und nur dann), wenn es wirklich geschaltet wurde. Unabhängig davon, woher das Schaltbefehl kam.
Prinzipiell eine gute Lösung. Wenn ich logisch verstanden habe.
Aber du gehst den Weg über Dummy und ein weiteres Modul. Das wollte ich mir vorerst sparen.
Bzw. der Umstieg auf MQTT2 war auch zurück zu "weniger ist mehr" ;-)
ZitatPrinzipiell eine gute Lösung. Wenn ich logisch verstanden habe.
Aber du gehst den Weg über Dummy und ein weiteres Modul. Das wollte ich mir vorerst sparen.
Dieses weitere Modul ist nur einmal vorhanden und erlaubt dafür sämtliche mqtt_devices einzusparen. Weniger ist mehr ;)
ZitatDie Lösung heißt - getrennte Topics für das Befehl und die Rückmeldung.
Ich fuerchte wir (mich inklusive) mischen hier unterschiedliche Sachen:
- ein "set XX on" erzeugt ein Event "XX on".
- die Rueckmeldung vom Geraet erzeugt "XX POWER1 on". Mit dem neuen Syntax eins weniger, aber kein "XX on"
- stateFormat setzt nur den Internal STATE, wg der Anzeige. Hat nichts mit Events zu tun.
- mit MQTT2_CLIENT+mosquitto+Tasmota kriegt man immer noch 2x POWER1: einmal aus dem gesendeten cmnds/sonoff/POWER1 (was mosquitto zurueckschickt), und einmal aus stat/sonoff/POWER1. Weiss noch nicht, wie ich das vermeiden soll
- mit MQTT2_SERVER gibts dieses Problem nicht.
=> Damit ist fuer mich das doppelte "XX on" aus dem ersten Beitrag noch nicht erklaert.
Danke für die Infos, da nehme ich auf jeden Fall wieder was mit.
Dass stateFormat nur den Internal STATE setzt und kein Event auslöst wusste ich nicht.
Also ich setze MQTT2_SERVER ein.
ZitatDamit ist fuer mich das doppelte "XX on" aus dem ersten Beitrag noch nicht erklaert.
Vermutlich kann ich es jetzt erklären.
das
attr <dev> eventMap { dev=>{ON=>'on',OFF=>'off'} } schlägt da gnadenlos, auf alles was ON/OFF ist, zu.
Das erste "XX on" ist mein "set XX on" aus der Weboberfläche das zweite "XX on" ist eigentlich "POWER1 ON" was ja von eventMap gändert wurde.
Ich musste mein Sonoff DUAL als Testgerät aufgeben und habe einen Sonoff Zwischenstecker per autocreate angelegt.
Da fiel es mir dann auch auf.
Beim Schalten aus der Weboberfläche heraus.
- ohne eventMap:
2018-11-24 23:15:52 MQTT2_DEVICE MQTT2_DVES_3E0F61 on
2018-11-24 23:15:52 MQTT2_DEVICE MQTT2_DVES_3E0F61 RESULT_POWER: ON
2018-11-24 23:15:52 MQTT2_DEVICE MQTT2_DVES_3E0F61 POWER: ON- mit eventMap:
2018-11-24 23:16:19 MQTT2_DEVICE MQTT2_DVES_3E0F61 on
2018-11-24 23:16:19 MQTT2_DEVICE MQTT2_DVES_3E0F61 on
2018-11-24 23:16:19 MQTT2_DEVICE MQTT2_DVES_3E0F61 onIrgendwie bin ich nun unsicherer als zuvor.
Auf state schalte ich das Device, aber auf state möchte ich auch das Feedback sehen. Das muss ja unweigerlich zwei Events erzeugen. Muss ich mich damit anfreunden, dass ich ein anderes reading (gleich POWER) als Feedback hernehme um z.B. den Zustand in Alexa oder Homekit zu sehen? Aber auf der anderen Seite muss state ja auch den aktuellen Zustand vom Device bekommen, da es sonst im WebIF nicht den genauen Status anzeigt. Ich dreh mich irgendwie im Kreis.
Kurzer Geistesblitz
vor um Mitternacht:
Vielleicht kann man ja RESULT_POWER hernehmen um mit eventMap den state zu setzen, und auf POWER triggert man einfach weiterführende Aktionen und hat eben keine Doppelaktionen mehr.
Danke fuer die Recherche.
So muesste man eventMap anpassen, damit das passiert, was ich eigentlich wollte:
attr DEVICE eventMap { dev=>{'^(.*)POWER(.): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.): ON$'=>'$1POWER$2: on'} }
Allerdings ist STATE dank stateFormat immer noch ON/OFF, da stateFormat auf das Reading zugreift, und eventMap die Events aendert, nicht die Readings selbst. Und ON/OFF erzeugt beim draufklicken kein toggle, dazu braucht man on/off.
Also muss stateFormat angepasst werden:attr DEVICE stateFormat {lc ReadingsVal("$name","POWER1",0)}
Aber dann ist eventMap ueberfluessig.
=> ich habe in attrTemplate das umgebauten stateFormat eingebaut und eventMap entfernt. Schalten erzeugt Folgendes:fhem> set MQTT2_mc off
2018-11-25 09:31:28 MQTT2_DEVICE MQTT2_mc off
2018-11-25 09:31:28 MQTT2_DEVICE MQTT2_mc RESULT_POWER1: OFF
2018-11-25 09:31:28 MQTT2_DEVICE MQTT2_mc POWER1: OFF
Wg. dem Geistesblitz: Beide Events kommen vom Geraet, ich verstehe noch nicht, warum RESULT_POWER1 besser sein soll als POWER1.
ZitatSo muesste man eventMap anpassen, ...
[...]
Also muss stateFormat angepasst werden:
Hätte ich so nie hinbekommen, dankeschön!
ZitatSchalten erzeugt Folgendes:
Ja, bestätige ich! ;-)
Also heißt es zusammenfassend für mich.
Auf "state" schalte ich intern, wenn bspw. mittels notify, die Steckdose durch ein Event ausgelöst werden soll.
<dev>:event { fhem "set Steckdose on/off" }Auf POWER oder RESULT_POWER (man kann den Topic ja auch entfernen und spart sich wieder ein Reading) reagiere ich, wenn in Abhängigkeit dessen Status weiteres passieren soll, oder ich den aktuellen Schaltzustand sowohl in Homekit oder Alexa darstellen möchte.
Vielen Dank für den Austausch, hat mich definitiv weitergebracht.
Ich hoffe mit meiner dummen Fragerei, konnte ich auch ein wenig für Inspiration sorgen.
Mir gefällt das mit den z.B. mit den Präfixen in den Readings richtig gut.
ZitatWg. dem Geistesblitz: Beide Events kommen vom Geraet, ich verstehe noch nicht, warum RESULT_POWER1 besser sein soll als POWER1.
Es war spät und wir hatten gestern Kindergeburtstag. ;-)
Die Kapitulation vor meiner eigenen Unfähigkeit, hat mir nochmal einen anderen Weg aufgezeigt.
Warum das ganze? Weil ich es einfach nicht hinbekommen habe, Alexa zu zeigen welchen Zustand das Device gerade hat, in Homekit lief es perfekt.
Ich manipuliere jetzt state über userReadings state:RESULT_POWER.* {lc ReadingsVal("$name","RESULT_POWER",0)}
und entprelle das ganze in event-on-change-reading .* auf.
Wenn ich nun über WebIF schalte:
2018-11-25 17:04:36 MQTT2_DEVICE MQTT2_DVES_3E0F61 on
2018-11-25 17:04:36 MQTT2_DEVICE MQTT2_DVES_3E0F61 RESULT_POWER: ON
2018-11-25 17:04:36 MQTT2_DEVICE MQTT2_DVES_3E0F61 POWER: ON
und über extern:
2018-11-25 17:05:09 MQTT2_DEVICE MQTT2_DVES_3E0F61 RESULT_POWER: OFF
2018-11-25 17:05:09 MQTT2_DEVICE MQTT2_DVES_3E0F61 off
2018-11-25 17:05:09 MQTT2_DEVICE MQTT2_DVES_3E0F61 POWER: OFF
Damit kann ich leben, Siri war eh schon glücklich, und der digitale Sprachassisten eine großen Onlineversenders, dess Name bei uns nicht genannt werden darf, ist es nun auch.
Internals:
CID DVES_3E0F61
DEF DVES_3E0F61
DEVICETOPIC MQTT2_DVES_3E0F61
IODev mqtt2_server
LASTInputDev mqtt2_server
MSGCNT 175
NAME MQTT2_DVES_3E0F61
NR 261
STATE off
TYPE MQTT2_DEVICE
mqtt2_server_MSGCNT 175
mqtt2_server_TIME 2018-11-25 16:58:45
OLDREADINGS:
READINGS:
2018-11-25 11:46:23 INFO1_FallbackTopic DVES_3E0F61
2018-11-25 11:46:23 INFO1_GroupTopic sonoffs
2018-11-25 11:46:23 INFO1_Module Sonoff S2X
2018-11-25 11:46:23 INFO1_Version 6.3.0
2018-11-25 11:46:23 INFO2_Hostname teststecki-3937
2018-11-25 11:46:23 INFO2_IPAddress 192.168.178.75
2018-11-25 11:46:23 INFO2_WebServerMode Admin
2018-11-25 11:46:23 INFO3_RestartReason Power on
2018-11-25 14:20:41 LWT online
2018-11-25 16:57:49 POWER OFF
2018-11-25 16:57:49 RESULT_POWER OFF
2018-11-25 16:58:45 STATE_POWER OFF
2018-11-25 16:58:45 STATE_Time 2018-11-25T16:58:34
2018-11-25 16:58:45 STATE_Uptime 0T05:12:19
2018-11-25 16:58:45 STATE_Vcc 3.170
2018-11-25 16:58:45 STATE_Wifi_AP 1
2018-11-25 16:58:45 STATE_Wifi_BSSId E0:28:6D:D2:72:AF
2018-11-25 16:58:45 STATE_Wifi_Channel 1
2018-11-25 16:58:45 STATE_Wifi_RSSI 98
2018-11-25 16:58:45 STATE_Wifi_SSId FRITZ!Box 7490
2018-11-25 16:02:03 UPTIME_Time 2018-11-25T16:02:00
2018-11-25 16:02:03 UPTIME_Uptime 0T04:15:45
2018-11-25 16:23:38 alexa_state off
2018-11-25 16:57:49 state off
Attributes:
DbLogExclude .*
IODev mqtt2_server
alexaName Teststecki
event-on-change-reading .*
genericDeviceType switch
readingList DVES_3E0F61:stat/teststecki/POWER:.* POWER
DVES_3E0F61:tele/teststecki/LWT:.* LWT
DVES_3E0F61:tele/teststecki/INFO1:.* { json2nameValue($EVENT, 'INFO1_') }
DVES_3E0F61:tele/teststecki/INFO2:.* { json2nameValue($EVENT, 'INFO2_') }
DVES_3E0F61:tele/teststecki/INFO3:.* { json2nameValue($EVENT, 'INFO3_') }
DVES_3E0F61:tele/teststecki/STATE:.* { json2nameValue($EVENT, 'STATE_') }
DVES_3E0F61:tele/teststecki/UPTIME:.* { json2nameValue($EVENT, 'UPTIME_') }
DVES_3E0F61:stat/teststecki/RESULT:.* { json2nameValue($EVENT, 'RESULT_') }
room Homekit,MQTT2_DEVICE,alexa
setList off:noArg cmnd/teststecki/POWER 0
on:noArg cmnd/teststecki/POWER 1
siriName Teststecki
userReadings state:RESULT_POWER.* {lc ReadingsVal("$name","RESULT_POWER",0)}
Zitat2018-11-25 17:04:36 MQTT2_DEVICE MQTT2_DVES_3E0F61 POWER: ON
Kannst du mir sagen, was fuer ein Geraet/Firmware das ist?
Die templates kennen bisher nur POWER1/POWER2.
Ein Sonoff S26 Zwischenstecker
Das ist die Version:
Tasmota Version 6.3.0
Build-Datum & -Uhrzeit 2018.10.30 17:39:28
Core-/SDK-Version 2_3_0/1.5.3(aec24ac9)
Den POWER1- und POWER2-Pfad kenne ich bisher nur aus dem Sonoff DUAL.
Das spuckt der Sonoff Basic beim Neustart aus, der verhält sich analog zum S26:
00:00:00 Projekt sonoff Sonoff_ke_LEDLicht (Topic sonoff_ke_ledlicht, Fallback sonoff_ke_ledlicht, GroupTopic sonoffs) Version 6.3.0-2_3_0
00:00:00 WIF: verbinden mit AP1 FRITZ!Box 7490 in Modus 11N wie sonoff_ke_ledlicht-5352...
00:00:06 WIF: verbunden
00:00:06 DNS: initialisiert
00:00:06 HTP: Web-Server aktiv bei sonoff_ke_ledlicht-5352.local mit IP-Adresse 192.168.178.38
00:00:06 MQT: Verbindungsversuch...
00:00:06 MQT: verbunden
00:00:06 MQT: tele/sonoff_ke_ledlicht/LWT = online (beibehalten)
00:00:06 MQT: cmnd/sonoff_ke_ledlicht/POWER =
00:00:06 MQT: tele/sonoff_ke_ledlicht/INFO1 = {"Module":"Sonoff Basic","Version":"6.3.0","FallbackTopic":"sonoff_ke_ledlicht","GroupTopic":"sonoffs"}
00:00:06 MQT: tele/sonoff_ke_ledlicht/INFO2 = {"WebServerMode":"Admin","Hostname":"sonoff_ke_ledlicht-5352","IPAddress":"192.168.178.38"}
00:00:06 MQT: tele/sonoff_ke_ledlicht/INFO3 = {"RestartReason":"Software/System restart"}
00:00:06 MQT: stat/sonoff_ke_ledlicht/RESULT = {"POWER":"OFF"}
00:00:06 MQT: stat/sonoff_ke_ledlicht/POWER = OFF
18:32:16 MQT: tele/sonoff_ke_ledlicht/STATE = {"Time":"2018-11-25T18:32:15","Uptime":"0T00:00:15","Vcc":3.179,"POWER":"OFF","Wifi":{"AP":1,"SSId":"FRITZ!Box 7490","BSSId":"E0:28:6D:D2:72:AF","Channel":1,"RSSI":80}}
18:32:16 MQT: domoticz/in = {"idx":1,"nvalue":0,"svalue":"17.7;51.8;1","Battery":58,"RSSI":8}
18:32:16 MQT: tele/sonoff_ke_ledlicht/SENSOR = {"Time":"2018-11-25T18:32:16","AM2301":{"Temperature":17.7,"Humidity":51.8},"TempUnit":"C"}
und so registriert ihn autocreate.
Internals:
CFGFN
CID sonoff_ke_ledlicht
DEF sonoff_ke_ledlicht
DEVICETOPIC MQTT2_sonoff_ke_ledlicht
IODev mqtt2_server
LASTInputDev mqtt2_server
MSGCNT 33
NAME MQTT2_sonoff_ke_ledlicht
NR 325
STATE off
TYPE MQTT2_DEVICE
mqtt2_server_MSGCNT 33
mqtt2_server_TIME 2018-11-25 18:32:15
READINGS:
2018-11-25 18:32:07 INFO1_FallbackTopic sonoff_ke_ledlicht
2018-11-25 18:32:07 INFO1_GroupTopic sonoffs
2018-11-25 18:32:07 INFO1_Module Sonoff Basic
2018-11-25 18:32:07 INFO1_Version 6.3.0
2018-11-25 18:32:07 INFO2_Hostname sonoff_ke_ledlicht-5352
2018-11-25 18:32:07 INFO2_IPAddress 192.168.178.38
2018-11-25 18:32:07 INFO2_WebServerMode Admin
2018-11-25 18:32:07 INFO3_RestartReason Software/System restart
2018-11-25 18:32:07 LWT online
2018-11-25 18:32:07 POWER OFF
2018-11-25 18:32:07 RESULT_POWER OFF
2018-11-25 18:32:15 SENSOR_AM2301_Humidity 51.8
2018-11-25 18:32:15 SENSOR_AM2301_Temperature 17.7
2018-11-25 18:32:15 SENSOR_TempUnit C
2018-11-25 18:32:15 SENSOR_Time 2018-11-25T18:32:16
2018-11-25 18:32:15 STATE_POWER OFF
2018-11-25 18:32:15 STATE_Time 2018-11-25T18:32:15
2018-11-25 18:32:15 STATE_Uptime 0T00:00:15
2018-11-25 18:32:15 STATE_Vcc 3.179
2018-11-25 18:32:15 STATE_Wifi_AP 1
2018-11-25 18:32:15 STATE_Wifi_BSSId E0:28:6D:D2:72:AF
2018-11-25 18:32:15 STATE_Wifi_Channel 1
2018-11-25 18:32:15 STATE_Wifi_RSSI 80
2018-11-25 18:32:15 STATE_Wifi_SSId FRITZ!Box 7490
2018-11-25 18:32:15 in_Battery 58
2018-11-25 18:32:15 in_RSSI 8
2018-11-25 18:32:15 in_idx 1
2018-11-25 18:32:15 in_nvalue 0
2018-11-25 18:32:15 in_svalue 17.7;51.8;1
2018-11-25 18:28:06 state off
Attributes:
DbLogExclude .*
IODev mqtt2_server
readingList sonoff_ke_ledlicht:tele/sonoff_ke_ledlicht/LWT:.* LWT
sonoff_ke_ledlicht:cmnd/sonoff_ke_ledlicht/POWER:.* POWER
sonoff_ke_ledlicht:tele/sonoff_ke_ledlicht/INFO1:.* { json2nameValue($EVENT, 'INFO1_') }
sonoff_ke_ledlicht:tele/sonoff_ke_ledlicht/INFO2:.* { json2nameValue($EVENT, 'INFO2_') }
sonoff_ke_ledlicht:tele/sonoff_ke_ledlicht/INFO3:.* { json2nameValue($EVENT, 'INFO3_') }
sonoff_ke_ledlicht:stat/sonoff_ke_ledlicht/RESULT:.* { json2nameValue($EVENT, 'RESULT_') }
sonoff_ke_ledlicht:stat/sonoff_ke_ledlicht/POWER:.* POWER
sonoff_ke_ledlicht:tele/sonoff_ke_ledlicht/STATE:.* { json2nameValue($EVENT, 'STATE_') }
sonoff_ke_ledlicht:domoticz/in:.* { json2nameValue($EVENT, 'in_') }
sonoff_ke_ledlicht:tele/sonoff_ke_ledlicht/SENSOR:.* { json2nameValue($EVENT, 'SENSOR_') }
room MQTT2_DEVICE
setList on cmnd/sonoff_ke_ledlicht/POWER ON
off cmnd/sonoff_ke_ledlicht/POWER OFF
setlist habe ich natürlich manuell angelegt.
Habe auch eben bemerkt, dass der state nun automatisch (durchs Modul?) in lowercase geschrieben wird. top!
ZitatTasmota Version 6.3.0
Ich habe 6.1.1 mit POWER1. Oder liegt es an einem angepassten Firmware (meiner ist "original")?
Vermutlich muss ich die Templates umbauen, bin aber noch unentschlossen, wie.
Also ich habe mir die Binary runtergeladen, von https://github.com/arendst/Sonoff-Tasmota/releases
Ich kann es nicht mehr zu 100% bestätigen, aber auch unter 5.x hatte ich auf dem Basic nur einen Topic mit "POWER", die Nummerierung kenne ich nur von dem DUAL.
ZitatVermutlich muss ich die Templates umbauen, bin aber noch unentschlossen, wie.
Meinst du die attr-Templates?
Die passen ja IMHO momentan für den DUAL. So könntest du ein Template für den Basic mit hinzufügen.
In der Hoffnung, ich habe dich da richtig verstanden.
Edit:
Sorry, jetzt erst raffe ich den Unterschied in den Templates zwischen 1ch und 2ch.
Zitat von: rudolfkoenig am 26 November 2018, 11:04:41
Ich habe 6.1.1 mit POWER1. Oder liegt es an einem angepassten Firmware (meiner ist "original")?
Vermutlich muss ich die Templates umbauen, bin aber noch unentschlossen, wie.
Ich setzte auch die Tasmota 6.3 Release Firmware (d.h. ohne individuelle Änderungen) ein.
So sieht ein SONOFF
Basic Device mit einem Kanal nach autoCreate und Anwendung des Templates sonoff_tasmota_1ch aus.
fhem> list MQTT2_DVES_324190
Internals:
CFGFN
CID DVES_324190
DEF DVES_324190
DEVICETOPIC MQTT2_DVES_324190
IODev my_MQTT2
LASTInputDev my_MQTT2
MSGCNT 157
NAME MQTT2_DVES_324190
NR 281
STATE POWER1
TYPE MQTT2_DEVICE
my_MQTT2_MSGCNT 157
my_MQTT2_TIME 2018-11-26 13:58:36
READINGS:
2018-11-26 10:51:27 INFO1_FallbackTopic DVES_324190
2018-11-26 10:51:27 INFO1_GroupTopic sonoffs
2018-11-26 10:51:27 INFO1_Module Sonoff Basic
2018-11-26 10:51:27 INFO1_Version 6.3.0
2018-11-26 10:51:27 INFO2_Hostname sonoff-0400
2018-11-26 10:51:27 INFO2_IPAddress 192.168.8.89
2018-11-26 10:51:27 INFO2_WebServerMode Admin
2018-11-26 10:51:27 INFO3_RestartReason Power on
2018-11-26 13:17:53 LWT Online
2018-11-26 13:17:53 POWER
2018-11-26 10:35:33 RESULT_Command Unknown
2018-11-26 10:51:27 RESULT_POWER OFF
2018-11-26 10:42:37 RESULT_SaveData ON
2018-11-26 13:58:36 STATE_POWER OFF
2018-11-26 13:58:36 STATE_Time 2018-11-26T13:58:37
2018-11-26 13:58:36 STATE_Uptime 0T03:07:21
2018-11-26 13:58:36 STATE_Vcc 3.116
2018-11-26 13:58:36 STATE_Wifi_AP 1
2018-11-26 13:58:36 STATE_Wifi_BSSId 5C:49:79:7C:93:A7
2018-11-26 13:58:36 STATE_Wifi_Channel 13
2018-11-26 13:58:36 STATE_Wifi_RSSI 100
2018-11-26 13:58:36 STATE_Wifi_SSId TobiVision
2018-11-26 10:42:33 STATUS5_StatusNET_DNSServer 192.168.8.1
2018-11-26 10:42:33 STATUS5_StatusNET_Gateway 192.168.8.1
2018-11-26 10:42:33 STATUS5_StatusNET_Hostname sonoff-0400
2018-11-26 10:42:33 STATUS5_StatusNET_IPAddress 192.168.8.89
2018-11-26 10:42:33 STATUS5_StatusNET_Mac 80:7D:3A:32:41:90
2018-11-26 10:42:33 STATUS5_StatusNET_Subnetmask 255.255.255.0
2018-11-26 10:42:33 STATUS5_StatusNET_Webserver 2
2018-11-26 10:42:33 STATUS5_StatusNET_WifiConfig 5
2018-11-26 10:42:29 STATUS_Status_ButtonRetain 0
2018-11-26 10:42:29 STATUS_Status_ButtonTopic 0
2018-11-26 10:42:29 STATUS_Status_FriendlyName_1 Sonoff
2018-11-26 10:42:29 STATUS_Status_LedState 1
2018-11-26 10:42:29 STATUS_Status_Module 1
2018-11-26 10:42:29 STATUS_Status_Power 0
2018-11-26 10:42:29 STATUS_Status_PowerOnState 3
2018-11-26 10:42:29 STATUS_Status_PowerRetain 0
2018-11-26 10:42:29 STATUS_Status_SaveData 1
2018-11-26 10:42:29 STATUS_Status_SaveState 1
2018-11-26 10:42:29 STATUS_Status_SensorRetain 0
2018-11-26 10:42:29 STATUS_Status_SwitchMode_1 0
2018-11-26 10:42:29 STATUS_Status_SwitchMode_2 0
2018-11-26 10:42:29 STATUS_Status_SwitchMode_3 0
2018-11-26 10:42:29 STATUS_Status_SwitchMode_4 0
2018-11-26 10:42:29 STATUS_Status_SwitchMode_5 0
2018-11-26 10:42:29 STATUS_Status_SwitchMode_6 0
2018-11-26 10:42:29 STATUS_Status_SwitchMode_7 0
2018-11-26 10:42:29 STATUS_Status_SwitchRetain 0
2018-11-26 10:42:29 STATUS_Status_SwitchTopic 0
2018-11-26 10:42:29 STATUS_Status_Topic sonoff
2018-11-26 13:01:59 UPTIME_Time 2018-11-26T13:02:00
2018-11-26 13:01:59 UPTIME_Uptime 0T02:10:44
Attributes:
IODev my_MQTT2
eventMap { dev=>{ON=>'on',OFF=>'off'} }
readingList DVES_324190:tele/sonoff/LWT:.* LWT
DVES_324190:cmnd/sonoff/POWER:.* POWER
DVES_324190:tele/sonoff/INFO1:.* { json2nameValue($EVENT, 'INFO1_') }
DVES_324190:tele/sonoff/INFO2:.* { json2nameValue($EVENT, 'INFO2_') }
DVES_324190:tele/sonoff/INFO3:.* { json2nameValue($EVENT, 'INFO3_') }
DVES_324190:stat/sonoff/RESULT:.* { json2nameValue($EVENT, 'RESULT_') }
DVES_324190:stat/sonoff/POWER:.* POWER
DVES_324190:tele/sonoff/STATE:.* { json2nameValue($EVENT, 'STATE_') }
DVES_324190:stat/sonoff/STATUS5:.* { json2nameValue($EVENT, 'STATUS5_') }
DVES_324190:stat/sonoff/STATUS:.* { json2nameValue($EVENT, 'STATUS_') }
DVES_324190:tele/sonoff/UPTIME:.* { json2nameValue($EVENT, 'UPTIME_') }
room MQTT2_DEVICE
setList off:noArg cmnd/sonoff/POWER1 0
on:noArg cmnd/sonoff/POWER1 1
toggle:noArg cmnd/sonoff/POWER1 2
stateFormat POWER1Damit der Zustand richtig im FHEM Web Frontend angezeigt wird, musste ich stateFormat von POWER1 auf POWER ändern. Bei der setList war keine Änderung nötig. Auch die Homekit Integration funktioniert "out of the box".
Danke für das Modul.
Gruß
Tobias
ZitatDamit der Zustand richtig im FHEM Web Frontend angezeigt wird, musste ich stateFormat von POWER1 auf POWER ändern.Bei der setList war keine Änderung nötig.
Ich habe jetzt ein tasmota_basic nach diesen Regeln angelegt. Die sonoff_tasmota2channel habe ich nach tasmota_2channel umbenannt, in der Hoffnung, dass es nicht sonoff spezifisch ist.Wuesste gerne, ob tasmota_1channel notwendig ist, oder nur ich habe es geschafft, mein sonoff basic falsch zu flashen.
ZitatAuch die Homekit Integration funktioniert "out of the box".
Was war dafuer zu tun?
Kann man sowas auch als attrTemplate vorstellen?
Homekit reagiert auf das Readings "state", zumindest ohne homebridgeMapping.
Ich vermute also, dass es nur "out of the box" läuft, wenn man das Sonoff-Device über das WebIF schaltet bzw. über set.
Zitat von: rudolfkoenig am 27 November 2018, 18:25:39
Was war dafuer zu tun?
Kann man sowas auch als attrTemplate vorstellen?
Für die Homekit Integration genügt es - zumindest bei 1-Kanal Switches - folgendes Attribut zu setzen - also auch per attrTemplate machbar:
attr <device> genericDeviceType switch
Üblicherweise wird die Device Selektion der HomeBridge über einen Raum gemacht. Diese Raumauswahl muss man dem User überlassen. In jedem Fall muss der homebridge service nach Hinzufügen eines neuen Device auch manuell neu gestartet werden, damit es in der Apple Home App sichtbar wird.
attr <device> room Homekit,MQTT2_DEVICE