Sonoff RF BridgeR2 mit Tasmota

Begonnen von Archimedes, 23 März 2024, 17:59:07

Vorheriges Thema - Nächstes Thema

Archimedes

Hallo,
auch wenn der FHEM Server schon seit 2016 bei uns die Hausautomation steuert, will ich dieses doch als Anfängerfrage formulieren, da alle Komponenten für mich Neuland sind.
Was soll erreicht werden: Die bisherigen 433MHz Sender auf Basis configurable Firmata (Arduino mit Ethernetmodul und 433MHz Sender, verdammt langer Thread hier im Forum) durch Tasmota mit MQTT2 ersetzen.
Leider bin ich aus den Forenbeiträgen nicht ganz schlau geworden, da mir an einigen Stellen die Zusammenhänge fehlen und damit Fragen für mich offen bleiben.

Was habe ich: Raspberry PI3 Bullseye mit FHEM 6.5 neu installiert, MQTT2 Modul eingerichtet und Sonoff RFBridgeR2 mit Tasmota 13.

Internals
CFGFN
CONNECTS
4
Clients
:MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
ClientsKeepOrder
1
DEF
1883 global
FD
9
FUUID
65fc1aca-f33f-3e5d-2d1d-ccb804f3f88742f9
NAME
MQTT2SRV
NR
42
PORT
1883
STATE
Initialized
TYPE
MQTT2_SERVER
eventCount
7

