mqtt2.template für RFbridge von Sonoff entwickeln

onkel-tobi · 11 Mai 2019, 12:15:15

Wo genau schau ich mir die ra messages an?
Passt das von meinem Vorgehen, was ich beschrieben hab?

Also solange ich die rL aus dem MQTT2_m2c MQQT2_device nicht lösche, empfange ich dort Daten. Selbst nach Erstellung des Bridge Devices. Sobald ich da aber die rL lösche, bekomme ich weder bei der bridge noch bei dem MQTT2_m2c irgendetwas an Daten, auch nicht nach reboot der sonoff...

Update: Was ich nicht verstehe ist, wieso im Dropdown bei attrTemplate die rf aktuell nicht auswählbar ist. War sie vorhin. Aktuelle Version ist drauf und in der mqtt2.template lokal ist der Abschnitt drin?!

Beta-User · 11 Mai 2019, 16:03:22

Zitat von: onkel-tobi am 11 Mai 2019, 12:15:15
Wo genau schau ich mir die ra messages an?

Am IO = m2c.
Brauchst du aber nicht mehr, was wir wissen wollten war, ob regelmäßig Messages reinkommen. Tun sie, wie du später ja geschrieben hast.

ZitatAlso solange ich die rL aus dem MQTT2_m2c MQQT2_device nicht lösche, empfange ich dort Daten. Selbst nach Erstellung des Bridge Devices. Sobald ich da aber die rL lösche, bekomme ich weder bei der bridge noch bei dem MQTT2_m2c irgendetwas an Daten, auch nicht nach reboot der sonoff...

Das hört sich SEHR GUT an.

Nochmal zur Erläuterung: kommt irgendwas rein, wird (aber jeweils erst bei Eingang der Nachricht!) zuerst nachgesehen, ob es ein Device gibt, das die Daten "abnimmt", also einen passenden readingList-Eintrag hat. Solange das am "falschen" Device der Fall ist, landet die Info dort (=> bei dir: MQTT2_m2c). Löschst du dort den rL-Eintrag, _muß_ eigentlich ein Device erstellt oder ergänzt werden (aktuelles FHEM vorausgesetzt).

Dazu werden zuerst _alle_ bridgeRegexp-Ausdrücke ausgewertet (egal, bei welchem Device sie stehen). Paßt das => das Device mit der CID, auf die die bridgeRegex verweist ($1 usw. hinten) ist der Abnehmer. Paßt es nicht: das Device mit der CID ist der Abnehmer (bei dir: MQTT2_m2c).

Ergo behaupte ich ganz frech, dass du ein neues Device hast, das du übersiehst... Die Daten landen definitiv irgendwo, und wenn es nicht in der Bridge ist (da ist es in diesem setup nie!), nicht im Device mit der m2c-CID (MQTT2_m2c), dann ist es ein NEUES Device, entsprechend der Vorgabe der bridgeRegexp.
=> Suchen, sobald was gesendet wurde.

Ggf. mal den Event-Monitor zu Rate ziehen.

ZitatUpdate: Was ich nicht verstehe ist, wieso im Dropdown bei attrTemplate die rf aktuell nicht auswählbar ist. War sie vorhin. Aktuelle Version ist drauf und in der mqtt2.template lokal ist der Abschnitt drin?!

Auch das ist völlig normal. Man sieht praktisch nie alle templates, die werden gefiltert. Hier: kein passender readingList-Eintrag => wenige tasmota-templates.

Imo. also alles, wie es sein sollte, wir scheinen nur aneinander vorbei zu reden... (die verlinkten Wiki-Beiträge hast du gelesen, oder?)

DasQ · 12 Mai 2019, 14:48:41

