[gelösst]Sonoff Basic in Homebridge einbinden

Begonnen von Larusso, 21 Januar 2018, 20:52:08

Vorheriges Thema - Nächstes Thema

Larusso

Hallo zusammen,

ich habe heute einen Sonoff Basic mit Tasmota geflashed und MQTT in FHEM eingerichtet. Funktioniert alles prima, das Gerät wird mir auch in meiner Home App angezeigt, allerdings kann ich es nicht im Iphone schalten. Das Licht (Sonoff Schalter) wird mir angezeigt und kann auch an und aus gesetzt werden, allerdings schaltet die Lampe nicht. In FHEM geht das prima, ich denke mir fehlt noch ein attr beim Homebridgemapping, allerdings weis ich nicht welches. Hat jemand von euch sonoff Geräte in der Homebridge eingebunden und kann mir Hilfestellung geben? Anbei noch das List des Devices:

Internals:
   IODev      Mosquitto
   NAME       SZ_Nachtlampe
   NR         372
   STATE      OFF
   TYPE       MQTT_DEVICE
   .qos:
     *          0
   .retain:
     *          0
   READINGS:
     2018-01-21 20:42:20   state           OFF
     2018-01-21 20:44:09   transmission-state subscription acknowledged
   message_ids:
   publishSets:
     :
       topic      cmnd/SZ_Nachtlampe/POWER
       values:
         ON
         OFF
   sets:
     OFF       
     ON         
   subscribe:
     stat/SZ_Nachtlampe/POWER
   subscribeExpr:
     ^stat\/SZ_Nachtlampe\/POWER$
   subscribeReadings:
     stat/SZ_Nachtlampe/POWER:
       cmd       
       name       state
Attributes:
   IODev      Mosquitto
   devStateIcon OFF:FS20.off:ON ON:FS20.on:OFF
   genericDeviceType light
   group      Beleuchtung
   icon       light_pendant_light
   publishSet ON OFF cmnd/SZ_Nachtlampe/POWER
   room       Homekit,Lampen
   stateFormat state
   subscribeReading_state stat/SZ_Nachtlampe/POWER
   webCmd     on:off
nanoCul434MHz, nanoCul868MHz, HueBridge, shellyRolladenaktoren, Nuki, Homematic, RPI3, Homebridge, Sonoffbridge, Xiaomi Saugrobotter,

KernSani

Rechts oben in diesem Forum gibt es ein Feld, in das man Suchbegriffe eintippen kann. Dann findet man z.B. sowas:

https://forum.fhem.de/index.php?topic=79175.0

da gibt's dann zumindest Ansätze für das HomebridgeMapping, wenn das (und andere Beiträge) nicht weiterhelfen bitte nochmal melden...
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Larusso

#2
Danke für den Hinweis.......aber genau den Beitrag habe ich gelesen und der bringt mich auch nicht weiter. Die Sufu habe ich benutzt, sonst würd ich nicht posten. Ich such dann mal weiter, wenn ich was raus bekomme schreibe ich. Wenn jemand das Problem kennt bzw. die Lösung kann er gerne schreiben, danke trotzdem an alle die sich melden.  ;D
nanoCul434MHz, nanoCul868MHz, HueBridge, shellyRolladenaktoren, Nuki, Homematic, RPI3, Homebridge, Sonoffbridge, Xiaomi Saugrobotter,

KernSani

Hi,
Da ich in deinem device kein homebridgemapping sehe, nahm ich an, du hast noch nicht versucht, das Homebridgemapping entsprechend zu pflegen.
Was passiert denn, wenn du ein homebrifgemapping wie im anderen Post eingibst? Hast du dir mal die debug-Ausgabe angesehen?



RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Larusso

Stand ein bisschen auf dem Schlauch.......es fehlte natürlich nur das "On=state,values=OFF:0;ON:1,cmdOff=OFF,cmdOn=ON" im Homebridgemapping.

Sorry KernSani aber du hattest recht da waren nur zu viele Bäume, ich hab den Wald nicht mehr gesehen.

;)
nanoCul434MHz, nanoCul868MHz, HueBridge, shellyRolladenaktoren, Nuki, Homematic, RPI3, Homebridge, Sonoffbridge, Xiaomi Saugrobotter,

KernSani

RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

wires.io

