MQTT2+Shelly: erste Konfiguration und template-Entwicklung

[rudolfkoenig]

Mein Plan ist, dass das Framework (FHEMWEB) auf beides reagiert.
Ich habe aus diesem Grund in images/openautomation/iconalias.txt ON und OFF eingetragen, d.h. diese werden schon passend angezeigt, was noch fehlt ist das kuenstlich erzeugte toggle, d.h. wenn man auf dem Symbol klickt ON als on zu erkennen und OFF zu senden, und kein off. Ist etwas mehr als ein einzeiler, und ich habe noch nicht die Gelegenheit gehabt es anzugehen.

[Beta-User]

@Rudi: Danke für die Rückmeldung, schön, dass das Thema insgesamt auf dem Radar ist. Eilt nicht, solange es irgedwie konkret am Ende gelöst wird .

@gvzdus:
Danke für die Infos und den screenshot von "nebenan", sind schon im Wiki zu finden .

@all:
- Im Wiki würden sich m.E. noch Shelly2 als Beispiele gut machen: Würde das dann im Gesamtkontext vor Tasmota darstellen (da Original-Hersteller-firmware) und drei Arten vorstellen wollen, wie man das Teil mit attrTemplate konfiguriert: Einheitsdevice mit 2 Kanälen, gesplittet je Kanal und Roller-Mode.
Das ist m.E. dann hinreichend, um die Möglichkeiten prototypisch darzustellen, Darstellung im Grunde ähnlich wie bei der shellybulb.

- (Voraussichtlich) am WE werde ich dann mal erste Gehversuche mit svn machen, Zugang wurde erteilt...

Schönen Tag allseits,

Beta-User

[osr]

Mein Plan ist, dass das Framework (FHEMWEB) auf beides reagiert.
Ich habe aus diesem Grund in images/openautomation/iconalias.txt ON und OFF eingetragen, d.h. diese werden schon passend angezeigt, was noch fehlt ist das kuenstlich erzeugte toggle, d.h. wenn man auf dem Symbol klickt ON als on zu erkennen und OFF zu senden, und kein off. Ist etwas mehr als ein einzeiler, und ich habe noch nicht die Gelegenheit gehabt es anzugehen.

Also für Tasmota (wo ja toggle nicht künstlich erzeugt werden muss weil die Geräte das ja machen) ist es vollkommen egal ob mit einem cmd/... on ON off OFF toggle oder TOGGLE oder Kombinationen gesendet werden. Was macht Shelly mit Originalfirmware? Gibt es dazu Infos?

Kurz ein Gedanke: Sowas in der Form wie unten  taucht im MQTT-Kontext ständig auf. Wäre es nicht einfacher, direkt über das Modul lowercase für (ON|OFF|On|Off) zu verwenden, sobald irgend ein Reading (incl. state) (von extern, also idR. vom Gerät kommend) auf genau einen der Werte gesetzt werden soll?

Ja das würde die Sache vereinheitlichen, sofern das nicht irgendwelche negativen Auswirkungen im Code hat. Aber eventMap sind dafür überall wirklich nicht schön. Gut wäre es wenn aber auch TOGGLE in toggle dann umgesetzt würde. Auch das kann von einem Switch/Button gesendet werden.

[Beta-User]

Auch hier die kurze Info:

habe das template-file eben etwas überarbeitet. Gebt doch bitte nach einem update heute Rückmeldung, ob/wie euch das gefällt.

Ankündigung: Es kommt  bei Gelegenheit insgesamt ein neuer Thread dazu, sonst ist die Diskussion ggf. zu sehr verteilt hier, sonstwo und zigbee), habe aber leider grade nicht mehr die Zeit und Ruhe dazu. Aber die bisher Beteiligten dürfen/sollen selbstredend vorläufig auch noch hier...

[dkreutz]

Hier dann noch ein Vorschlag für ein ShellyPlug-Template - der hat einen Kanal mit Strommessung, also quasi ein halber Shelly2. Ich habe das Shelly2-Template genommen und den copy-Teil für den zweiten Kanal weggelassen:

Code Auswählen Erweitern


# shellyplug using original firmware.
name:shellyplug
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;ShellyPlug name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on
attr DEVICE readingList shellies/DEVNAME/relay/0:.* state
attr DEVICE getList shellies/DEVNAME/relay/power power


