mqtt2.template für RFbridge von Sonoff entwickeln

Begonnen von Tueftler1983, 27 März 2019, 10:02:44

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: onkel-tobi am 09 Juni 2019, 09:43:11
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?
Doch, im Prinzip kannst due eine Kopie verwenden und einfach alles rauswerfen, was du nicht brauchst bzw. so ändern, dass es genau auf die eine "Endhardware" paßt (on/off-code usw.).
ZitatAußerdem hab ich dann noch ein paar Bewegungssensoren, die werden in der Bridge als auch schon als json raw angezeigt:

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?
Das sollte innerhalb einer Kopie (s.o.) pro Bewegungssensor gehen, ganz ohne externen Eventhandler oder dummy.
Dazu einfach die Regex entsprechend anpassen, die für das Extrahieren der Einzeldaten da ist. Aus
  /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 }
wird dann
  /Smarthome/Buero/DVES_9EFABC/tele/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...(<passender Code>)...RfKey...([^"]+)..., ? {"state"=>"open"} : undef }
usw. (ggf. können die anderen Suchmuster in den Klammern noch eingeschränkt werden)...
Und wieder alles andere rauswerfen, was nichts mit dem Sensor zu tun hat.
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

onkel-tobi

Hi Beta-User,

also das klappt soweit wunderbar. 2. Bridge genauso umgestellt.
Nun habe ich mich an die Mumbi's gemacht.

Auf der Konsole der Bridge bekomme ich:
/Smarthome/DG/DVES_B2AB43/tele/RESULT = {"RfReceived" {"Sync":10200,"Low":320,"High":820,"Data":"02270F","RfKey":"None"}}

Hier habe ich dann mal folgende setlist probiert:
on:noArg /Smarthome/DG/DVES_B2AB43/cmnd/RfSend {"Sync":"10200"Low":"320","High":"810","Data":"02270F"}
off:noArg /Smarthome/DG/DVES_B2AB43/cmnd/RfSend {"Sync":"10250"Low":"300","High":"840","Data":"02270E"}

Das klappt aber noch nicht, weil ich vermutlich noch was falsch mache, hast Du da evtl. noch einen Tipp?

Danke & Gruß,
Tobi

Beta-User

Hmm, sieht nach einem dicken Brett aus...

Also, nachdem ich hier (https://github.com/arendst/Sonoff-Tasmota/wiki/Sonoff-RF-Bridge-433) und hier (https://github.com/arendst/Sonoff-Tasmota/wiki/commands#sonoff-rf-bridge) mal nachgelesen habe:

Zum einen könnte es sein, dass es am einfachsten wäre, die Codes dann einfach als RfKey<x> anzulernen und dann via MQTT wieder abzurufen.

2. Option wäre, die binären RAW-Codes zu ermitteln

Die dritte Option könnte evtl. backlog sein (also mehrere Befehle in Folge zu versenden), da die einzelnen Elemente aus dem JSON nacheinander einzustellen zu sein scheinen (high,low und sync vor dem eigentlichen Data-Element). Da müßte ich aber auch raten und rumexperimentieren, wobei ich davon ausgehe, dass da dann kein JSON zu verwenden ist.

Also in die Richtung:
off:noArg /Smarthome/DG/DVES_B2AB43/cmnd/Backlog RfSync 10250; RfLow 300; RfHigh 840; RfCode #02270E

Ich hoffe, du kannst was damit anfangen :) , ist vermutlich ziemlich schwer zu verstehen.
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

onkel-tobi

Zitat von: Beta-User am 11 Juni 2019, 09:48:36
Also in die Richtung:
off:noArg /Smarthome/DG/DVES_B2AB43/cmnd/Backlog RfSync 10250; RfLow 300; RfHigh 840; RfCode #02270E

Ich hoffe, du kannst was damit anfangen :) , ist vermutlich ziemlich schwer zu verstehen.
Also mit einem bereits bestehenden device scheint das zu klappen. Werde ich am WE spätestens noch weiter testen, DANKE!

Womit ich noch nicht weiter gekommen bin ist der Bewegungsmelder, da scheine ich zu blöd für zu sein.
Habe folgendes device angelegt:

Internals:
   CFGFN      FHEM/schlafzimmer.cfg
   DEVICETOPIC dg_sz_mo1
   FUUID      5d0141ad-f33f-daf3-c035-a565d3b9ad485225
   IODev      m2c
   LASTInputDev m2c
   MSGCNT     62
   NAME       dg_sz_mo1
   NR         572
   STATE      ???
   TYPE       MQTT2_DEVICE
   m2c_MSGCNT 62
   m2c_TIME   2019-06-12 21:42:21
   READINGS:
Attributes:
   IODev      m2c
   alias      Bewegungsmelder DG
   event-on-change-reading .*
   model      A_01d_tasmota_rf
   readingList /Smarthome/DG/DVES_B2AB43/tele/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...("781826")...RfKey...([^"]+)..., ? {"state"=>"on"} : undef }
   room       motion,Schlafzimmer

Unter rL ist aber korrekt? Habe zwischenzeitlich state mal von open auf on geändert, aber auch das bringt nichts. Vermutlich weil ich es einfach noch nicht durchdrungen hab...

Gruß,
Tobi

Beta-User

Zitat von: onkel-tobi am 12 Juni 2019, 21:44:40
Unter rL ist aber korrekt?
Nope, die Anführungszeichen sind hier "das Problem".

Sowas sollte passen:
   readingList /Smarthome/DG/DVES_B2AB43/tele/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...(781826)...RfKey...([^"]+)..., ? {"state"=>"on"} : undef }
Zur Erläuterung: Das ist eigentlich eine regex ("=~") iVm. if (match) ... else .... Wie immer bei regexen steht dabei ein Punkt für genau ein Zeichen, hier also auch z.B. die Anführungszeichen (die wie alle Sonderzeichen gerne Probleme machen und hier daher mit dem Punkt ersetzt sind). Dabei sind hier noch sog. capture groups drin, die wir eigentlich nicht (mehr) brauchen (es war nur einfacher, das auf die Schnelle zu kopieren aus dem Ausgangscode; da ist dann vielleicht einfacher nachzuvollziehen, wo die einzelnen capture groups dann im Endeffekt landen ;) .
Das ganze könnte auch so vereinfacht werden:
   readingList /Smarthome/DG/DVES_B2AB43/tele/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..[A-Za-z0-9]+..Low..[\d]+..High..[\d]+..Data...781826...RfKey...[^"]+..., ? {"state"=>"on"} : undef }

Vielleicht schaust du dir bei Gelegenheit mal an, was dieses kryptische Zeug wie "[\d]+" und "[A-Za-z0-9]+" bedeutet, ist wirklich für FHEM insgesamt sehr hilfreich, wenn man das mal (halbwegs) verstanden hat. M.E. sind die Ausdrücke hier ganz gut erläutert: http://regex101.com/, ansonsten ist auch https://regexr.com/ ganz hilfreich.
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

onkel-tobi

So, nun mal wieder etwas Zeit die Themen abzuschließen.

@Beta-User: Nochmals vielen Dank für deine Ideen und Geduld.

Die Umstellung auf mqtt2 hat super geklappt, auch die Bewegungsmelder habe ich entsprechend einbinden können.
Meine neuen mumbi Dosen habe ich leider nicht einbinden können. Wie ich über die Logs herausgefunden habe handelt es sich da um rolling codes, insofern wird das wohl nichts.

Gruß & nochmals Danke,
Tobi

Beta-User

Zitat von: onkel-tobi am 14 Juli 2019, 12:23:37
Meine neuen mumbi Dosen habe ich leider nicht einbinden können. Wie ich über die Logs herausgefunden habe handelt es sich da um rolling codes, insofern wird das wohl nichts.
Vorab mal Danke für die Rückmeldung!

Vielleicht noch eine Anmerkung zu den mumbi-Dosen:
Kann es sein, dass das nur eine sehr begrenzte Zahl von "rollierenden" Codes ist (ich habe 4 im Hinterkopf)? Dann könnte man nämlich ggf. "einen workaround" finden (z.B. die 4 Codes in ein userAttr schieben und dann einfach immer den jeweils auf den aktuellen Code folgenden "rollierenden" wählen bzw. senden); irgendwo gab's dazu auch mal eine DOIF-Lösung, wenn ich das richtig im Kopf habe...
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

rudolfkoenig

Zitatz.B. die 4 Codes in ein userAttr schieben und dann einfach immer den jeweils auf den aktuellen Code folgenden "rollierenden" wählen bzw. senden
Fuer sowas kann man die Funktion Each verwenden:fhem> info log
fhem> defmod myAt at +*00:00:02 { Log 1, Each("myAt", "7,99,3,17") }
fhem>
2019.07.15 20:35:42 1 : 7
2019.07.15 20:35:44 1 : 99
2019.07.15 20:35:46 1 : 3
2019.07.15 20:35:48 1 : 17
2019.07.15 20:35:50 1 : 7
2019.07.15 20:35:52 1 : 99
2019.07.15 20:35:54 1 : 3
2019.07.15 20:35:56 1 : 17
...

Beta-User

...das ist cool, kannte ich (mal wieder) bisher noch nicht... ::)

Bin mal gespannt, ob wir damit eine Lösung für die mumbis hinbekommen (und es wirklich nur eine kleine Anzahl von code ist, die man sich merken muß).
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

device111

Hallo Onkel-Tobi,

kannst du das nochmal ein wenig erläutern, wie du das senden mit backlog gemacht hast?

Blicke da irgendwie gar nicht mehr durch...

Gruß,
Device

onkel-tobi

Hi,

also das mit dem rolling code habe ich noch nicht ausprobieren können.

Werde ich aber hoffentlich in ca. 2 Wochen kn meinem Urlaub nachholen.

Das mit dem backlog kannst du via console alles testen.

Gruß,
Tobi


Gesendet von iPad mit Tapatalk

denis.robel

Hallo,

ich versuche nun schon seit ner gefühlten Ewigkeit das Senden mit der RF bridge hinzubekommen.
Ich möchte ein paar Steckdosen schalten, die einen Rolling Code haben 4 verschieden für jeweils on und off.

Ich habe dazu 2 Fragen:

1. wie binde ich das Backlog Komanndo in die Bridge ein ?
2. wie kann man die Rolling Codes handhaben ?

Ich habe MQTT2 Server mit Tasmota Bridge am Start. Ein paar Bewegungsmelder kann ich über die Bridge empfangen und auswerten.
VG

Denis

Beta-User

Bist du sicher, dass du einen Rolling Code in Senderichtung brauchst?
Wir hatten neulich einen Fall, da war es ausreichend, einen der 4 Codes zu senden, das konnte immer derselbe sein, allerdings war es ein etwas anderes Device: https://forum.fhem.de/index.php/topic,103737.0.html

Wenn du damit nicht alleine klarkommst, bitte melden, ansonsten wäre es toll, wenn du das Ergebnis dann posten könntest, dann kann ich das auch mit "vertemplaten" (zur späteren Anpassung durch die Nutzer).
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

denis.robel

Hallo,

ich habe in meiner setList steht folgendes:

on:noArg cmnd/sonoffbr1/Backlog RfSync 7360; RfLow 530; RfHigh 1060; RfCode #93B3B0
off:noArg cmnd/sonoffbr1/Backlog RfSync 7370; RfLow 520; RfHigh 1070; RfCode #98A990


Bei der Bridge steht dann beim Stauswechsel onn / off  Log:

20:19:01 MQT: stat/sonoffbr1/RESULT = {"RfSync":7360}
20:19:01 MQT: stat/sonoffbr1/RESULT = {"RfLow":530}
20:19:01 MQT: stat/sonoffbr1/RESULT = {"RfHigh":1060}
20:19:01 MQT: stat/sonoffbr1/RESULT = {"RfCode":"#93B3B0"}
20:19:07 MQT: stat/sonoffbr1/RESULT = {"RfSync":7370}
20:19:07 MQT: stat/sonoffbr1/RESULT = {"RfLow":520}
20:19:08 MQT: stat/sonoffbr1/RESULT = {"RfHigh":1070}
20:19:08 MQT: stat/sonoffbr1/RESULT = {"RfCode":"#98A990"}


Leider schalten die Steckdosen nicht....
Gibts dazu noch nen Hinweis?
VG

Denis

Beta-User

Hmm, mir ist nicht ganz klar, wierum hier die Kommunikation läuft...

Anders gefragt: Du hast vermutlich eine Fernbedienung. Kannst du da mal ein paar mal schalten und mitschneiden, was dann MQTT-seitig von der Bridge gesendet wird? (Am besten bitte den kompletten JSON-Blob liefern).
Das was du gepostet hattest, bezog sich auf das, was passiert, wenn du FHEM-seitig zu schalten versuchst, oder?
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