[gelöst] Mit Sonoff RF Bridge 433 und Sonoff RM433 Befehle empfangen und senden

[Mihca]

Meine Sonoff RF Bridge ist mit Tasmota 8.3.1 und der Portisch Firmware für den RF-Sender geflasht (https://tasmota.github.io/docs/devices/Sonoff-RF-Bridge-433/). Als Device wurde sie automatisch in Fhem angelegt. Als Template hat sie tasmota_rf. Mit dem Fhem Template empfängt Fhem aber von der Bridge keine Kommandos, die gesendet oder empfangen werden. Die Reading-List ist im Fhem-Template mE unvollständig. Hier meine entsprechend angepasste RAW-Definition:

Code Auswählen Erweitern

defmod SonoffRF MQTT2_DEVICE SonoffRF
attr SonoffRF IODev MQTT2Server
attr SonoffRF autocreate 1
attr SonoffRF devStateIcon Online:mqtt_bridge_2@#1de223 Offline:mqtt_bridge_2@red
attr SonoffRF event-on-change-reading .*
attr SonoffRF icon mqtt_bridge_2
attr SonoffRF model tasmota_rf
attr SonoffRF readingList tele/tasmota_C0D1C6/INFO.:.* { json2nameValue($EVENT) }\
  tele/tasmota_C0D1C6/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...([A-Za-z0-9]+)...RfKey...([^"]+)..., ? {"json_raw"=>$EVENT} : undef }\
  tele/tasmota_C0D1C6/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...([A-Za-z0-9]+)...RfKey...([^"]+)..., ? {"Data"=>"$4"} : undef }\
SonoffRF:tele/tasmota_C0D1C6/LWT:.* LWT\
SonoffRF:cmnd/tasmota_C0D1C6/POWER:.* POWER\
SonoffRF:tele/tasmota_C0D1C6/STATE:.* { json2nameValue($EVENT) }\
SonoffRF:tele/tasmota_C0D1C6/RESULT:.* { json2nameValue($EVENT) }\
SonoffRF:stat/tasmota_C0D1C6/RESULT:.* { json2nameValue($EVENT) }
attr SonoffRF room MQTT2_DEVICE
attr SonoffRF setList rfsend:textField cmnd/tasmota_C0D1C6/RFsend {"$EVTPART1"}
attr SonoffRF stateFormat LWT\
<a href="http://IPAddress" target="_blank">IPAddress</a>


