MQTT2+Shelly: erste Konfiguration und template-Entwicklung

[draddy]

Azubi Monk an Monk ...
soo, @Beta-User, mach was draus ^^ (pm)

Grundidee wäre Implementierung mit ON / OFF Erweiterung auf toggle mit automatischem Reading habe ich beschrieben ^^

gn8 

[Beta-User]

Hi zurück,

Danke für den Input.

Erste Fassung ist in https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Shelly_Gen2. Muss das noch nacharbeiten und das mit dem "normalen" list ist m.E. auch im 1rst Gen (wo das "abgeschrieben" wurde) nicht optimal, da sollte eigentlich überall RAW stehen.
Es ist nach meinem Geschmack noch etwas sehr "frei" geschrieben, und der "toggle" ist bereits (update heute) im attrTemplate drin, also per default vorhanden.

Wenn möglich bitte auch (am einfachsten mit einer Kopie per RAW) das überarbeitete attrTemplate testen .

Im Zweifel einfach einen neuen Thread in https://forum.fhem.de/index.php/board,80.0.html dazu starten, und ich bin auch nicht böse, wenn einer der anderen "Wissenden" zum Thema Wiki und Shelly 2nd Gen. das direkt passend einpflegt.

[draddy]

Im Zweifel einfach einen neuen Thread in https://forum.fhem.de/index.php/board,80.0.html dazu starten, und ich bin auch nicht böse, wenn einer der anderen "Wissenden" zum Thema Wiki und Shelly 2nd Gen. das direkt passend einpflegt.

moin,
Diskussion zum Wiki Beitrag hab ich mal hier gestartet:
https://forum.fhem.de/index.php/topic,126581.0.html

aktuell will mein System das neue Template halt nicht ziehen wie es scheint.

[draddy]

moin beta

hab da glaub noch ein Problemchen gefunden, kanns aber nur bei meinem Shelly Plus 1 sagen da ich keine anderen Shellys per Mqtt drin hab ...

sowohl das Internal STATE als auch das Reading state hängen sich manchmal auf "set on|off" auf - passiert immer dann, wenn das device einen status hat, und diesen nochmal bekommt.

nach einem umschalten ist wieder alles OK.

Lg

[Beta-User]

Hmm, ohne den MQTT-Verkehr dazu zu kennen, sehe ich dazu grade keinen "Anpack".
Wenn "state" (das Reading) auf "set xy" stehen bleibt, kommt keine passende Antwort zurück, oder sie wird nicht korrekt verarbeitet. Evtl. hat sich da auch wieder eine Kleinigkeit an der fw geändert? (der 1-er "tickt " ab der Stelle etwas anders als der 4-er, und es wäre naheliegend, dass man das seitens der Fa. auf einen einheitlichen Stand gebracht hat).

[draddy]

moin

1. Toggle off --> on
2. Toggle on --> off
3. set off

hoffe hilft

Code: [Auswählen]

shellyplus1-441793a3b110/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Toggle","params": {"id":0}}
fhem2shelly/rpc {"id":0,"src":"shellyplus1-441793a3b110","dst":"fhem2shelly","result":{"was_on":false}}
shellyplus1-441793a3b110/status/switch:0 {"id":0, "source":"MQTT", "output":true,"temperature":{"tC":49.6, "tF":121.3}}
shellyplus1-441793a3b110/events/rpc {"src":"shellyplus1-441793a3b110","dst":"shellyplus1-441793a3b110/events","method":"NotifyStatus","params":{"ts":1647240737.32,"switch:0":{"id":0,"output":true,"source":"MQTT"}}}

shellyplus1-441793a3b110/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Toggle","params": {"id":0}}
fhem2shelly/rpc {"id":0,"src":"shellyplus1-441793a3b110","dst":"fhem2shelly","result":{"was_on":true}}
shellyplus1-441793a3b110/status/switch:0 {"id":0, "source":"MQTT", "output":false,"temperature":{"tC":49.5, "tF":121.1}}
shellyplus1-441793a3b110/events/rpc {"src":"shellyplus1-441793a3b110","dst":"shellyplus1-441793a3b110/events","method":"NotifyStatus","params":{"ts":1647240739.34,"switch:0":{"id":0,"output":false,"source":"MQTT"}}}

shellyplus1-441793a3b110/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false}}
fhem2shelly/rpc {"id":0,"src":"shellyplus1-441793a3b110","dst":"fhem2shelly","result":{"was_on":false}}
[code]

[Beta-User]

hoffe hilft

...in Teilen...

