mqtt2.template: bugs, Fragen, Anregungen

[Fabiango]

Neuer Thread ist dazu geöffnet
https://forum.fhem.de/index.php?topic=138681.0

[Homalix99]

Hallo,

habe heute shelly PM mini in Generation 3 erhalten.
Wäre dafür ein eigenes Template angebracht, bzw. gibt es da schon was?

Gruß

Alex

[Beta-User]

Wäre dafür ein eigenes Template angebracht, bzw. gibt es da schon was?

Vielleicht versuchst du mal, ob ein bestehendes paßt, und ab hier gäbe es auch "Spaß" zu dem Thema: https://forum.fhem.de/index.php?msg=1322586

[plin]

Mein Template wled_controller zeigt mir zwar die Effekte als Namensliste an, ein set xxx efectname xyz zeigt aber keine Wirkung.

set xxx effect/effect_next/effect_prev/effect_random funktionieren.

[Beta-User]

Mein Template wled_controller zeigt mir zwar die Effekte als Namensliste an, ein set xxx efectname xyz zeigt aber keine Wirkung.

set xxx effect/effect_next/effect_prev/effect_random funktionieren.

Moin, die Frage dürfte bei den WLED-Usern besser aufgehoben sein wie hier.
Über https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L5434 geht es nach https://forum.fhem.de/index.php?topic=98880.0...

[kennymc.c]

Zigbee2MQTT plant wohl bald ein 2.0 Update mit dem die Unterstützung für die Legacy API entfernt werden soll (https://github.com/Koenkk/zigbee2mqtt/discussions/24198). So wie es aussieht scheinen die zigbee2mqtt Templates noch diese veralteten Topics zu verwenden wie z.B. /log, /bind|unbind, /ota_update, /device und /request. Ist da ein Update in Planung?

[Beta-User]

Ist da ein Update in Planung

Öhm, bin zwar jüngst auf z2m gewechselt (und störe mich an den vielen "unnötigen" Topics, aber das ist bisher an mir vorbeigegangen...

Vorschläge für Updates sind immer willkommen, sonst folgt halt ggf. irgendwann ein update, wenn es mir selbst zu bunt wird oder der update eingespielt .

Wir sollten dazu ggf. mal einen neuen Thread aufmachen.

[kennymc.c]

Die 2.0 soll es ab morgen im dev Branch zum Testen geben und ab dem 3. Januar ist der reguläre Release geplant

[kabanett]

Hallo,
ich musste einen Shelly 2.5 neue Kondensatoren spendieren und nach dem Reset, neu als Roller in fhem anbinden.
Warum auch immer, wurde das Template: shelly25_roller_invert_0 verschlimmbessert.

Könnte man das Atrribut devStateIcon wieder in die alte Version zurück versetzen?

Code Auswählen Erweitern

.*/opens:fts_shutter_up@red .*/closes:fts_shutter_down@red true:10px-kreis-gruen false:10px-kreis-rot 0/stop:fts_shutter_100 100/stop:fts_shutter_10 9\d/stop:fts_shutter_10 8\d/stop:fts_shutter_20 7\d/stop:fts_shutter_30 6\d/stop:fts_shutter_40 5\d/stop:fts_shutter_50 4\d/stop:fts_shutter_60 3\d/stop:fts_shutter_70 2\d/stop:fts_shutter_80 1\d/stop:fts_shutter_90 0\d/stop:fts_shutter_100 set_.*:fts_shutter_updown
statt
.*/open:fts_shutter_up@red .*/close:fts_shutter_down@red true:10px-kreis-gruen false:10px-kreis-rot 0/stop:fts_shutter_100 100/stop:fts_shutter_10 9\d/stop:fts_shutter_10 8\d/stop:fts_shutter_20 7\d/stop:fts_shutter_30 6\d/stop:fts_shutter_40 5\d/stop:fts_shutter_50 4\d/stop:fts_shutter_60 3\d/stop:fts_shutter_70 2\d/stop:fts_shutter_80 1\d/stop:fts_shutter_90 0\d/stop:fts_shutter_100 set_.*:fts_shutter_updown
Dann funktioniert auch die Anzeige während der Fahrt wieder.

Danke und Gruß

[alkazaa]

Eine Anregung:
Das Attribut 'autocreate' eines MQTT2_DEVICE steuert das Erweitern/Nicht-Erweitern der readingList eines vorhandenen MQTT2_DEVICE.
Standardmäßig ist es auf 1, was u.U. unnötig viele readings erzeugen kann, z.B. bei Shelly device, wenn man in deren Web-GUI 'rumkonfiguriert'.

Das kann man mit autocreate=0 zwar verhindern, aber man möchte vielleicht trotzdem sehen, was angelegt worden wäre.

Mein Vorschlag: das MQTT2_DEVICE autocreate bekommt drei Zustände on, off, inform.  Bei 'inform' schreibt es z.B. Log-Einträge o.ä. über die möglicherweise verpassten readings (bzw. der entsprechenden nicht vorgenommenen readingList Erweiterung)

[Beta-User]

Moin.

Mein Vorschlag: das MQTT2_DEVICE autocreate bekommt drei Zustände

Das hat nicht originär was mit attrTemplate zu tun, sondern eher mit MQTT2_DEVICE allgemein und wäre von daher ggf. in einem eigenen Thread besser aufgehoben.

Meine 2ct: Das braucht man nicht.

Vielleicht wäre es gut, bei viel mehr templates autocreate auf 0 zu setzen, aber prinzipiell gibt es mehr/andere Optionen, um zu sehen, was stattgefunden hätte. Mir fällt spontan ein:
- "Show MQTT traffic" am IO anschalten, regex auf dieses Device begrenzen und dann einfach den Verkehr in Ruhe (ggf. mit einer Kopie) analysieren. Das gleiche geht ggf. mit Tools wie "mosquitto_sub".
- Testsystem oder "Paralleldevice" (gleiche ClientID) bemühen. Das muss man weder loggen noch irgenwie bedienen können, aber man kann sehen, wie insbesondere JSON ausgepackt würden wäre und mit den verschiedenen Spielarten von json2nameValue() rumspielen...
Oder man loggt damit grade sowas wie topic/value (siehe dazu auch im Wiki die "Schritt für Schritt-Seite").