shelly duo bulb gen3 über mqtt schalten

[TomLee]

Hab mich mit dem MQTT2_DISCOVERY noch nicht beschäftigt und auch nie was in so einem Json drinsteht.
Kann man es nicht an irgendwas festmachen (wo es geht), gleich auf die Fhemtypischen Readings zum mappen: https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings

[the ratman]

jetzt sperren ma die 2 in ein tiefes loch und warten, bis es selbsterstellende templates mit readings nach der genfer konvention gibt ... *bg*

[TomLee]

Irgendwo wo oben (finds nicht mehr, ist jetzt weg) war deine Vorgabe du willst es in ein paar Jahren auch noch verstehen.
Das beste für dich wär halt, das gar nix anrührst und es out of box funzt...

[the ratman]

wäre tatsächlich das beste.

und nur zur sicherheit:
mein geistiger erguss von oben sollt eher witzig sein, den irgendeine forderung.
ich würd mir auch nie die frechheit raus nehmen, eine forderung zu stellen (dafür zahl ich hier zu wenig), ich erkläre max. meine situation.

[Guybrush]

Hab mich mit dem MQTT2_DISCOVERY noch nicht beschäftigt und auch nie was in so einem Json drinsteht.
Kann man es nicht an irgendwas festmachen (wo es geht), gleich auf die Fhemtypischen Readings zum mappen: https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings

wird es ja, nur intern. das Problem ist, das man es händisch bearbeiten können soll und dafür brauchts referenzen. Das hab ich jetzt so gelöst. Es wird ja richtig gemapped. Das kann man oft viel einfacher machen. Das Problem sind aber die Sonderfälle, die manche devices mit sich bringen

[Beta-User]

mein geistiger erguss von oben sollt eher witzig sein, den irgendeine forderung.
ich würd mir auch nie die frechheit raus nehmen, eine forderung zu stellen (dafür zahl ich hier zu wenig), ich erkläre max. meine situation.

Das hatte ich schon so verstanden, und auch den Willen erkannt, die "Bringschulden" zu erfüllen.

Die vorhandenen attrTemplate sollen v.a. funktionale Devices bringen, die aus FHEM-Sicht "typisch bedienbar" sind. Das geht ausdrücklich an manchen Stellen zulasten der Performance, um auch mal auf den Thread MQTT best current practice zu verweisen und klarer zu machen, warum es (berechtigte) Kritik an der einen oder anderen Stelle gibt.

Irgendwo wo oben (finds nicht mehr, ist jetzt weg) war deine Vorgabe du willst es in ein paar Jahren auch noch verstehen.
Das beste für dich wär halt, das gar nix anrührst und es out of box funzt...

Das Beste wäre, wenn man auch noch nach Jahren halbwegs nachvollziehen kann, wie die nach dem aktuellen Stand der Dinge erforderlichen Puzzleteile zusammengehören. Also nochmal zum vertiefteren Verständis ein paar Anmerkungen dazu, wie man Helfern für MQTT-Themen hilft, wenn man wenig Ahnung hat:

- Man versucht rauszufinden, was das betreffende Gadget sendet, wenn man es lokal (oder per eigenem Web-Interface) bedient. Dazu kann man den "Show MQTT traffic"-Knopf am jeweiligen MQTT2_(SERVER|CLIENT) aktivieren, was zwischenzeitlich auch wieder voll funktional sein sollte. Alternativ arbeitet man sich in "mosquitto_sub" ein, siehe auch https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Mqtt#step-6-receive-notifications-over-mqtt.
- Manche Gadgets versuchen, einem zu helfen, indem sie "discovery"-Informationen schicken. Für FHEM war das bisher völlig sinnfrei und ergab nur ein Haufen unverständlicher Readings, daher war seither die Empfehlung, diese Messages direkt zu verwerfen (ignore am IO). Dennoch steht da natürlich drin, wie sich das Gadget per MQTT steuern läßt. Prinzipiell hilfreich, wenn man den JSON-Blob mit den Infos sinnvoll darstellt.
- Die Alternative ist, entweder zu rätseln, bekannte Geräte derselben Quelle (Shelly) durchzuprobieren oder eben die dazu passende Doku zu suchen (und zu verlinken). Das wäre hier https://shelly-api-docs.shelly.cloud/gen2/Devices/Gen3/ShellyDuoBulbG3, aus der dann insbesondere abzulesen wäre, wie man das Ding steuern kann.

Letzteres ist hier ja schon bekannt, und eventuell (!) auch nicht der einzige Weg (anscheinend kann man auch andere Formate wie dieses ausgesprochen komplizierte rpc-Gedöns verwenden, wenn man Lust hat, das auszuprobieren oder die Doku findet).

