shelly duo bulb gen3 über mqtt schalten

[Guybrush]

das kommt im nächsten update rein. ich kann das aber leider nur über unittests und shelly doku validieren, weil ich so einen shelly nicht selbst hab. dadurch zieht sich das etwas

wegen deines anderen shelly:

wie ist da der mqtt prefix von? den nachfolgend einsetzen

Code Auswählen Erweitern

set mqttDiscovery discoverShelly <MQTT-Topic-Prefix>
set mqttDiscovery rebuildDevice shellyplugsg3_sz_angi_venti clearReadings


[the ratman]

problem gefunden - mein prefix hatte leerzeichen. scheint den mqtt2server nicht zu stören, deinen discover schon

gut, nun hab ich 2 steckdosen nach deinen einstellungen neu drinnen.
der rest hat mal deine angaben zusätzlich in der readinglist und teilweise in der setlist. schauen ma mal, ob ich mir gestern die "streiterei" nur eingebildet hab.

was mir noch fehlt, is tasächlich der status. ich kriege keine schaltbare, grafische anzeige hin. also z.b. für dose ein aus.
gut, schaltbar geht mit webcmd *g*. aber das wäre in meinen augen nicht "fhem standard"

was die pulps angeht ... kann ich dir helfen?
wenn dann aber wie immer: ich hab 0 ahnung und mach nur blöd, was du mir hier schreibst. denken wirst in der beziehung ausschließlich du!

[Guybrush]

das geht einfach mit devStateIcon. z.b.

müsste bei dir in etwa so aussehen (vorausgesetzt switch_0 ist das was du steuern willst):

Code Auswählen Erweitern

attr shellyplugsg3_sz_angi_venti devStateIcon true:control_on_off@green false:control_standby@orange
attr shellyplugsg3_sz_angi_venti eventMap /switch_0 on:Ein/switch_0 off:Aus/
attr shellyplugsg3_sz_angi_venti stateFormat switch_0
attr shellyplugsg3_sz_angi_venti webCmd Ein:Aus


[Beta-User]

das geht einfach mit devStateIcon. z.b.

müsste bei dir in etwa so aussehen (vorausgesetzt switch_0 ist das was du steuern willst):

Code Auswählen Erweitern

attr shellyplugsg3_sz_angi_venti devStateIcon true:control_on_off@green false:control_standby@orange
attr shellyplugsg3_sz_angi_venti eventMap /switch_0 on:Ein/switch_0 off:Aus/
attr shellyplugsg3_sz_angi_venti stateFormat switch_0
attr shellyplugsg3_sz_angi_venti webCmd Ein:Aus


eventMap ist imo Mist und sollte vermieden werden.

[the ratman]

genau die hätte ich vergessen. naja, zumindest zeigt mir jetzt der schalter an und aus an. schalten tut er eh nicht.

ich nehme natürlich gerne alternive/bessere/lustigere/... lösungen *g*

[Guybrush]

schalten sollte aber gehen. dann musst du gucken was du hast. switch_0 wirds ja wohl sein?

[the ratman]

klar, sonst würd er auch nix anzeigen.
allerdings müsste das ja ein toggle sein, und den haben ma ja nicht, is mir so nebenher eingefallen *g* oder wart, da war doch was mit schaltbefehl hinten dran ... ich schau nochmal
aber passt schon - ich hab meine zustandsanzeige wieder fürs schnelle "drüber schauen", das is da eh das wichtigste. der rest rennt bei mir eh über readingsgroups. und die hab ich zum glück grundlegend im griff ...

[the ratman]

hab ich doch mal richtig geraten:     
devstateicon --> true:control_on_off@green:Aus false:control_standby@orange:Ein

[Beta-User]

hab ich doch mal richtig geraten:     
devstateicon --> true:control_on_off@green:Aus false:control_standby@orange:Ein

Ohne dieses unselige eventMap:

Code Auswählen Erweitern

true:control_on_off@green:switch_0+onImo sollte ein "Hauptkanal" immer on und off ohne Channel-Nummer verstehen. Sonst geht auch SetExtensions nicht (on-for-timer usw.).

[the ratman]

natürli no schöner, und funzt. eventmap is auch geschichte.

dank dir!

[the ratman]

so, nun hab ich das erste device mit blu sensoren übernommen - ich hätte warscheinlich noch a 3. mal fragen sollen ... wie komm ich an miene blu devices, weil die sind weg?

[Guybrush]

mit dem nächsten update von mqtt2_discovery werden die auch behandelt. das schaff ich vielleicht morgen zu publishen

[the ratman]

tu ned hetzten - habs backup zurück, die pflanzenlampen schalten wieder, die sensoren sensoren wieder, die taster tasten wieder.
ich glaub aber, wir müssen no an unserer kommunikation arbeiten. dachte, das is kein thema, nachdem du dazu nix gesagt hast.