Sonoff RFBridgeR2 mit Tasmota 13.4.0.1 deutsch. Kein Portisch, funktioniert mit der R2 aktuell nicht. Ist mir nicht wichtig, da ich im Haus aktuell nur mit den alten Codes arbeite, also entweder das Mäuseklavier oder Intertechno V1, bei dem die Codierung aus Buchstaben und Zahlen an der FB eingestellt wird.
Tasmota MQTT Einstellungen DVES_%06X für Client und Topic, wie im Wiki beschrieben.
Über autoconfig wurde das Device angelegt. Logfiles protokollieren auch bereits empfangene Codes mit. Und nun weiß ich nicht weiter  :-\  :(
Aus den Forenbeiträgen ergibt sich für mich nicht die Version und Konfiguration der RF Bridge, also Portisch bei R1 oder nicht bei R2. Somit weiß ich nicht, an welche Anleitung welchen Forenbeitrag ich mich halten soll. Portisch erlaubt nicht die Tastenbelegung über das Webinterface, aber kann ich auch über die R2 ohne Portisch Sendecodes über cmnd auslösen (natürlich alles über FHEM) oder muss ich die 16 virtuellen Tasten vorbelegen und über FHEM nur diese drücken? Auch weiß ich nicht, ob das auszuwählende MQTT Template tasmota_rf für die R2 funktioniert. Aus diesem Grund habe ich noch nichts weiter ausgewählt.

Gruß Axel

Internals
CFGFN
CID
DVES_B47953
DEF
DVES_B47953
FUUID
65fd6254-f33f-3e5d-a4e8-0b212b42b0e03b88
IODev
MQTT2SRV
LASTInputDev
MQTT2SRV
MQTT2SRV_CONN
MQTT2SRV_192.168.178.115_58179
MQTT2SRV_MSGCNT
299
MQTT2SRV_TIME
2024-03-23 17:28:18
MSGCNT
299
NAME
MQTT2_DVES_B47953
NR
43
STATE
???
TYPE
MQTT2_DEVICE
eventCount
308

Readings
Heap 25 2024-03-23 17:48:18
IODev MQTT2SRV 2024-03-22 11:49:56
Info1_FallbackTopic cmnd/DVES_B47953_fb/ 2024-03-23 12:23:14
Info1_GroupTopic cmnd/tasmotas/ 2024-03-23 12:23:14
Info1_Module Sonoff RFBridge 2024-03-23 12:23:14
Info1_Version 13.4.0.1(tasmota-SONOFF_RF_BRIDGE_DE) 2024-03-23 12:23:14
Info2_Hostname DVES-B47953-6483 2024-03-23 12:23:14
Info2_IPAddress 192.168.178.115 2024-03-23 12:23:14
Info2_WebServerMode Admin 2024-03-23 12:23:14
Info3_BootCount 9 2024-03-23 12:23:14
Info3_RestartReason Power On 2024-03-23 12:23:14
LWT Online 2024-03-23 12:23:14
LoadAvg 19 2024-03-23 17:48:18
MqttCount 1 2024-03-23 17:48:18
POWER 2024-03-23 12:23:14
RfReceived_Data 01555F 2024-03-23 16:52:56
RfReceived_High 1860 2024-03-23 16:52:56
RfReceived_Low 614 2024-03-23 16:52:56
RfReceived_RfKey None 2024-03-23 16:52:56
RfReceived_Sync 18178 2024-03-23 16:52:56
Sleep 50 2024-03-23 17:48:18
SleepMode Dynamic 2024-03-23 17:48:18
Time 2024-03-23T17:48:18 2024-03-23 17:48:18
Uptime 0T05:25:10 2024-03-23 17:48:18
UptimeSec 19510 2024-03-23 17:48:18
Wifi_AP 1 2024-03-23 17:48:18
Wifi_BSSId 34:31:C4:2B:0B:55 2024-03-23 17:48:18
Wifi_Channel 6 2024-03-23 17:48:18
Wifi_Downtime 0T00:00:04 2024-03-23 17:48:18
Wifi_LinkCount 1 2024-03-23 17:48:18
Wifi_Mode 11n 2024-03-23 17:48:18
Wifi_RSSI 100 2024-03-23 17:48:18
Wifi_SSId FRITZ!Box 7490 2024-03-23 17:48:18
Wifi_Signal -47 2024-03-23 17:48:18
bat 0 2024-03-23 12:23:23
btn_1 0 2024-03-23 12:23:23
btn_10 0 2024-03-23 12:23:23
btn_11
0
2024-03-23 12:23:23
btn_12 .... usw....

Attributes
readingList
DVES_B47953:tele/DVES_B47953/LWT:.* LWT
DVES_B47953:cmnd/DVES_B47953/POWER:.* POWER
DVES_B47953:tele/DVES_B47953/INFO1:.* { json2nameValue($EVENT) }
DVES_B47953:tele/DVES_B47953/INFO2:.* { json2nameValue($EVENT) }
DVES_B47953:tele/DVES_B47953/INFO3:.* { json2nameValue($EVENT) }
DVES_B47953:tele/DVES_B47953/STATE:.* { json2nameValue($EVENT) }
DVES_B47953:tasmota/discovery/80646FB47953/config:.* { json2nameValue($EVENT) }
DVES_B47953:tasmota/discovery/80646FB47953/sensors:.* { json2nameValue($EVENT) }
DVES_B47953:tele/DVES_B47953/RESULT:.* { json2nameValue($EVENT) }

room   MQTT2_DEVICE


Beta-User

Zitat von: Archimedes am 23 März 2024, 17:59:07Aus den Forenbeiträgen ergibt sich für mich nicht die Version und Konfiguration der RF Bridge, also Portisch bei R1 oder nicht bei R2. Somit weiß ich nicht, an welche Anleitung welchen Forenbeitrag ich mich halten soll.
Das ist mit dem sehr "speziellen RF-Zeug" auch schwierig, die vorhandenen attrTemplate sind im Prinzip nur Beispiele, wie man es machen kann... Da (afaik) auch auf dem Tasmota-ESP selbst dann noch Codes als "Tasten" (oder "POWERx"?) gespeichert werden können (?) usw., ergeben sich noch viel mehr Kombinationsmöglichkeiten, so dass das ganze im Endeffekt schlicht extrem unübersichtlich ist.

Um die ggf. besser zu verstehen, wie (allgemein) die Zusammenhänge (und Möglichkeiten) mit MQTT2_DEVICE sind, empfehle ich "Schritt für Schritt" im Wiki (ist aber sehr straff).

Im Prinzip ist es m.E. am einfachsten, jede Hardware, die über die Bridge empfangen oder angesprochen werden soll als eigene MQTT2_DEVICE-Instanz anzulegen (wenn mehrere schalbare Relays verbaut sind, ggf. sogar mehrere Instanzen/Hardware), und dann ggf. in der readingList der jeweiligen Instanz auch gleich die Payload im "vorderen Teil" mit zu analysieren. (Mir ist klar, dass das sehr abstrakt klingt, fang' am besten mal damit an, in Ruhe den "Roh-Verkehr" am MQTT2_SERVER anzuschauen, wenn du Tasten an irgendeiner Fernbedienung drückst).
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

Archimedes

Moin, danke für die Info. Habe folgendes durchgeführt:
Sender und Funksteckdose mit Mäuseklavier, eine Lampe kann geschaltet werden.

https://tasmota.github.io/docs/Commands/#rf-bridge

Die SonoffBridgeR2 angelernt: Taste 1 Lampe an Taste 2 Lampe aus:
Die angelernten Codes sehen über die Tasmota Kommandozeile folgendermaßen aus(rfkey1 an, rfkey2 aus):

18:01:26.948 CMD: rfkey1 5
18:01:26.956 MQT: stat/DVES_B47953/RESULT = {"RfKey1":{"Sync":18922,"Low":586,"High":1814,"Data":"014551"}}
18:01:45.723 CMD: rfkey2 5
18:01:45.731 MQT: stat/DVES_B47953/RESULT = {"RfKey2":{"Sync":18922,"Low":584,"High":1814,"Data":"014554"}}

Der MQTT Traffic sieht hierzu folgendermaßen aus, wenn ich beide Keys über die Tasmota WebUI kurz nacheinander drücke:

18:53:32.142  DVES_B47953  stat/DVES_B47953/RESULT  {"RfKey1":"Learned sent"}
18:53:49.675  DVES_B47953  stat/DVES_B47953/RESULT  {"RfKey2":"Learned sent"}

Die Lampe schaltet ein und aus, aber was ist damit nun anzufangen ?
Der Traffic sieht etwas anders aus, wenn ich die original Fernbedienung drücke und die Lampe einmal an und wieder aus geht, das wird ja auch mit protokolliert:

18:37:10.981 DVES_B47953 tele/DVES_B47953/RESULT {"Time":"2024-03-24T18:37:10","RfReceived":{"Sync":17522,"Low":598,"High":1804,"Data":"01555F","RfKey":"None"}}
18:37:22.646 DVES_B47953 tele/DVES_B47953/RESULT {"Time":"2024-03-24T18:37:21","RfReceived":{"Sync":19192,"Low":596,"High":1804,"Data":"01555F","RfKey":"None"}}

Nur dafür hätte ich die Keys 1 und 2 nicht programmieren brauchen...

Was kann ich mit den Daten anfangen, um daraus ein FHEM Device für Einschalten / Ausschalten zu erstellen ?


Beta-User

Zitat von: Archimedes am 24 März 2024, 19:25:40Was kann ich mit den Daten anfangen, um daraus ein FHEM Device für Einschalten / Ausschalten zu erstellen ?
Hmmm, habe eben nochmal geschaut, scheinbar haben wir nur für OpenMQTTGateway ein paar Beispiele erstellt...

Hier mal der "Schnelldurchgang" - ausgehend vom aktuellen on/off-Device-template für 433MHz@OMG:
name:OpenMQTTGateway_simple_RF433_switch
prereq:{my @devices=devspec2array("model=OpenMQTTGateway_MCU");return 1 if $devices
;return 0}
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*/O[^/]*M[^/]*G[^/]*/.*
desc:use this with an OpenMQTTGateway. For further details visit https://github.com/1technophile/OpenMQTTGateway/wiki<br>Recommended structure of the topic pattern home/OpenMQTTGateway/.*.<br>NOTE: Initial version, not yet tested, just build according to https://forum.fhem.de/index.php/topic,103737.0.html<br>Adopt settings to your needs.<br>NOTE: this might create a new device!
order:X_02a
par:ONCOMMANDREGEX;ONCOMMANDREGEX typically is one or more Codes like 13027392|13519216|12585648|13349168;undef
par:ON_COMMAND;ON_COMMAND typically is a set of parameters like "value":"13027392","protocol":4,"length":24,"delay":350;undef
par:OFFCOMMANDREGEX;OFFCOMMANDREGEX typically is one or more Codes like 13381408|13226144|13381408|13599888;undef
par:OFF_COMMAND;ON_COMMAND typically is a set of parameters like "value":"13381408","protocol":4,"length":24,"delay":350;undef
par:BASE_ID;BASE_ID typically is home;{ AttrVal('DEVICE','devicetopic',AttrVal('DEVICE','readingList','')) =~ m<([^:]+)/O[^/]*M[^/]*G[^/]*> ? $1 : undef }
par:DEVNAME;DEVNAME typically contains OpenMQTTGateway;{ AttrVal('DEVICE','devicetopic',AttrVal('DEVICE','readingList','')) =~ m<[^:]+/(O[^/]*M[^/]*G[^/]*)> ? $1 : undef }
par:DEVCID;CID of the new device - try to read the last RF value; { ReadingsVal("DEVICE","value","unknown") }
par:NEWDEVROOM;Room of the calling device; {AttrVal('DEVICE','room','MQTT2_\DEVICE')}
defmod OMG_DEVCID MQTT2_\DEVICE DEVCID
deletereading -q OMG_DEVCID (?!associatedWith|IODev).*
defmod OMG_DEVCID MQTT2_\DEVICE DEVCID
attr OMG_DEVCID autocreate 0
attr OMG_DEVCID readingList\
  BASE_ID/DEVNAME/433toMQTT:.* { $EVENT =~ m,..value..(ONCOMMANDREGEX)..protocol..\d..length..\d+..delay..\d+.,? {"state"=>"on"} : $EVENT =~ m,..value..(OFFCOMMANDREGEX)..protocol..\d..length..\d+..delay..\d+., ? {"state"=>"off"}:return }\
  BASE_ID/DEVNAME/433toMQTT:.* { $EVENT =~ m,..value..([\d]+)..protocol..\d..length..\d+..delay..\d+.,? {"received_code"=>"$1"}:return }
attr OMG_DEVCID setList\
  on:noArg BASE_ID/DEVNAME/commands/MQTTto433 {ON_COMMAND}\
  off:noArg BASE_ID/DEVNAME/commands/MQTTto433 {OFF_COMMAND}

Wir brauchen also zum einen eine readingList, die "irgendwie" on und off erkennen kann und das in state schreibt. Und zum anderen eine setList, ebenfalls mit den MQTT-Kommandos für on und off...

Let's start:

define testlight MQTT2_DEVICE
attr testlight readingList stat/DVES_B47953/RESULT:.*"Data":"014551".* {{state=>'on'}}\
stat/DVES_B47953/RESULT:.*"Data":"014554".* {{state=>'off}}\
tele/DVES_B47953/RESULT:.*"Data":"01555F".* {{state=>ReadingVal($name,'state','off') eq 'on' ? 'off':'on'}
Vermutlich sind die ersten zwei Zeilen der readingList noch halbewegs klar, bei der dritten wissen wir nur, dass geschaltet wurde und toggeln einfach den Wert... suboptimal, aber anscheinend gibt die Hardware nicht mehr her.
Was die setList angeht, bin ich unsicher, auf welchen Topic die Kommandos gehen sollen. Nach https://tasmota.github.io/docs/Commands/#with-mqtt müßte es hier
cmnd/DVES_B47953/RfKey<x> y sein, um was mit den gespeicherten Keys zu machen, mit y=senden=1. Also:
attr testlight setList on cmnd/DVES_B47953/RfKey1 1\
  off cmnd/DVES_B47953/RfKey2 1

Hoffe, das paßt halbwegs, bitte erst mal selbst die Beiträge zu OMG lesen, Schreibfehler suchen und weiterspielen, wenn das unklar ist oder nicht funktionieren sollte...
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

Archimedes

Moin,
danke für die Infos! Habe erstmal folgendes gemacht und das Device angelegt. Bitte beachten, anhand der Tasmota Dokumentation https://tasmota.github.io/docs/Commands/#rf-bridge habe ich den Cmnd Befehl von Rfkeyx 1 auf Rfkeyx 6 geändert. Rfkeyx 1 sendet den Default Code, Rfkeyx 6 den erlernten Code.

define testlight MQTT2_DEVICE
attr testlight readingList stat/DVES_B47953/RESULT:.*"Data":"014551".* {{state=>'on'}}\
stat/DVES_B47953/RESULT:.*"Data":"014554".* {{state=>'off}}\
tele/DVES_B47953/RESULT:.*"Data":"01555F".* {{state=>ReadingVal($name,'state','off') eq 'on' ? 'off':'on'}
attr testlight room MQTT_Test
attr testlight setList on cmnd/DVES_B47953/RfKey1 6\
  off cmnd/DVES_B47953/RfKey2 6
#  FUUID      6606ea7a-f33f-3e5d-be96-093e76c4bc7428c0
#  IODev      MQTT2SRV
#  LASTInputDev MQTT2SRV
#  MQTT2SRV_CONN MQTT2SRV_192.168.178.115_58075
#  MQTT2SRV_MSGCNT 3
#  MQTT2SRV_TIME 2024-03-29 19:15:52
#  MSGCNT    3
#  NAME      testlight
#  NR        50
#  STATE      on
#  TYPE      MQTT2_DEVICE
#  eventCount 8
#  READINGS:
#    2024-03-29 17:48:13  IODev          MQTT2SRV
#    2024-03-29 17:50:07  state          on
#
setstate testlight on
setstate testlight 2024-03-29 17:48:13 IODev MQTT2SRV
setstate testlight 2024-03-29 17:50:07 state on


Schalten funktioniert und ergibt im MQTT2 Log

19:54:45.687 SENT cmnd/DVES_B47953/RfKey1 6
19:54:45.799 DVES_B47953 stat/DVES_B47953/RESULT {"RfKey1":"Learned sent"}

Alternativ dazu habe ich ein Dummydevice erstellt und sende über httpgetfile. Aber nur testweise. Ich möchte definitv MQTT2 nutzen.
Das funktioniert auch, allerdings ist zu beachten, hierbei nicht die 6, sondern die 1 anzugeben ("/?m=1&k=1").

define Schreibtisch dummy
attr Schreibtisch alias Schreibtisch
attr Schreibtisch room Arbeitszimmer
attr Schreibtisch setList on off
define off_Schreibtisch notify Schreibtisch:off { GetHttpFile("192.168.178.115:80", "/?m=1&k=2") }
attr off_Schreibtisch alias off_Schreibtisch
define on_Schreibtisch notify Schreibtisch:on { GetHttpFile("192.168.178.115", "/?m=1&k=1") }
attr on_Schreibtisch alias on_Schreibtisch


Somit erstmal alles supi das Ding über FHEM zu schalten mit MQTT oder http. Übrigens ist bei beiden Wegen das MQTT Protokoll identisch:

DVES_B47953 stat/DVES_B47953/RESULT {"RfKey1":"Learned sent"}

Wenn ich jetzt eine andere FB nehme und die Lampe erfolgreich schalte, so wird dieses von der Bridge erkannt und protokolliert. Dachte daraus könnte ich nun den Status ableiten...Allerdings habe ich noch niemals im Protokoll gesehen, dass er das einem Rfkey zuordnet. Ich habe hier 4 Protokolleinträge zweimal aus (1-2) und zweimal an (3-4). Und nun? Für mich nicht aussagekräftig. Von dieser FB habe ich die Rfkeys 1 und 2 angelernt!

2 mal aus
20:12:00.331 DVES_B47953 tele/DVES_B47953/RESULT {"Time":"2024-03-29T20:11:59","RfReceived":{"Sync":18490,"Low":602,"High":1804,"Data":"01555F","RfKey":"None"}}
20:12:03.794 DVES_B47953 tele/DVES_B47953/RESULT {"Time":"2024-03-29T20:12:03","RfReceived":{"Sync":17032,"Low":598,"High":1804,"Data":"01555F","RfKey":"None"}}
2 mal an
20:13:43.637 DVES_B47953 tele/DVES_B47953/RESULT {"Time":"2024-03-29T20:13:42","RfReceived":{"Sync":17014,"Low":600,"High":1804,"Data":"01555F","RfKey":"None"}}
20:13:52.214 DVES_B47953 tele/DVES_B47953/RESULT {"Time":"2024-03-29T20:13:51","RfReceived":{"Sync":17032,"Low":598,"High":1804,"Data":"01555F","RfKey":"None"}}

Um die ganze Sache noch etwas weiter zu verwirren, habe ich ein weiteres Dummydevice gebaut, welches mir den zugeordneten Tastencode im Logfile des MQTT Devices ausgibt:
Rfkey1 5 und Rfkey2 5.

2024-03-29_20:24:20 MQTT2_DVES_B47953 RfKey1_High: 1814
2024-03-29_20:24:20 MQTT2_DVES_B47953 RfKey1_Sync: 18922
2024-03-29_20:24:20 MQTT2_DVES_B47953 RfKey1_Data: 014551
2024-03-29_20:24:20 MQTT2_DVES_B47953 RfKey1_Low: 586
2024-03-29_20:25:30 MQTT2_DVES_B47953 RfKey2_Low: 584
2024-03-29_20:25:30 MQTT2_DVES_B47953 RfKey2_Sync: 18922
2024-03-29_20:25:30 MQTT2_DVES_B47953 RfKey2_Data: 014554
2024-03-29_20:25:30 MQTT2_DVES_B47953 RfKey2_High: 1814

Die Beiträge zu OMG werde ich die kommenden Tage lesen. Evtl. ergeben sich daraus weitere Erkenntnisse.
Kurz:
- Schalten funktioniert über MQTT und http mit FHEM
- Device ist aktuell begrenzt auf 8 Geräte on/off wegen fehlendem Portisch (kein FHEM Problem, siehe Tasmota Doku)
- Logfiles gibt es, Device bedingt nicht wirklich aussagekräftig
- Braucht nach einer Pause einige Anläufe, bis er reagiert, egal ob über MQTT oder http, wohl WLAN bedingt. Muss sehen wie ich damit umgehe.

Gruß Axel

Beta-User

Zitat von: Archimedes am 29 März 2024, 20:43:22Wenn ich jetzt eine andere FB nehme und die Lampe erfolgreich schalte, so wird dieses von der Bridge erkannt und protokolliert. Dachte daraus könnte ich nun den Status ableiten...Allerdings habe ich noch niemals im Protokoll gesehen, dass er das einem Rfkey zuordnet. Ich habe hier 4 Protokolleinträge zweimal aus (1-2) und zweimal an (3-4). Und nun? Für mich nicht aussagekräftig. Von dieser FB habe ich die Rfkeys 1 und 2 angelernt!
Hmmm, da die Firmware für diese FB keine wirklich eindeutigen Ergebnisse liefert, kann man nur versuchen, daraus ein logisches "toggle" zu machen, wie das ja schon in der readingList drin ist (und evtl. nicht funktioniert). Besser wird es nicht...

Würde das Ding schlicht gegen was anderes ersetzen (ich nehme für sowas in der Regel ZigBee), der 433MHz-"Gruscht" ist halt einfach technisch nicht mehr auf der Höhe der Zeit.
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