#6
Zur Ergänzung bzw. Frage an die FHEM Profis: Um Sonoff auch lokal schalten zu können (siehe: https://github.com/arendst/Tasmota/wiki/Buttons-and-Switches) und den Zustand dann auch richtig dargestellt zu bekommen, musste ich folgende Bretter in FHEM reinzimmern:

define MQTT2_DVES_97052F_notify_1 notify MQTT2_DVES_97052F:POWER1:.on { if(ReadingsVal("MQTT2_DVES_97052F","state","") eq "off") {fhem("set MQTT2_DVES_97052F on")} }

define MQTT2_DVES_97052F_notify_2 notify MQTT2_DVES_97052F:POWER1:.off { if(ReadingsVal("MQTT2_DVES_97052F","state","") eq "on") {fhem("set MQTT2_DVES_97052F off")} }

Geht das auch eleganter?

TomLee

Hallo,

MQTT_DEVICE ist bei mir gefühlt ewig her.
Laut Aussage von Andre sollen ja in homebridge-fhem Geräte unabhängig von der schreibweise (groß/klein) erkannt werden.
Dein Beispiel zeigt mir wieder das das nicht so ist.

Du hast aber die Möglichkeit in Tasmota ON/OFF mit StateText1 off/StateText2 on auf Kleinschreibung umzustellen, dann braucht man auch kein homebridgeMapping mehr.

Wenn du das mal ausprobieren magst ?

Gruß

Thomas

wires.io

Das Problem liegt darin, dass bei lokaler Schalterbetätigung das Reading "POWER" geändert wird, das (entscheidende) Reading "state" sich aber nicht ändert. Daher triggere ich das Schalten bei Änderung von "POWER".

TomLee

Ups, du nutzt ja MQTT2, hatte nicht genau gelesen du bist ja gar nicht der TE.

Du löschst einfach dein homebridgeMapping nimmst die vorgeschlagenen Einstellungen zu StateText1/2 vor und setzt noch jsonMap POWER:state dann landet Power auch in state.

wires.io

Mit jsonMap POWER:state ändert sich "state" nicht bei Änderung von "POWER".
Und: homebridgemapping brauche ich doch auf jeden Fall, oder nicht?

TomLee

zeig mal ein list oder Raw Definition von dem Gerät.

Nein, wenn on/off in state landet braucht man kein homebridgeMapping mehr.

wires.io

defmod MQTT2_DVES_97052F MQTT2_DEVICE DVES_97052F
attr MQTT2_DVES_97052F IODev myBroker
attr MQTT2_DVES_97052F alias plugboard
attr MQTT2_DVES_97052F genericDeviceType outlet
attr MQTT2_DVES_97052F homebridgeMapping On=state,valueOff=off,cmdOff=on,cmdOn=on
attr MQTT2_DVES_97052F readingList DVES_97052F:stat/tasmota/RESULT:.* { json2nameValue($EVENT) }\
DVES_97052F:tele/tasmota/STATE:.* { json2nameValue($EVENT) }\
DVES_97052F:tele/tasmota/SENSOR:.* { json2nameValue($EVENT) }\
DVES_97052F:stat/tasmota/POWER:.* POWER\
DVES_97052F:tele/tasmota/LWT:.* LWT\
DVES_97052F:cmnd/tasmota/POWER:.* POWER\
DVES_97052F:tele/tasmota/INFO1:.* { json2nameValue($EVENT) }\
DVES_97052F:tele/tasmota/INFO2:.* { json2nameValue($EVENT) }\
DVES_97052F:tele/tasmota/INFO3:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_97052F room Homekit,MQTT
attr MQTT2_DVES_97052F setList on cmnd/tasmota/POWER on\
off cmnd/tasmota/POWER off\
reboot cmnd/tasmota/Restart 1
attr MQTT2_DVES_97052F webCmd on:off:reboot

TomLee

Das zwar kein list und auch keine Raw Definition aber man sieht trotzdem das kein Attribut jsonMap gesetzt ist.

Wenn du die jetzige Definition nicht ändern möchtest kopiere das Gerät einfach (copy MQTT2_DVES_97052F MQTT2_DVES_97052F2) und nimm dort das jsonMap mit rein und das homebridgemapping raus.

wires.io

Das ist der erste Teil von Raw definition - den zweiten Teil wollte ich hier nicht posten. jsonMap hatte ich gelöscht. Welche Info brauchst Du denn genau?

TomLee

Naja, den unteren Teil wenn jsonMap gesetzt ist und die Steckdose einmal geschalten wurde, wäre hilfreich.

Beta-User

#16
Anmerkungen:

1. jsonMap greift nur, wenn man die "volle Form" von json2nameValue() verwendet - ist hier nicht der Fall...

2. attrTemplate scheint dem TE (noch) nicht geläufig zu sein.

3. Der Name des Devices ist noch "tasmota" => unbedingt ändern, wie bereits auf der Tasmoat-Homepage empfohlen.

Empfehlung:
Nach der Änderung des Namens bitte das Device löschen, autocreate wieder aktiv sein lassen (=ESP booten lassen), nachsehen, ob das LWT-Reading da ist und dann das passende attrTemplate anwenden. Mehr dazu: "Praxisbeispiele" im Wiki.
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

wires.io

#17
Danke, werde die Tipps bei der nächsten Inbetriebnahme berücksichtigen.

ZitatDer Name des Devices ist noch "tasmota" => unbedingt ändern, wie bereits auf der Tasmoat-Homepage empfohlen

Du meinst den Namen der Topics, oder?

Beta-User

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

wires.io

Zitat2. attrTemplate scheint dem TE (noch) nicht geläufig zu sein.

Habe das nun mit einem neuen Sonoff / Tasmota Basic probiert. Funktioniert zunächst "out of the box", allerdings wird die lokale Schalterbetätigung zwar in FHEM korrekt erkannt, aber nicht an Homekit weitergegeben. Kann jedoch per Homekit ein- und ausschalten. Was läuft da schief? state hat bei mir die Zustände "set-on" und "set-off".

Beta-User

Sorry, da war noch ein kleiner Fehler im template, an einer Stelle steht statt "stat" "tele".

Nach 8h ein update+restart, dann das attrTemplate nochmal anwenden, bitte.
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

wires.io

Hat das gefehlt?

stat/DVES_F9629C/POWER1:.* state


Sent from my iPad using Tapatalk

Beta-User

Jein: das müsste passen, ersetzt aber den unnötigen 'tele'-Pfad...
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

Weil ich es gerade vor mir habe:

Das alles wäre noch ausgeführt worden hättest du wie vorgeschlagen ein passendes Template angewendet:

set IO_DEV publish CMNDTOPIC/Backlog StateText1 off; StateText2 on; StateText3 toggle; StateText4 hold; SetOption26 1; SaveData 1

wires.io

Zitat von: Beta-User am 07 März 2020, 07:02:37
Nach 8h ein update+restart, dann das attrTemplate nochmal anwenden, bitte.

Auch wenn es hier nicht reinpasst. Nach einem Update sind 99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm und 98_EDIPLUG.pm nicht mehr funktionsfähig und ich kann nur durch Wiederherstellen meiner alten FHEM Installation normal arbeiten. Irgendwelche Tipps dazu?

Beta-User

Uh, klingt eklig...

Von wann war denn der Stand, der läuft?

(Wegen der ersten Sache ggf. mal im HM-Bereich nachhorchen, da gab es einige hefitge Umbauten vor vielen Monaten, bitte aber auch schauen, was dazu im Log steht (ggf. auf einer Testinstallation!) Ediplug: k.a.).
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

wires.io

Nun habe ich einen weiteren Tasmota / Sonoff Basic in Betrieb mit "A_01a_tasmota_basic_state_power1" genommen. Leider sendet der nichts auf dem Topic POWER1. Was nun?

Beta-User

Wenn du ein template mit diesem Namen erfolgreich anwenden konntest, ist FHEM nicht aktuell => erst aktualisieren (+Neustart), dann nochmal das mit dem richtigen Namen anwenden und dann wieder melden, falls es trotzdem nicht funktioniert.
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

wires.io

In FHEM scheint es ja zu passen. Aber Sonoff sendet nichts auf dem Topic POWER1. Muss ich auf der Console von Tasmota etwas setzen?

Beta-User

Die backlog-Befehle kann man dem (aktuellen!) template entnehmen, update ist in jedem Fall dringend zu empfehlen.

Meine Glaskugel vermutet aber zusätzlich, dass du zwei sonoff ver"tasmota"t hast und nur bei dem einen nichts ankommt, was dann daran liegt, dass du den Namen nicht empfehlungsgemäß umgestellt hast. Wenn dir das jetzt spanisch vorkommt, such' mal im Wiki nach "Praxisbeispiele zu MQTT.*".
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

wires.io

In der Tasmota Console sehe ich, dass bei Power on/off auf das Topic POWER geschrieben wird und zwar ON oder off. Nach m.E. bräuchte ich jedoch on / off (kleingeschrieben) auf das Topic POWER1. Und dahin sendet Tasmota nichts.

TomLee

Zeig doch einfach mal ein list von dem Device, dann braucht man auch nicht vermuten.

Meine Glaskugel sagt dein FHEM ist aktuell und nachdem du das A_01a_tasmota_basic_state_power1-Template angewendet hast macht jsonMap was es soll, das Reading POWER1 ausblenden.

Und mit der ReadingList-Zeile
stat/irgendwas/POWER1:.* state
landet der Status von POWER1 in state

Nichts anderes, meine Vermutung, wird dein list zeigen.

Gruß

Thomas

Beta-User

In https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template gibt es seit längerem kein "A_irgendwas" mehr. Das Ding heißt seit längerem "tasmota_basic_state_power1" und sieht ziemlich anders aus als das alte, u.A. was das JSON-Handling angeht...

Aber wenn ihr meint, verzichtet auf update und rätselt weiter... Nur eben ohne mich :P
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

wires.io

Wie oben erläutert, zerschießt mir ein Update meine FHEM Installation. Von daher leider (momentan) keine Option. Und warum Tasmota nichts auf POWER1 sendet, hat doch damit nichts zu tun. Oder übersehe ich etwas?

Beta-User

Ich kann leider nicht ohne weiteres nachvollziehen, zu welchem Template-Stand welche backlog-Befehle gesendet wurden; an sich sollte das konstant gewesen sein, aber scheinbar kam da irgendwas nicht am Tasmota an.

Ohne update bleibt nur die Option, das händisch nachzuvollziehen, was das template eben macht, was aber wegen der Optionen gar nicht so einfach ist, die da zwischenzeitlich eingeflossen sind... Kurz: Du solltest die backlog-Befehle ermitteln (sind im tasmota_set_lowercase_texts_and_state1 drin) und dann das Device an sich händisch auf den Stand von tasmota_basic_state_power1 anpassen.

Zu OT: Excludefromupdate für die drei "Kandidaten" geht nicht?
Und Info an den Maintainer ist erfolgt (ggf. mit einem Hinweis, wo das Problem jeweils liegt)?
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

wires.io

Jetzt geht es - keine Ahnung warum:

Internals:
   CID        DVES_F96A96
   DEF        DVES_F96A96
   DEVICETOPIC MQTT2_DVES_F96A96
   FUUID      5e69f39e-f33f-807b-8fff-6119cc9befec8b35
   IODev      myBroker
   LASTInputDev myBroker
   MSGCNT     689
   NAME       MQTT2_DVES_F96A96
   NR         89
   STATE      off
   TYPE       MQTT2_DEVICE
   myBroker_MSGCNT 689
   myBroker_TIME 2020-04-08 17:36:34
   OLDREADINGS:
   READINGS:
     2020-04-08 17:36:06   Heap            27
     2020-04-08 17:36:06   LoadAvg         19
     2020-04-08 17:36:06   MqttCount       2
     2020-04-08 17:36:34   POWER1          off
     2020-04-08 17:30:36   SaveData        on
     2020-04-08 17:30:36   SetOption26     on
     2020-04-08 17:36:06   Sleep           50
     2020-04-08 17:36:06   SleepMode       Dynamic
     2020-04-08 17:30:35   StateText1      off
     2020-04-08 17:30:35   StateText2      on
     2020-04-08 17:30:36   StateText3      toggle
     2020-04-08 17:30:36   StateText4      hold
     2020-04-08 17:36:06   Switch1         off
     2020-04-08 17:36:06   Time            2020-04-08T16:36:06
     2020-04-08 17:36:06   Uptime          0T02:45:12
     2020-04-08 17:36:06   UptimeSec       9912
     2020-04-08 17:36:06   Wifi_AP         1
     2020-04-08 17:36:06   Wifi_BSSId      C8:0E:14:38:46:2D
     2020-04-08 17:36:06   Wifi_Channel    1
     2020-04-08 17:36:06   Wifi_Downtime   0T00:00:09
     2020-04-08 17:36:06   Wifi_LinkCount  2
     2020-04-08 17:36:06   Wifi_RSSI       76
     2020-04-08 17:36:06   Wifi_Signal     -62
     2020-04-08 17:36:34   state           off
Attributes:
   IODev      myBroker
   alias      coffeemaker
   autocreate 0
   model      A_01a_tasmota_basic_state_power1
   readingList tele/DVES_F96A96/LWT:.* LWT
tele/DVES_F96A96/STATE:.* { json2nameValue($EVENT) }
tele/DVES_F96A96/SENSOR:.* { json2nameValue($EVENT) }
tele/DVES_F96A96/INFO.:.* { json2nameValue($EVENT) }
stat/DVES_F96A96/RESULT:.* { json2nameValue($EVENT) }
stat/DVES_F96A96/POWER1:.* state
   room       Homekit,MQTT
   setList    off:noArg    cmnd/DVES_F96A96/POWER1 0
  on:noArg     cmnd/DVES_F96A96/POWER1 1
  toggle:noArg cmnd/DVES_F96A96/POWER1 2
  on-for-timer {my $duration = $EVTPART1 < 11.2 ? $EVTPART1*10 : $EVTPART1+100; 'cmnd/DVES_F96A96/Backlog pulseTime1 '.$duration.'; POWER1 1'}
   setStateList on off toggle
   stateFormat POWER1