[osr]

Hatte in der letzten Version die 3 templates nochmal komplett gepostet. Die scheinen aber noch nicht im Repository zu sein.

Bitte beachten, das <> sollte eigentlich ein < dann / dann div dann > sein aber das macht die Forumsoftware immer weg.

In der letzten Version hatte ich auch autocreate 0 an den Anfang und deleteReading an den Schluss gesetzt, so dass da nicht irgendwas dazwischen passieren kann.

Das einzige was noch hinzu muss ist

Code Auswählen Erweitern


attr DEVICE eventMap { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }


Dann sollte das passen auch für Standard-Tasmotas

[Beta-User]

Hallo zusammen,

habe eben ein update ins svn geschoben und hoffe, den gesamten input von heute einigermaßen verarbeitet zu haben.

ACHTUNG: es sind die ersten desc:-Anweisungen drin, vermutlich wird daher auch ein update vom attrTemplate-Modul benötigt! (laden lies sich das auch so, aber wesentlich mehr habe ich nicht getestet!) Am besten daher einfach die Auszüge ohne die desc-Anweisungen verwenden, wenn jemand vor dem update von morgen noch was machen will).

Kurzfassung:- shellyplug dazugefügt (DANKE!)
- dto. für den tasmota+motion+si7021 (hatte ich irgendwann gedacht drin zu haben, die anderen sollten eigentlich schon drin gewesen sein, allerdings ggf. unter etwas anderem Namen und s.u.)

Bei den tasmota-Sachen stand im Topic noch DEVICE drin. Das war in jedem Fall nicht richtig (siehe https://forum.fhem.de/index.php/topic,94434.msg871955.html#msg871955), ich habe daher eine ungetestete Variante der shelly-DEVNAME-Extraktion versucht. Bitte um Rückmeldung!

Ansonsten ist das interne Weiterverweisen ausgeweitet. So wird jetzt bei allen Tasmotas das 09x-template vorab durchlaufen, was z.B. dann generell auch die "vermissten"

Code Auswählen Erweitern

deleteReading DEVICE .*
attr DEVICE autocreate 0und die Basis-readingList setzt.
Wenn dann was "vorläufig falsch" ist, wird einfach die nächste gleichnamige Anweisung drübergebügelt, nach dem Motto: last beats all.

Das macht es erst mal etwas unübersichtlicher (wenn das über 2 oder 3 Stufen läuft), die Ergebnisse aber hoffentlich in sich konsistent und leichter zu pflegen.

@Rudi: habe das nicht getestet, gehe aber davon aus, dass die Parameter (par:) nur jeweils innerhalb eines template verfügbar sind, also auf jeder Stufe neu ermittelt werden müssen?

Großes Danke an alle geduldigen Tester, seht mir nach, dass ich mich grad nicht noch in die Tasmota-firmware einarbeiten will, um das vorab alles nachzuvollziehen!

[Beta-User]

Kurze Frage noch: Ist das getList aus den shellys wirklich so korrekt?

Code Auswählen Erweitern


attr DEVICE getList shellies/DEVNAME/relay/power power

Nach meinen (bisher nicht erfolgreichen) Versuchen mit der get-Funktion müßte es eher so sein :

Code Auswählen Erweitern

attr DEVICE getList power shellies/DEVNAME/relay/power

[miggun]

Es funktioniert so auf jeden Fall.
Hier mal die funktionierende Leistungserfassung der Küchenbeleuchtung Shelly2:

Code Auswählen Erweitern

defmod Kueche_Licht_Leistung MQTT2_DEVICE shellyswitch-32B268
attr Kueche_Licht_Leistung IODev MQTT2_SERVER
attr Kueche_Licht_Leistung getList shellies/shellyswitch-32B268/relay/power power
attr Kueche_Licht_Leistung readingList shellyswitch_32B268:shellies/shellyswitch-32B268/relay/power:.* power
attr Kueche_Licht_Leistung room 01_Küche,MQTT2_DEVICE,Messwerte
attr Kueche_Licht_Leistung stateFormat power

[Beta-User]

Danke für die Rückmeldung.

Ist aber in der Darstellung komisch, ich bekomme da ein dropDown-Feld mit dem topic-String?!?

Hätte eher gedacht, dass es aussehen sollte wie das hier:

Code Auswählen Erweitern

attr Kueche_Licht_Leistung getList power:noArg shellies/shellyswitch-32B268/relay/power power


Kannst das ja mal so ändern, dann verstehst du, was ich von der optischen Seite her meine.

Aber jetzt ist bei mir der Groschen gefallen, Danke!

@Rudi:
Hilfe...
Jetzt weiß ich zwar, wie ich einen get-Befehl für zigbee2mqtt zusammenbauen muß, aber a) sieht es besch... aus und b) habe ich keine Ahnung, was ich für "Reading" hinten reinschreiben soll, wenn da ein json zurückkommt. log, log.* habe ich versucht (so beginnen alle Readings, die dadurch angelegt werden) .