An der Bridge habe ich die Sonoff RM433 auf die ersten 8 Keys angelernt (https://tasmota.github.io/docs/Commands/#rf-bridge). (Ich hatte vorher erfolglos versucht eine Intertechno ITS-10 Fernbedienung anzulernen.) Um Befehle, die von der Bridge emfangen werden, in Fhem auszuwerten, habe ich folgendes Notify angelegt:

Code Auswählen Erweitern


defmod SonoffRFnotify notify SonoffRF:RfReceived.*:.* \
\
{\
my $RfKey = ReadingsVal("SonoffRF", "RfReceived_RfKey","undefined");;\
\
{\
if    ($RfKey eq "1") {fhem("set RolloWesten on")}\
elsif ($RfKey eq "2") {fhem("set RolloWesten off")}\
elsif ($RfKey eq "3") {fhem("set RolloSueden on")}\
elsif ($RfKey eq "4") {fhem("set RolloSueden off")}\
elsif ($RfKey eq "5") {fhem("set RolloTerrasse on")}\
elsif ($RfKey eq "6") {fhem("set RolloTerrasse off")}\
elsif ($RfKey eq "7") {fhem("set RolloEssen on")}\
elsif ($RfKey eq "8") {fhem("set RolloEssen off")}\
};;\
\
}
attr SonoffRFnotify icon helper_doiftools
attr SonoffRFnotify room Timer


Das funktioniert soweit jetzt alles prima. Die RfKey[1-8] der RM433 werden zuverlässig empfangen und die Rollos über Fhem geschaltet.

Eigentlich deckt das meinen Anwendungsfall ab. Da ich aber gerade daransitze, würde ich der Vollständigkeit halber gerne die RfKey[1-16] Kommandos auch versenden können. Ich habe mich bereits durch diverse Threads durchgearbeitet, aber ich kriege nichts Vernünfiges hin.

Wenn ich in der Tasmota-Web-Konsole der Bridge "RfKey1" eingebe, kommt die Meldung:

Code Auswählen Erweitern

stat/tasmota_C0D1C6/RESULT = {"RfKey1":"Learned sent"} Wenn ich in der Set-List der Bridge in Fhem "RfKey1" eingebe, kommt in der Tasmota-Konsole die Meldung:

Code Auswählen Erweitern

stat/tasmota_C0D1C6/RESULT = {"Command":"Unknown"}

Kann jemand helfen?

Vielen Dank vorab!

VG Achim

[Beta-User]

Eigentlich deckt das meinen Anwendungsfall ab. Da ich aber gerade daransitze, würde ich der Vollständigkeit halber gerne die RfKey[1-16] Kommandos auch versenden können. Ich habe mich bereits durch diverse Threads durchgearbeitet, aber ich kriege nichts Vernünfiges hin.

...irgendwie wollte bisher keiner der User das Ding vollends zuende bringen, also: Danke!...

In der Doku steht:

RfKey<x> Send learned or default RF data for RfKey<x> (x = 1 – 16)
1 = send default RF data for RfKey<x> using RfSync, RfLow, RfHigh and RfHost parameters[....] 6 = send learned RF data

Daraus hätte ich jetzt folgendes für eine setList gebaut (key1 könnte auch "on" sein usw.):

Code Auswählen Erweitern

key1:noArg cmnd/tasmota_C0D1C6/RfKey1 6\
key2:noArg cmnd/tasmota_C0D1C6/RfKey2 6

Generell zu "RolloWesten": Ist das eine Art dummy-Device, oder könnte das auch MQTT2_DEVICE sein, das dann nur die RF-Keys 1 und 2 abbonniert und (MQTT-mäßig) sendet?

MMn. würde es Sinn machen, die RF-Keys ggf. paarig je an eigene MQTT2_DEVICE-Instanzen zu verlagern und nicht in der Bridge selbst zu verwalten?

[Mihca]

Ich bin begeistert  , das funzt! Eigentlich hätte ich da auch durch Lesen der von mir zitierten Anleitung selbst drauf kommen können. Ein super Danke mal wieder an Dich!

Gibt es jetzt noch eine Abkürzung, damit man da nicht 16 keys auflisten muss? Wie z.B.:

Code Auswählen Erweitern


RfKey[1-16]:noArg cmnd/tasmota_C0D1C6/RfKey[1-16] 6\   # das ist natürlich falsch so!


RolloWesten und RolloOsten sind Structures, mit denen mehrere MQTT2-Rollo-Schalter (Sonoff T2 EU 2C) geschaltet werden sollen. Es ist ein Projekt für ein neues Haus; derzeit sind die dahinterliegenden MQTT2-Rollos noch Dummies, bis alle Sonoff T2 2C aus China da sind. RolloTerrasse und RolloEssen sind MQTT2-Einzelrollos (derzeit noch Dummies).

[Beta-User]

 

Das mit der "Abkürzung" ginge selbstredend (mit etwas Perl). Falls du "üben" magst, hier mal ein Ansatzpunkt: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L3293

(ich glaube aber nicht, dass du damit insgesamt glücklich wirst, wie gesagt: paarweise an ein MQTT2_DEVICE packen und das dann mit on/off belabeln dürfte zielführender sein).

OT: neues Haus und WLAN-Schrott ist eine Sch...-Kombination; ich hoffe, du hast dir das gut überlegt bzw. deinen Freund/Abnehmer deutlich gewarnt, das das zwar billig, aber ansonsten unter vielen Gesichtspunkten suboptimal ist!

Nachtrag: Wenn es indirekt darum geht, einen MQTT-Weg zur Steuerung der structures usw. zu haben, käme hier ggf. auch eine MQTT_GENERIC_BRIDGE in Frage, die die MQTT-Events direkt an die Zieldevices leitet zur weiteren Auswertung.

[Mihca]

Danke Ob ich das dann mit dem Perl übe, oder dann eben doch 16 RfKeys definiere, überlege ich mir noch.

Habe das mit dem WLAN lange überlegt. Ich hatte früher viele HomeMatic Aktoren, die ich alle durch die Sonoffs ersetzt habe. Damit bin ich ganz zufrieden. KNX war mir am Ende zu teuer.

Das mit den Structures lasse ich jetzt so. Ich fürchte auf dem von Dir vorgeschlagenen Weg "verbastele" ich mich, da ich nicht fit genug in Perl und MQTT bin. Deshalb bin ich ja auch so oft hier zum fragen

Nochmals Danke!
VG Achim

[Beta-User]

Na ja, mußt du selbst wissen... Vielleicht wäre es möglich, wenigstens die Aktoren nicht dezentral einzubauen, sondern die Kabel alle am Schaltschrank zusammenzuführen. Dann kannst du (oder ein späterer Käufer der Hütte...) irgendwann doch umrüsten, falls es sich als notwendig oder zweckmäßig erweist.
Es gibt übrigens bei Tasmota auch eine "Vielfach"-Rollladenfunktion - entsprechend viele freie PINs vorausgesetzt. Sowas reduziert wenigstens die Zahl der WLAN-Teilnehmer, und ein mit der Problemanalyse im dümmsten Fall beauftragter Elektriker weiß wenigstens, wie die Installation in etwa funktionieren könnte...

Was die structures anbelangt, war der Vorschlag auch nicht so zu verstehen, dass die entfallen sollen, sondern, dass du MGB dazu nutzen kannst, direkt die structures zu steuern, ohne noch einen extra Eventhandler zwischenschalten zu müssen. Aber wegen der paar Infos ist es auch egal.
(Und Perl kann man lernen, wie du an mir siehst... Dürfte eher ein Problem der Gleichzeitigkeit sein - neben einem Neubau her ist es keine so gute Idee ).

[Mihca]

Das mit der Zentralen Steuerung und den 4-fach Schaltern hatte ich auch überlegt. Aber wenn man dann noch per Hand am jeweiligen Fenster schalten möchte, wirds kompliziert.

[Beta-User]

Na ja, ein normaler (gegen Doppelbetätigung verriegelter) Doppeltaster sollte den Job machen können - entsprechende 230V-verträgliche Eingänge am zentralen Aktor und ein entsprechendes Kabel dahin vorausgesetzt . (Das kann man dann ggf. später auch für was anderes nutzen oder gleich in Niederspannung auslegen - nur 3.3V sind allerdings bei längeren Strecken  Mist...)

[Mihca]

Ja, das ginge, hatte ich auch überlegt. Aber der Sonoff/Fhem weis dann mE nicht mehr, wie das Rollo steht. Dann müsste man anfangen am Sonoff herumzulöten und freie GPIOS soweit es die beim 4-fach Schalter noch gibt mit Rückmeldungen versehen. Da ist die Lösung mit 2-Kanal Sonoffs am jeweiligen Fenster einfacher.

[Beta-User]

Na ja, also wenn ich das mit der Rollladenfunktion@Tasmota richtig verstanden habe, weiß die recht gut, wo der Rollladen jeweils steht - eine ordentliche Kalibrierung vorausgesetzt; und das v.a. auch bei lokaler Tastenbetätigung. (Die firmware sieht mir nach der besten Rollladenimplementierung aus, die mir bisher über den Weg gelaufen ist, weil ziemlich viele Parameter gesetzt werden können, die indirekt auch die Dicke der Panzerwicklung mit berücksichtigen... Da Ding hat wirklich nur die Haken, dass es WLAN ist und ggf. auf Fertigungsqualität zugunsten des günstig möglichsten Preises verzichtet wurde).

[Mihca]

Das überlege ich nochmal. Für alle, die eine Lösung zum eingangs beschriebenen Problem suchen, hier der derzeitige Stand der Lösung für 8 Schalter (zusammen mit dem Notify aus meinem Eingangsbeitrag funktioniert das prima):

Code Auswählen Erweitern

defmod SonoffRF MQTT2_DEVICE SonoffRF
attr SonoffRF IODev MQTT2Server
attr SonoffRF autocreate 1
attr SonoffRF devStateIcon Online:mqtt_bridge_2@#1de223 Offline:mqtt_bridge_2@red
attr SonoffRF event-on-change-reading .*
attr SonoffRF icon mqtt_bridge_2
attr SonoffRF model tasmota_rf
attr SonoffRF readingList tele/tasmota_C0D1C6/INFO.:.* { json2nameValue($EVENT) }\
  tele/tasmota_C0D1C6/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...([A-Za-z0-9]+)...RfKey...([^"]+)..., ? {"json_raw"=>$EVENT} : undef }\
  tele/tasmota_C0D1C6/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...([A-Za-z0-9]+)...RfKey...([^"]+)..., ? {"Data"=>"$4"} : undef }\
