Doppeltes Event auf state bei MQTT2_DEVICE (set ignorieren?)

[der-pw]

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 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

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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

[dev0]

Wie 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?

[der-pw]

... doch greifen, oder?

Kurz und knapp, ja! Manchmal sieht man den Wald vor lauter Bäumen nicht.

Danke fürs "wachrütteln". 

[der-pw]

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

[Beta-User]

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...

[hexenmeister]

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:

Code Auswählen Erweitern

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-long

EDIT: Das Beispiel setzt Nutzung von MQTT_GENERIC_BRIDGE voraus.

[Beta-User]

...an sich einleuchtend...
Paßt auch auf meine Beobachtungen zum Verhalten z.B. der Zigbee-Leuchten.

[rudolfkoenig]

Ich meine das Problem ist leicht anders gelagert.
Tasmota meldet das Schalten ueber zwei getrennte Topics:

stat/sonoff/POWER1:OFF
stat/sonoff/RESULT:{"POWER1":"OFF"}

Das bisherige autocreate hat das mit

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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.

[der-pw]

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.

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...

So ein bißchen ist das auch mein Mantra. "Bei CUL_HM funktioniert das ja"

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.

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"

[hexenmeister]

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.

Dieses weitere Modul ist nur einmal vorhanden und erlaubt dafür sämtliche mqtt_devices einzusparen. Weniger ist mehr 

[rudolfkoenig]

Die 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.

[der-pw]

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.

Damit 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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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 on

Irgendwie 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.

[rudolfkoenig]

Danke fuer die Recherche.

So muesste man eventMap anpassen, damit das passiert, was ich eigentlich wollte:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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.

[der-pw]

So muesste man eventMap anpassen, ...
[...]
Also muss stateFormat angepasst werden:

Hätte ich so nie hinbekommen, dankeschön!

Schalten 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.

Wg. 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.

[der-pw]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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)}

[rudolfkoenig]

2018-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.

[der-pw]

Ein Sonoff S26 Zwischenstecker
Das ist die Version:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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!

[rudolfkoenig]

Tasmota 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.

[der-pw]

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.

Vermutlich 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.

[tpm88]

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.

Code Auswählen Erweitern


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 POWER1

Damit 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

[rudolfkoenig]

Damit 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.

Auch die Homekit Integration funktioniert "out of the box".

Was war dafuer zu tun?
Kann man sowas auch als attrTemplate vorstellen?

[der-pw]

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.

[tpm88]

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:

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

attr <device> room  Homekit,MQTT2_DEVICE