Das liegt nicht (nur) an FHEM: Das Rückmeldeverhalten des Shelly scheint nicht konsistent zu sein.
Mögliche Ansätze:
- FHEM sendet was "falsches", wobei hier m.E. nur eine Änderung der "id" in Frage kommen könnte => wir müßten die setList ändern und die id variabel gestalten;
- die firmware ist buggy => an den Hersteller wenden.

Würde empfehlen, mal dort nachzufragen, ob das so gedacht ist, dass die status und event-Topics nur manchmal "beliefert" werden...

[OdfFhem]

Ich bin mir nicht sicher, ob ich etwas übersehen habe ...

Der Shelly antwortet stets mit dem "momentanen" Zustand; sollte jetzt durch den Schaltwunsch eine Änderung erfolgen, wird auch der neue Zustand mitgeteilt.

Im letzten Fall ist der Shelly aber schon aus und ändert dementsprechend nichts ... schickt also auch keine "Änderungsmitteilung".

[Beta-User]

...auch wieder wahr...

Hmm, im Moment habe ich noch keine zündende Idee, wie man mit "doppelt genähten" Anweisungen sinnvoll umgehen kann und sollte.

[draddy]

ja genau!
solange tatsächlich geschaltet wird, alles OK!

also, wenigstens ist mir noch nichts aufgefallen bei echter Schaltung.
tritt wirklich immer dann auf, wenn man einen Befehl sendet, der nicht ausgeführt wird, weil der shelly diesen status schon hat.

halt die frage, ob man nicht ins Modul "einfach" nen check baut.

wiegesagt, das ist alles kein Weltuntergang, in dem fall ist nach einem doppel toggle alles ok, ist mir halt aufgefallen als ich bissl mit readingsgroup und proxy gefummelt habe, das manchmal statt dem icon eben ein "set on|off" da gestanden ist.

habe auch noch nicht ganz festgestellt, wann das bei mir genau passiert (also, das ein "off" gesendet wird obwohl off ist)

wenn es hilft ... mit unserem neuen "in_mode" passiert das nicht, wenn dieser auf z.b. flip steht, und ich erneut flip sende, ist das reading ganz ganz kurz "set flip" wird dann aber sofort auf "flip" geändert.

[Beta-User]

halt die frage, ob man nicht ins Modul "einfach" nen check baut.

...stellte sich die Frage, was "das Modul" sein soll...
MQTT2_DEVICE liefert schon "das richtige", wenn man "setStateList" _nicht_ setzt - nur eben um den Preis, dass dann der state ggf. "optimistic" ist und Fehler in der Übermittlung nicht mehr transparent wären.

Man könnte auch den "eigenen" Topic "fhem2shelly/rpc" auswerten und dann auf die "war schon so"-Rückmeldungen so reagieren, dass man das state-Reading passend setzt... Bin für konstruktive Vorschläge offen und übernehme das ggf. gerne in die attrTemplate .

[draddy]

mea culpa! natürlich Template nicht Modul


korrigier mich, aber: es kommt doch gar keine antwort vom shelly wenn ich "off" an den ausgeschalteten shelly sende oder?

wenn der shelly off ist, und ich nochmal off sende kommt nur von "fhem2shelly" result "was_on":false" und in dem moment schickt fhem2shelly doch nichts mehr an das device selbst, oder verstehe ich das falsch?

[Beta-User]

korrigier mich, aber: es kommt doch gar keine antwort vom shelly wenn ich "off" an den ausgeschalteten shelly sende oder?

Doch, es kommt eine Antwort, nur haben wir die bisher verworfen, nämlich

kommt nur von "fhem2shelly" result "was_on":false"

Das müßte man auswerten und prüfen, ob es ein "set on" war oder ein "set off"; beide Fälle unterscheiden sich nämlich, und nur im (jeweils) einen düfte dann ein "off" (bzw. "on") in state geschrieben werden (siehe deine MQTT-Messages von vorhin).

in dem moment schickt fhem2shelly doch nichts mehr an das device selbst, oder verstehe ich das falsch?

Es muss auch nichts mehr an den ESP gesendet werden, es muss nur der state in FHEM (korrekt) aktualisiert werden.

[draddy]

hmhm ... also ... ich wiss vom "in_mode" noch, das neue readings erstellt wurden ...

hab "fhem2shelly/rpc:.* {}" mal aus der readingslist rausgeworfen ... aber da wurden keine neuen erstellt (dachte mir wäre ein versuch wert)

[Beta-User]

...das Browserfenster hast du danach und nach mind. einem Schaltvorgang per refresh aktualisiert...?