- zu guter Letzt ist es v.a. für komplett unbekanntes Terrain hilfreich, wenn man Topic-Payload im Klartext hat (dann kann man z.B. mosquitto_pub verwenden, um testweise nachzustellen, was passiert, oder wenigstens raw-Definitionen einspielen, ohne lange umformatieren zu müssen (z.B. aus dem "Copy for forum" Format).

Da der Kontext hier klar ist, (und wir daher eigentlich auf umfangreiche Tests verzichten können?!?) stellt sich jetzt v.a. die Frage, wie man auf dem Hin- und Rückweg dieselben Readings verwendet/setzt. 

Das macht die Kombi aus readingList und jsonMap - vorausgesetzt, man weist json2nameValue() an, das letztere auch zu benutzen - wir brauchen also die "lange Form":

Code Auswählen Erweitern

$DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT, '', $JSONMAP) }
$DEVICETOPIC/online:.* online
$DEVICETOPIC/rpc:.* {}
fhem/rpc:.* {}
Der letzte eintrag dient dazu, die (mir völlig unsinnig vorkommende) Rückmeldung des Aktors zu verwerfen, mit der dieser mitteilt, dass er die prc-Infos bekommen hat... Diesen braucht man allerdings eigentlich in einer FHEM-Installation genau ein mal, dann hat sich das. (Siehe "Effizienz" oben).

Klarer?

[TomLee]

Die Sonderfälle hab ich ja mit "wo es geht" erstmal ausgenommen.

Kannst mal zeigen welche Readings mit dem JSON der Bulb von @the Ratman erstellt würden?

[Guybrush]

das geht nicht so mal eben, weil das bei shellys aktiv abgefragt werden muss. aber grundsätzlich alle die es gibt mit vernünftigen namen. ich habs halt nur mit shelly 1 gen 4 testen können, weil ich nur die hab. ich hab das aber universell integriert. deswegen ja mal testen    sollte eigentlich alles funktionieren und alle verfügbaren readings/sets/gets liefern

[the ratman]

gut, ich ersetze mein zeug mit

Code Auswählen Erweitern

$DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT, '', $JSONMAP) }
$DEVICETOPIC/online:.* online
$DEVICETOPIC/rpc:.* {}
fhem/rpc:.* {}alles andere lass ich derweil mal, wie es ist.
ct, pct kommt mal neu als reading (hatte die mal weggemacht zum suchen) - traraaaa - sowhl pct und ct werden gemerkt, sind verstellbar ... ich wäre also somit abgespeist und zufrieden - danke euch nochmal!

falls man von mir was benötigt, und ich dazu nicht mein fhem killen muss - nur sagen.
ich besitze derweil:
o) 2 dieser bulbs
o) eine 4fach steckdose
o) eine einfach steckdose (die kleine mit a bissi weniger ampere)
o) einen shelly plus uno noch ungelötet, also noch ein nackter. mit dem könnt ihr mich bei lust fernsteuern. der hats noch nicht eilig eingesetzt zu werden, stünde also zur verfügung. der würde wahrscheinlich eh auch ein paar tunings vertragen. ich hab dessen einstellungen zusammengekrazt und sicher falsch, wenn er auch mal grundlegend macht.

und daran hängen div. blu sensoren/aktoren:
o) mehrere 4fach taster
o) temp sensoren
o) einen fensterkontakt https://www.conrad.de/de/p/shelly-blu-zb-door-window-white-shelly-sensor-bluetooth-zigbee-3775976.html mit total sinnloser lux funktion, dafür super kipperkennung.
o) sobald conrad mit mir gnädig ist (also in gefühlt 10 jahren), einen https://www.conrad.de/de/p/shelly-shelly-plus-rgbw-pm-controller-bluetooth-wi-fi-3308356.html rgbw unterputz schalter für 12 bis 24v.

was ich noch hätte wären gehäuse für die dinger zum selber drucken. wer die will kriegt die stl's zugesendet, wenn er verspricht sie nicht an andere als fheml'er weiter zu geben.
ein paar bilder: https://www.kodinerds.net/thread/81059-shelly-halterungen-mit-3d-druck/
ajo, die wandtaster haben schon mehrere halterungen. vor allem welche, die keinen rahmen mehr brauchen, also nur noch das einstecken des tasters erfordern. bspl. im anhang

Klarer?