SonoffRF:tele/tasmota_C0D1C6/LWT:.* LWT\
SonoffRF:tele/tasmota_C0D1C6/STATE:.* { json2nameValue($EVENT) }\
SonoffRF:tele/tasmota_C0D1C6/RESULT:.* { json2nameValue($EVENT) }\
SonoffRF:stat/tasmota_C0D1C6/RESULT:.* { json2nameValue($EVENT) }\
SonoffRF:cmnd/tasmota_C0D1C6/POWER:.* POWER
attr SonoffRF room MQTT2_DEVICE
attr SonoffRF setList RfKey1:noArg cmnd/tasmota_C0D1C6/RfKey1 6\
RfKey2:noArg cmnd/tasmota_C0D1C6/RfKey2 6\
RfKey3:noArg cmnd/tasmota_C0D1C6/RfKey3 6\
RfKey4:noArg cmnd/tasmota_C0D1C6/RfKey4 6\
RfKey5:noArg cmnd/tasmota_C0D1C6/RfKey5 6\
RfKey6:noArg cmnd/tasmota_C0D1C6/RfKey6 6\
RfKey7:noArg cmnd/tasmota_C0D1C6/RfKey7 6\
RfKey8:noArg cmnd/tasmota_C0D1C6/RfKey8 6
attr SonoffRF stateFormat LWT\
<a href="http://IPAddress" target="_blank">IPAddress</a>



