Hallo,
ich bin am Einrichten meiner Weihnachtsbeleuchtung und möchte das ganze natürlich Smart machen. :) Habe hier ein paar Sonoff Steckdosen mit Tasmota. Diese möchte ich per MQTT steuern und auch in Homebridge einrichten um sie auch für die Frau bei Bedarf einfach steuern zu lassen. Ich habe folgendes Problem. Wenn ich eine Dose über FHEM ein- oder ausschalte aktualisiert sich der Status in Homebridge nicht. Umgekehrt geht es schon, also wenn ich über die Home-App schalte verändert sich der Status in FHEM sofort. Muss da irgendetwas zusätzlich konfiguriert werden? Bin im MQTT-Thema noch nicht so mega drin.
Hallo,
ein list vom Device wäre hilfreich ;)
list DeviceName
in FHEMWeb und die Ausgabe dann hier in "code-Tags" (das '#' im "Menü") posten...
Aber ich tippe schwer auf fehlendes/falsches homebridgeMapping ;)
Siehe hier: https://forum.fhem.de/index.php/topic,85310.msg776511.html#msg776511 und/oder hier https://forum.fhem.de/index.php/topic,83121.msg753436.html#msg753436
EDIT: oder selber mal im Forum nach "Tasmota mqtt homebridgeMapping" bzw. "Tasmota mqtt homekit" suchen ;)
Ansonsten mit mehr Info "wiederkommen" ;)
Gruß, Joachim
Hi und danke für die Info. Ja leider habe ich noch kein Homebridgemapping betrieben. Nach Eintragen des Mappings funktioniert das Schalten nur leider garnicht mehr. Habe ich vielleicht den Stecker falsch konfiguriert? Ist ein Sonoff S26.
Internals:
CID DVES_1C852C
DEF DVES_1C852C
DEVICETOPIC Sonoff3
IODev MQTT2_FHEM_Server
LASTInputDev MQTT2_FHEM_Server
MQTT2_FHEM_Server_MSGCNT 8
MQTT2_FHEM_Server_TIME 2019-12-01 22:00:44
MSGCNT 8
NAME Sonoff3
NR 440
STATE off
TYPE MQTT2_DEVICE
READINGS:
2019-12-01 22:00:44 Heap 15
2019-12-01 21:45:33 LWT Online
2019-12-01 22:00:44 LoadAvg 19
2019-12-01 22:00:44 POWER1 off
2019-12-01 11:51:59 SaveData on
2019-12-01 11:51:59 SetOption26 on
2019-12-01 22:00:44 Sleep 50
2019-12-01 22:00:44 SleepMode Dynamic
2019-12-01 11:51:58 StateText1 off
2019-12-01 11:51:58 StateText2 on
2019-12-01 11:51:58 StateText3 toggle
2019-12-01 11:51:59 StateText4 hold
2019-12-01 22:00:44 Time 2019-12-01T22:00:44
2019-12-01 22:00:44 Uptime 0T10:24:50
2019-12-01 21:49:35 state set_off
2019-12-01 21:46:22 subscriptions cmnd/DVES_1C852C_fb/# cmnd/sonoff3/# cmnd/sonoffs/#
Attributes:
IODev MQTT2_FHEM_Server
alias Wohnzimmer-Stern
autocreate 0
homebridgeMapping On=state,values=OFF:0;ON:1,cmdOff=OFF,cmdOn=ON
model A_01a_tasmota_basic_state_power1
readingList tele/sonoff3/LWT:.* LWT
tele/sonoff3/STATE:.* { json2nameValue($EVENT) }
tele/sonoff3/SENSOR:.* { json2nameValue($EVENT) }
tele/sonoff3/INFO.:.* { json2nameValue($EVENT) }
stat/sonoff3/RESULT:.* { json2nameValue($EVENT) }
room Homekit,Licht,MQTT,Steckdosen,Wohnzimmer
setList off:noArg cmnd/sonoff3/POWER1 0
on:noArg cmnd/sonoff3/POWER1 1
toggle:noArg cmnd/sonoff3/POWER1 2
on-for-timer {my $duration = $EVTPART1*10; 'cmnd/sonoff3/Backlog POWER1 1; delay '.$duration.'; POWER1 0'}
setStateList on off toggle
stateFormat POWER1
Ich kenne mich mit Sonoff/Tasmota/etc. nicht wirklich aus...
...aber du hast ja so einiges an Attributen und auch "eigenartige" Readings z.B. StateText1 usw.
Bei state steht auch set_off, das passt nat. nicht zu dem was du bei homebridgeMapping stehen hast...
Auch weiß ich nicht, was von dem Ganzen für ein-/ausschalten da ist...
Wie hast du denn das Device eingebunden!?
EDIT: ok MQTT_SERVER und MQTT_DEVICE... Selbst oder attrTemplate genutzt!?
Gruß, Joachim
Hast du dir mal die Templates zu dem Thema MQTT etc. angeschaut?
Wie geschrieben kenne ich das MQTT-Zeugs praktisch gar nicht...
...aber das homebridgeMapping muss nat. zu Status und Schaltbefehlen passen...
Also wo steht der Status (state hat ja aktuell set_off) und wie schaltest du ein/aus, also welcher set-Befehl...
Das dann eben ins homebridgeMapping...
Gruß, Joachim
Ich hab meine Sonoff_S20 mal endlich ausgekramt, nicht nur wegen des Threads, ich brauch sie jetzt eh zur Weihnachtszeit.
Die richtigen Suchworte wären MQTT2 TASMOTA POWER1 HOMEBRIDGE FHEM gewesen um fündig zu werden. ;)
Mit
attr Sonoff3 userReadings state:POWER1:.* {ReadingsVal($name,"POWER1","")}
sollte alles passen, ohne homebridgemapping.
Gruß
Thomas
@Joachim
Die komischen Readings wie StateText1,StateText2,StateText3, SaveData,SetOption26, sleep ... sind Statusmeldungen zu Einstellungen die man in der Tasmota-Konfiguration vorgenommen hat.
Die kann man auch suchen und landet immer hier (https://github.com/arendst/Tasmota/wiki/Commands) :P
Hi Tom,
danke!
Macht die "Sache" aber nicht wirklich übersichtlich(er)... ;)
Gruß, Joachim
Hmm, vermutlich sollte man die Tasmota-Templates auch dahingehend umbauen, dass man teilweise mit JSONMAP arbeitet? Das mit den userReadings gefällt mir nicht so...
Mal unterstellt, die Rückmeldung kommt über "stat":
...
stat/sonoff3/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE jsonMap POWER1:state
(Dann kann man ohne stateFormat und ohne userReadings auskommen).
Zitat von: TomLee am 01 Dezember 2019, 23:32:27
Mit
attr Sonoff3 userReadings state:POWER1:.* {ReadingsVal($name,"POWER1","")}
sollte alles passen, ohne homebridgemapping.
Gruß
Thomas
Das war das was ich gebraucht habe, vielen Dank, nun geht es!
Ich habe nun noch ein paar 433Mhz Steckdosen, bei dennen ich das gleiche Problem habe. Schalten geht, aber wenn ich per FHEM Schalte ändert sich der Status in Home nicht. Hier war auch kein Mapping hinterlegt, daher hab ich das Mapping von den Tasmota-Dosen hinterlegt. Danach ging wieder nichts. Habe dann alles klein geschrieben weil in den Readings nichts groß ist, aber leider wieder keine Statusübergabe. Könnt Ihr mir hierbei helfen? Ist ja wirklich nur ein on und off was hier übergeben wird. Leider verstehe ich das mit den Mappings noch nicht so ganz.
Internals:
Command sudo /opt/fhem/bin/sendElro -u 1 -i 2 -S
DEF sudo /opt/fhem/bin/sendElro -u 1 -i 2 -S 1 0
NAME DoseB
NR 69
OffValue 0
OnValue 1
STATE off
TYPE GenShellSwitch
READINGS:
2019-12-02 11:04:16 state off
Attributes:
alias Stehlampe Wohnzimmer
fm_type offbutton,onbutton,lamp
group Steckdosen
homebridgeMapping on=state,values=off:0;on:1,cmdOff=off,cmdOn=on
room Steckdosen,AllesÜbersicht,Homekit
Wenn du die Steckdosen über set Steckdose on/off schalten kannst und der Status in state steht, dann brauchst du normalerweise gar kein Mapping.
Allerdings würde ich mal einen genericDeviceType (switch!?) setzen...
Also genericDeviceType setzen und homebridgeMapping löschen...
Gruß, Joachim
Habe den genericDeviceType auf "light" gesetzt und das Mapping gelöscht. Geht leider noch nicht. Ich kann zwar in FHEM schalten, aber der Status ändert sich in Home nicht. Wenn ich dagegen in Home schalte ändert sich der Status in FHEM direkt. Bei genericDeviceType "switch" verhält es sich genauso.
Wo steht denn der Gerätestatus? state!?
Wie schaltest du ein/aus? set Gerät on / set Gerät off !?
EDIT: nach den Änderungen homekit/homebridge (oder was immer da läuft) neu gestartet bzw. neu "einlesen lassen"!?
Gruß, Joachim
Zitat von: marcel151 am 02 Dezember 2019, 11:07:47
Ich habe nun noch ein paar 433Mhz Steckdosen, bei dennen ich das gleiche Problem habe. Schalten geht, aber wenn ich per FHEM Schalte ändert sich der Status in Home nicht. Hier war auch kein Mapping hinterlegt, daher hab ich das Mapping von den Tasmota-Dosen hinterlegt. Danach ging wieder nichts. Habe dann alles klein geschrieben weil in den Readings nichts groß ist, aber leider wieder keine Statusübergabe. Könnt Ihr mir hierbei helfen? Ist ja wirklich nur ein on und off was hier übergeben wird. Leider verstehe ich das mit den Mappings noch nicht so ganz.
Das auch genauso bei meinen IT-Steckdosen (gewesen).
Hier waren die Suchwörter ;D
it homebridge 433 on off fhemum einen Hinweis zu finden es mal mit genericDeviceType light zu verwenden.
Ich weiß nicht warum aber dann wird der Status in Home korrekt angezeigt wird und zuvor mit switch nicht.
defmod it_Steckdose3 IT 0F0F0000F0 FF F0
attr it_Steckdose3 userattr deko deko_map structexclude
attr it_Steckdose3 IODev sduino
attr it_Steckdose3 ITclock 271
attr it_Steckdose3 ITrepetition 8
attr it_Steckdose3 alexaName weihnachtsbeleuchtung
attr it_Steckdose3 comment 0F0F0000F0 FF F0
attr it_Steckdose3 genericDeviceType light
attr it_Steckdose3 room Homekit,IT
setstate it_Steckdose3 off
setstate it_Steckdose3 2019-03-28 21:53:20 protocol V1
setstate it_Steckdose3 2019-12-02 13:20:59 state off
Zu dem jsonmap: das klappt so wie vorgeschlagen noch nicht, man muss zusätzlich noch setStateList on off toggle löschen.
Ehrlich gesagt hab ich das mit setStateList auch noch nicht verstanden / mich mit beschäftigt bisher war das für mich sinnlos. 8)
Also:
defmod MQTT2_Sonoff_S20 MQTT2_DEVICE DVES_12F2A2
attr MQTT2_Sonoff_S20 IODev MQTT2_Server
attr MQTT2_Sonoff_S20 autocreate 0
attr MQTT2_Sonoff_S20 comment NOTE: on-for-timer is limited to 18h max duration!
attr MQTT2_Sonoff_S20 event-on-change-reading .*
attr MQTT2_Sonoff_S20 icon hue_filled_outlet
attr MQTT2_Sonoff_S20 jsonMap POWER1:state
attr MQTT2_Sonoff_S20 model tasmota_basic_state_power1
attr MQTT2_Sonoff_S20 readingList tele/sonoffs20/LWT:.* LWT\
tele/sonoffs20/STATE:.* { json2nameValue($EVENT) }\
tele/sonoffs20/SENSOR:.* { json2nameValue($EVENT) }\
tele/sonoffs20/INFO.:.* { json2nameValue($EVENT) }\
stat/sonoffs20/RESULT:.* { json2nameValue($EVENT) }
attr MQTT2_Sonoff_S20 room Homekit,MQTT2_DEVICE
attr MQTT2_Sonoff_S20 setList off:noArg cmnd/sonoffs20/POWER1 0\
on:noArg cmnd/sonoffs20/POWER1 1\
toggle:noArg cmnd/sonoffs20/POWER1 2\
on-for-timer {my $duration = $EVTPART1 < 11.2 ? $EVTPART1*10 : $EVTPART1+100;; 'cmnd/sonoffs20/Backlog pulseTime1 '.$duration.';; POWER1 1'}\
setOtaUrl:textField cmnd/sonoffs20/OtaUrl $EVTPART1\
upgrade:noArg cmnd/sonoffs20/upgrade 1
setstate MQTT2_Sonoff_S20 off
setstate MQTT2_Sonoff_S20 2019-12-02 13:53:32 FallbackTopic DVES_12F2A2
setstate MQTT2_Sonoff_S20 2019-12-02 13:53:32 GroupTopic sonoffs
setstate MQTT2_Sonoff_S20 2019-12-02 13:53:32 Hostname sonoffs20-4770
setstate MQTT2_Sonoff_S20 2019-12-02 13:53:32 IPAddress 192.168.188.64
setstate MQTT2_Sonoff_S20 2019-12-02 13:53:32 LWT online
setstate MQTT2_Sonoff_S20 2019-12-02 13:53:32 Module Sonoff Basic
setstate MQTT2_Sonoff_S20 2019-12-02 13:53:32 POWER1 off
setstate MQTT2_Sonoff_S20 2019-12-02 13:53:25 Restart Restarting
setstate MQTT2_Sonoff_S20 2019-12-02 13:53:32 RestartReason Software/System restart
setstate MQTT2_Sonoff_S20 2019-12-01 23:09:35 SaveData on
setstate MQTT2_Sonoff_S20 2019-12-01 23:09:35 SetOption26 on
setstate MQTT2_Sonoff_S20 2019-12-01 23:09:34 StateText1 off
setstate MQTT2_Sonoff_S20 2019-12-01 23:09:34 StateText2 on
setstate MQTT2_Sonoff_S20 2019-12-01 23:09:35 StateText3 toggle
setstate MQTT2_Sonoff_S20 2019-12-01 23:09:35 StateText4 hold
setstate MQTT2_Sonoff_S20 2019-12-02 13:50:30 Time 2019-12-02T13:50:29
setstate MQTT2_Sonoff_S20 2019-12-02 13:50:30 Uptime 0T00:45:19
setstate MQTT2_Sonoff_S20 2019-12-02 13:50:30 Vcc 3.160
setstate MQTT2_Sonoff_S20 2019-12-02 13:53:32 Version 6.3.0
setstate MQTT2_Sonoff_S20 2019-12-02 13:53:32 WebServerMode Admin
setstate MQTT2_Sonoff_S20 2019-12-02 13:50:30 Wifi_AP 2
setstate MQTT2_Sonoff_S20 2019-12-02 13:50:30 Wifi_BSSId FC:EC:DA:FD:26:1A
setstate MQTT2_Sonoff_S20 2019-12-02 13:50:30 Wifi_Channel 6
setstate MQTT2_Sonoff_S20 2019-12-02 13:50:30 Wifi_RSSI 84
setstate MQTT2_Sonoff_S20 2019-12-02 13:50:30 Wifi_SSId FBF
setstate MQTT2_Sonoff_S20 2019-12-02 13:31:22 state off
Der Gerätestatus (on oder off) steht in state.
Das wird über sendelro gemacht
sudo /opt/fhem/bin/sendElro -u 1 -i 2 -S 1 0
1 für an und 0 für aus.
Habe jedes Mal nach einer Änderung Homebrigde einmal neu gestartet. Schalten funktioniert jeweils in FHEM und Home. Aber leider wird der Status beim Schalten in FHEM nicht an Home übergeben. Und wie gesagt, mit genericDeviceType funktioniert es nicht.
Marcel kannst du bitte deine Sonoff Steckdose auch mal dem jsonmap (wie in meinem Beispiel) und ohne userReadings, setStateList und statFormat konfigurieren. Wird bei dir dann auch der Status korrekt in Home angezeigt ?
Zitat von: marcel151 am 02 Dezember 2019, 14:00:02
Das wird über sendelro gemacht
sudo /opt/fhem/bin/sendElro -u 1 -i 2 -S 1 0
1 für an und 0 für aus.
Ja aber das ist ja der "native" Befehl, den das fhem-Device schickt/schicken muss...
...aber wie steuerst du das fhem-Device!?
Also das "Gerät/Device" DoseB !?
Doch sicher mit irgendwas wie:
set DoseB on
Denn (wie geschrieben):
entweder "erkennt" homebridge/homekit/wieauchimmer das Gerät "einfach so", also wie/wo der Status "steht" und wie "geschalten" wird...
...oder es muss eben über das homebridgeMapping "beigebracht" werden.
Wie der Name sagt: es wird das "Mapping" beschrieben (für homekit) zwischen dem was fhem hat/braucht und dem was für Homekit notwendig ist/dort "verstanden" wird...
Du kannst auch hier mal schauen:
https://wiki.fhem.de/wiki/Homebridge_User_Configs
https://wiki.fhem.de/wiki/Alexa_und_Mappings
Da alexa-fhem und homebridge und sogar (Teile von) ghome (oder wie genau die Umsetzung mit Google heißt) vom selben Entwickler kommen und ähnliche/gleiche Codebasis haben gehen (meist) auch Mappings der jeweils anderen "Geschmacksrichtungen" ;)
Gruß, Joachim
Zitat von: TomLee am 02 Dezember 2019, 14:08:24
Marcel kannst du bitte deine Sonoff Steckdose auch mal dem jsonmap (wie in meinem Beispiel) und ohne userReadings, setStateList und statFormat konfigurieren. Wird bei dir dann auch der Status korrekt in Home angezeigt ?
Ja das geht, allerdings schreibt er mir automatisch folgendes in die readingList:
DVES_1C766E:cmnd/sonoff1/POWER:.* POWER
DVES_1C766E:stat/sonoff1/POWER1:.* POWER1
DVES_1C766E:stat/sonoff1/RESULT:.* { json2nameValue($EVENT) }
DVES_1C766E:tele/sonoff1/STATE:.* { json2nameValue($EVENT) }
Aber wenn ich userReadings, setStateList und statFormat rausnehme geht es trotzdem noch.
Zitat von: MadMax-FHEM am 02 Dezember 2019, 14:12:16
Ja aber das ist ja der "native" Befehl, den das fhem-Device schickt/schicken muss...
...aber wie steuerst du das fhem-Device!?
Also das "Gerät/Device" DoseB !?
Doch sicher mit irgendwas wie:
set DoseB on
Denn (wie geschrieben):
entweder "erkennt" homebridge/homekit/wieauchimmer das Gerät "einfach so", also wie/wo der Status "steht" und wie "geschalten" wird...
...oder es muss eben über das homebridgeMapping "beigebracht" werden.
Wie der Name sagt: es wird das "Mapping" beschrieben (für homekit) zwischen dem was fhem hat/braucht und dem was für Homekit notwendig ist/dort "verstanden" wird...
Ja genau, mit set DoseB on oder off Schalte ich die Dose. Muss ich denn nun noch was in homebridgemapping packen?
Vielleicht solltest du die firmware erst mal aktualisieren (6.3 ist drauf, richtig?). Habe das zwar nicht im Detail verfolgt, denke aber, dass es da ein paar Änderungen gab, so dass es sowas ggf. gar nicht mehr gibt?
stat/sonoff1/POWER1:.* POWER1
Ansonsten wäre es einfach:
stat/sonoff1/POWER1:.* state
6.6.0 ist aktuell drauf. Allerdings habe ich mit den Sonoff-Steckdosen keine Probleme mehr, es klappt mittlerweile alles. Ich habe aktuell "nur" noch das beschriebene Problem mit den 433MHz Dosen, dass dort der Status nicht übergeben wird.
Hmm, wenn das auch in den aktuellen Versionen über STATTOPIC/POWER1 reinkommt, wäre es trotzdem die Frage, ob man es allg. gleich für alle Tasmota-templates nach state mappt (via readingList)?
Aktuell ist glaube 7.1.1.1, oder? Kann bei Gelegenheit die Steckdosen einmal updaten. :) Es wäre aber nett wenn Ihr mir auch noch bei dem zweiten Problem helfen könntet, auch wenn es nicht direkt zu MQTT passt.
EDIT: Wie heißt es so schön, never change a running system. Jetzt sind die Dosen auf 7.1.1.1 und die Statusübergabe hat da wieder nicht geklappt. Mit hinzufügen des userReadings :
userReadings state:POWER1:.* {ReadingsVal($name,"POWER1","")}
klappt es wieder.
Meine aktuelle Konfiguration:
Internals:
CID DVES_1C852C
DEF DVES_1C852C
DEVICETOPIC Sonoff3
FUUID 5de3978f-f33f-c236-6e7f-69ea3f20a5328cce
IODev MQTT2_FHEM_Server
LASTInputDev MQTT2_FHEM_Server
MQTT2_FHEM_Server_MSGCNT 52
MQTT2_FHEM_Server_TIME 2019-12-02 15:31:18
MSGCNT 52
NAME Sonoff3
NR 439
STATE off
TYPE MQTT2_DEVICE
READINGS:
2019-12-02 15:12:19 FallbackTopic cmnd/DVES_1C852C_fb/
2019-12-02 15:12:19 GroupTopic cmnd/sonoffs/
2019-12-02 15:27:23 Heap 27
2019-12-02 15:12:19 Hostname sonoff3-1324
2019-12-02 15:12:19 IPAddress 192.168.2.171
2019-12-02 15:12:19 LWT Online
2019-12-02 15:27:23 LoadAvg 19
2019-12-02 15:12:19 Module Sonoff Basic
2019-12-02 15:27:23 MqttCount 1
2019-12-02 15:09:43 OtaUrl http://thehackbox.org/tasmota/tasmota.bin
2019-12-02 15:31:18 POWER1 off
2019-12-02 15:12:19 RestartReason Software/System restart
2019-12-01 11:51:59 SaveData on
2019-12-01 11:51:59 SetOption26 on
2019-12-02 15:27:23 Sleep 50
2019-12-02 15:27:23 SleepMode Dynamic
2019-12-01 11:51:58 StateText1 off
2019-12-01 11:51:58 StateText2 on
2019-12-01 11:51:58 StateText3 toggle
2019-12-01 11:51:59 StateText4 hold
2019-12-02 15:27:23 Time 2019-12-02T15:27:22
2019-12-02 15:09:44 Upgrade Version 6.6.0 from http://thehackbox.org/tasmota/tasmota.bin
2019-12-02 15:27:23 Uptime 0T00:15:12
2019-12-02 15:27:23 UptimeSec 912
2019-12-02 15:12:19 Version 7.1.1.1(eb1785c-tasmota)
2019-12-02 15:12:19 WebServerMode Admin
2019-12-02 10:37:24 subscriptions cmnd/DVES_1C852C_fb/# cmnd/sonoff3/# cmnd/sonoffs/#
Attributes:
IODev MQTT2_FHEM_Server
alias Wohnzimmer-Stern
autocreate 0
model A_01a_tasmota_basic_state_power1
readingList tele/sonoff3/LWT:.* LWT
tele/sonoff3/STATE:.* { json2nameValue($EVENT) }
tele/sonoff3/SENSOR:.* { json2nameValue($EVENT) }
tele/sonoff3/INFO.:.* { json2nameValue($EVENT) }
stat/sonoff3/RESULT:.* { json2nameValue($EVENT) }
room Homekit,Licht,MQTT,Steckdosen,Wohnzimmer
setList off:noArg cmnd/sonoff3/POWER1 0
on:noArg cmnd/sonoff3/POWER1 1
toggle:noArg cmnd/sonoff3/POWER1 2
on-for-timer {my $duration = $EVTPART1*10; 'cmnd/sonoff3/Backlog POWER1 1; delay '.$duration.'; POWER1 0'}
userReadings userReadings state:POWER1:.* {ReadingsVal($name,"POWER1","")}
Komischerweise sieht das Attribut readingList bei einer anderen Dose anders aus:
readingList DVES_1C766E:cmnd/sonoff1/POWER:.* POWER
DVES_1C766E:stat/sonoff1/POWER1:.* POWER1
DVES_1C766E:stat/sonoff1/RESULT:.* { json2nameValue($EVENT) }
DVES_1C766E:tele/sonoff1/STATE:.* { json2nameValue($EVENT) }
DVES_1C766E:tele/sonoff1/LWT:.* LWT
DVES_1C766E:stat/sonoff1/UPGRADE:.* UPGRADE
DVES_1C766E:tele/sonoff1/INFO1:.* { json2nameValue($EVENT) }
DVES_1C766E:tele/sonoff1/INFO2:.* { json2nameValue($EVENT) }
DVES_1C766E:tele/sonoff1/INFO3:.* { json2nameValue($EVENT) }
Funktioniert aber genauso.
Zitat von: marcel151 am 02 Dezember 2019, 14:38:56
Ja genau, mit set DoseB on oder off Schalte ich die Dose. Muss ich denn nun noch was in homebridgemapping packen?
Drum wundert mich ja, dass es homebridge nicht automatisch erkennt...
Weil das eigentlich "Standard" ist, also Zustand in state und schalten per set DeviceName on/off...
Ansonsten vielleicht (also eigentlich nachdem was du schreibst):
homebridgeMapping clear On=state,valueOn=on,cmdOn=on,cmdOff=off
EDIT: und sicherheitshalber noch genericDeviceType
Hast du mal bei den Beispielen geschaut, ob etwas passt!?
Gruß, Joachim
Zitat von: MadMax-FHEM am 02 Dezember 2019, 15:34:04
Ansonsten vielleicht (also eigentlich nachdem was du schreibst):
homebridgeMapping clear On=state,valueOn=on,cmdOn=on,cmdOff=off
EDIT: und sicherheitshalber noch genericDeviceType
Hast du mal bei den Beispielen geschaut, ob etwas passt!?
Gruß, Joachim
Habe ich so gesetzt, meine Konfiguration sieht aktuell so aus:
Internals:
Command sudo /opt/fhem/bin/sendElro -u 1 -i 2 -S
DEF sudo /opt/fhem/bin/sendElro -u 1 -i 2 -S 1 0
NAME DoseB
NR 69
OffValue 0
OnValue 1
STATE off
TYPE GenShellSwitch
READINGS:
2019-12-02 15:40:12 state off
Attributes:
alias Stehlampe Wohnzimmer
fm_type offbutton,onbutton,lamp
genericDeviceType light
group Steckdosen
homebridgeMapping clear On=state,valueOn=on,cmdOn=on,cmdOff=off
room Steckdosen,AllesÜbersicht,Homekit
Schalten funktioniert sowohl per FHEM als auch per Home App. Wenn ich in Home schalte ändert FHEM sofort den Status, wenn ich dagegen in FHEM schalte tut sich in Home nichts.
Zitat von: marcel151 am 02 Dezember 2019, 15:07:33
Meine aktuelle Konfiguration:
[...]
Wenn das neue auf ohne
DVES_1C766E:stat/sonoff1/POWER1:.* POWER1
auskommt, wird (neuerdings?) POWER1 via JSON übertragen. Wenn das so ist (?), dann BITTE das mit JSONMAP testen.
Wenn ich weiß, was ich wo eintragen muss helfe ich gerne. Wo darf ich was an der Konfiguration ändern?
Du kannst eine Kopie des Devices anfertigen und damit gefahrlos rumtesten. Ansonsten stand die Anleitung eigentlich schon hier:
Zitat von: Beta-User am 02 Dezember 2019, 07:46:06
Hmm, vermutlich sollte man die Tasmota-Templates auch dahingehend umbauen, dass man teilweise mit JSONMAP arbeitet? Das mit den userReadings gefällt mir nicht so...
Mal unterstellt, die Rückmeldung kommt über "stat":
...
stat/sonoff3/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE jsonMap POWER1:state
(Dann kann man ohne stateFormat und ohne userReadings auskommen).
Wenn stat falsch ist: ggf. mal den MQTT-Verkehr abhören oder auch die JSON-Blobs als Readinginhalt abfangen.
Dazu die Zeile doppeln:
stat/sonoff3/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }stat/sonoff3/RESULT:.* JSON_RESULT
Warum so umständlich man sieht doch schön in der Konsole auf der Tasmotaoberfläche was da ständig per MQTT rausgeht ?
00:00:00 CFG: aus Flash geladen am FA, zählen 2680
00:00:00 Projekt sonoff SonoffObi Version 6.6.0(release-sonoff)-2_3_0
00:00:00 WIF: verbinden mit AP1 FBF in Modus 11N als sonoffOBI-6183...
00:00:07 WIF: verbunden
00:00:07 HTP: Web-Server aktiv bei sonoffOBI-6183 mit IP-Adresse 192.168.188.68
15:34:08 MQT: Verbindungsversuch...
15:34:08 MQT: verbunden
15:34:08 MQT: tele/sonoffOBI/LWT = Online (beibehalten)
15:34:08 MQT: cmnd/sonoffOBI/POWER =
15:34:08 MQT: tele/sonoffOBI/INFO1 = {"Module":"Generic","Version":"6.6.0(release-sonoff)","FallbackTopic":"cmnd/DVES_55F827_fb/","GroupTopic":"sonoffs"}
15:34:08 MQT: tele/sonoffOBI/INFO2 = {"WebServerMode":"Admin","Hostname":"sonoffOBI-6183","IPAddress":"192.168.188.68"}
15:34:08 MQT: tele/sonoffOBI/INFO3 = {"RestartReason":"Software/System restart"}
15:34:08 MQT: stat/sonoffOBI/RESULT = {"POWER1":"off"}
15:34:08 MQT: stat/sonoffOBI/POWER1 = off
15:34:16 MQT: tele/sonoffOBI/STATE = {"Time":"2019-12-02T15:34:16","Uptime":"0T00:00:17","Heap":15,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER1":"off","Wifi":{"AP":1,"SSId":"FBF","BSSId":"E8:DF:70:50:BB:5A","Channel":11,"RSSI":22,"LinkCount":1,"Downtime":"0T00:00:07"}}
15:35:36 MQT: stat/sonoffOBI/RESULT = {"POWER1":"off"}
15:35:36 MQT: stat/sonoffOBI/POWER1 = off
15:39:17 MQT: tele/sonoffOBI/STATE = {"Time":"2019-12-02T15:39:17","Uptime":"0T00:05:18","Heap":15,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER1":"off","Wifi":{"AP":1,"SSId":"FBF","BSSId":"E8:DF:70:50:BB:5A","Channel":11,"RSSI":22,"LinkCount":1,"Downtime":"0T00:00:07"}}
15:44:01 APP: Serielles Logging deaktiviert
15:44:18 MQT: tele/sonoffOBI/STATE = {"Time":"2019-12-02T15:44:18","Uptime":"0T00:10:19","Heap":15,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER1":"off","Wifi":{"AP":1,"SSId":"FBF","BSSId":"E8:DF:70:50:BB:5A","Channel":11,"RSSI":22,"LinkCount":1,"Downtime":"0T00:00:07"}}
15:44:26 MQT: stat/sonoffOBI/RESULT = {"PulseTime1":"120 (Active 120)"}
15:44:26 MQT: stat/sonoffOBI/RESULT = {"POWER1":"on"}
15:44:26 MQT: stat/sonoffOBI/POWER1 = on
15:44:46 MQT: stat/sonoffOBI/RESULT = {"POWER1":"off"}
15:44:46 MQT: stat/sonoffOBI/POWER1 = off
15:45:21 MQT: stat/sonoffOBI/RESULT = {"POWER1":"off"}
15:45:21 MQT: stat/sonoffOBI/POWER1 = off
15:49:18 MQT: tele/sonoffOBI/STATE = {"Time":"2019-12-02T15:49:18","Uptime":"0T00:15:19","Heap":15,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER1":"off","Wifi":{"AP":1,"SSId":"FBF","BSSId":"E8:DF:70:50:BB:5A","Channel":11,"RSSI":24,"LinkCount":1,"Downtime":"0T00:00:07"}}
15:54:18 MQT: tele/sonoffOBI/STATE = {"Time":"2019-12-02T15:54:18","Uptime":"0T00:20:19","Heap":14,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER1":"off","Wifi":{"AP":1,"SSId":"FBF","BSSId":"E8:DF:70:50:BB:5A","Channel":11,"RSSI":22,"LinkCount":1,"Downtime":"0T00:00:07"}}
15:59:18 MQT: tele/sonoffOBI/STATE = {"Time":"2019-12-02T15:59:18","Uptime":"0T00:25:19","Heap":15,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER1":"off","Wifi":{"AP":1,"SSId":"FBF","BSSId":"E8:DF:70:50:BB:5A","Channel":11,"RSSI":24,"LinkCount":1,"Downtime":"0T00:00:07"}}
16:04:18 MQT: tele/sonoffOBI/STATE = {"Time":"2019-12-02T16:04:18","Uptime":"0T00:30:19","Heap":15,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER1":"off","Wifi":{"AP":1,"SSId":"FBF","BSSId":"E8:DF:70:50:BB:5A","Channel":11,"RSSI":24,"LinkCount":1,"Downtime":"0T00:00:07"}}
16:09:18 MQT: tele/sonoffOBI/STATE = {"Time":"2019-12-02T16:09:18","Uptime":"0T00:35:19","Heap":15,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER1":"off","Wifi":{"AP":1,"SSId":"FBF","BSSId":"E8:DF:70:50:BB:5A","Channel":11,"RSSI":24,"LinkCount":1,"Downtime":"0T00:00:07"}}
16:14:20 MQT: tele/sonoffOBI/STATE = {"Time":"2019-12-02T16:14:20","Uptime":"0T00:40:21","Heap":15,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER1":"off","Wifi":{"AP":1,"SSId":"FBF","BSSId":"E8:DF:70:50:BB:5A","Channel":11,"RSSI":24,"LinkCount":1,"Downtime":"0T00:00:07"}}
16:19:21 MQT: tele/sonoffOBI/STATE = {"Time":"2019-12-02T16:19:20","Uptime":"0T00:45:21","Heap":14,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER1":"off","Wifi":{"AP":1,"SSId":"FBF","BSSId":"E8:DF:70:50:BB:5A","Channel":11,"RSSI":24,"LinkCount":1,"Downtime":"0T00:00:07"}}
Ich schau später mal das ich eine Steckdose update.
Ich hab mich gerade mit zwei alten MQTT2_Device (2 Kanäle) beschäftigt, eins sah anders aus, da wurde mir das zum ersten mal setStateList klar. :P
:) Man sieht es, wenn man einen Tasmota hat...
(Also: richtig getippt, und vermutlich hat sich da auch nichts von V6 auf V7 geändert...)
(@TomLee: Deine Meinung, was das JSON-mappen nach state angeht? Die Diskussion sollten wir aber ggf. nach Tasmota allgemein verlagern...)
Was setStateList angeht: Sorry, dass ich das überlesen hatte; vermutlich macht es bei den einkanaligen noch nicht den großen Unterschied, aber spätestens, wenn andere Readings gesetzt werden sollen, wird es interessanter...
Zitat(@TomLee: Deine Meinung, was das JSON-mappen nach state angeht? Die Diskussion sollten wir aber ggf. nach Tasmota allgemein verlagern...)
Weiß nicht was du von mir hören willst, was ich weiß das es schonmal für die structure (Wehnachtsbeleuchtung) die ich heute angelegt habe brauchbar war, weil die steht auch auf undefined wenn in state set_... steht.
Will eigentlich nur wissen, ob du das via JSONMAP auch für zielführender/besser ansiehst als den Weg, erst ein anderes Reading (POWER1) entstehen zu lassen, nur um das dann via internem Eventhandler (userReading) wieder woanders hin zu packen...
Zitat von: marcel151 am 02 Dezember 2019, 15:42:25
Habe ich so gesetzt, meine Konfiguration sieht aktuell so aus:
Internals:
Command sudo /opt/fhem/bin/sendElro -u 1 -i 2 -S
DEF sudo /opt/fhem/bin/sendElro -u 1 -i 2 -S 1 0
NAME DoseB
NR 69
OffValue 0
OnValue 1
STATE off
TYPE GenShellSwitch
READINGS:
2019-12-02 15:40:12 state off
Attributes:
alias Stehlampe Wohnzimmer
fm_type offbutton,onbutton,lamp
genericDeviceType light
group Steckdosen
homebridgeMapping clear On=state,valueOn=on,cmdOn=on,cmdOff=off
room Steckdosen,AllesÜbersicht,Homekit
Schalten funktioniert sowohl per FHEM als auch per Home App. Wenn ich in Home schalte ändert FHEM sofort den Status, wenn ich dagegen in FHEM schalte tut sich in Home nichts.
Bist dann sicher, dass in state (also dem Reading state) immer der aktuelle Zustand ist und dass der auch on/off ist!?
Also auch genau so geschrieben!?
Gruß, Joachim
Zitat von: MadMax-FHEM am 02 Dezember 2019, 17:14:49
Bist dann sicher, dass in state (also dem Reading state) immer der aktuelle Zustand ist und dass der auch on/off ist!?
Ja bin ich. :) Siehe Anhänge.
Tja, dann weiß ich auch nicht, sorry...
Bei alexa-fhem gibt es ein Logfile (also NICHT fhem-Log) wo man sehen kann was jeweils hin und her geht...
Gibt es bei homebridge bestimmt auch, weiß nur nicht wo...
Wenn du das weißt, dann dort mal schauen...
...und/oder mal posten...
Gruß, Joachim
Wenn ich mich mit deinem Problem mit dem GenshellSwitch_Device beschäftige stosse ich auf den User Deespe der das Problem 2016 schilderte und bisher seine Lösung (wenn er eine hat) hier im Forum bisher nicht schilderte, mglw. bin ich einfältig aber es wird dann wsl. ich auch keine geben.
Wenn du keine Lösung findest kannst es (wie immer :P) mit einem zusätlichen Readingsproxy_Device lösen.
Dazu, bei Interesse, mal ein jsonlist2 DoseB zeigen, auch wenn bisher eigentlich klar das es die setter on/off gibt.
Zitat von: MadMax-FHEM am 02 Dezember 2019, 19:28:10
Bei alexa-fhem gibt es ein Logfile (also NICHT fhem-Log) wo man sehen kann was jeweils hin und her geht...
Gibt es bei homebridge bestimmt auch, weiß nur nicht wo...
Ich habe jetzt mal den Debugmodus von homebridge gestartet und habe folgende Erkenntnisse gewonnen:
Wenn ich die Steckdose über FHEM schalte passiert im Homebridge Log garnichts, was anscheinend genau mein Problem darstellt.
Wenn ich über die Home-App schalte (was wie gesagt funktioniert) steht dort folgendes:
[12/2/2019, 8:45:30 PM] [FHEM] DoseB: executing set cmd for On with value true
[12/2/2019, 8:45:30 PM] [FHEM] executing: http://127.0.0.1:8083/fhem?cmd=set%20DoseB%20on&fwcsrf=csrf_100137549077224&XHR=1
Zum Vergleich das Log einer Sonoff-Dose beim Schalten in FHEM (Status ändert sich auch in Home):
2019-12-02 20:46:51 caching: Sonoff3-state: on
[12/2/2019, 8:46:51 PM] [FHEM] Sonoff3-state valueOn/valueOff: value on mapped to 1
[12/2/2019, 8:46:51 PM] [FHEM] caching: On: true (as boolean; from 'on')
und beim Schalten in Home:
[12/2/2019, 8:47:43 PM] [FHEM] Sonoff3: executing set cmd for On with value true
[12/2/2019, 8:47:43 PM] [FHEM] executing: http://127.0.0.1:8083/fhem?cmd=set%20Sonoff3%20on&fwcsrf=csrf_100137549077224&XHR=1
2019-12-02 20:47:43 caching: Sonoff3-state: on
[12/2/2019, 8:47:43 PM] [FHEM] Sonoff3-state valueOn/valueOff: value on mapped to 1
[12/2/2019, 8:47:43 PM] [FHEM] caching: On: true (as boolean; from 'on')
Da scheint wohl noch irgendwas zu fehlen...
Zitat von: TomLee am 02 Dezember 2019, 20:24:40
Wenn ich mich mit deinem Problem mit dem GenshellSwitch_Device beschäftige stosse ich auf den User Deespe der das Problem 2016 schilderte und bisher seine Lösung (wenn er eine hat) hier im Forum bisher nicht schilderte, mglw. bin ich einfältig aber es wird dann wsl. ich auch keine geben.
Wenn du keine Lösung findest kannst es (wie immer :P) mit einem zusätlichen Readingsproxy_Device lösen.
Dazu, bei Interesse, mal ein jsonlist2 DoseB zeigen, auch wenn bisher eigentlich klar das es die setter on/off gibt.
Das wäre in der Tat nicht so schön. Ich will zwar auf kurz oder lang von den "dummen" Dosen weg und komplett auf Sonoffs/Shellys setzen, allerdings warte ich da noch auf Angebote. :) Dieses Jahr zu Weihnachten müssen teilweise noch die guten alten Baumarktsteckdosen herhalten.
Hier ein jsonlist2 DoseB:
{
"Arg":"DoseB",
"Results": [
{
"Name":"DoseB",
"PossibleSets":"on off toggle on-for-timer",
"PossibleAttrs":"alias comment:textField-long eventMap:textField-long group room suppressReading userReadings:textField-long verbose:0,1,2,3,4,5 loglevel:0,1,2,3,4,5,6 event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading cmdIcon devStateIcon devStateIcon:textField-long devStateStyle fm_type genericDeviceType:ignore,switch,outlet,light,blind,speaker,thermostat,ignore,lock,window,contact homebridgeMapping:textField-long icon siriName sortby webCmd webCmdLabel:textField-long widgetOverride userattr",
"Internals": {
"Command": "sudo /opt/fhem/bin/sendElro -u 1 -i 2 -S ",
"DEF": "sudo /opt/fhem/bin/sendElro -u 1 -i 2 -S 1 0",
"FUUID": "5c4723ea-f33f-c236-712e-f00e355fd21fa2ac",
"NAME": "DoseB",
"NR": "69",
"OffValue": "0",
"OnValue": "1",
"STATE": "on",
"TYPE": "GenShellSwitch"
},
"Readings": { "state": { "Value":"on", "Time":"2019-12-02 20:46:14" } },
"Attributes": {
"alias": "Stehlampe Wohnzimmer",
"fm_type": "offbutton,onbutton,lamp",
"genericDeviceType": "light",
"group": "Steckdosen",
"homebridgeMapping": "clear On=state,valueOn=on,cmdOn=on,cmdOff=off",
"room": "Steckdosen,AllesÜbersicht,Homekit"
}
} ],
"totalResultsReturned":1
}
Wenn nichts in der Ausgabe kommt, dann kriegt das homebridge wohl nicht mit...
Was kommt denn im Eventmonitor?
Also wenn du das selbe tust...
Evtl. dann mal anpassen...
...also das homebridgeMapping...
Ob dann state "falsch" ist oder nur die Events anders heißen (also doch nicht on/off, evtl. 1/0 und durch ein "Mapping" geändert werden) sollte man sehen...
Ansonsten gehen mir leider langsam die Ideen aus...
Gruß, Joachim
Zitat von: MadMax-FHEM am 02 Dezember 2019, 20:53:29
Was kommt denn im Eventmonitor?
Also wenn du das selbe tust...
Das einzige was im Eventmonitor beim An- und Ausschalten der Dose passiert ist folgendes:
2019-12-02 21:01:11 GenShellSwitch DoseB on
2019-12-02 21:01:13 GenShellSwitch DoseB off
Beim Schalten der Sonoff-Dose steht dort folgendes:
2019-12-02 21:04:18 MQTT2_DEVICE Sonoff3 on
2019-12-02 21:04:18 MQTT2_DEVICE Sonoff3 POWER1: on
2019-12-02 21:04:19 MQTT2_DEVICE Sonoff3 off
2019-12-02 21:04:19 MQTT2_DEVICE Sonoff3 POWER1: off
Postest du mal ein aktuelles jsonlist2 von Sonoff3...
...der geht ja jetzt, oder!?
Zum Vergleich...
EDIT: ansonsten halt dann doch (wie schon vorgeschlagen) readingsProxy...
Gruß, Joachim
Zitat von: MadMax-FHEM am 02 Dezember 2019, 21:33:51
Postest du mal ein aktuelles jsonlist2 von Sonoff3...
...der geht ja jetzt, oder!?
Ja der geht jetzt.
{
"Arg":"Sonoff3",
"Results": [
{
"Name":"Sonoff3",
"PossibleSets":"off:noArg on:noArg toggle:noArg on-for-timer off-till intervals blink off-till-overnight on-till off-for-timer on-till-overnight attrTemplate:?,General_Info,MQTT2_CLIENT_general_bridge,tasmota_basic,tasmota_basic_state_power1,tasmota_1ch+motion+SI7021,tasmota_POW,tasmota_POW_USB_split,tasmota_ir,tasmota_rf,tasmota_use_DS18x20_id,tasmota_clear_readings_reset_readingsList_and_reboot,tasmota_set_lowercase_texts_and_state1,tasmota_set_uppercase_texts_and_state1,tasmota_set_power1_state_to_power,tasmota_2channel_split,tasmota_2ch_unified,tasmota_2ch_shutter_invert_1,tasmota_2ch_shutter_invert_0,tasmota_4channel_split,tasmota_4ch_unified_basic_text,tasmota_4ch_unified_icon,tasmota_rgb_led_controller,tasmota_TuyaMCU_dimmer,shelly1,eBus_daemon_splitter,zigbee2mqtt_bridge,wled_controller,go_eCharger,esp_milight_hub_bridge,esp_milight_hub_remote_events_only,OpenMQTTGateway_MCU,wallpanel_app",
"PossibleAttrs":"alias comment:textField-long eventMap:textField-long group room suppressReading userReadings:textField-long verbose:0,1,2,3,4,5 IODev autocreate:0,1 bridgeRegexp:textField-long devicetopic devPos disable:0,1 disabledForIntervals getList:textField-long imageLink jsonMap:textField-long model readingList:textField-long setExtensionsEvent:1,0 setList:textField-long setStateList event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading cmdIcon devStateIcon devStateIcon:textField-long devStateStyle fm_type genericDeviceType:ignore,switch,outlet,light,blind,speaker,thermostat,ignore,lock,window,contact homebridgeMapping:textField-long icon siriName sortby webCmd webCmdLabel:textField-long widgetOverride userattr",
"Internals": {
"CID": "DVES_1C852C",
"DEF": "DVES_1C852C",
"DEVICETOPIC": "Sonoff3",
"FUUID": "5de3978f-f33f-c236-6e7f-69ea3f20a5328cce",
"LASTInputDev": "MQTT2_FHEM_Server",
"MQTT2_FHEM_Server_MSGCNT": "199",
"MQTT2_FHEM_Server_TIME": "2019-12-02 21:32:23",
"MSGCNT": "199",
"NAME": "Sonoff3",
"NR": "439",
"STATE": "off",
"TYPE": "MQTT2_DEVICE"
},
"Readings": {
"FallbackTopic": { "Value":"cmnd/DVES_1C852C_fb/", "Time":"2019-12-02 15:12:19" },
"GroupTopic": { "Value":"cmnd/sonoffs/", "Time":"2019-12-02 15:12:19" },
"Heap": { "Value":"27", "Time":"2019-12-02 21:32:23" },
"Hostname": { "Value":"sonoff3-1324", "Time":"2019-12-02 15:12:19" },
"IPAddress": { "Value":"192.168.2.171", "Time":"2019-12-02 15:12:19" },
"LWT": { "Value":"Online", "Time":"2019-12-02 15:12:19" },
"LoadAvg": { "Value":"19", "Time":"2019-12-02 21:32:23" },
"Module": { "Value":"Sonoff Basic", "Time":"2019-12-02 15:12:19" },
"MqttCount": { "Value":"1", "Time":"2019-12-02 21:32:23" },
"OtaUrl": { "Value":"http://thehackbox.org/tasmota/tasmota.bin", "Time":"2019-12-02 15:09:43" },
"POWER1": { "Value":"off", "Time":"2019-12-02 21:32:23" },
"RestartReason": { "Value":"Software/System restart", "Time":"2019-12-02 15:12:19" },
"SaveData": { "Value":"on", "Time":"2019-12-01 11:51:59" },
"SetOption26": { "Value":"on", "Time":"2019-12-01 11:51:59" },
"Sleep": { "Value":"50", "Time":"2019-12-02 21:32:23" },
"SleepMode": { "Value":"Dynamic", "Time":"2019-12-02 21:32:23" },
"StateText1": { "Value":"off", "Time":"2019-12-01 11:51:58" },
"StateText2": { "Value":"on", "Time":"2019-12-01 11:51:58" },
"StateText3": { "Value":"toggle", "Time":"2019-12-01 11:51:58" },
"StateText4": { "Value":"hold", "Time":"2019-12-01 11:51:59" },
"Time": { "Value":"2019-12-02T21:32:22", "Time":"2019-12-02 21:32:23" },
"Upgrade": { "Value":"Version 6.6.0 from http://thehackbox.org/tasmota/tasmota.bin", "Time":"2019-12-02 15:09:44" },
"Uptime": { "Value":"0T06:20:12", "Time":"2019-12-02 21:32:23" },
"UptimeSec": { "Value":"22812", "Time":"2019-12-02 21:32:23" },
"Version": { "Value":"7.1.1.1(eb1785c-tasmota)", "Time":"2019-12-02 15:12:19" },
"WebServerMode": { "Value":"Admin", "Time":"2019-12-02 15:12:19" },
"state": { "Value":"off", "Time":"2019-12-02 21:04:19" },
"subscriptions": { "Value":"cmnd/DVES_1C852C_fb/# cmnd/sonoff3/# cmnd/sonoffs/#", "Time":"2019-12-02 10:37:24" }
},
"Attributes": {
"IODev": "MQTT2_FHEM_Server",
"alias": "Wohnzimmer-Stern",
"autocreate": "0",
"model": "A_01a_tasmota_basic_state_power1",
"readingList": "tele/sonoff3/LWT:.* LWT\n tele/sonoff3/STATE:.* { json2nameValue($EVENT) }\n tele/sonoff3/SENSOR:.* { json2nameValue($EVENT) }\n tele/sonoff3/INFO.:.* { json2nameValue($EVENT) }\n stat/sonoff3/RESULT:.* { json2nameValue($EVENT) }",
"room": "Homekit,Licht,MQTT,Steckdosen,Wohnzimmer",
"setList": "off:noArg cmnd/sonoff3/POWER1 0\n on:noArg cmnd/sonoff3/POWER1 1\n toggle:noArg cmnd/sonoff3/POWER1 2\n on-for-timer {my $duration = $EVTPART1*10; 'cmnd/sonoff3/Backlog POWER1 1; delay '.$duration.'; POWER1 0'}",
"userReadings": "userReadings state:POWER1:.* {ReadingsVal($name,\"POWER1\",\"\")}"
}
} ],
"totalResultsReturned":1
}
Hmmm, hatte gehofft etwas bzgl. On/OffValue zu finden...
Zitat von: DoseB
"OffValue": "0",
"OnValue": "1",
um vielleicht was "ableiten" zu können...
Was du noch tun könntest: zu Sprachassistenten (oder so ähnlich) verschieben, dann "stolpert" vielleicht Andre (justme1968) hier drüber und hat vielleicht noch eine Idee...
Gruß, Joachim
Zitat von: Beta-User am 02 Dezember 2019, 16:29:27
:) Man sieht es, wenn man einen Tasmota hat...
(Also: richtig getippt, und vermutlich hat sich da auch nichts von V6 auf V7 geändert...)
Sehe keinen Unterschied:
00:00:00 CFG: aus Flash geladen am FB, zählen 509
00:00:00 Projekt tasmota Stecker Version 7.1.1(tasmota)-2_6_1
00:00:00 WIF: verbinden mit AP2 FBF in Modus 11N als sonoffs20-4770...
00:00:05 WIF: verbunden
00:00:05 HTP: Web-Server aktiv bei sonoffs20-4770 mit IP-Adresse 192.168.188.64
00:00:05 UPP: Multicast (wieder-)verbunden
22:33:30 MQT: Verbindungsversuch...
22:33:30 MQT: verbunden
22:33:30 MQT: tele/sonoffs20/LWT = Online (beibehalten)
22:33:30 MQT: cmnd/sonoffs20/POWER =
22:33:30 MQT: tele/sonoffs20/INFO1 = {"Module":"Sonoff Basic","Version":"7.1.1(tasmota)","FallbackTopic":"cmnd/DVES_12F2A2_fb/","GroupTopic":"cmnd/sonoffs/"}
22:33:30 MQT: tele/sonoffs20/INFO2 = {"WebServerMode":"Admin","Hostname":"sonoffs20-4770","IPAddress":"192.168.188.64"}
22:33:30 MQT: tele/sonoffs20/INFO3 = {"RestartReason":"Software/System restart"}
22:33:30 MQT: stat/sonoffs20/RESULT = {"POWER1":"off"}
22:33:30 MQT: stat/sonoffs20/POWER1 = off
22:33:31 UPP: Multicast (wieder-)verbunden
22:33:34 MQT: tele/sonoffs20/STATE = {"Time":"2019-12-02T22:33:34","Uptime":"0T00:00:12","UptimeSec":12,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER1":"off","Wifi":{"AP":2,"SSId":"FBF","BSSId":"FC:EC:DA:FD:26:1A","Channel":6,"RSSI":76,"LinkCount":1,"Downtime":"0T00:00:06"}}
22:33:35 MQT: stat/sonoffs20/RESULT = {"POWER1":"on"}
22:33:35 MQT: stat/sonoffs20/POWER1 = on
22:33:36 MQT: stat/sonoffs20/RESULT = {"POWER1":"off"}
22:33:36 MQT: stat/sonoffs20/POWER1 = off
Ich muss mich leider noch einmal mit einem kleinen Problem melden. Und zwar ist mir aufgefallen, dass sich der Status in FHEM und Homebridge bei Schalten über den integrierten Schalter der Dose nicht ändert. Ich glaube das ist wohl eher kein spezifisches Homebrigde-Problem. Woran könnte das liegen? Hier noch einmal meine Config:
CID DVES_1C393C
DEF DVES_1C393C
DEVICETOPIC Sonoff2
FUUID
IODev MQTT2_FHEM_Server
LASTInputDev MQTT2_FHEM_Server
MQTT2_FHEM_Server_MSGCNT 2
MQTT2_FHEM_Server_TIME 2019-12-13 16:04:07
MSGCNT 2
NAME Sonoff2
NR 444
STATE off
TYPE MQTT2_DEVICE
READINGS:
2019-12-12 22:14:04 FallbackTopic cmnd/DVES_1C393C_fb/
2019-12-12 22:14:04 GroupTopic cmnd/sonoffs/
2019-12-13 16:04:07 Heap 28
2019-12-12 22:14:04 Hostname sonoff2-6460
2019-12-12 22:14:04 IPAddress 192.168.2.170
2019-12-13 16:02:06 LWT Online
2019-12-13 16:04:07 LoadAvg 19
2019-12-12 22:14:04 Module Sonoff Basic
2019-12-13 16:04:07 MqttCount 3
2019-12-02 15:03:24 OtaUrl http://thehackbox.org/tasmota/tasmota.bin
2019-12-13 16:04:07 POWER1 off
2019-12-12 22:14:04 RestartReason Power on
2019-12-13 16:04:07 Sleep 50
2019-12-13 16:04:07 SleepMode Dynamic
2019-12-13 16:04:07 Time 2019-12-13T16:04:07
2019-12-02 15:03:24 Upgrade Version 6.6.0 from http://thehackbox.org/tasmota/tasmota.bin
2019-12-13 16:04:07 Uptime 0T17:50:12
2019-12-13 16:04:07 UptimeSec 64212
2019-12-12 22:14:04 Version 7.1.1.1(8c32950-tasmota)
2019-12-12 22:14:04 WebServerMode Admin
[...]
2019-12-09 21:03:19 state off
2019-12-05 15:24:00 subscriptions cmnd/DVES_1C393C_fb/# cmnd/sonoff2/# cmnd/sonoffs/#
Attributes:
IODev MQTT2_FHEM_Server
alias Lichterkette
autocreate 0
genericDeviceType light
model A_01a_tasmota_basic_state_power1
readingList tele/sonoff2/LWT:.* LWT
tele/sonoff2/STATE:.* { json2nameValue($EVENT) }
tele/sonoff2/SENSOR:.* { json2nameValue($EVENT) }
tele/sonoff2/INFO.:.* { json2nameValue($EVENT) }
stat/sonoff2/RESULT:.* { json2nameValue($EVENT) }
room Homekit,MQTT,Steckdosen
setList off:noArg cmnd/sonoff2/POWER1 0
on:noArg cmnd/sonoff2/POWER1 1
toggle:noArg cmnd/sonoff2/POWER1 2
on-for-timer {my $duration = $EVTPART1*10; 'sonoff2/Backlog POWER1 1; delay '.$duration.'; POWER1 0'}
userReadings userReadings state:POWER1:.* {ReadingsVal($name,"POWER1","")}
Würde sagen, dass entweder die Info vom Tasmota nicht kommt, oder die Message über cmnd reinkommt, aber nicht verarbeitet wird, weil autocreate am Device auf 0 steht.
=> Attribut autocreate am Sonoff2 mal löschen und den MQTT-Verkehr abhören (sollte z.B. über die Tasmota-Konsole gehen), wenn die Taste gedrückt wird.
Ah mir ist folgendes aufgefallen: Wenn ich den Sonoff von außen schalte wird das Reading ,,POWER1" getriggert. Allerdings nicht ,,state". Das wird nur beim Schalten über FHEM oder homebridge getriggert. Ist noch was an der Config falsch?
Ergänzend dazu, in der Konsole sieht man auch nicht mehr ob (hier jetzt an meinem Beispiel) direkt am Device oder aus FHEM.
18:47:50 MQT: stat/sonoffs20/RESULT = {"POWER1":"off"}
18:47:50 MQT: stat/sonoffs20/POWER1 = off
18:47:54 MQT: stat/sonoffs20/RESULT = {"POWER1":"on"}
18:47:54 MQT: stat/sonoffs20/POWER1 = on
18:48:04 MQT: stat/sonoffs20/RESULT = {"POWER1":"off"}
18:48:04 MQT: stat/sonoffs20/POWER1 = off
18:48:09 MQT: stat/sonoffs20/RESULT = {"POWER1":"on"}
18:48:09 MQT: stat/sonoffs20/POWER1 = on
Gruß
Thomas
Ein setzen des "autocreate" auf 1 hat nichts gebracht. Ich vermute wie gesagt ganz stark, dass es daran liegt, dass beim Schalten am Sonoff selber oder über eigene Weboberfläche nur das "POWER1" getigert wird. Reading "State" verändert sich nicht. Daher wahrscheinlich auch keine Statusänderung in FHEM bzw. Home. Ein Update auf 7.1.2.6 hat leider auch nichts gebracht.
Hallo, sag mal wurde das mittlerweile gelöst?
Ich habe das selbe Problem, GenShellSwitch gibt den Satus nicht korrekt an die Home-App zurück.
Internals:
Command /opt/fhem/scripts/light_wz_03.sh
DEF /opt/fhem/scripts/light_wz_03.sh on off
FUUID 5d8e5375-f33f-10d1-bf26-60b4128de4201e39
NAME wz_03_n
NR 95
OffValue off
OnValue on
STATE on
TYPE GenShellSwitch
READINGS:
2020-09-30 21:02:05 state on
Attributes:
alias WZ-Lampe3
fhem_widget_channels [{"allowed_values":["off","on"],"locations":["WGRID","WIDGET","WATCH","WLIST","AGRID","ALIST","WSTAT","APP"],"background_image":"\/images\/default\/li_wht_on.png"}]
genericDeviceType outlet
group Licht
homebridgeMapping On=valueOn=on,cmdOn=on,cmdOff=off
room Homekit,Wohnzimmer
Jemand eine Idee?
Ich habe das Problem mit Hilfe von Dummys gelöst.
ich muss das Thema noch mal hoch holen.
Ich habe eine Tasmota Steckdose und da funktioniert die Statusanzeige auf der Homebridge problemlos. Genauso wie bei Homatic-Geräten und anderen auch.
Nur bei bei den Tasmato 4-Fach-Schaltern (Template "tasmota_4channel_split") wird immer "ein" angezeigt.
Hat jemand noch einen Tip für mich?
Der Workaround über Dummys wäre zwar möglich, aber wirklich schön ist die Lösung nicht
Zitat von: hobbyprovider am 23 Mai 2021, 12:25:10
Nur bei bei den Tasmato 4-Fach-Schaltern (Template "tasmota_4channel_split") wird immer "ein" angezeigt.
An ein generelles Problem mag ich nicht so recht glauben. Passen die Zustände denn, wenn du von FHEM aus schaltest?
Sonst bitte mal ein list vom Hauptkanal (Power1) und einem Nebenkanal zeigen.
Sorry für die späte Antwort.
Grundsätzlich funktionieren die Devices. Mit einem Umweg über Dummys funktioniert es auch über die Homebridge.
Auch wenn ich die Kanäle direkt auf dem Webinterface des Gerätes schalte, wird der Status korrekt an FHEM übermittelt.
Bei der Funkstekdose (1 Kanal) habe ich bemerkt, dass die Homebridge manchmal den Status nicht korrekt zurückgemeldet bekommt. Dann lässt sich das Gerät auch für einige Sekunden nicht schalten. Ich konnte es aber nie gezielt provozieren.
Bin nicht ganz sicher welche Infos Du benötigst. Meinst Du das?
Power1
readingList
tele/Tasmota4-01/LWT:.* LWT
tele/Tasmota4-01/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }
tele/Tasmota4-01/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }
tele/Tasmota4-01/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }
tele/Tasmota4-01/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }
stat/Tasmota4-01/POWER1:.* state
stat/Tasmota4-01/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
setList
off:noArg cmnd/Tasmota4-01/POWER1 0
on:noArg cmnd/Tasmota4-01/POWER1 1
toggle:noArg cmnd/Tasmota4-01/POWER1 2
setOtaUrl:textField cmnd/Tasmota4-01/OtaUrl $EVTPART1
upgrade:noArg cmnd/Tasmota4-01/upgrade 1
Power2
readingList
stat/Tasmota4-01/POWER2:.* state
setList
off:noArg cmnd/Tasmota4-01/POWER2 0
on:noArg cmnd/Tasmota4-01/POWER2 1
toggle:noArg cmnd/Tasmota4-01/POWER2 2
Zitat von: hobbyprovider am 24 Mai 2021, 12:43:32
Sorry für die späte Antwort.
dto; irgendwie ist mir das rausgegangen, eventuell auch deswegen, weil ich auch nicht recht weiß, was ich mit den Infos anfangen könnte...
Der Reihe nach:
Zitat
Bin nicht ganz sicher welche Infos Du benötigst. Meinst Du das?
"Im Prinzip" ja. Aber: Es ist "unleserlich", da nicht in code-Tags verpackt (#-Symbol). Und es ist vermutlich nur ein Auszug...
Ergo kann ich nur raten, ob z.B. das genericDeviceType-Attribut an diesen Geräten gesetzt ist (das attrTemplate sollte das eigentlich machen)?
Wenn nein: Nachholen (switch).
In allen Fällen wage ich zu behaupten, dass der dummy-Umweg (wie in 99,8% aller anderen Fälle auch, in denen mit dummy was "gradegebogen" wird) unnötig ist und ggf. die eigentlichen Probleme nur verschleiert
Zitat
Bei der Funkstekdose (1 Kanal) habe ich bemerkt, dass die Homebridge manchmal den Status nicht korrekt zurückgemeldet bekommt. Dann lässt sich das Gerät auch für einige Sekunden nicht schalten. Ich konnte es aber nie gezielt provozieren.
Das klingt eher danach, als wäre die Verbindung zeitweise gestört und das Device bliebe daher auf "set_on" (oä.), was ggf. Homebridge nicht verarbeiten kann. Das bekommt man aber nur raus, wenn man gezielt sucht und ggf. mal z.B. einen watchdog darauf ansetzt (oder ggf. mal schaut, ob bzgl. der Zeitstempel was verwertbares im Logfile steht).
Hier der Auszug aus fhem.cfg:
define MQTT2_Tasmota4_01 MQTT2_DEVICE Tasmota4_01
setuuid MQTT2_Tasmota4_01 60a801d6-f33f-6d5c-6f53-6026dc978150aaf6
attr MQTT2_Tasmota4_01 alias Laterne
attr MQTT2_Tasmota4_01 autocreate 0
attr MQTT2_Tasmota4_01 comment Channel 1 for MQTT2_Tasmota4_01, see also MQTT2_Tasmota4_01_CH2, MQTT2_Tasmota4_01_CH3 and MQTT2_Tasmota4_01_CH4
attr MQTT2_Tasmota4_01 genericDeviceType light
attr MQTT2_Tasmota4_01 group Garten
attr MQTT2_Tasmota4_01 jsonMap POWER1:0 POWER2:0 POWER3:0 POWER4:0 Dimmer:0 Channel_0:0 Channel_1:0 Channel_2:0 Channel_3:0 Channel_4:0 HSBColor:0 Color:0
attr MQTT2_Tasmota4_01 model tasmota_4channel_split
attr MQTT2_Tasmota4_01 readingList tele/Tasmota4-01/LWT:.* LWT\
tele/Tasmota4-01/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/Tasmota4-01/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/Tasmota4-01/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/Tasmota4-01/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
stat/Tasmota4-01/POWER1:.* state\
stat/Tasmota4-01/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr MQTT2_Tasmota4_01 room MQTT
attr MQTT2_Tasmota4_01 setList off:noArg cmnd/Tasmota4-01/POWER1 0\
on:noArg cmnd/Tasmota4-01/POWER1 1\
toggle:noArg cmnd/Tasmota4-01/POWER1 2\
setOtaUrl:textField cmnd/Tasmota4-01/OtaUrl $EVTPART1\
upgrade:noArg cmnd/Tasmota4-01/upgrade 1
attr MQTT2_Tasmota4_01 setStateList on off toggle
attr MQTT2_Tasmota4_01 sortby 11
define FileLog_MQTT2_Tasmota4_01 FileLog ./log/fhem-%Y-%m-%d.log MQTT2_Tasmota4_01
setuuid FileLog_MQTT2_Tasmota4_01 60a801d6-f33f-6d5c-0626-515f3ff4cdb20f73
attr FileLog_MQTT2_Tasmota4_01 logtype text
define MQTT2_Tasmota4_01_CH2 MQTT2_DEVICE Tasmota4_01
setuuid MQTT2_Tasmota4_01_CH2 60a8020c-f33f-6d5c-4c8c-aabe0b52a2d8b8cf
attr MQTT2_Tasmota4_01_CH2 alias Pool
attr MQTT2_Tasmota4_01_CH2 autocreate 0
attr MQTT2_Tasmota4_01_CH2 comment Channel 2 for MQTT2_Tasmota4_01, see also MQTT2_Tasmota4_01, MQTT2_Tasmota4_01_CH3 and MQTT2_Tasmota4_01_CH4
attr MQTT2_Tasmota4_01_CH2 genericDeviceType switch
attr MQTT2_Tasmota4_01_CH2 group Garten
attr MQTT2_Tasmota4_01_CH2 jsonMap POWER2:0 Dimmer:pct POWER1:0 Heap:0 LedTable:0 LoadAvg:0 MqttCount:0 SaveData:0 Scheme:0 SetOption26:0 Sleep:0 SleepMode:0 Speed:0 StateText1:0 StateText2:0 StateText3:0 StateText4:0 Time:0 Uptime:0 UptimeSec:0 Wifi_SSId:0 Wifi_RSSI:0 Wifi_LinkCount:0 Wifi_Downtime:0 Wifi_Channel:0 Wifi_BSSId:0 Wifi_AP:0 ANALOG_A0:0 SetOption26:0 Sleep:0 SleepMode:0 Speed:0 StateText1:0 StateText2:0 StateText3:0 StateText4:0 Time:0 Uptime:0 UptimeSec:0 Wifi_SSId:0 Wifi_RSSI:0 Wifi_LinkCount:0 Wifi_Downtime:0 Wifi_Channel:0 Wifi_BSSId:0 Wifi_AP:0
attr MQTT2_Tasmota4_01_CH2 model tasmota_4channel_split
attr MQTT2_Tasmota4_01_CH2 readingList stat/Tasmota4-01/POWER2:.* state
attr MQTT2_Tasmota4_01_CH2 room Automatik,MQTT
attr MQTT2_Tasmota4_01_CH2 setList off:noArg cmnd/Tasmota4-01/POWER2 0\
on:noArg cmnd/Tasmota4-01/POWER2 1\
toggle:noArg cmnd/Tasmota4-01/POWER2 2
attr MQTT2_Tasmota4_01_CH2 setStateList on off toggle
attr MQTT2_Tasmota4_01_CH2 sortby 12
Die Datenverbindung ist stabil (soweit man das bei einem WLAN sagen kann).
Ich habe das ganze jetzt einige Tage im Einsatz und hatte nicht einmal den Fall, dass ein Gerät nicht "gehorcht" hat.
Würde auch nicht zum Fehlerbild passen. Beispiel:
Das Gerät wird ausgeschaltet. Die funktion wird auch korrekt übertragen, Das Icon zeigt auch kurz den korrekten Status an und springt dann wieder auf Status "ein". Das Gerät bleibt aber aus.
Als genericDeviceType habe ich "switch" oder "light" eingetragen". Der Parameter wird aber nicht durch das Template gesetzt.
Das checke ich nochmal ob es da einen Unterschied gibt - ich vermute aber nicht.
Den Dummy stelle ich genauso ein und der funktioniert ohne Probleme. Daher gehe ich davon aus, dass irgend ein Status zurück kommt, welcher die Homebridge "verwirrt".
Zitat von: hobbyprovider am 03 Juni 2021, 13:39:17
Hier der Auszug aus fhem.cfg:
Mal davon abgesehen, dass fhem.cfg-Auszüge an sich (berechtigterweise!) verpönt sind (im Unterschied zu "list <device>" bzw. "list -R" - Ausgaben): Wir würden die Info benötigen, wie das Device konkret steht in dem Moment, in dem Homebridge "aus dem Tritt" ist.
Da du scheinbar alles loggst: Schau mal was wann im Log zu finden ist, und ob wirklich immer direkt vom ESP eine Vollzugsmeldung zurückkommt (Wechsel von "set_.*" auf "on" bzw. "off"), oder ob er sich da irgendwo dazwischen "verschluckt".
Aus dieser Beschreibung werde ich nicht schlau:
Zitat
Das Gerät wird ausgeschaltet. Die funktion wird auch korrekt übertragen, Das Icon zeigt auch kurz den korrekten Status an und springt dann wieder auf Status "ein". Das Gerät bleibt aber aus.
Bezugspunkt von "Icon" ist FHEMWEB oder Homebridge (was auch immer das ist)? Für mich interessant ist erst mal FHEM/FHEMWEB => STATE / state? Was steht da zum jeweiligen Zeitpunkt? Events?
Da hier auch IODev nicht in den Attributen auftauchte: Falls (!) das Problem war, dass das attrTemplate-Setzen nicht sauber durchgelaufen war und der state daher auf "set_on" etc. stehen geblieben ist (siehe: https://forum.fhem.de/index.php/topic,121495.0/topicseen.html):
update durchführen (zumindest für mqtt2.template) und dann nochmal das attrTemplate anwenden bzw. dafür sorgen, dass die "backlog"-Kommandos durchlaufen, die dafür zuständig sind, die Tasmota-Konfiguration (auf dem ESP) "FHEM"-tauglich zu machen.
So! meine Garage, und damit meine Tasmota-Geräte, waren ein paar Tage offline.
Jetzt habe ich nochmal getestet.
Einen "Freeze" konnte ich nicht provozieren. Aber das Gerät wird immer als "on" in der Homebridge angezeigt. Hier der List im FHEM kurz nachdem das Gerät ausgeschaltet wurde
list MQTT2_Tasmota4_01_CH3
Internals:
CID Tasmota4_01
DEF Tasmota4_01
DEVICETOPIC MQTT2_Tasmota4_01_CH3
FUUID 60a8020d-f33f-6d5c-9d80-cec95f84cb453cc0
IODev mqttBroker
LASTInputDev mqttBroker
MSGCNT 6
NAME MQTT2_Tasmota4_01_CH3
NR 1073
STATE OFF
TYPE MQTT2_DEVICE
mqttBroker_MSGCNT 6
mqttBroker_TIME 2021-06-14 20:13:15
JSONMAP:
POWER1 state
READINGS:
2021-06-14 19:30:38 IODev mqttBroker
2021-05-21 20:55:10 associatedWith MQTT2_Tasmota4_01,MQTT2_Tasmota4_01_CH2,MQTT2_Tasmota4_01_CH4
2021-05-21 20:55:10 attrTemplateVersion 20200828
2021-06-14 20:13:15 state OFF
Attributes:
alias MQTT-Ole
autocreate 0
genericDeviceType light
jsonMap POWER1:state
model tasmota_4channel_split
readingList stat/Tasmota4-01/POWER3:.* state
room Homekit,MQTT
setList off:noArg cmnd/Tasmota4-01/POWER3 0
on:noArg cmnd/Tasmota4-01/POWER3 1
setStateList on off toggle
sortby 13
der Log in der Homebridge sieht so aus:
2021-06-14 20:14:06 caching: MQTT2_Tasmota4_01_CH3-state: set_off
2021-06-14 20:14:06 caching: MQTT2_Tasmota4_01_CH3-state: OFF
[14/06/2021, 20:14:06] [FHEM] caching: On: true (as boolean; from 'OFF')
in der 3ten Zeile sieht man, dass der Status als "on" gesehen wird.
Bei einem (funktionierenden) Dummy sieht das so aus:
2021-06-14 20:24:14 caching: schaltdummy-state: off
[14/06/2021, 20:24:14] [FHEM] caching: On: false (as boolean; from 'off')
Grundsätzlich funktioniert das Gerät im FHEM völlig problemlos. Der Status wird korrekt dargestellt.
Mit dem Workaround über einen Dummy funktioniert es aus über die Homebridge. Egal ob direkt im FHEM oder über die Homebridge geschaltet wird. Die Funktion und der Status werden immer korrekt übermittelt
Irgendwas muss schief gelaufen sein beim anwenden des tasmota_4channel_split-Templates, das führt eigentlich im Hintergrund auch das tasmota_set_lowercase_texts_and_state1 aus.
Ich meine du kannst auf eines der 4-Channel-Devices problemlos nachträglich das tasmota_4channel_split-Templates anwenden, welches auf Kleinschreibung der Status umstellt, was Voraussetzung für einen korrekten Status in Homebridge ist.
Oder du machst das einfach selbst in der Konsole von dem 4-CH-Device:
Backlog StateText1 off; StateText2 on; StateText3 toggle; StateText4 hold; SetOption26 1; SaveData 1