Schön wäre es, wenn wir das wie setList bauen könnten mit $EVENT etc. und einem eindeutigen Trenner (oder Klammerung), der das Topic vom Sendeinhalt und dem Reading (-Array) abgrenzt. Den Topic braucht in der Anzeige in FHEMWEB keiner...

[Beta-User]

So.
Eben noch etwas mit den neuen desc-Optionen rumgespielt, daher gabs nochmal ein update im svn. Wer testen will, sollte diese Version nutzen, ist einfach schöner ...

Da man mit <br> auch mehrzeilige Beschreibungen generieren kann, fände ich es am wenigsten fehleranfällig, zukünftig den Status (Experimentell, testing...) in die Beschreibung mit unterzubringen; dto. für konkrete Geräte, firmwareversionen etc.. Das verhindert, dass durch die Änderung eines Namens Weiterleitungen zu Bruch gehen können und macht updates für getestete Geräte einfacher.

@Rudi:
Da ist noch eine Anregung mit drin, so eine Art Einleitung zuzulassen (name:<filename>). Habe keine Ahnung, ob das viel Aufwand wäre und über mehrere Dateien funktioniert, könnte aber hilfreich sein, um weitere Info anzuzeigen. Geht aber auch so...

[rudolfkoenig]

Schön wäre es, wenn wir das wie setList bauen könnten mit $EVENT etc. und einem eindeutigen Trenner (oder Klammerung), der das Topic vom Sendeinhalt und dem Reading (-Array) abgrenzt.

Kannst du mir bitte einen konkreten Beispiel nennen, indem du die raw Daten (gesendet+empfangen) hier anhaenst, und das was du im Dialog sehen willst.

Da ist noch eine Anregung mit drin, so eine Art Einleitung zuzulassen (name:<filename>)

Damit sehe ich zwei Probleme:
- ich will diese Hilfe nicht zu wiki/commandref Ersatz verkommen lassen. Es waere sinnvoller einen attrTemplate Abschnitt in der MQTT2_DEVICE Commandref-Abschnitt einzufuegen, was dann beim Auswahl von attrTemplate eingeblendet wird. Ich will das Einblenden auf etwas dezenteres umbauen, als das aktuell der Fall ist.
- fuer ein Geraet koennen/werden attrTemplate Eintraege aus mehreren .template Dateien (fuer FHEMWEB, alexa, etc, alles noch TODO) zusammengemischt, da wuerde eine "MQTT2-Einfuehrung" verwirren.

[rudolfkoenig]

habe das nicht getestet, gehe aber davon aus, dass die Parameter (par:) nur jeweils innerhalb eines template verfügbar sind, also auf jeder Stufe neu ermittelt werden müssen?

Ja. Ein Template faengt mit einer name: Zeile an. Ausnahme ist die letzte vor dem name: befindliche Kommentarzeile, falls kein desc: vorhanden ist.

[Beta-User]

Moin Rudi,

vorab: magst du diesen Thread anpinnen?

Der Vorschlag, die MQTT2-DEVICE-cref zu nutzen, gefällt mir, bei Gelegenheit kommt da dann ein Vorschlag.

Was getList angeht:
Die rawEvents finden sich in der beigefügten file.
list vom Bridge-Device:

Code Auswählen Erweitern

