Homebridge - Keine Status Übergabe?

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

Vorheriges Thema - Nächstes Thema

marcel151

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.

MadMax-FHEM

#1
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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

marcel151

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

MadMax-FHEM

#3
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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

MadMax-FHEM

#4
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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

TomLee

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

TomLee

@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  :P

MadMax-FHEM

Hi Tom,

danke!

Macht die "Sache" aber nicht wirklich übersichtlich(er)... ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

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

marcel151

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

MadMax-FHEM

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

marcel151

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.

MadMax-FHEM

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

TomLee

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 fhem

um 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


marcel151

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

TomLee

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 ?

MadMax-FHEM

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

marcel151

#17
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?

Beta-User

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

marcel151

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.

Beta-User

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

marcel151

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

MadMax-FHEM

#22
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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

marcel151

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

Beta-User

Zitat von: marcel151 am 02 Dezember 2019, 15:07:33
Meine aktuelle Konfiguration:
[...]
Wenn das neue auf ohne
DVES_1C766E:stat/sonoff1/POWER1:.* POWER1auskommt, wird (neuerdings?) POWER1 via JSON übertragen. Wenn das so ist (?), dann BITTE das mit JSONMAP testen.
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

marcel151

Wenn ich weiß, was ich wo eintragen muss helfe ich gerne. Wo darf ich was an der Konfiguration ändern?

Beta-User

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

TomLee

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

Beta-User

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

TomLee

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.

Beta-User

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

MadMax-FHEM

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

marcel151

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

MadMax-FHEM

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

TomLee

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.


marcel151

#35
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
}

MadMax-FHEM

#36
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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

marcel151

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

MadMax-FHEM

#38
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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

marcel151

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
}

MadMax-FHEM

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

TomLee

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

marcel151

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

Beta-User

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

marcel151

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?

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