sind dann übrigens alle blu drinnen?
bisher hab ich zumindest mal blu ht, blu wallswitch4, blu door/window davon meistens mehrere und ein paar auch in der neueren zigbee version (aber das dürfte ja ned wirklich stören)

[Beta-User]

und darf i no a frage stellen, wegen der mqtt templates?

wie ist das eigentlich aufgebaut? bisher war ich der meinung, es kommt halt irgendein neues device von shelly raus, jemand schreibt ein template dafür und stellts zur verfügung. denke, das ist falsch?
wonach geht das bei shelly? generationen, firmware, ...? sprich: wie erkenne ich, welches template ich für was verwenden kann?

MQTT Templates sind jedenfalls nur ein Behelf, weil FHEM bislang kein natives Discovery hatte.

Vielleicht noch ein paar Anmerkungen dazu, nachdem ich jetzt eine richtige Tastatur benutzen kann:

Man kann die Sammlung in attrTemplate als "Behelf" abtun, aber zum einen ist das entstanden, als viele gängige Gadgets auch noch kein "discovery" kannten, und zum anderen folgen diese "Vorlagen", oder vielleicht besser als Gestaltungsvorschläge zu bezeichnete Sammlung, einer gewissen Logik, die v.a. auch darin besteht, "workarounds" für typische Probleme anzubieten, die eben mit den Gadgets verbunden sind.

Das beginnt bei "Kleinigkeiten", wie eben der Präferenz von "split"-Templates, bei denen jeder Kanal als eigene MQTT2_DEVICE-Instanz repräsentiert wird, damit man je einen eigenen "on" und "off"-setter erhält.

Entstanden ist es als kurratierte Sammlung, zu der im Prinzip jeder beitragen konnte, der wollte. Von daher hat recht häufig jemand einen Vorschlag gemacht (oder auch nur ein fertig konfiguriertes Device gezeigt), aus dem dann unter Beachtung der oben kurz angerissenen Designvorgaben dann eben ein template wurde, das im Ergebnis eine gewisse "Einheitlichkeit" im look&feel mit anderen Devices mit ähnlicher Funktionalität erreicht werden kann.
Nicht alles ist "gut" oder entspricht meinem ganz persönlichen Geschmack, aber jeder kann das Ergebnis ändern, wie er mag und sollte erst mal eine funktionale Ausgangsbasis haben.

Da ich als "Kurator" weder in der Lage bin, alle bekannten Gadgets je mit einem 1:1 passenden template zu versehen, und das auch nicht sinnvoll ist, sind die in der Regel so organisiert, dass man erst mal innerhalb der Familie (z.B. Shelly "alt" oder "rpc") sieht, welche Auswahl da ist, und sich dann das funktional am nächsten liegende (anhand der Beschreibung oder der "Kommandos") aussuchen muss oder kann. Wenn man also eine Bulb hat, kann es sein, dass für sowas schon was da ist (vielleicht mit Farbe, aber ohne cct), in der Regel paßt zumindest der "plug" auch für ein dimmbares Licht (dann halt nur on/off).

Mein Wunsch an "MQTT2_DISCOVERY" wäre, dass Klarheit über die zu erzielenden Design-Vorgaben herrscht. Von daher fand ich den Ansatz von Martin gut, es durch "ergänzende Angaben" zu ermöglichen, dass ggf. auch mehrere "channels" angelegt werden. Zumindest für "häufige Devices" (wie Tasmota-basiert oder Shelly, vielleicht auch zigbee2mqtt) dürfte es möglich sein, das zu leisten. 

Falls Fragen zu den Design-Vorgaben (aus der "alten Welt") an sich bestehen sollten, gebe ich gerne meinen Senf dazu, wenn ich an einer Tastatur sitze dann ggf. auch mit etwas weniger kurzen Fassungen wie "eventMap ist unselig".

[Guybrush]

wie meinst du das denn mit mehreren channels? MQTT2_DISCOVERY legt bereits alle an, die ein device hat. Ich bin da aber auch total offen für konstruktive Vorschläge!

Im Unterbau hab ich z.b. schon eine semantic map drin. Damit kann man dann auch automatisiert visualisierungen umsetzen. das hab ich bei mir lokal schon seit längerem laufen und ist ganz cool geworden. Das ist im prinzip FTUI3 und lässt sich entsprechend anpassen, aber man hat dann halt für jedes device schon ein passendes template, wo man nur noch mit css ran muss (wenn gewünscht). Das ist quasi ein HA Frontend für Fhem. Die Semantic Map lässt sich aber auch für anders gut nutzen. Ist jedenfalls ein nettes Ding, wenn jedes reading "weiß", ob es ne Temperatur darstellt oder einen Zustand.