defmod MQTT2_zigbee_pi MQTT2_DEVICE zigbee_pi
attr MQTT2_zigbee_pi IODev MQTT2_FHEM_Server
attr MQTT2_zigbee_pi bridgeRegexp zigbee_pi:zigbee2mqtt/(0x[A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"
attr MQTT2_zigbee_pi getList zigbee_pi:zigbee2mqtt/bridge/config/devices message_.*
attr MQTT2_zigbee_pi readingList zigbee_pi:zigbee2mqtt/bridge/log:.* { json2nameValue($EVENT) }\
  zigbee_pi:zigbee2mqtt/bridge/state:.* state
attr MQTT2_zigbee_pi room MQTT2_DEVICE
attr MQTT2_zigbee_pi setList permit_join:true,false zigbee_pi:zigbee2mqtt/bridge/config/permit_join $EVTPART1\
  remove:textField zigbee_pi:zigbee2mqtt/bridge/config/remove $EVTPART1\
  log_level:debug,info,warn,error zigbee_pi:zigbee2mqtt/bridge/config/log_level $EVTPART1\
  rename:textField zigbee_pi:zigbee2mqtt/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}\
  network_map:raw,graphviz zigbee_pi:zigbee2mqtt/bridge/networkmap  $EVTPART1\
  devicelist:noArg zigbee_pi:zigbee2mqtt/bridge/config/devices

setstate MQTT2_zigbee_pi network_map
setstate MQTT2_zigbee_pi 2018-12-15 11:58:59 message device incoming
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_1_friendly_name 0x90fd9ffffe65db16
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_1_ieeeAddr 0x90fd9ffffe65db16
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_1_model LED1650R5
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_1_type Router
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_2_friendly_name 0x90fd9ffffe0bcd51
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_2_ieeeAddr 0x90fd9ffffe0bcd51
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_2_model LED1650R5
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_2_type Router
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_3_friendly_name 0x90fd9ffffefe2b91
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_3_ieeeAddr 0x90fd9ffffefe2b91
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_3_model TRADFRI remote control
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_3_type EndDevice
setstate MQTT2_zigbee_pi 2018-12-15 11:52:49 state network_map
setstate MQTT2_zigbee_pi 2018-12-15 11:58:59 type pairing

Die getList funktioniert weitgehend so wie im list dargestellt, wobei ich eben mit diversen Varianten (der Reading-Angabe rumgespielt hatte: log, log_.*, message, message_.*), aber immer die timeout-message erhalte. Gehe davon aus, dass das entweder ist, weil die Antwort auf einem anderen Topic kommt oder eben wg. des JSON-Formats.

Von der Darstellung her wäre mir das so lieber, wie es bei "set" ist.
Folgendes sieht m.E. stringent aus (in FHEMWEB):

Code Auswählen Erweitern

attr MQTT2_zigbee_pi getList network_map:raw,graphviz zigbee_pi:zigbee2mqtt/bridge/networkmap  $EVTPART1 $EVTPART1\
  devicelist:noArg zigbee_pi:zigbee2mqtt/bridge/config/devices log

(2*$EVTPART1, da einmal zu versenden, einmal reading, auf das gewartet wird)
Damit wäre auch als normaler FHEM-Befehl (vom Aufbau her, über den Effekt mag man streiten) sinnig: "get MQTT2_zigbee_pi networkmap raw".

Im Dialogfeld wäre dann super, wenn untereinander alle sich aus dem JSON ergebenden Readings (sortiert) gelistet würden (hier: message_.*); auf das "message_" könnte man dabei verzichten (v.a., wenn das anders die Kompabilität mit normalen Strings bricht).

Hoffe, das ist so nachvollziehbar?

[miggun]

Danke für die Rückmeldung.

Ist aber in der Darstellung komisch, ich bekomme da ein dropDown-Feld mit dem topic-String?!?

Hätte eher gedacht, dass es aussehen sollte wie das hier:

Code Auswählen Erweitern

attr Kueche_Licht_Leistung getList power:noArg shellies/shellyswitch-32B268/relay/power power


Kannst das ja mal so ändern, dann verstehst du, was ich von der optischen Seite her meine.

Aber jetzt ist bei mir der Groschen gefallen, Danke!

Wenn ich ehrlich bin fällt mir gerade kein Unterschied zwischen den beiden Varianten auf. Worauf muss ich achten?
Das war ja der alte:

Code Auswählen Erweitern

attr Kueche_Licht_Leistung getList shellies/shellyswitch-32B268/relay/power power

Jetzt habe ich Deinen drin:

Code Auswählen Erweitern

attr Kueche_Licht_Leistung getList power:noArg shellies/shellyswitch-32B268/relay/power power