Hallo zusammen,
in diesem Thead soll ein template entwickelt werden um die Sonoff RFBridge gescheit unter MQTT2 anzubinden.
Beta-User und ich beginnen hier mal aber sind für Unterstützung offen und dankbar!
So in der Konsole von der RFbridge steht das....
19:35:26 MQT: /SmartHome/Interface/Bridge/tele/LWT = online (beibehalten)
19:35:26 MQT: /SmartHome/Interface/Bridge/cmnd/POWER =
19:35:26 MQT: /SmartHome/Interface/Bridge/tele/INFO1 = {"Module":"Sonoff Bridge","Version":"5.12.0","FallbackTopic":"RFbridge","GroupTopic":"sonoffs"}
19:35:26 MQT: /SmartHome/Interface/Bridge/tele/INFO2 = {"WebServerMode":"Admin","Hostname":"Sonoff","IPAddress":"192.168.2.50"}
19:35:26 MQT: /SmartHome/Interface/Bridge/tele/INFO3 = {"RestartReason":"Software/System restart"}
19:35:34 MQT: /SmartHome/Interface/Bridge/tele/STATE = {"Time":"2019.03.26 19:35:34","Uptime":"0 00:00:13","Vcc":3.471,"Wifi":{"AP":1,"SSId":"FRITZ!Box 6360 Cable Holger","RSSI":68,"APMac":"C8:0E:14:xx:xx:xx"}}
19:44:21 MQT: /SmartHome/Interface/Bridge/tele/RESULT = {"RfReceived":{"Sync":12460,"Low":440,"High":1250,"Data":"128489","RfKey":"None"}}
Dazu das im MQTT2_MQTT2CLIENT
MQTT2Client:/SmartHome/Interface/Bridge/tele/LWT:.* LWT
MQTT2Client:/SmartHome/Interface/tele/sonoff/LWT:.* LWT
MQTT2Client:/SmartHome/Interface/Garten/tele/LWT:.* LWT
MQTT2Client:/SmartHome/Interface/Spuelmaschine/tele/LWT:.* LWT
MQTT2Client:/SmartHome/Interface/Trockner/tele/LWT:.* LWT
MQTT2Client:/SmartHome/Interface/Spuelmaschine/tele/UPTIME:.* { json2nameValue($EVENT) }
MQTT2Client:/SmartHome/Interface/Garten/tele/UPTIME:.* { json2nameValue($EVENT) }
MQTT2Client:/SmartHome/Interface/Trockner/tele/UPTIME:.* { json2nameValue($EVENT) }
MQTT2Client:/SmartHome/Interface/Bridge/tele/UPTIME:.* { json2nameValue($EVENT) }
MQTT2Client:/SmartHome/Interface/Bridge/tele/STATE:.* { json2nameValue($EVENT) }
MQTT2Client:/SmartHome/Interface/Bridge/tele/RESULT:.* { json2nameValue($EVENT) }
Habe dann in der über autocreate angelegten RFbridge 2 Readings hinzugefügt (die zwei unteren Zeilen)
/SmartHome/Interface/Bridge/cmnd/POWER:.* POWER
/SmartHome/Interface/Bridge/tele/INFO1:.* { json2nameValue($EVENT) }
/SmartHome/Interface/Bridge/tele/INFO2:.* { json2nameValue($EVENT) }
/SmartHome/Interface/Bridge/tele/INFO3:.* { json2nameValue($EVENT) }
/SmartHome/Interface/Bridge/tele/RESULT:.* { json2nameValue($EVENT) }
/SmartHome/Interface/Bridge/tele/STATE:.* { json2nameValue($EVENT) }
So und noch die Raw Definition der RFbridge
defmod MQTT2_Bridge MQTT2_DEVICE Bridge
attr MQTT2_Bridge IODev MQTT2_Client
attr MQTT2_Bridge readingList /SmartHome/Interface/Bridge/cmnd/POWER:.* POWER\
/SmartHome/Interface/Bridge/tele/INFO1:.* { json2nameValue($EVENT) }\
/SmartHome/Interface/Bridge/tele/INFO2:.* { json2nameValue($EVENT) }\
/SmartHome/Interface/Bridge/tele/INFO3:.* { json2nameValue($EVENT) }\
/SmartHome/Interface/Bridge/tele/RESULT:.* { json2nameValue($EVENT) }\
/SmartHome/Interface/Bridge/tele/STATE:.* { json2nameValue($EVENT) }
attr MQTT2_Bridge room MQTT2_DEVICE
setstate MQTT2_Bridge 2019-03-26 19:35:27 FallbackTopic RFbridge
setstate MQTT2_Bridge 2019-03-26 19:35:27 GroupTopic sonoffs
setstate MQTT2_Bridge 2019-03-26 19:35:27 Hostname Sonoff
setstate MQTT2_Bridge 2019-03-26 19:35:27 IPAddress 192.168.2.50
setstate MQTT2_Bridge 2019-03-26 19:35:27 Module Sonoff Bridge
setstate MQTT2_Bridge 2019-03-26 19:35:27 POWER
setstate MQTT2_Bridge 2019-03-26 19:35:27 RestartReason Software/System restart
setstate MQTT2_Bridge 2019-03-27 10:11:18 RfReceived_Data 100401
setstate MQTT2_Bridge 2019-03-27 10:11:18 RfReceived_High 900
setstate MQTT2_Bridge 2019-03-27 10:11:18 RfReceived_Low 350
setstate MQTT2_Bridge 2019-03-27 10:11:18 RfReceived_RfKey None
setstate MQTT2_Bridge 2019-03-27 10:11:18 RfReceived_Sync 10590
setstate MQTT2_Bridge 2019-03-27 08:55:34 Time 2019.03.27 08:55:33
setstate MQTT2_Bridge 2019-03-27 08:55:34 Uptime 0 13:20:13
setstate MQTT2_Bridge 2019-03-27 08:55:34 Vcc 3.471
setstate MQTT2_Bridge 2019-03-26 19:35:27 Version 5.12.0
setstate MQTT2_Bridge 2019-03-26 19:35:27 WebServerMode Admin
setstate MQTT2_Bridge 2019-03-27 08:55:34 Wifi_AP 1
setstate MQTT2_Bridge 2019-03-27 08:55:34 Wifi_APMac C8:0E:14:55:25:98
setstate MQTT2_Bridge 2019-03-27 08:55:34 Wifi_RSSI 66
setstate MQTT2_Bridge 2019-03-27 08:55:34 Wifi_SSId FRITZ!Box 6360 Cable Holger
setstate MQTT2_Bridge 2019-03-26 19:35:27 associatedWith MQTT2_GeneralBridge
In den Readings sind die für mich wichtigen Daten enthalten, das ist das RfReceived_Data das ist das empfangene Funksignal über das ich Events auslösen kann. Ich weiß nicht welche Daten noch benötigt werden.
So, also ausgehend von der Info ist das Ergebnis in etwa so:19:44:21 MQT: /SmartHome/Interface/Bridge/tele/RESULT = {"RfReceived":{"Sync":12460,"Low":440,"High":1250,"Data":"128489","RfKey":"None"}}Aus dem template zur tasmota-IR (A_01d_tasmota_ir) wissen wir, dass bei Ir folgendes funktioniert:
tele/DEVNAME/RESULT:.* { $EVENT =~ m,..IrReceived....Protocol...([A-Za-z0-9]+)...Bits..([\d]+)..Data...([A-Za-z0-9]+)..., ? {"$1_$2"=>$3} : json2nameValue($EVENT) }
Das bildet für jede Protokoll-Bit-Kombination jeweils ein neues Reading und schreibt die Data-Information da rein.
Daraus leite ich mal folgenden Test für die readingList ab:
/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) }
Kannst du das mal testen und ggf. verbessern? Die Herleitung ist hoffentlich einigermaßen nachvollziehbar...
Also das läst sich so nicht in der readingList speichern, gibt einen Syntax error.
syntax error at (eval 535909) line 1, near "$4_"
syntax error at (eval 535909) line 1, near "}}"
Dann mach mal Anführungszeichen drumrum:"$4_$5"
Diese Readings werden ja schon gebildet:
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
Durch diese Zeile in der readingList
/SmartHome/Interface/Bridge/tele/RESULT:.* { json2nameValue($EVENT) }
Gut das hat er geschluckt, neue Readings werden aber keine angelegt beim Empfang eines Signales
Zitat von: Beta-User am 27 März 2019, 10:42:12
Dann mach mal Anführungszeichen drumrum:"$4_$5"
Neuer Versuch; ich würde auf den "None"-Teil der regex als Problem tippen, das kann aber auch was anderes sein...
/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) }
Zitat von: Tueftler1983 am 27 März 2019, 10:42:57
Durch diese Zeile in der readingList
/SmartHome/Interface/Bridge/tele/RESULT:.* { json2nameValue($EVENT) }
Ändere das mal bitte:
/SmartHome/Interface/Bridge/tele/RESULT:.* {RfReceived=>encode_json(decode_json($EVENT)->{RfReceived})}Damit sollten wir erkennen, was bei der anderen verabeitungsmäßig durchläuft (die andere macht Einzelreadings, wenn die regexp nicht paßt), diese hier sollte "den inneren JSON" in ein neues Readings schreiben.
Also das bringt noch nen Syntax fehler
/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"}}
Was meinst du jetzt?
Soll ich die zeile löschen
/SmartHome/Interface/Bridge/tele/RESULT:.* { json2nameValue($EVENT) }
Und durch diese ersetzen?
/SmartHome/Interface/Bridge/tele/RESULT:.* {RfReceived=>encode_json(decode_json($EVENT)->{RfReceived})}
Das mit dem Syntaxfehler muß ich mir in Ruhe ansehen (der ":" und die nachfolgende Funktion fehlen mit Absicht?).
Dann verwende für die "RESULT"-Zeile nur noch einen Eintrag.
Wenn das hier geht, dann das:
/SmartHome/Interface/Bridge/tele/RESULT:.* { $EVENT =~ m,..RfReceived.*, ? {RfReceived=>encode_json(decode_json($EVENT)->{RfReceived})} : json2nameValue($EVENT) }
Sonst:/SmartHome/Interface/Bridge/tele/RESULT:.* {RfReceived=>encode_json(decode_json($EVENT)->{RfReceived})}
Also der code läuft und erzeugt für jeden empfangenen code ein eigenes Reading
/SmartHome/Interface/Bridge/tele/RESULT:.* { $EVENT =~ m,..RfReceived.*, ? {RfReceived=>encode_json(decode_json($EVENT)->{RfReceived})} : json2nameValue($EVENT) }
Habe mal Screenshot von den Readings und der readingList gemacht
Hmm, da paßt irgendwas nicht zusammen...
Die Readingnamen mit "Zahl1_Zahl2_Zahl3" und die Readings selbst passen zu dem Code, den ich bis 11:00 Uhr gepostet hatte, vermutlich noch ohne den "None"-Text, aber mit Anführungszeichen.
Jedenfalls paßt es nicht zu dem aktuellen. Der müßte ein Reading mit Namen RfReceived bilden und da einen JSON reinschreiben.
Bitte nochmal alle Readings löschen, und dann die Schritte ab Einführung der Anführungszeichen nochmal durchgehen (nur ein Eintrag für RESULT), dabei das Browserfenster nach dem Senden des RF-Codes aktualisieren. Bitte bei dem Schritt anhalten, der Readings in obigem Format liefert, wenn es sowas gibt...
Dann: RfKey scheint für was "bekanntes" zu stehen, wenn er nicht None ist. Kannst du so eine mal drücken und den MQTT-Verkehr dazu (eigentlich: den JSON) zeigen?
Also diese Definition
/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
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
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...)
Das.... Liefert gar keine Readings
/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
/SmartHome/Interface/Bridge/tele/RESULT:.* {RfReceived=>encode_json(decode_json($EVENT)->{RfReceived})}
Bringt dieses Reading
RfReceived
{"Sync":5120,"RfKey":"None","High":460,"Data":"775544","Low":150}
Zu den Keys sollte das weiter helfen
https://github.com/arendst/Sonoff-Tasmota/wiki/Sonoff-RF-Bridge-433
Zitat von: Tueftler1983 am 27 März 2019, 13:09:56
Also diese Definition
/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
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:
/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).
Da fand ich es am Anfang aber schon fast besser das immer wenn ein signal empfangen wurde sich nur die Readings für,
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?
Zitat von: Tueftler1983 am 27 März 2019, 13:50:33
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.
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.
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?
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.
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.
Zitat von: Tueftler1983 am 27 März 2019, 14:33:25
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:
/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
{"$1_$2_$3"=>$4}einfach
{"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?
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.
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?
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.
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!).
So alle Geräte laufen jetzt mit den default Einstellungen in MQTT als nächstes werde ich mich an den MQTT2_Server.
Ist richtig wenn ich den MQTT2_Server nutze muss ich den
Moskito Server vom raspberry deaktivieren/deinstallieren,
das MQTT device Moskito löschen in FHEM,
den MQTT2_CLIENT in FHEM löschen und MQTT2_generalBridge löschen oder?
Zitat von: Tueftler1983 am 27 März 2019, 17:23:41
Ist richtig wenn ich den MQTT2_Server nutze muss ich den
Moskito Server vom raspberry deaktivieren/deinstallieren,
das MQTT device Moskito löschen in FHEM,
den MQTT2_CLIENT in FHEM löschen und MQTT2_generalBridge löschen oder?
"müssen" ist nur das Freimachen des Ports 1883 (wenn du an den externen Geräten nichts ändern willst). Aber ansonsten ist es ok, wenn du alle Schritte wie von dir aufgeschrieben durchführst (dann brauche ich auch nicht lange zu erklären, wie es teilweise auch anders noch ginge...)
So,
also habe jetzt umgestellt auf MQQT2_FHEM_SERVER, es hat alles geklappt habe das autocreate aber auf no geschaltet da er mir meine Geräte nochmal angelegt hatte.
Mosquitto ist deinstalliert und alle nicht mehr benötigten module sind gelöscht.
An dieser stelle nochmal Herzlichen dank für die Unterstützung!!
Danke für die Rückmeldung, freut mich, wenn das trotz der anfänglichen Skepsis jetzt doch einigermaßen reibungslos gegangen ist :) .
Empfehlung noch: Geräte werden nur dann per autocreate "nochmal" angelegt, wenn sowohl
- das topic "noch keinen Abnehmer hat" als auch
- kein Device mit passender CID vorhanden ist (wenn vorhanden, wird dessen readingList ergänzt).
Du hattest vermutlich letzteres Problem. Das läßt sich vermeiden, wenn man in der Konfiguration der tasmotas gleich das "DEVS_%06X" (?) als topic angibt, solange der CLIENT iVm. der GeneralBridge aktiv ist. Später dann, indem man die CID aller MQTT2_DEVICEs prüft und erforderlichenfalls händisch ändert (was ich jetzt ggf. nachzuholen empfehlen würde).
Bitte melden, wenn das zu sehr Kauderwelsch ist :) .
Habe halt vom Namen her gerne alles verständlich, kann ich dann bei Client im Gerät unter den MQTT Einstellungen auch Waschmaschine schreiben um es eindeutig zu machen oder ist es da besser das default zu lassen?
Default: DVES_849E9D
Ich würde da jetzt: Waschmaschine
rein schreiben
Du hast im Prinzip alle Freiheit, das zu machen, wie du magst. Ich neige dazu, das nur "am Ende" (in FHEM) umzubenennen (rename oder alias), weil ich lieber "die Hardware sehe" (hier also die Chip-ID); das ist aber an der Stelle nur ein Baugefühl, das mich da leitet :) .
Um den tasmota (also dessen web-if) aufzurufen, haben wir jüngst auch einen Vorschlag gepostet, wie man aus dem LWT-Statement einen klickbaren Link dahin macht (siehe das tasmota-shutter-template).
Ich habe mal im Hinblick auf usere Erkenntnisse im Wiki ein paar Änderungen in den Praxisbeispielen und dem MQTT2_CLIENT-Artikel vorgenommen. Vielleicht magst du mir Rückmeldung geben, ob das für dich verständlich ist (bei Verbesserungsbedarf gerne auch im Wiki-Bereich, es gibt glaube ich zu beidem einen Artikel).
Hallo, und sorry für die späte Rückmeldung.
Also ich finde das Wiki jetzt verständlicher, vielleicht kommt das aber auch durch das eigene testen und einrichten. Im Prinzip finde ich es mit dem FHEM MQTT2_Server einfacher als über den extra system Dienst MQTT Mosquitto.
Auf jeden Fall nochmal danke für den super support
Danke für die Rückmeldung, besser spät als nie :) .
Auch nach meiner Einschätzung ist es mit dem MQTT2_SERVER einfacher, da der den Ursprung der Daten kennt. Dazu hat man bei kleinen Installationen keine weiteren Abhängigkeiten, auch wenn mosquitto an sich keine schwierige Komponente ist.
Jetzt wäre es noch nett, wenn du ein list -r liefern könntest von deinen jetzigen Einstellungen, dann kann ich das ggf. "vertemplaten" wie im Thread-Titel angekündigt? Dann wäre es auch in meinen Augen [gelöst]. (Testen - mit einer copy sollte das gefahrlos gehen - wäre dann noch nett.)
Hey ho,
reicht das? Oder das komplette list -r auch mit den empfangenen Daten?
define BridgeSonoff MQTT2_DEVICE Bridge
attr BridgeSonoff IODev MQTT2_FHEM_Server
attr BridgeSonoff readingList cmnd/Bridge/POWER:.* POWER\
tele/Bridge/INFO1:.* { json2nameValue($EVENT) }\
tele/Bridge/INFO2:.* { json2nameValue($EVENT) }\
tele/Bridge/INFO3:.* { json2nameValue($EVENT) }\
tele/Bridge/STATE:.* { json2nameValue($EVENT) }\
tele/Bridge/INFO:.* { json2nameValue($EVENT) }\
tele/Bridge/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...([A-Za-z0-9]+)...RfKey...([^"]+)..., ? {"Data"=>$4} : json2nameValue($EVENT) }\
tele/Bridge/LWT:.* LWT\
tele/Bridge/UPTIME:.* { json2nameValue($EVENT) }
attr BridgeSonoff room MQTT2_DEVICE
Sollte reichen...
Hat das Ding ein Relais? Der cmnd-Teil in der readingList klang danach. Achtung: das macht "Kleinschreibung" für on/off.
name:A_01d_tasmota_rf
desc:Demonstrates an option how to configure tasmota devices as RF remote control extension.<br><a href="https://forum.fhem.de/index.php/topic,99042.msg927000.html#msg927000">Forum Thread</a><br>NOTE: Sending commands is missing, you may contribute...
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*(tele|cmnd).*
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
set DEVICE attrTemplate A_01a_tasmota_basic_state_power1
attr DEVICE setList \
off:noArg cmnd/DEVNAME/POWER1 0\
on:noArg cmnd/DEVNAME/POWER1 1\
attr DEVICE readingList \
tele/DEVNAME/INFO.:.* { json2nameValue($EVENT) }\
tele/DEVNAME/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...([A-Za-z0-9]+)...RfKey...([^"]+)..., ? {"Data"=>$4} : json2nameValue($EVENT) }\
tele/DEVNAME/LWT:.* LWT\
tele/DEVNAME/UPTIME:.* { json2nameValue($EVENT) }
attr DEVICE stateFormat Data\
<br>\
<a href="http://IPAddress" target="_blank">IPAddress</a>
attr DEVICE event-on-change-reading .*
attr DEVICE model A_01d_tasmota_rf
Nein ein Relais hat die RFbridge nicht
OK, dann sollte es das hier tun:name:A_01d_tasmota_rf
desc:Demonstrates an option how to configure tasmota devices as RF remote control extension.<br><a href="https://forum.fhem.de/index.php/topic,99042.msg927000.html#msg927000">Forum Thread</a><br>NOTE: Sending commands is missing, you may contribute...
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*(tele|cmnd).*
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
attr DEVICE devStateIcon Online:10px-kreis-gruen Offline:10px-kreis-rot
attr DEVICE readingList \
tele/DEVNAME/INFO.:.* { json2nameValue($EVENT) }\
tele/DEVNAME/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...([A-Za-z0-9]+)...RfKey...([^"]+)..., ? {"Data"=>$4} : json2nameValue($EVENT) }\
tele/DEVNAME/LWT:.* LWT\
tele/DEVNAME/UPTIME:.* { json2nameValue($EVENT) }
attr DEVICE stateFormat <a href="http://IPAddress" target="_blank">\
LWT\
</a><br>\
Data
attr DEVICE event-on-change-reading .*
attr DEVICE model A_01d_tasmota_rf
Kann nur grade bei mir nix testen da mein USBstick sich verabschiedet hat auf dem alles an logs, die FHEM.cfg die.Städte
Halt alles was gespeichert wird.
Lesen geht aber schreiben nicht. Warte auf meine msata SSD. Hoffe das dann meine Probleme gelöst sind
Laß dir Zeit; ggf. findet sich ja auch jemand anderes, der grade sowas rumliegen hat...?
Hallo Leute,
da ich neuling bin und mich seit einigen tagen mit mqtt2 und der rf bridge rum schlage, habe ich eine frage.
wie bekomm ich denn aus fhem eine rfcode rausgesendet?
vor der umstellung auf mqtt2 ging alles wunderbar über das tut ( https://haus-automatisierung.com/hardware/fhem/2018/03/22/fhem-tutorial-reihe-part-56-sonoff-rf-bridge.html (https://haus-automatisierung.com/hardware/fhem/2018/03/22/fhem-tutorial-reihe-part-56-sonoff-rf-bridge.html) )
die bridge ist in fhem eingebunden und ich bekomme auch die ganzen readings.
Hier der Auszug aus der raw:
Zitatdefmod BridgeSonoff MQTT2_DEVICE RF_Bridge
attr BridgeSonoff IODev Mosquitto
attr BridgeSonoff group Sonoff_Logik
attr BridgeSonoff icon mqtt
attr BridgeSonoff readingList tele/RF_Bridge/LWT:.* LWT\
cmnd/RF_Bridge/POWER:.* POWER\
cmnd/RF_Bridge/Backlog:.* Backlog\
tele/RF_Bridge/INFO1:.* { json2nameValue($EVENT) }\
tele/RF_Bridge/INFO2:.* { json2nameValue($EVENT) }\
tele/RF_Bridge/INFO3:.* { json2nameValue($EVENT) }\
tele/RF_Bridge/STATE:.* { json2nameValue($EVENT) }\
tele/RF_Bridge/UPTIME:.* { json2nameValue($EVENT) }\
tele/RF_Bridge/RESULT:.* { json2nameValue($EVENT) }\
attr BridgeSonoff room 90_Interface
attr BridgeSonoff stateFormat RfReceived_Data
setstate BridgeSonoff FFD154
setstate BridgeSonoff 2019-04-29 20:59:09 FallbackTopic cmnd/RF_Bridge_fb/
setstate BridgeSonoff 2019-04-29 20:59:09 GroupTopic sonoffs
setstate BridgeSonoff 2019-04-29 20:59:09 Hostname RF_Bridge-7543
setstate BridgeSonoff 2019-04-29 20:59:09 IPAddress 192.168.1.108
setstate BridgeSonoff 2019-05-03 09:17:27 LWT Online
setstate BridgeSonoff 2019-05-03 18:49:11 LoadAvg 19
setstate BridgeSonoff 2019-04-29 20:59:09 Module Sonoff Bridge
setstate BridgeSonoff 2019-04-29 20:59:09 POWER
setstate BridgeSonoff 2019-04-29 20:59:09 RestartReason Software/System restart
setstate BridgeSonoff 2019-05-03 18:34:56 RfReceived_Data FFD154
setstate BridgeSonoff 2019-05-03 18:34:56 RfReceived_High 530
setstate BridgeSonoff 2019-05-03 18:34:56 RfReceived_Low 210
setstate BridgeSonoff 2019-05-03 18:34:56 RfReceived_RfKey None
setstate BridgeSonoff 2019-05-03 18:34:56 RfReceived_Sync 5910
setstate BridgeSonoff 2019-05-03 18:49:11 Sleep 50
setstate BridgeSonoff 2019-05-03 18:49:11 SleepMode Dynamic
setstate BridgeSonoff 2019-05-03 18:49:11 Time 2019-05-03T17:49:11
setstate BridgeSonoff 2019-05-03 18:49:11 Uptime 3T21:50:09
setstate BridgeSonoff 2019-05-03 18:49:11 Vcc 3.458
setstate BridgeSonoff 2019-04-29 20:59:09 Version 6.4.1(sonoff)
setstate BridgeSonoff 2019-04-29 20:59:09 WebServerMode Admin
setstate BridgeSonoff 2019-05-03 18:49:11 Wifi_AP 1
setstate BridgeSonoff 2019-05-03 18:49:11 Wifi_BSSId 04:92:26:55:EE:60
setstate BridgeSonoff 2019-05-03 18:49:11 Wifi_Channel 10
setstate BridgeSonoff 2019-05-03 18:49:11 Wifi_RSSI 72
setstate BridgeSonoff 2019-05-03 18:49:11 Wifi_SSId IDO 2,4Ghz
setstate BridgeSonoff 2019-04-30 05:44:29 associatedWith MQTT2_GeneralBridge
schon mal vielen dank für eure hilfe
Hallo und willkommen im Forum!
Das Senden sollte auch gehen, vielleicht schaust du dir mal das IR-Template an, das macht das ganz ähnlich, wie es hier erforderlich sein dürfte.
(Am einfachsten dein device kopieren und mal das ir-template darauf anwenden; dann schauen, was der tasmota eigentlich auf welchem Topic konkret braucht (ein JSON-blob?)).
Bitte ggf. mal den Blob hier einstellen, eben alles, was du dazu weißt/woanders findest...
Hi,
also ich würde das Template auch mal ausprobieren.
Aktuell habe ich folgendes device:
Internals:
CFGFN
CID MQTT2
DEF MQTT2
DEVICETOPIC MQTT2_MQTT2
FUUID 5cd08ff0-f33f-daf3-60ed-2c7ead9a71c728ae
IODev MQTT2
NAME MQTT2_MQTT2
NR 1060
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2019-05-06 21:50:09 LWT online
Attributes:
IODev MQTT2
readingList MQTT2:/Smarthome/Buero/sonoffrf/tele/LWT:.* LWT
MQTT2:/Smarthome/DG/sonoffrf/tele/LWT:.* LWT
room MQTT2_DEVICE
Habe 2 bridges mit den unter readinglist genannten topics.
Nachdem ich das Template eingebunden habe, muss ich dann nun das device mqtt2_mqtt2 auf attrTemplate A_01d_tasmota_rf setzen, oder?
Sofern dem so ist, bekomme ich da beim 1. mal:
Unknown command MQTT2:/Backlog, try help.
Unknown command MQTT2:/POWER1, try help.
Unknown command MQTT2:/POWER1, try help.
Unknown command MQTT2:/POWER1, try help.
Unknown command MQTT2:/LWT:.*, try help.
Unknown command MQTT2:/STATE:.*, try help.
Unknown command MQTT2:/SENSOR:.*, try help.
Unknown command MQTT2:/INFO.:.*, try help.
Unknown command MQTT2:/RESULT:.*, try help.
Unknown command MQTT2:/POWER1, try help.
Unknown command MQTT2:/POWER1, try help.
Unknown command MQTT2:/INFO.:.*, try help.
Unknown command MQTT2:/RESULT:.*, try help.
Unknown command MQTT2:/LWT:.*, try help.
Unknown command MQTT2:/UPTIME:.*, try help.
Gruß,
Tobi
Moin onkel-tobi,
ist das richtig, dass du 2x diese Hardware hast? Kannst du dann bitte mal den einen einfach auch die Seite packen und vorläufig nicht mehr anpacken? (so, wie er ist!) Ich würde gerne ein paar grundlegende Änderungen an dem template-file machen, so dass diese (besch...) Änderungen der Topic-Struktur, die in diesen ... Videos vorgenomen werden, zukünftig keine Probleme mehr machen, und bräuchte dazu aber einen Tester....
Ansonsten:
Bitte lies den Artikel https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele, dort insbesondere #Allgemeine_Einstellungen_und_Hinweise und #Tasmota und überfliege wg. des Topic-Themas usw. evtl. zur Vertiefung noch https://forum.fhem.de/index.php/topic,99688.0.html.
Bitte stelle aber erst mal nicht die Topic-Struktur um, sondern ändere lediglich die Angaben zu "client" und "topic" (Felder 3 und 6 hier (https://forum.fhem.de/index.php?action=dlattach;topic=99042.0;attach=118135;image)), m.E. sollte man da grundsätzlich "DVES_%06X" verwenden.
Ich versuche dir dann ein template-file zu generieren, das du dann einbinden können solltest wie hier (https://forum.fhem.de/index.php/topic,94495.msg872201.html#msg872201) unter "Testen" beschrieben (file muß die üblichen Rechte haben.
Anbei eine Testfile.
Bitte mit den richtigen Rechten nach /opt/fhem/FHEM/lib/AttrTemplate/ packen, dann {AttrTemplate_Initialize()} über die Kommandozeile ausführen und das template A_01d_tasmota_rf ausführen.
Hi Beta-User,
vielen Dank schon mal!
Zitat von: Beta-User am 07 Mai 2019, 09:01:36
ist das richtig, dass du 2x diese Hardware hast? Kannst du dann bitte mal den einen einfach auch die Seite packen und vorläufig nicht mehr anpacken? (so, wie er ist!) Ich würde gerne ein paar grundlegende Änderungen an dem template-file machen, so dass diese (besch...) Änderungen der Topic-Struktur, die in diesen ... Videos vorgenomen werden, zukünftig keine Probleme mehr machen, und bräuchte dazu aber einen Tester....
Das ist soweit richtig. habe 2 sonoff bridges, die via mosquitto an fhem angebunden sind.
Soll / muss ich die Anbindung dann auch zurückbauen für den Test?
An dein Template mache ich mich jetzt mal nebenbei.
Update: client hatte ich bereits so im default stehen. Bei topic habe ich sonoffrf. Verbindungsdetails lasse ich wie sie waren? (sprich die gehen via mqtt an den mosquitto und von da aus per mqtt2_client an fhem, sofern ich das richtig verstehe?).
Update 2: Habe nun alles eingespielt. Habe aber scheinbar Probleme mit den templates.
Im default ist ja die Datei mqtt2.template vorhanden. Wenn die nicht mehr vorhanden ist, kriege ich keine Auswahl. Ist sie vorhanden, ist das Template template A_01d_tasmota_rf nicht vorhanden?!
Gruß,
Tobi
Moin Tobi,
du kannst die zusätzliche Datei wieder rauswerfen und dann bitte ein update machen - ich habe den RF mal in der vorläufigen Fassung in das allg. templatefile aufgenommen.
Was das setup angeht, kannst du das so lassen. Das wird jetzt zwar vielleicht einige überraschen, aber ich würde das gerne zeigen, dass man "sowas" - zwar mit etwas mehr Aufwand - auch mit mosquitto+MQTT2_CLIENT hinbekommt, und zwar mit den "verbogenen" Topic-Strukturen aus diesen unseligen Videos :P .
Bitte aber vorab prüfen, ob in den settings der tasmota-Geräte unterschiedliche "topic"-Angaben drinstehen, das scheint im Moment dieselbe (undynamische) Angabe zu sein (ich würde eine dynamische Vergabe empfehlen, siehe hier: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Tasmota). Ändere das aber bitte erst mal noch nicht!
Nach dem was du schreibst, gehe ich davon aus, dass du im Moment genau ein MQTT2-Device hast?
Dann mach bitte folgendes:
1. Erstelle davon eine Kopie (copy MQTT2_MQTT2 MQTT2_RF1)
2. Auf MQTT2_MQTT2 wendest du das template "A_00_MQTT2_CLIENT_general_bridge" an.
Dann solltest du drei MQTT2-DEVICE-Geräte haben: MQTT2, MQTT2_MQTT2 und MQTT2_RF1.3. Passe die bridge-Regexp des Geräts MQTT2 an, RAW-Code:
attr MQTT2 bridgeRegexp \
/Smarthome/[/]([^/]+)[/]([^/]+)[/](tele|cmnd|stat)[/].*:.* "$2"\
shellies[/]([^/]+)[/].*:.* "$1"\
(ESPClient_[^/]+)[/].*:.* "$1"
4. Jetzt änderst du die topic-Angabe einer der rf-tasmotas (Feld 6 in dem Web-interface); ggf. den tasmota neu starten.
Bei aktiviertem Autocreate solltest du jetzt ein weiteres MQTT2-Device bekommen mit Angaben aus der Änderung in Schritt 4. Auf dieses wendest du dann bitte das rf-template an.
Wenn das bis dahin geklappt hat, sehen wir weiter, wenn es Probleme gibt, bitte melden...
Danke, dass sieht erst mal glaube ich gut aus:
Internals:
CFGFN
CID MQTT2
DEF MQTT2
DEVICETOPIC MQTT2_RF1
FUUID 5cd2d6a3-f33f-daf3-1a42-3a5ad42fe7274b6e
IODev MQTT2
LASTInputDev MQTT2
MQTT2_MSGCNT 55
MQTT2_TIME 2019-05-08 16:18:01
MSGCNT 55
NAME MQTT2_RF1
NR 11488
STATE state
<br>
<a href="http://192.168.x.x" target="_blank">192.168.x.x</a>
TYPE MQTT2_DEVICE
READINGS:
2019-05-08 15:39:54 FallbackTopic DVES_9EFABC
2019-05-08 15:39:54 GroupTopic sonoffs
2019-05-08 15:39:54 Hostname Sonoff-Bridge
2019-05-08 15:39:54 IPAddress 192.168.x.x
2019-05-08 15:39:54 LWT Online
2019-05-08 15:39:54 Module Sonoff Bridge
2019-05-08 15:39:54 POWER
2019-05-08 15:39:54 RestartReason Software/System restart
2019-05-08 15:32:11 RfCode #005451
2019-05-08 16:11:16 RfReceived_Data 412426
2019-05-08 16:11:16 RfReceived_High 1180
2019-05-08 16:11:16 RfReceived_Low 410
2019-05-08 16:11:16 RfReceived_RfKey None
2019-05-08 16:11:16 RfReceived_Sync 12290
2019-05-08 16:18:01 Time 2019-05-08T15:18:01
2019-05-08 16:18:01 Uptime 3T05:00:12
2019-05-08 16:18:01 Vcc 3.142
2019-05-08 15:39:54 Version 6.1.1
2019-05-08 15:39:54 WebServerMode Admin
2019-05-08 16:18:01 Wifi_AP 1
2019-05-08 16:18:01 Wifi_APMac 0E:EC:DA:1A:9C:57
2019-05-08 16:18:01 Wifi_RSSI 68
2019-05-08 16:18:01 Wifi_SSId HA
Attributes:
IODev MQTT2
autocreate 1
event-on-change-reading .*
model A_01d_tasmota_rf
room MQTT2_DEVICE
setList power:noArg /Smarthome/Buero/sonoffrf/cmnd/RFsend POWERCMD
volumeup:noArg /Smarthome/Buero/sonoffrf/cmnd/RFsend VOLUMEUPCMD
rfsend:textField /Smarthome/Buero/sonoffrf/cmnd/RFsend {"Protocol":"$EVTPART1","Bits":$EVTPART2,"Data":"0x$EVTPART3"}
stateFormat state
<br>
<a href="http://IPAddress" target="_blank">IPAddress</a>
Allerdings habe ich mit den devices nciht ganz dein vermutetes Verhalten?
mqtt2 ist nämlich mein mqtt_client und dem kann ich ja kein Template zuweisen.
mqtt2_mqtt2, dass vermutlich jetzt "verhuddelt" ist:
Internals:
CID MQTT2
DEF MQTT2
DEVICETOPIC MQTT2_MQTT2
FUUID 5cd1d9da-f33f-daf3-5143-f7ecbdfd2efc97c0
IODev MQTT2
LASTInputDev MQTT2
MQTT2_MSGCNT 1144
MQTT2_TIME 2019-05-08 16:25:23
MSGCNT 1144
NAME MQTT2_MQTT2
NR 1053
STATE Data
<br>
<a href="http://IPAddress" target="_blank">IPAddress</a>
TYPE MQTT2_DEVICE
OLDREADINGS:
READINGS:
2019-05-08 15:39:54 FallbackTopic DVES_9EFABC
2019-05-08 15:39:54 GroupTopic sonoffs
2019-05-08 15:39:54 Hostname Sonoff-Bridge
2019-05-08 15:39:54 IPAddress 192.168.x.x
2019-05-08 15:39:54 LWT Online
2019-05-08 15:39:54 Module Sonoff Bridge
2019-05-08 15:39:54 POWER
2019-05-08 15:39:55 RestartReason Software/System restart
2019-05-08 16:14:34 RfCode #1451
2019-05-08 16:23:09 RfReceived_Data 00555F
2019-05-08 16:23:09 RfReceived_High 1050
2019-05-08 16:23:09 RfReceived_Low 370
2019-05-08 16:23:09 RfReceived_RfKey None
2019-05-08 16:23:09 RfReceived_Sync 11030
2019-05-08 16:25:23 Time 2019-05-08T15:25:23
2019-05-08 16:25:23 Uptime 0T00:45:36
2019-05-08 16:25:23 Vcc 3.196
2019-05-08 15:39:54 Version 6.1.1
2019-05-08 15:39:54 WebServerMode Admin
2019-05-08 16:25:23 Wifi_AP 1
2019-05-08 16:25:23 Wifi_APMac 8A:8A:20:8D:97:25
2019-05-08 16:25:23 Wifi_RSSI 86
2019-05-08 16:25:23 Wifi_SSId HA
Attributes:
IODev MQTT2
readingList MQTT2:/Smarthome/Buero/sonoffrf/cmnd/RfCode:.* RfCode
MQTT2:/Smarthome/Buero/sonoffrfEG/tele/LWT:.* LWT
MQTT2:/Smarthome/Buero/sonoffrfEG/cmnd/POWER:.* POWER
MQTT2:/Smarthome/Buero/sonoffrfEG/tele/INFO1:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/sonoffrfEG/tele/INFO2:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/sonoffrfEG/tele/INFO3:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/sonoffrfEG/tele/STATE:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/LWT:.* LWT
MQTT2:/Smarthome/Buero/DVES_9EFABC/cmnd/POWER:.* POWER
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/INFO1:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/INFO2:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/INFO3:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/STATE:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/RESULT:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/DG/sonoffrf/tele/STATE:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/DG/sonoffrf/tele/RESULT:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/DG/sonoffrf/tele/UPTIME:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/UPTIME:.* { json2nameValue($EVENT) }
room MQTT2_DEVICE
und:
Internals:
CFGFN
CID MQTT2_GeneralBridge
DEF MQTT2_GeneralBridge
DEVICETOPIC MQTT2_GeneralBridge
FUUID 5cd2d6b6-f33f-daf3-eceb-178160d129308e24
IODev MQTT2
NAME MQTT2_GeneralBridge
NR 11491
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2019-05-08 15:16:39 associatedWith MQTT2_MQTT2
Attributes:
IODev MQTT2
autocreate 1
bridgeRegexp (tele|cmnd)[/]([^/]+)[/].*:.* "$2"
shellies[/]([^/]+)[/].*:.* "$1"
(ESPClient_[^/]+)[/].*:.* "$1"
comment Do not use very open bridgeRegexp expressions! This might lead to irritating results...
model A_00_MQTT2_CLIENT_general_bridge
room MQTT2_DEVICE
setStateList on off
Danke & Gruß,
Tobi
OK, sieht tatsächlich soweit fast ok aus.
Bitte an MQTT2_GeneralBridge die bridgeRegexp so ändern wie oben vorgeschlagen.
Dann einfach mqtt2_mqtt2 (und evtl. die Kopie) löschen (von der Kopie hast du ja eine RAW, falls wir die nochmal brauchen).
Es sollten dann zwei neue dafür angelegt werden, die getrennte readingList-Angaben haben (nach "Topic"-Angabe in der tasmota-config getrennt) und das auch als CID-Internal anzeigen.
Hier die neuen lists:
Internals:
CFGFN
CID MQTT2_GeneralBridge
DEF MQTT2_GeneralBridge
DEVICETOPIC MQTT2_GeneralBridge
FUUID 5cd2d6b6-f33f-daf3-eceb-178160d129308e24
IODev MQTT2
NAME MQTT2_GeneralBridge
NR 11491
STATE ???
TYPE MQTT2_DEVICE
OLDREADINGS:
READINGS:
Attributes:
IODev MQTT2
autocreate 1
bridgeRegexp attr MQTT2 bridgeRegexp \
/Smarthome/[/]([^/]+)[/]([^/]+)[/](tele|cmnd|stat)[/].*:.* "$2"\
shellies[/]([^/]+)[/].*:.* "$1"\
(ESPClient_[^/]+)[/].*:.* "$1"
comment Do not use very open bridgeRegexp expressions! This might lead to irritating results...
model A_00_MQTT2_CLIENT_general_bridge
room MQTT2_DEVICE
setStateList on off
Internals:
CFGFN
CID MQTT2
DEF MQTT2
DEVICETOPIC MQTT2_RF1
FUUID 5cd2d6a3-f33f-daf3-1a42-3a5ad42fe7274b6e
IODev MQTT2
LASTInputDev MQTT2
MQTT2_MSGCNT 56
MQTT2_TIME 2019-05-08 17:26:53
MSGCNT 56
NAME MQTT2_RF1
NR 11488
STATE rfsend
<br>
<a href="http://192.168.x.x" target="_blank">192.168.x.x</a>
TYPE MQTT2_DEVICE
READINGS:
2019-05-08 17:26:45 FallbackTopic DVES_9EFABC
2019-05-08 17:26:45 GroupTopic sonoffs
2019-05-08 17:26:45 Hostname Sonoff-Bridge
2019-05-08 17:26:45 IPAddress 192.168.x.x
2019-05-08 17:26:45 LWT Online
2019-05-08 17:26:45 Module Sonoff Bridge
2019-05-08 17:26:45 POWER
2019-05-08 16:53:45 Protocol #02270F
2019-05-08 17:26:45 RestartReason Software/System restart
2019-05-08 15:32:11 RfCode #005451
2019-05-08 16:11:16 RfReceived_Data 412426
2019-05-08 16:11:16 RfReceived_High 1180
2019-05-08 16:11:16 RfReceived_Low 410
2019-05-08 16:11:16 RfReceived_RfKey None
2019-05-08 16:11:16 RfReceived_Sync 12290
2019-05-08 17:28:01 Time 2019-05-08T16:28:01
2019-05-08 17:28:01 Uptime 3T06:10:12
2019-05-08 17:28:01 Vcc 3.142
2019-05-08 17:26:45 Version 6.1.1
2019-05-08 17:26:45 WebServerMode Admin
2019-05-08 17:28:01 Wifi_AP 1
2019-05-08 17:28:01 Wifi_APMac 0E:EC:DA:1A:9C:57
2019-05-08 17:28:01 Wifi_RSSI 66
2019-05-08 17:28:01 Wifi_SSId HA
2019-05-08 16:53:45 state rfsend
Attributes:
IODev MQTT2
autocreate 1
event-on-change-reading .*
model A_01d_tasmota_rf
readingList MQTT2:/Smarthome/Buero/sonoffrf/cmnd/RFsend:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/STATE:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/LWT:.* LWT
MQTT2:/Smarthome/Buero/DVES_9EFABC/cmnd/POWER:.* POWER
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/INFO1:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/INFO2:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/INFO3:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/DG/sonoffrf/tele/STATE:.* { json2nameValue($EVENT) }
room MQTT2_DEVICE
setList power:noArg /Smarthome/Buero/sonoffrf/cmnd/RFsend POWERCMD
volumeup:noArg /Smarthome/Buero/sonoffrf/cmnd/RFsend VOLUMEUPCMD
rfsend:textField /Smarthome/Buero/sonoffrf/cmnd/RFsend {"Protocol":"$EVTPART1","Bits":$EVTPART2,"Data":"0x$EVTPART3"}
stateFormat state
<br>
<a href="http://IPAddress" target="_blank">IPAddress</a>
weitere devices nicht vorhanden.
Soweit auch klar, in der readingList stehen einige Angaben von beiden drin (was bekannt ist, wird dort auch verarbeitet, wo es steht), und das LWT vom 2. scheint noch nicht aktualisiert worden zu sein. Evtl. doch auch MQTT2_RF1 mal löschen und beide ESP's neu starten (dann sollte in jedem Fall LWT gesendet werden).
MQTT2_RF1 gelöscht, beide Bridges restartet, jetzt gibt es wieder das mqtt2_mqtt2, kein weiteres.
lt. IP ist es jetzt die 2. (nicht angepasste) bridge:
Internals:
CFGFN
CID MQTT2
DEF MQTT2
DEVICETOPIC MQTT2_MQTT2
FUUID 5cd2fab1-f33f-daf3-5902-4a44398e7aac23e2
IODev MQTT2
LASTInputDev MQTT2
MQTT2_MSGCNT 12
MQTT2_TIME 2019-05-08 17:53:17
MSGCNT 12
NAME MQTT2_MQTT2
NR 11950
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2019-05-08 17:50:33 FallbackTopic DVES_B2AB43
2019-05-08 17:50:33 GroupTopic sonoffs
2019-05-08 17:50:33 Hostname sonoffrf-2883
2019-05-08 17:50:33 IPAddress 192.168.x.x
2019-05-08 17:50:32 LWT online
2019-05-08 17:50:33 Module Sonoff Bridge
2019-05-08 17:50:33 POWER
2019-05-08 17:50:33 RestartReason Software/System restart
2019-05-08 17:53:17 RfReceived_Data 8148C6
2019-05-08 17:53:17 RfReceived_High 1180
2019-05-08 17:53:17 RfReceived_Low 410
2019-05-08 17:53:17 RfReceived_RfKey None
2019-05-08 17:53:17 RfReceived_Sync 12300
2019-05-08 17:50:41 Time 2019-05-08T16:50:40
2019-05-08 17:50:41 Uptime 0T00:00:15
2019-05-08 17:50:41 Vcc 3.142
2019-05-08 17:50:33 Version 6.2.1
2019-05-08 17:50:33 WebServerMode Admin
2019-05-08 17:50:41 Wifi_AP 1
2019-05-08 17:50:41 Wifi_APMac 0E:EC:DA:1A:9C:57
2019-05-08 17:50:41 Wifi_RSSI 74
2019-05-08 17:50:41 Wifi_SSId HA
Attributes:
IODev MQTT2
readingList MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/RESULT:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/DG/sonoffrf/tele/RESULT:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/LWT:.* LWT
MQTT2:/Smarthome/Buero/DVES_9EFABC/cmnd/POWER:.* POWER
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/INFO1:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/INFO2:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/INFO3:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/DG/sonoffrf/tele/LWT:.* LWT
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/STATE:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/DG/sonoffrf/cmnd/POWER:.* POWER
MQTT2:/Smarthome/DG/sonoffrf/tele/INFO1:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/DG/sonoffrf/tele/INFO2:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/DG/sonoffrf/tele/INFO3:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/DG/sonoffrf/tele/STATE:.* { json2nameValue($EVENT) }
room MQTT2_DEVICE
In der BridgeRegexp ist evtl. noch ein / zu viel, sorry, wenn ich das übersehen haben sollte:
/Smarthome/[/]([^/]+)[/]([^/]+)[/](tele|cmnd|stat)[/].*:.* "$2"\
Das sollte so heißen:
/Smarthome[/]([^/]+)[/]([^/]+)[/](tele|cmnd|stat)[/].*:.* "$2"\
Kann sein, dass der "/" am Anfang auch stört, dann bitte die eckigen klammern drum.
kein Problem, ich bin ja froh dass Du dich dem Thema überhaupt annimmst ;)
Leider keine große Veränderung. Mit "/" vorne kam nichts, ohne kommt wieder ein device, jetzt aber wieder die 1. Bridge (war aber auch die die ich zuerst rebootet hab):
Internals:
CFGFN
CID MQTT2
DEF MQTT2
DEVICETOPIC MQTT2_MQTT2
FUUID 5cd30ca3-f33f-daf3-ab0b-c277be0c749673a0
IODev MQTT2
LASTInputDev MQTT2
MQTT2_MSGCNT 17
MQTT2_TIME 2019-05-08 19:08:02
MSGCNT 17
NAME MQTT2_MQTT2
NR 13380
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2019-05-08 19:07:30 FallbackTopic DVES_B2AB43
2019-05-08 19:07:30 GroupTopic sonoffs
2019-05-08 19:07:30 Hostname sonoffrf-2883
2019-05-08 19:07:30 IPAddress 192.168.x.x
2019-05-08 19:07:30 LWT online
2019-05-08 19:07:30 Module Sonoff Bridge
2019-05-08 19:07:30 POWER
2019-05-08 19:07:31 RestartReason Software/System restart
2019-05-08 19:08:02 RfReceived_Data 8148C6
2019-05-08 19:08:02 RfReceived_High 1190
2019-05-08 19:08:02 RfReceived_Low 400
2019-05-08 19:08:02 RfReceived_RfKey None
2019-05-08 19:08:02 RfReceived_Sync 12350
2019-05-08 19:07:38 Time 2019-05-08T18:07:38
2019-05-08 19:07:38 Uptime 0T00:00:17
2019-05-08 19:07:38 Vcc 3.142
2019-05-08 19:07:30 Version 6.2.1
2019-05-08 19:07:30 WebServerMode Admin
2019-05-08 19:07:38 Wifi_AP 1
2019-05-08 19:07:38 Wifi_APMac 0E:EC:DA:1A:9C:57
2019-05-08 19:07:38 Wifi_RSSI 68
2019-05-08 19:07:38 Wifi_SSId HA
Attributes:
IODev MQTT2
readingList MQTT2:/Smarthome/DG/sonoffrf/tele/RESULT:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/LWT:.* LWT
MQTT2:/Smarthome/Buero/DVES_9EFABC/cmnd/POWER:.* POWER
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/INFO1:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/INFO2:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/INFO3:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/RESULT:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/STATE:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/DG/sonoffrf/tele/LWT:.* LWT
MQTT2:/Smarthome/DG/sonoffrf/cmnd/POWER:.* POWER
MQTT2:/Smarthome/DG/sonoffrf/tele/INFO1:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/DG/sonoffrf/tele/INFO2:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/DG/sonoffrf/tele/INFO3:.* { json2nameValue($EVENT) }
MQTT2:/Smarthome/DG/sonoffrf/tele/STATE:.* { json2nameValue($EVENT) }
room MQTT2_DEVICE
Zitat von: Beta-User am 08 Mai 2019, 17:55:33
Kann sein, dass der "/" am Anfang auch stört, dann bitte die eckigen klammern drum.
Hattest du das versucht:
[/]Smarthome[/]([^/]+)[/]([^/]+)[/](tele|cmnd|stat)[/].*:.* "$2"\Ansonsten eventuell noch erweitern:
[^/]*[/]Smarthome[/]([^/]+)[/]([^/]+)[/](tele|cmnd|stat)[/].*:.* "$2"\Generelle Anmerkung:
Es ist oft hilfreich, die Namensangaben usw. etwas zu variieren und nicht ganz so "generisch" Teile zu verwenden, die auch woanders her kommen könnten; hier siehst du z.B. nicht ohne weiteres, aus welcher Quelle autocreate welches Device ableitet. Es wäre m.E. einfacher, wenn du den MQTT2_CLIENT nicht gerade "MQTT2" nennen würdest, sondern z.B. "m2c" oder "mqtt2client". Dann könntest du besser nachvollziehen, dass dies dann wieder als CID für das abgeleitete Device genutzt wird usw..
Anders gesagt:
Solange du ein "Sammeldevice" mit CID hast, die dem Namen des Client entspricht, in dem alles landet, greift die bridgeRegexp nicht. Das müssen wir also als erstes fixen, dann geht's weiter.
Habe nun mal alles gelöscht und nur den m2c als mqtt2_client definiert.
Wie soll ich jetzt am besten vorgehen?
Wir benötigen ein Bridge mqtt2_device mit passender bridgeRegexp => template+anpassen.Kurz, da mobil
Vermutlich hab ich dich nicht richtig verstanden.
Habe nun:
Internals:
CFGFN
CID m2c
DEF m2c
DEVICETOPIC MQTT2_m2c
FUUID 5cd4845f-f33f-daf3-5eeb-8512fbafff932dd3
IODev m2c
LASTInputDev m2c
MSGCNT 1
NAME MQTT2_m2c
NR 1202
STATE ???
TYPE MQTT2_DEVICE
m2c_MSGCNT 1
m2c_TIME 2019-05-09 21:50:11
OLDREADINGS:
READINGS:
Attributes:
IODev m2c
autocreate 1
bridgeRegexp attr MQTT2 bridgeRegexp \
/Smarthome[/]([^/]+)[/]([^/]+)[/](tele|cmnd|stat)[/].*:.* "$2"\
shellies[/]([^/]+)[/].*:.* "$1"\
(ESPClient_[^/]+)[/].*:.* "$1"
room MQTT2_DEVICE
Und :
Internals:
CFGFN
CID MQTT2_GeneralBridge
DEF MQTT2_GeneralBridge
DEVICETOPIC MQTT2_GeneralBridge
FUUID 5cd484d7-f33f-daf3-ad4d-fb43c0d1326f2124
IODev m2c
NAME MQTT2_GeneralBridge
NR 1215
STATE ???
TYPE MQTT2_DEVICE
OLDREADINGS:
READINGS:
Attributes:
IODev m2c
autocreate 1
bridgeRegexp attr MQTT2 bridgeRegexp \
/Smarthome[/]([^/]+)[/]([^/]+)[/](tele|cmnd|stat)[/].*:.* "$2"\
shellies[/]([^/]+)[/].*:.* "$1"\
(ESPClient_[^/]+)[/].*:.* "$1"
comment Do not use very open bridgeRegexp expressions! This might lead to irritating results...
model A_00_MQTT2_CLIENT_general_bridge
room MQTT2_MQTT2_m2c
setStateList on off
Dabei ist es egal, ob die bridgeexp in dem 1. oder 2 device drin ist. Weitere devices werden nicht angelegt.
Das erste "/" in der bridgeRegexp bitte mal innerhalb [] und (Schritt 2) vorneweg .* anfügen.
Du meinst beide Versionen aus Thread #58? Habe ich, aber ohne Erfolg.
Zitat von: onkel-tobi am 09 Mai 2019, 22:21:08
Du meinst beide Versionen aus Thread #58? Habe ich, aber ohne Erfolg.
Ok, danke für die Rückmeldung dazu.
An den topic-Strukturen hattest du nichts verändert, oder?
Wenn nein, habe ich im Moment keine Idee, an was es klemmt. Wenn man https://regexr.com/ nutzt, um die erste bridgeRegexp zu checken (mit der vollen Version "[^/]*[/]Smarthome[/]([^/]+)[/]([^/]+)[/](tele|cmnd|stat)[/].*" (das folgende ":.*" ist bei den anderen auch erwiesenermaßen unschädlich...) mit dem Topicstring (einschl. CID) "MQTT2:/Smarthome/Buero/DVES_9EFABC/tele/LWT" kommt das korrekte Ergebnis raus.
Anmerkungen:
- Ich gehe davon aus, dass irgendwas gesendet wurde von den ESP's. (wg. reboot oä; die readingList-Einträge sind beide leer, da sollte eigentlich was stehen ??? ).
- Es reicht, wenn die bridgeRegexp an einem Gerät steht, die andere kannst du löschen. Da jedes Mal beim Ändern die readingList gelöscht wird, hatte ich das damals auf ein eigens dafür geschaffenes Device gelegt, damit man ggf. die readingList vom "Sammeldevice" (bei dir: MQTT2_m2c)noch hat und da ggf. dann manuell eingreifen kann. Das würde ich hier auch bevorzugen. Also: MQTT2_GeneralBridge für die bridgeRegexp-Änderungen, MQTT2_m2c für das Rüfen, ob dort (immer noch) die Readings landen, wenn was gesendet wird, ohne dass die bridgeRegexp greift.
(Ich hoffe, das halbwegs verständlich erläutert zu haben; wenn man damit ein wenig gespielt hat, wird es in der Regel klarer...)
Vielleicht machst du zum besseren Verständnis mal noch einen zusätzlichen bridgeRegexp-Eintrag:
.*DVES_(9EFABC).* "$1"Damit sollte in jedem Fall nach irgendeinem Lebenszeichen von dem DVES_9EFABC ein neues MQTT2_DEVICE mit Namen MQTT2_9EFABC und der CID 9EFABC angelegt werden (vorausgesetzt, die andere "smarthome"-bridgeRegexp greift nicht, aber auch dann gibt es ein (etwas anderes) neues Device).
Hi,
jetzt bekomme ich zwar grad was, aber ein dev wird nicht angelegt :(
Internals:
CFGFN
CID m2c
DEF m2c
DEVICETOPIC MQTT2_m2c
FUUID 5cd5ca42-f33f-daf3-7e1b-72445b475b02dd0f
IODev m2c
LASTInputDev m2c
MSGCNT 1
NAME MQTT2_m2c
NR 1133
STATE ???
TYPE MQTT2_DEVICE
m2c_MSGCNT 1
m2c_TIME 2019-05-10 21:06:50
OLDREADINGS:
READINGS:
2019-05-10 21:06:50 Time 2019-05-10T20:06:49
2019-05-10 21:06:50 Uptime 2T00:45:20
2019-05-10 21:06:50 Vcc 3.142
2019-05-10 21:06:50 Wifi_AP 1
2019-05-10 21:06:50 Wifi_APMac 0E:EC:DA:1A:9C:57
2019-05-10 21:06:50 Wifi_RSSI 78
2019-05-10 21:06:50 Wifi_SSId HA
Attributes:
IODev m2c
readingList m2c:/Smarthome/DG/sonoffrf/tele/STATE:.* { json2nameValue($EVENT) }
m2c:/Smarthome/Buero/DVES_9EFABC/tele/UPTIME:.* { json2nameValue($EVENT) }
m2c:/Smarthome/DG/sonoffrf/tele/UPTIME:.* { json2nameValue($EVENT) }
room MQTT2_DEVICE
Und:
Internals:
CID MQTT2_GeneralBridge
DEF MQTT2_GeneralBridge
DEVICETOPIC MQTT2_GeneralBridge
FUUID 5cd5ca61-f33f-daf3-a0c2-87dc908a82bcac9d
IODev m2c
NAME MQTT2_GeneralBridge
NR 1056
STATE ???
TYPE MQTT2_DEVICE
Attributes:
IODev m2c
autocreate 1
bridgeRegexp attr MQTT2 bridgeRegexp \
[^/]*[/]Smarthome[/]([^/]+)[/]([^/]+)[/](tele|cmnd|stat)[/].* "$2"\
shellies[/]([^/]+)[/].*:.* "$1"\
(ESPClient_[^/]+)[/].*:.* "$1"
comment Do not use very open bridgeRegexp expressions! This might lead to irritating results...
model A_00_MQTT2_CLIENT_general_bridge
room MQTT2_DEVICE
setStateList on off
Hättest du die RL in MQTT2_m2c gelöscht?
Wie ist es, wenn du die bridgeRegex wie vorgeschlagen mit dem konkreten Namen ergänzt?
Zitat von: Beta-User am 11 Mai 2019, 07:45:24
Hättest du die RL in MQTT2_m2c gelöscht?
Ja, habe ich gestern mal beim rumspielen probiert.
Den Namen in der bridgeRegex, wie mach ich das genau? In der general bridge dann einfach Zeile einfügen im bridgeRegex attr?
Ja, einfach eine weitere Zeile
Leider auch keine Veränderung :(
Verstehe das einfach nicht. Denn die Tage hatte ich ja zumindest mal das RF1, was gar nicht so schlecht aussah...
Autocreate bei beiden (*_m2c und generalbridge) ist aber korrekt?
BridgeRegex sieht so aus:
attr MQTT2 bridgeRegexp \
[^/]*[/]Smarthome[/]([^/]+)[/]([^/]+)[/](tele|cmnd|stat)[/].* "$2"\
shellies[/]([^/]+)[/].*:.* "$1"\
(ESPClient_[^/]+)[/].*:.* "$1"\
.*DVES_(9EFABC).* "$1"
Hmmm, fhem ist aktuell, oder?
Und du löschst nach jeder Änderung der bridgeRegex die rL des MQTT2_m2c bzw. das ganze device? Anschließend einen der ESPs neu starten?
Wenn ja: sehr komisch...
Hi,
also nach jd. Änderung das *_mc device habe ich nicht gelöscht.
Werde ich dann jetzt mal probieren.
Das general_bridge lasse ich aber drin?
Gruß,
Tobi
Ja, die GeneralBridge ist zum "Sortieren" da, und soll das, was zusammen gehört jeweils in genau ein Device weiterleiten, aber eben trennen, was nicht zusammen gehört...Muss also bleiben.
Sortiert werden aber nur _unbekannte_ Topics. Deswegen muss das andere bzw die rL vereinfacht gelöscht werden (bereinigen würde reichen...).
Nochmals vielen Dank für deine Geduld!
Ich habe das Gefühl ich mache noch grundsätzlich was falsch.
Hatte jetzt mal das MQTT2_m2c gelöscht, damit bleibt also der mqqt2_client (m2c):
Internals:
BUF
CFGFN FHEM/vccu.cfg
DEF 127.0.0.1:1883
DeviceName 127.0.0.1:1883
FD 88
FUUID 5cd5c8be-f33f-daf3-1854-333afde33c9e5e0e
NAME m2c
NR 42
PARTIAL
STATE opened
TYPE MQTT2_CLIENT
WBCallback
clientId m2c
lastMsgTime 1557557123.32289
nextOpenDelay 5
READINGS:
2019-05-11 08:42:53 state opened
Attributes:
autocreate simple
Und die generalBridge:
Internals:
CID MQTT2_GeneralBridge
DEF MQTT2_GeneralBridge
DEVICETOPIC MQTT2_GeneralBridge
FUUID 5cd5ca61-f33f-daf3-a0c2-87dc908a82bcac9d
IODev m2c
NAME MQTT2_GeneralBridge
NR 1055
STATE ???
TYPE MQTT2_DEVICE
Attributes:
IODev m2c
autocreate 1
bridgeRegexp attr MQTT2 bridgeRegexp \
[^/]*[/]Smarthome[/]([^/]+)[/]([^/]+)[/](tele|cmnd|stat)[/].* "$2"\
shellies[/]([^/]+)[/].*:.* "$1"\
(ESPClient_[^/]+)[/].*:.* "$1"
comment Do not use very open bridgeRegexp expressions! This might lead to irritating results...
model A_00_MQTT2_CLIENT_general_bridge
room MQTT2_DEVICE
setStateList on off
BridgeRegexp hatte ich in beiden Versionen probiert...
Und ich starte die bridge nach jd. Änderung durch.
Aber ich bekomme nichts mehr. Das sah bei dem mqtt2_m2c device noch anders aus, da kam zumindest was ins rL.
Update:
ICh werde nun noch mal alles löschen außer dem MQQT2_client.
Diesen setze ich auf autocreate simple?
Dann sollte ein MQTT2_client device entstehen, bei dem ich dann autocreat auf 1 stelle?
Außerdem attrTemplate anwende mit general bridge.
Dann entsteht das generalBridge device, dass ich dann auf jd. Fall mit autocreate 1 setze und in dem ich die bridgeRegex wie oben anpasse.
Entsprechend das rL in MQTT2_m2c löschen, die sonoff bridge neustarten und es sollte die 1. Bridge erstellt werden?
RAW-Events am IO ansehen => was kommt rein...
Sorry für Kurzfassung, bin nur mobil.
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?!
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?)
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.
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
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?
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 :o , 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.
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?
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
Ergänze mal in der Smarthome-Zeile noch ":.*". Also so:
Smarthome[/]([^/]+)[/]([^/]+)[/](tele|cmnd|stat)[/].*:.* "$2"\
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:
/Smarthome[/]([^/]+)[/]([^/]+)[/](tele|cmnd|stat)[/].*:.* "$2"
shellies[/]([^/]+)[/].*:.* "$1"
(ESPClient_[^/]+)[/].*:.* "$1"
und die readingList im "Sammeldevice" gelöscht.
Dann wird bei einem
mosquitto_pub -h zigbeepi -i SmartHome -t /Smarthome/Buero/DVES_9EFABC/tele/LWT -m onlineautomatisch ein Device namens MQTT2_DVES_9EFABC angelegt (RAW):
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.
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
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:
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
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 ;) ).
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:
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 toggleDas 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? ;)
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:
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.
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:
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
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.
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
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.
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,SchlafzimmerUnter 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
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.
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
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...
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
...
...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ß).
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
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
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.
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).
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?
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?
Hallo Beta-User,
erst einmal Danke für die Rückmeldungen und Deine Zeit.
Ich habe eine Fernbedienung zu den Dosen und wenn ich da auf A On drücke kommt folgendes log in der Bridge:
15:42:28 MQT: tele/sonoffbr1/RESULT = {"RfReceived":{"Sync":7340,"Low":520,"High":1070,"Data":"9C6470","RfKey":"None"}}
15:42:33 MQT: tele/sonoffbr1/RESULT = {"RfReceived":{"Sync":7360,"Low":540,"High":1050,"Data":"93B3B0","RfKey":"None"}}
15:42:34 MQT: tele/sonoffbr1/RESULT = {"RfReceived":{"Sync":7400,"Low":540,"High":1050,"Data":"973730","RfKey":"None"}}
15:42:35 MQT: tele/sonoffbr1/RESULT = {"RfReceived":{"Sync":7380,"Low":520,"High":1060,"Data":"9BF040","RfKey":"None"}}
und für A off:
5:43:42 MQT: tele/sonoffbr1/RESULT = {"RfReceived":{"Sync":7350,"Low":510,"High":1070,"Data":"91D210","RfKey":"None"}}
15:43:43 MQT: tele/sonoffbr1/RESULT = {"RfReceived":{"Sync":7370,"Low":520,"High":1070,"Data":"98A990","RfKey":"None"}}
15:43:44 MQT: tele/sonoffbr1/RESULT = {"RfReceived":{"Sync":7370,"Low":510,"High":1080,"Data":"9E08A0","RfKey":"None"}}
15:43:45 MQT: tele/sonoffbr1/RESULT = {"RfReceived":{"Sync":7380,"Low":510,"High":1080,"Data":"999520","RfKey":"None"}}
das sind die jeweils 4 rollenden Codes...
Kannst du mal on bzw- off-setter für jeweils alle 4 Varianten einrichten und dann mal testen, ob die Codes nacheinander funktionieren bzw. erst mal einer davon und dann die anderen nacheinander? Wenn ja, müßten wir uns den Each-Vorschlag von Rudi mal näher ansehen (ist auch Neuland für mich)...
Hi Beta-User,
ich habe nun folgendes in der setList:
on:noArg cmnd/sonoffbr1/Backlog RfSync 7350; RfLow 520; RfHigh 1070; RfCode #9C6470
on:noArg cmnd/sonoffbr1/Backlog RfSync 7350; RfLow 520; RfHigh 1070; RfCode #93B3B0
on:noArg cmnd/sonoffbr1/Backlog RfSync 7350; RfLow 520; RfHigh 1070; RfCode #973730
on:noArg cmnd/sonoffbr1/Backlog RfSync 7350; RfLow 520; RfHigh 1070; RfCode #9BF040
off:noArg cmnd/sonoffbr1/Backlog RfSync 7370; RfLow 510; RfHigh 1080; RfCode #91D210
off:noArg cmnd/sonoffbr1/Backlog RfSync 7370; RfLow 510; RfHigh 1080; RfCode #98A990
off:noArg cmnd/sonoffbr1/Backlog RfSync 7370; RfLow 510; RfHigh 1080; RfCode #9E08A0
off:noArg cmnd/sonoffbr1/Backlog RfSync 7370; RfLow 510; RfHigh 1080; RfCode #999520
power:noArg DVES_6609A1:tele/sonoffbr1/RFsend POWERCMD
volumeup:noArg DVES_6609A1:tele/sonoffbr1/RFsend VOLUMEUPCMD
rfsend:textField DVES_6609A1:tele/sonoffbr1/RFsend {"Protocol":"$EVTPART1","Bits":$EVTPART2,"Data":"0x$EVTPART3"}
Ich bin da sowas von blutiger Anfäger... Ich hoffe, dass Du das so meintest mit den Codes.
oder sollte die Setlist so aussehen?
on:noArg cmnd/sonoffbr1/Backlog RfSync 7350; RfLow 520; RfHigh 1070; RfCode #9C6470; RfSync 7350; RfLow 520; RfHigh 1070; RfCode #93B3B0; RfSync 7350; RfLow 520; RfHigh 1070; RfCode #973730; RfSync 7350; RfLow 520; RfHigh 1070; RfCode #9BF040
off:noArg cmnd/sonoffbr1/Backlog RfSync 7370; RfLow 510; RfHigh 1080; RfCode #91D210; RfSync 7370; RfLow 510; RfHigh 1080; RfCode #98A990; RfSync 7370; RfLow 510; RfHigh 1080; RfCode #9E08A0; RfSync 7370; RfLow 510; RfHigh 1080; RfCode #999520
Also jeweils alle codes für on bzw off in einem Backlog Commando...
Sollte im ersten Wurf mal bitte in etwa so wie in dem ersten Vorschlag sein, aber die setter müssen sich unterscheiden (also on, on1 ...).
Hi Beta-User,
ich hab alles eingerichtet und mal die codes probiert. Leider zuckt da irgend wie gar nichts...
Ich hab auch leider keine Idee woran es liegen könnte....
Kann es sein, dass hier evtl. noch ein anderes Protokoll ne Rolle spielt z.B. IT oder so etwas?
Das Protokoll ist vermutlich hier nicht das Problem, aber eine Idee habe ich grade auch nicht. Die "433-er-Welt" ist einfach wenig standardisiert. Ggf. müßtest du mal nachsehen, ob du das auf ein raw-Format runtergebrochen bekommst oder so. Ist aber ein Spezialthema, bei dem ich nicht helfen kann - evtl. mal gesondert (separater Thread) versuchen? Ist auch nicht MQTT2-Module-spezifisch.