Viel Spass beim Basteln
VG
Achim

[Beta-User]

...vielleicht mache ich doch mal noch ein "Key1/2"-template dazu...?

Kannst du mal das hier testen?

Code Auswählen Erweitern

defmod SonoffRF_key MQTT2_DEVICE SonoffRF
attr SonoffRF_key devStateIcon Online:mqtt_bridge_2@#1de223 Offline:mqtt_bridge_2@red
attr SonoffRF_key icon mqtt_bridge_2
attr SonoffRF_key model tasmota_rf_keys_example
attr SonoffRF_key readingList tele/tasmota_C0D1C6/INFO.:.* { json2nameValue($EVENT) }\
  tele/tasmota_C0D1C6/LWT:.* LWT\
  tele/tasmota_C0D1C6/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/tasmota_C0D1C6/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/tasmota_C0D1C6/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  stat/tasmota_C0D1C6/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr SonoffRF_key setList on:noArg cmnd/tasmota_C0D1C6/RfKey1 6\
  off:noArg cmnd/tasmota_C0D1C6/RfKey2 6
attr SonoffRF_key stateFormat LWT\
<a href="http://IPAddress" target="_blank">IPAddress</a>\
state
attr SonoffRF_key setStateList on off
attr SonoffRF_key userReadings state:RfKey[12].* { ReadingsAge($name,"RfKey2",10000) > ReadingsAge($name,"RfKey1",10000) ? "on" : "off" }Was mir insgesamt dabei noch nicht klar ist: Wann welche Infos versendet werden, insbesondere, ob es einen "alleinigen update" der key-Readings gibt, und ob es ggf. dann Sinn macht, einige Readings via jsonMap auszublenden (daher hier vorsorglich schon die lange Form von json2nameValue()).

[Mihca]

Ja, das funktioniert . Bis auf die beiden "overnight" habe ich alle getestet. Das LWT und die IP-Adresse werden nicht angezeigt. Die entsprechenden Readings sind nicht da.

[Beta-User]

Thx, dann packe ich das bei Gelegenheit mal noch mit rein.

LWT usw. werden nur bei ausdrücklicher Anforderung bzw. einem reboot befüllt, das sollte kein Problem sein.

Worauf sich allerdings "overnight" bezieht, ist mir bis dato ein Rätsel...

[Mihca]

es gibt im Menü ein "set SonoffRF_key on-till-overnight" und "off-till-overnigt" die ich kurzfristig nicht testen kann

Stimmt, LWT und IP sind nach Neustart der Bridge da!