mqtt2.template für RFbridge von Sonoff entwickeln

[Beta-User]

Erst mal sehr schön!

Vermutlich müssen wir die Elemente umsortieren, bzw. die beiden Fälle "RfKey"="None" und "RfKey"="irgendwas" auseinanderhalten. None sollte vorläufig mal ein Reading der bisherigen Benenung, dann aber nur mit $4 als Inhalt ergeben, "irgendwas" können wir vermutlich anders behandeln. Dazu müßte man aber wissen, was "irgendwas" alles sein kann...

(Ich meine mich erinnern zu können, dass man der Bridge bestimmte Codes "beibringen" kann. Ist dem so, können wir diese Codes mit einiger Sicherheit als "eben empfangen" filtern. Bitte auch um Info, was man da ggf. via MQTT publishen muß, um Tasten zu programmieren...)

[Tueftler1983]

Das.... Liefert gar keine Readings

Code Auswählen Erweitern

/SmartHome/Interface/Bridge/tele/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...([A-Za-z0-9]+)...RfKey...(None)..., ? {"$1_$2_$3"=>"$4_$5"} : json2nameValue($EVENT) }

Das hier

Code Auswählen Erweitern

/SmartHome/Interface/Bridge/tele/RESULT:.* {RfReceived=>encode_json(decode_json($EVENT)->{RfReceived})}
Bringt dieses Reading

Code Auswählen Erweitern

RfReceived
{"Sync":5120,"RfKey":"None","High":460,"Data":"775544","Low":150}

[Tueftler1983]

Zu den Keys sollte das weiter helfen
https://github.com/arendst/Sonoff-Tasmota/wiki/Sonoff-RF-Bridge-433

[Beta-User]

Also diese Definition

Code Auswählen Erweitern