ich bin mir nicht sicher in wie weit die RF funktionalität der Sonoff 4CH und Touch T1 mit der Bridge zu tun hat, die Doku ist da etwas lückenhaft bis nicht vorhanden. Als RF empfänger können beide mit Tasmota genutzt werden. allerdings konnt ich nichts brauchbares in den log`s finden und readings werden auch keine erzeugt.

************************** [edit] *************************

also die Sonoff geräte Sonoff 4CH pro und Sonoff Touch T1 (1-3 Gang/CH) können nur RF empfangen (reciever)

in wie weit man sich jetzt gedanken macht, diese funktion, auf basis der erkenntnisse aus diesem thread, kann dann in einem eigenen thread diskutiert werden.

onkel-tobi · 18 Mai 2019, 21:59:41

So, hatte und habe leider aktuell wenig Zeit aber heute noch mal drüber geschaut.

Zitat von: Beta-User am 11 Mai 2019, 16:03:22
=> Suchen, sobald was gesendet wurde.
Ggf. mal den Event-Monitor zu Rate ziehen.Auch das ist völlig normal. Man sieht praktisch nie alle templates, die werden gefiltert. Hier: kein passender readingList-Eintrag => wenige tasmota-templates.

Definitiv kein neues device. Eventviewer bringt mich auch nicht weiter.
Version ist 19345, werde aber noch mal updaten und anschließend noch mal testen & Ergebnis dann posten.

Gruß,
Tobi

onkel-tobi · 23 Mai 2019, 21:01:48

Also ich kriege es nicht hin.
dast _m2c device - solange es alleine da ist- nimmt die readings alle an.
Sobald ich dann das template GeneralBridge anwende und das 2. device angelegt wird (MQTT2_GeneralBridge), kommt nichts mehr...

Noch irgendeine Idee?

Beta-User · 24 Mai 2019, 08:36:16

Hmmm, also, jetzt habe ich das mit einem Testsystem mal nachgestellt, und kann das bestätigen:
Dieser Schrägstrich am Anfang des Topic-Pfades macht es "kaputt", aber aus irgendeinem Grund, über den ich (oder ggf. Rudi) mal grübeln muß erst dann, wenn CID und Topic-Tree getrennt werden

, wofür es scheinbar ausreicht, wenn (irgend-) eine bridgeRegexp definiert ist.

(Sch.. "ich mach das dann mal so, weiß auch nicht, ob das gut ist, aber bisher ist es gutgegangen..." in diesem Video; bei den (ordentlichen) firmwares und daemons, die mir bisher über den Weg gelaufen sind, macht _ keine/r_ vorab einen "/" in den (default-) Topic-Pfad....)

Wie gesagt, darüber muß ich mal "hirnen", einstweilen würde ich vorschlagen, in der tasmota-Konfiguration mal den ersten "/" vor "Smarthome" wegzulassen und dementsprechend auch die bridgeRegexp an der Stelle zu ändern.
Jedenfalls mit mosquitto_pub konnte ich damit dann - den Erwartungen entsprechend - neue Geräte anlegen.

onkel-tobi · 25 Mai 2019, 18:05:27

Ich hatte das topic ehrlich gesagt auch einfach so gelassen.
Habe eine Anleitung eines blogs befolgt und ja, hat halt funktioniert

BreidgeRegexp wäre dann so korrekt?

Code Auswählen

Smarthome[/]([^/]+)[/]([^/]+)[/](tele|cmnd|stat)[/].* "$2"\
shellies[/]([^/]+)[/].*:.* "$1"\
(ESPClient_[^/]+)[/].*:.* "$1"

Denn da passiert aktuell noch nichts.rL des _m2c devices muss ja gelöscht werden, wenn ich das richtig in Erinnerung habe.

Danke & Gruß,
Tobi

Beta-User · 27 Mai 2019, 09:30:11

Ergänze mal in der Smarthome-Zeile noch ":.*". Also so:

Code Auswählen

Smarthome[/]([^/]+)[/]([^/]+)[/](tele|cmnd|stat)[/].*:.* "$2"\

Beta-User · 28 Mai 2019, 07:51:36

Also, eben habe ich das mit einem mosquitto und aktuellen Modulen nochmal durchgespielt.
Gibt es ein autocreate-Device, der MQTT2_CLIENT steht auf autocreate simple und man hat in der per "set ... attrTemplate A_00_MQTT2_CLIENT_general_bridge" erstellte GeneralBridge (MQTT2_DEVICE) folgende bridgeRegexp (hier: Eingabe in das Textfeld zur Bearbeitung des Attribut-inhalts) eingestellt:

Code Auswählen

/Smarthome[/]([^/]+)[/]([^/]+)[/](tele|cmnd|stat)[/].*:.* "$2"
  shellies[/]([^/]+)[/].*:.* "$1"
  (ESPClient_[^/]+)[/].*:.* "$1"

und die readingList im "Sammeldevice" gelöscht.
Dann wird bei einem

Code Auswählen

mosquitto_pub -h zigbeepi -i SmartHome -t /Smarthome/Buero/DVES_9EFABC/tele/LWT -m onlineautomatisch ein Device namens MQTT2_DVES_9EFABC angelegt (RAW):

Code Auswählen

defmod MQTT2_DVES_9EFABC MQTT2_DEVICE DVES_9EFABC
attr MQTT2_DVES_9EFABC IODev myMQTTclient
attr MQTT2_DVES_9EFABC readingList /Smarthome/Buero/DVES_9EFABC/tele/LWT:.* LWT
attr MQTT2_DVES_9EFABC room MQTT2_DEVICE

Bin im Moment ratlos, warum das bisher erfolglos war, aber mit einem aktuellen FHEM sollte es jetzt stressfrei gehen.

onkel-tobi · 04 Juni 2019, 19:06:59

So, es funktioniert nun auch bei mir.
Danke noch ma für deine Hilfe. Nun muss ich dann die Tage mal schauen wie es weitergeht. Auf jd. Fall war das heute ja schon mal ein Riesen Schritt

)

Gruß,
Tobi

onkel-tobi · 07 Juni 2019, 16:05:42

Hi BetaUser,

wie mache ich dann jetzt nun weiter? Sollten Geräte, die via 433 mHz und die Bridge geschaltet werden selber angelegt werden?
Die Bridge sieht so aus:

Code Auswählen

Internals:
   CFGFN      
   CID        DVES_9EFABC
   DEF        DVES_9EFABC
   DEVICETOPIC MQTT2_DVES_9EFABC
   FUUID      5cf6a1eb-f33f-daf3-5d40-57bbc687c6dd0075
   IODev      m2c
   LASTInputDev m2c
   MSGCNT     2510
   NAME       MQTT2_DVES_9EFABC
   NR         171198
   STATE      rfsend
<br>
<a href="http://192.168.18.151" target="_blank">192.168.18.151</a>
   TYPE       MQTT2_DEVICE
   m2c_MSGCNT 2510
   m2c_TIME   2019-06-07 15:47:24
   READINGS:
     2019-06-07 14:21:31   Data            412426
     2019-06-04 18:53:00   FallbackTopic   DVES_9EFABC
     2019-06-04 18:53:00   GroupTopic      sonoffs
     2019-06-04 18:53:00   Hostname        Sonoff-Bridge
     2019-06-04 18:53:00   IPAddress       192.168.18.151
     2019-06-05 18:12:59   LWT             Online
     2019-06-04 18:53:00   Module          Sonoff Bridge
     2019-06-04 18:53:00   POWER           
     2019-06-04 18:53:00   RestartReason   Software/System restart
     2019-06-06 17:21:56   RfReceived_Data 412426
     2019-06-06 17:21:56   RfReceived_High 1200
     2019-06-06 17:21:56   RfReceived_Low  400
     2019-06-06 17:21:56   RfReceived_RfKey None
     2019-06-06 17:21:56   RfReceived_Sync 12300
     2019-06-07 15:47:24   Time            2019-06-07T14:47:25
     2019-06-07 15:47:24   Uptime          2T20:54:33
     2019-06-07 15:47:24   Vcc             3.197
     2019-06-04 18:53:00   Version         6.1.1
     2019-06-04 18:53:00   WebServerMode   Admin
     2019-06-07 15:47:24   Wifi_AP         1
     2019-06-07 15:47:24   Wifi_APMac      8A:8A:20:8D:97:25
     2019-06-07 15:47:24   Wifi_RSSI       82
     2019-06-07 15:47:24   Wifi_SSId       HA
     2019-06-06 19:02:00   associatedWith  MQTT2_GeneralBridge
     2019-06-07 14:21:31   json_raw        {"RfReceived":{"Sync":12300,"Low":400,"High":1190,"Data":"412426","RfKey":"None"}}
     2019-06-06 20:07:10   state           rfsend
Attributes:
   IODev      m2c
   event-on-change-reading .*
   model      A_01d_tasmota_rf
   readingList /Smarthome/Buero/DVES_9EFABC/tele/INFO.:.* { json2nameValue($EVENT) }
  /Smarthome/Buero/DVES_9EFABC/tele/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...([A-Za-z0-9]+)...RfKey...([^"]+)..., ? {"json_raw"=>$EVENT} : undef }
  /Smarthome/Buero/DVES_9EFABC/tele/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...([A-Za-z0-9]+)...RfKey...([^"]+)..., ? {"Data"=>"$4"} : undef }
/Smarthome/Buero/DVES_9EFABC/tele/STATE:.* { json2nameValue($EVENT) }
/Smarthome/Buero/DVES_9EFABC/tele/UPTIME:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    power:noArg /Smarthome/Buero/DVES_9EFABC/cmnd/RFsend POWERCMD
  volumeup:noArg /Smarthome/Buero/DVES_9EFABC/cmnd/RFsend VOLUMEUPCMD
  rfsend:textField /Smarthome/Buero/DVES_9EFABC/cmnd/RFsend {"Protocol":"$EVTPART1","Bits":$EVTPART2,"Data":"0x$EVTPART3"}
   stateFormat state
<br>
<a href="http://IPAddress" target="_blank">IPAddress</a>

Ansonsten habe ich auch mal probiert via RFsend den code zu senden, aber das funktioniert leider so nicht?
Hast Du oder jemand anderes noch einen Denkanstoß für mich?

Danke & Gruß,
Tobi

Beta-User · 07 Juni 2019, 17:03:08

Also:

Zum einen kann die Bridge wohl einzelne Codes (paarweise?) direkt speichern. Die kann man dann auch (via MQTT) direkt abrufen. Wenn du sowas haben willst, mußt du dir überlegen, wie du die Codes da reinbringst und dann wissen, wie sie via MQTT abgerufen werden können (beides sollte kein Hexenwerk sein und der Doku zu tasmota zu entnehmen sein). Wenn du das hast, würde ich für jedes Paar ein weiteres MQTT2-Device anlegen mit on/off als setList (und den zugehörigen cmnd-Anweisungen). Damit kann das dann auch SetExtensions-OnForTimer etc..

Zum anderen könntest du versuchen rauszufinden, wie du eigene Sendecodes bastelst. Da würde ich darauf tippen, dass es ähnlich ist wie bei der IR-Variante (da war irgendeine Kleinigkeit im JSON unterschiedlich zum Empfang), ich hatte dazu auch hier schon mal Vermutungen geäußert, wie das sein könnte. Auch da gilt: erst mal die Doku studieren und ggf. bei tasmota nachfragen, beim "Übersetzen in FHEM/MQTT2-Device" bin ich dann gerne behilflich.
Dann wäre wieder die Frage, ob es einfache on/off-Geräte sein sollen, oder ob es komplexer ist. In letzterem Fall würde ich dazu raten, remotecontrol zu nutzen und eine generische Sendecode-Zeile in dem vorhandenen MQTT2-Device zu verwenden. (Meine Güte, das klingt kompliziert, ist es aber eigentlich nicht, der JSON wird ja scheinbar sauber zerteilt, wenn ich das richtig sehe. Das können wir auch gerne step by step zusammen entwickeln, aber dazu müßte ich zuerst wissen, was du eigentlich in der "Realität" erreichen willst

).

onkel-tobi · 07 Juni 2019, 17:25:16

Zitat von: Beta-User am 07 Juni 2019, 17:03:08
...aber dazu müßte ich zuerst wissen, was du eigentlich in der "Realität" erreichen willst ).

Danke.
Also ich habe bisher keine codes auf dem sonoff gespeichert, sondern habe auc einzelne devices angelegt a la:

Code Auswählen

Internals:
   CFGFN      FHEM/wohnzimmer.cfg
   FUUID      5c5dae97-f33f-d748-26b6-a78b76d79c9c2d8b
   IODev      Mosquitto
   NAME       eg_wz_p1
   NR         414
   STATE      off
   TYPE       MQTT_DEVICE
   READINGS:
     2019-06-07 06:51:01   state           #1514
     2019-06-07 06:51:01   transmission-state outgoing publish sent
   message_ids:
   publishSets:
     :
       topic      /Smarthome/Buero/sonoffrf/cmnd/RfCode
       values:
         on
         off
         toggleon
         off
         toggle
   sets:
     off        
     on         
     toggle     
     toggleon   
   subscribe:
   subscribeExpr:
   subscribeQos:
Attributes:
   IODev      Mosquitto
   alexaName  "Couch passiv"
   alias      "Couch passiv"
   devStateIcon ON:rc_GREEN:OFF OFF:rc_RED:ON Offline:rc_BLUE:OFF
   event-on-change-reading state
   eventMap   #1511:on #1514:off
   publishSet on off toggleon off toggle /Smarthome/Buero/sonoffrf/cmnd/RfCode
   room       Licht,MQTT,Wohnzimmer
   stateFormat {ReadingsVal($name,"presence","") eq "Offline" ? "Offline" : ReadingsVal($name,"state","")}
   webCmd     on off toggle

Das hat für mich so funktioniert, ich wusste was zutun ist und gut war es

Jetzt haben wir ja was anderes getestet und (ich glaube wg. dem topic bei publisSet funktioniert der Status quo halt nicht mehr.
Könnte das natürlich anpassen, aber ich dachte wenn schon mqtt2 ist das vllt. eben auch ganz anders gedacht?...
Dazu muss ich dann noch meine mumbi's einbinden, aber in der Theorie sollte sich das ja auch finden lassen, da sie auch einen code senden.

Ich hoffe Du verstehst was ich meine?

Beta-User · 08 Juni 2019, 11:29:12

Die Frage ist, wo "damals" die Angaben herkamen.

Für mich sieht das so aus, als gäbe es eine Art Datenbank mit diversen Codes, die auf der Bridge gespeichert sind, die man auf "RfCode" unter dem cmnd-Pfad aufrufen kann. Die "#nnnn" scheinen Codes aus der Datenbank/Liste zu sein?
Da hier das Topic etwas anders geschrieben wird, ist auch das Topic für JSON-Sendeanweisungen ggf. etwas anders?

Würde daher mal die setList so probieren:

Code Auswählen

setList on:noArg /Smarthome/Buero/DVES_9EFABC/cmnd/RfCode #1511
  off:noArg /Smarthome/Buero/DVES_9EFABC/cmnd/RfCode #1514
  rfsend:textField /Smarthome/Buero/DVES_9EFABC/cmnd/RfSend {"Protocol":"$EVTPART1","Bits":$EVTPART2,"Data":"0x$EVTPART3"}

Ansonsten (wenn das on/off nicht klappt bzw. das generische "rfsend" aktiviert werden soll oder so nicht funktioniert) wären Auszüge aus der Rf-Topicstruktur und den Formaten, wie was zu versenden ist aus der tasmota-Doku hilfreich.

Wenn es klappt, kannst du dieses on/off-Paar dann auch wieder auf eine eigenes Device auslagern bzw. weitere nach diesem Muster (mit anderen Codes) anlegen.

onkel-tobi · 09 Juni 2019, 09:43:11

Zitat von: Beta-User am 08 Juni 2019, 11:29:12
Wenn es klappt, kannst du dieses on/off-Paar dann auch wieder auf eine eigenes Device auslagern bzw. weitere nach diesem Muster (mit anderen Codes) anlegen.

Hi,

also das scheint soweit erst mal zu klappen. Was genau meinst Du mit auslagern? Stehe da noch etwas auf dem Schlauch, denn das Gerät kopieren und die setlist anpassen wäre ja zu einfach, da es sich bei dem Gerät selbst ja um die bridge handelt?

Ich bin eigtl. bisher immer so vorgegangen, dass ich mir das auf der Console (der sonoff bridge) angeschaut habe und dann entsprechend den rfcode für das on/off in einem Device verwendet.

Außerdem hab ich dann noch ein paar Bewegungssensoren, die werden in der Bridge als auch schon als json raw angezeigt:

Code Auswählen

json_raw
{"RfReceived":{"Sync":12340,"Low":390,"High":1200,"Data":"412426","RfKey":"None"}}

Da würde ich dann vermutlich ne doif schreiben, die je nach Data ein Dummy beschreibt, oder macht das Sinn, dass dann auch anders zu machen?

Danke nochmals & schöne Feiertage,
Tobi