Homebridge - Keine Status Übergabe?

Begonnen von marcel151, 01 Dezember 2019, 11:14:21

Vorheriges Thema - Nächstes Thema

TomLee

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

marcel151

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.

BooStar

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?

BooStar

Ich habe das Problem mit Hilfe von Dummys gelöst.

hobbyprovider

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
mein System:
2 vernetzte FHEM auf RPi
1.: mit Cul 868 und 433
2.: mit 1Wire-Adapter DS9490R

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

hobbyprovider

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


mein System:
2 vernetzte FHEM auf RPi
1.: mit Cul 868 und 433
2.: mit 1Wire-Adapter DS9490R

Beta-User

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).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

hobbyprovider

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".
mein System:
2 vernetzte FHEM auf RPi
1.: mit Cul 868 und 433
2.: mit 1Wire-Adapter DS9490R

Beta-User

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?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

hobbyprovider

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
mein System:
2 vernetzte FHEM auf RPi
1.: mit Cul 868 und 433
2.: mit 1Wire-Adapter DS9490R

TomLee

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