/SmartHome/Interface/Bridge/tele/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...([A-Za-z0-9]+)...RfKey...([^"]+)..., ? {"$1_$2_$3"=>"$4_$5"} : json2nameValue($EVENT) }
Liefert das Reading wenn ein Signal empfangen wird

Code Auswählen Erweitern

5130_150_470
775544_None

RFkey ist, man kann in der Bridge 15 Keys anlernen. Also wie eine frei programmierbare Funkfernbedienung. Habe ich aber keine da ich mit der Bridge nur Signale Empfange aber keine Sende

Wir machen mit der "erfolgreichen Variante" weiter, oder? Ferndiagnostik im RF-Bereich wegen des Anlernens macht wenig Sinn, da muß dann ggf. noch jemand anderes weitermachen.

Wenn wir nur "None"-Codes haben, lassen wir das weg (für andere wäre das aber ggf. dann doch interessant...).
Also vorläufig nur noch:

Code Auswählen Erweitern

/SmartHome/Interface/Bridge/tele/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...([A-Za-z0-9]+)...RfKey...([^"]+)..., ? {"$1_$2_$3"=>$4} : json2nameValue($EVENT) }
Jetzt sollte eine Fernbedienung auf unterschiedlichen Tasten eigentlich unterschiedliche Readininhalte für EIN Reading liefern, eine andere Fernbedienung könnte dann ein anderes Reading bauen, wieder mit Änderung des Readinginhalts für verschiedene Tastendrücke.

Ist das so? (Wenn ja, ist der eigentliche Empfangsteil schon fertig, du hast schöne kurze, hoffentlich eindeutige Events an einer definierten Stelle, auf die du einen Event-Handler ansetzen kannst).

[Tueftler1983]

Da fand ich es am Anfang aber schon fast besser das immer wenn ein signal empfangen wurde sich nur die Readings für,

Code Auswählen Erweitern

RfReceived_Data
775151
2019-03-27 07:08:55
RfReceived_High
460
2019-03-27 07:08:55
RfReceived_Low
150
2019-03-27 07:08:55
RfReceived_RfKey
None
2019-03-27 07:08:55
RfReceived_Sync
5070
Geändert haben
Weißt du wie ich meine?

[Beta-User]

Da fand ich es am Anfang aber schon fast besser das immer wenn ein signal empfangen wurde sich nur die Readings für,
[...]
Weißt du wie ich meine?

Ich glaube schon zu verstehen, wie dir das vorkommt, das ist sicher auch eine Art Geschmacksfrage.

ABER: Eine bestimmte Taste erzeugt ein bestimmtes RF-Signal, das nur durch seine Kodierung _und_ die eigentliche Payload (Data) zusammen eindeutig ist. Also mußt du irgendwie bei der Reaktion auf eine bestimmte Taste auch alle diese Daten berücksichtigen. Das hinterher wieder zusammenzusuchen, ist m.E. nur die zweitbeste Lösung.

Wir können jetzt aber auch bequem hergehen, und z.B. in RfReceived dann statt des JSON "S$1H$2L$3_D_$4" "ausspucken" oder das sonst beliebig formatieren. Du darst da gerne kreativ sein, solltest dabei aber vor Augen haben, was du damit am Ende anstellen willst. Es soll ja eine Art "Input-Device" sein, also irgend ein anderes Gerät in FHEM beeinflussen.

EDIT: Und andere wollen das ggf. auch als Output-Gerät ("Signalduino") nutzen; die brauchen dann Sendecodes; auch da ist es einfacher, wenn die Elemente irgendwie zusammen abgebildet sind, im "schlimmsten" Fall als JSON.

[Tueftler1983]

Okay verstehe,
ich habe bisher in dem Tasmota_Device meine Doifs oder notifys auf das Reading "RfReceived_Data" getriggert dieses ist bei jeder Taste oder Fensterkontakt eindeutig. Die anderen Daten sind nicht immer gleichbleibend bei ein und dem selben signal.

[Beta-User]

Na ja, wenn das jetzt genau so via MQTT2_DEVICE wieder geliefert wird, brauchen wir da ja nicht zwanghaft was anders machen...

Für ein template würde ich das schon (zusaätzlich?) tun, einfach weil es eindeutiger ist, und da gehört m.E. auch die Sende-Seite mit rein.

Wer - wie du in diesem Fall - zur Vermeidung weiteren Aufwands die "Standardreadings" braucht, dem reicht dann ja der weitere (doppelte) Eintrag mit der json2valueName()-Anweisung.

Wie willst du weiter verfahren? Eine Umstellung auf nur noch MQTT2_DEVICE (auch mit anderer topic-Struktur) wäre jedenfalls wie gesehen in deiner Konstellation gar kein Problem, oder habe ich was übersehen?

[Tueftler1983]

Vielleicht geht eine Kombination,
sodass das Reading "RfReceived" ausgegeben wird so wie es jetzt im Screenshot ist. Und zusätzlich auch ein Readind mit dem Namen "Data" das dann den code enthält, denn auf diesen triggern ja dann die doifs oder notifys.
Erster Screenshot ist von jetzt der zweite wie es vorher in den Readings war.

[Tueftler1983]

Ich stelle komplett auf MQTT2 um werde dafür auch in der RFbride in den MQTT Einstellungen wieder auf standard Einstellungen zurück stellen so wie ich es auch  bei den Gosund gemacht habe.

[Beta-User]

Vielleicht geht eine Kombination,

Geht!
Willst du mehrer Readings haben, braucht jedes eine eigene Zeile, 2 oder 3 unterschiedliche Auswertungen sind damit kein Thema.

Da über RESULT aber nicht nur RF-Daten kommen, sollte irgendwo eine Anweisung stehen, dass diese anderen Daten "ganz normal" mit json2nameValue() auszupacken sind.

M.E. sollte daher immer eine Zeile etwas in der Art enthalten:

Code Auswählen Erweitern

/SmartHome/Interface/Bridge/tele/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...([A-Za-z0-9]+)...RfKey...([^"]+)..., ? {"$1_$2_$3"=>$4} : json2nameValue($EVENT) }Darin ist zum einen die Unterscheidung RfReceived-JSON oder nicht zum anderen werden die Datenelemente als $n verfügbar. Damit kannst du beliebig spielen. Wenn du also ein Reading namens "Data" brauchst, wird aus dem Teil

Code Auswählen Erweitern

{"$1_$2_$3"=>$4}einfach

Code Auswählen Erweitern

{"Data"=>$4}Das gewünschte Reading  "RfReceived" kommt entweder über die encode/decode-Anweisung, oder du baust das händisch zusammen mit $n; dann sollte halt hinter dem Doppelpunkt nichts stehen oder vielleicht auch "undef" (ohne Anführungszeichen).

Bei der Umstellung mußt du halt ggf. noch die Topicpfade in der readingList anfassen oder die Auswerte-Codes entsprechend auf ein neues Device übertragen. Da das ganze kein Hexenwerk ist und nicht viele Devices beteiligt sind: gleich den MQTT2_SERVER als IO nehmen?

[Tueftler1983]

Sorry ich komm teilweise nicht mit.
Ich bin "nur" Anwender und das über steigt meinen Horizont dann doch ein wenig.

Ich denke ich schaffe es jetzt meine Geräte einzubinden und die Readings zu erzeugen die ich für meine Anwendungen brauche.

Wo jetzt der unterschied liegt den Broker "Moskito" als device in FHEM zu lassen oder auf MQTT2_Server zu wechseln verstehe ich noch nicht so recht.

[Beta-User]

Wo habe ich dich verloren?

Bei Zusammenbauen der Readings? Dann einfach nochmal in Ruhe die Beiträge lesen und etwas rumprobieren.

Bei der Empfehlung, auf MQTT2_SERVER umzustellen?
Gründe:
- Der MQTT2_SERVER benötigt keine GeneralBridge, sondern "kennt" die einzelnen Datenquellen und bildet daraus direkt jeweils ein Device, ohne dass man irgendwas tun müßte. Erst, wenn diese selbst eine Art "IO-Funktionalität" haben, müßte man wieder eine bridgeRegexp nutzen, um daraus wieder logische Einzeldevices abzuleiten (wie z.B. bei zigbee2mqtt). Ergo ist es übersichtlicher, weil mind. ein Device entfällt (und ein darunterliegender Systemdienst).
- Man benötigt keine zusätzlichen Perl-Module; bei einem Umzug auf andere Hardware reicht es also, die cfg zu übertragen.
- Keine doppelte Datenhaltung: In FHEM brauchst du die Daten eh', da ist kein Unterschied zum CLIENT, aber der Broker entfällt.

Nachteil: der MQTT2_SERVER ist eben kein vollwertiger Server wie mosquitto. Das benötigt man in der Regel aber auch nicht. Erst bei größeren Installationen hat ein "echter Broker" ggf. Vorteile. Aber wegen 6-20 tasmota-Geräten?

[Tueftler1983]

Verloren das trifft es.

Denke ich bekomme jetzt die RFbridge ans laufen auch mit dem standard MQTT Einstellungen im Gerät.

Danach werde ich versuchen auf MQTT2_Server umzustellen.

[Beta-User]

Keine Sorge, Rom wurde auch nicht an einem Tag erbaut, und diese ganzen seltsamen Zeichen und Abkürzungen mußte ich mir auch erst mühsam erarbeiten.

Trotzdem die Anregung, den mosquitto erst mal zu deaktivieren und gleich den MQTT2_SERVER zu definieren (und den CLIENT zu löschen, kannst ja eine RAW-Definition wegspeichern, dann ist der schnell wieder "am Leben", wenn du ihn nochmal benötigen solltest).

Darfst mir glauben, dieses Vorgehen ist im Ergebnis schneller. Es _kann_ nur sein, dass deine jetzigen Geräte etwas durcheinanderkommen (daher ist es besser, das gleich zu machen, weil die "neuen" Geräte einschl. der RF-Bridge dann gleich "passen" undnicht mehr nachbearbeitet werden müssen).

Bin mal gespannt, ob du das am Ende genauso sehen wirst.

(Wenn alles klappt: nicht vergessen, den mosquitto entweder aus dem Linux-Systemstart zu nehmen oder zu deinstallieren!).