sagen mas mal so: ich glaube so halbwegs zu kapieren, was du mir grade zeigen willst. allerdings bezweifel ich, dass ich jetzt lustig ein neues device anlegen könnte.
ich hab mir jetzt am mqtt2server mal show mqtt traffic gegeben - kannst mir eigentlich auch gleich den matrix screensaver anwerfen ... hat ungefähr die selbe bedeutung für mich *g*. ich denke aber, ich würde dort nach anweisung was finden, dass dann hier helfen könnte.

[TomLee]

@the Ratman

Kannst du mal in deiner MQTT2_SERVER Definition "ratBroker" oben auf "Show MQTT traffic" klicken, bei Filter "discovery" eingeben, die Bulb einmal neu starten und die Ausgabe hier posten?

Ich kenns aus der Vergangenheit nur so, kann sein das der Zweig auch abgefragt werden muss, keine Ahnung.


Guybrush sein Agent bekommts nicht hin, anhand der bisher gezeigten Readings nachzuvollziehen wie json2nameValue Readings erstellt um den Json abzuleiten...

[the ratman]

hmm,

wenn ich dicovery als filter nehme, die bulb einschalte und wieder ausschalte kommt gar nix.
die zeile schaut dann so aus: "Hide MQTT traffic  Reset  Filter:  discovery"

mit .* kommt (ich hoffe, ich hab den rest weg) - für einmal on und einmal off:

Code Auswählen Erweitern

19:51:46.069 SENT shellyduobulbg3-9070694a9e14/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"on":true}}
19:51:46.091 shelly_blug_duo_wz fhem/rpc {"id":0,"src":"shellyduobulbg3-9070694a9e14","dst":"fhem","result":null}
19:51:46.118 shelly_blug_duo_wz shellyduobulbg3-9070694a9e14/events/rpc {"src":"shellyduobulbg3-9070694a9e14","dst":"shellyduobulbg3-9070694a9e14/events","method":"NotifyStatus","params":{"ts":1788889905.11,"cct:0":{"apower":4.5}}}
19:51:46.125 shelly_blug_duo_wz shellyduobulbg3-9070694a9e14/events/rpc {"src":"shellyduobulbg3-9070694a9e14","dst":"shellyduobulbg3-9070694a9e14/events","method":"NotifyStatus","params":{"ts":1788889905.11,"cct:0":{"brightness":50,"ct":2700,"output":true,"source":"MQTT"}}}



19:51:48.349 SENT shellyduobulbg3-9070694a9e14/rpc {"id":0,"src":"fhem","method":"CCT.Set","params":{"id":0,"on":false}}
19:51:48.370 shelly_blug_duo_wz fhem/rpc {"id":0,"src":"shellyduobulbg3-9070694a9e14","dst":"fhem","result":null}
19:51:48.398 shelly_blug_duo_wz shellyduobulbg3-9070694a9e14/events/rpc  {"src":"shellyduobulbg3-9070694a9e14","dst":"shellyduobulbg3-9070694a9e14/events","method":"NotifyStatus","params":{"ts":1788889907.39,"cct:0":{"brightness":50,"ct":2700,"output":false,"source":"MQTT"}}}
19:51:48.408 shelly_blug_duo_wz shellyduobulbg3-9070694a9e14/events/rpc {"src":"shellyduobulbg3-9070694a9e14","dst":"shellyduobulbg3-9070694a9e14/events","method":"NotifyStatus","params":{"ts":1788889907.40,"cct:0":{"apower":0.0}}}

[the ratman]

gehen ma mal von aus, du meinst ned nur schalten, sondern reboot ... kommt gleich

nö, nach bulb reboot kommt auch nix

[TomLee]

das geht nicht so mal eben, weil das bei shellys aktiv abgefragt werden muss.

Dann wird es wohl so sein, ich will und mag mich damit aktuell nicht beschäftigen...

[Guybrush]

shelly schickt nativ keine discovery messages. das muss aktiv abgefragt werden. sonst reichts ja passiv zu lauschen (bei homeassistant kompatiblen devices). die capabilities bekommt man so aber nicht mit. mit autocreate werden zumindest readings erstellt. wenn man aber fertige listen haben will, geht es nur mit discovery messages oder in dem fall bei shelly mit aktiver abfrage. das ist nativ im Modul drin. Ich hab das Modul ja auch deshalb entwickelt, weils für viele zu kompliziert ist/war die reading/setLists richtig zu konfiguieren und auch mir das mit den templates offen gesagt schon immer zu aufwendig war. lief am ende immer darauf hinaus alles zu matchen und dann step by step zu reduzieren. war aber alles zuviel aufwand...

[TomLee]

Ja, sry. Reboot war gemeint oder kurz Spannungsfrei machen.