MQTT2+Shelly: erste Konfiguration und template-Entwicklung

[Beta-User]

Kommt denn auf die zweite Variante eine vernünftige Antwort, wenn du das set nutzt?
Sehen beide Varianten in FHEMWEB gleich aus? (bei mir mit den Modulversionen von gestern eindeutig nicht).

Wenn dieselbe Antwort kommt, würde ich die templates direkt so umbauen! Im Moment besteht sonst das Risiko, dass das demnächst in der bisherigen Form nicht mehr funktioniert...

[miggun]

Kommt denn auf die zweite Variante eine vernünftige Antwort, wenn du das set nutzt?
Sehen beide Varianten in FHEMWEB gleich aus? (bei mir mit den Modulversionen von gestern eindeutig nicht).

Wenn dieselbe Antwort kommt, würde ich die templates direkt so umbauen! Im Moment besteht sonst das Risiko, dass das demnächst in der bisherigen Form nicht mehr funktioniert...

Beide genau gleich.
Aber ich kann nur das Ergebnis beurteilen. Von der Programmierung habe ich ja so gut wie keine Ahnung.
Da beides gleiche Ergebnisse liefert, dass nehmen, was programmiertechnisch safe ist.

[Beta-User]

THX, Korrektur ist im svn .

Bitte um Prüfung&Rückmeldung, möglichst für alle shelly-Varianten.

[OdfFhem]

@Beta-User

Ich habe heute die Gelegenheit genutzt, ein wenig mit getList,setList,readingList sowie bridgeRegexp,readingList zu experimentieren.

Bis jetzt hat sich dabei folgende attr-Festlegung ergeben:

Code Auswählen Erweitern


attr MQTT2_myMqttClient bridgeRegexp\
zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"
attr MQTT2_myMqttClient getList\
devicelist:noArg log zigbee2mqtt/bridge/config/devices\
networkmap:graphviz,raw networkmap_result zigbee2mqtt/bridge/networkmap $EVTPART1
attr MQTT2_myMqttClient readingList\
zigbee2mqtt/bridge/state:.* state\
zigbee2mqtt/bridge/config/devices:.* {}\
zigbee2mqtt/bridge/config/log_level:.* log_level\
zigbee2mqtt/bridge/config/permit_join:.* permit_join\
zigbee2mqtt/bridge/config/rename:.* { json2nameValue($EVENT, 'rename_') }\
zigbee2mqtt/bridge/log:.* log\
zigbee2mqtt/bridge/networkmap:.* {}\
zigbee2mqtt/bridge/networkmap/graphviz:.* networkmap_result\
zigbee2mqtt/bridge/networkmap/raw:.* networkmap_result
attr MQTT2_myMqttClient setList\
log_level:debug,info,warn,error zigbee2mqtt/bridge/config/log_level $EVTPART1\
permit_join:true,false zigbee2mqtt/bridge/config/permit_join $EVTPART1\
remove:textField zigbee2mqtt/bridge/config/remove $EVTPART1\
rename:textField zigbee2mqtt/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}\
devicelist:noArg zigbee2mqtt/bridge/config/devices\
networkmap:graphviz,raw zigbee2mqtt/bridge/networkmap $EVTPART1


• MQTT2_myMqttClient ist das MQTT2_DEVICE, das automatisch bei der Definition vom MQTT2_CLIENT als "zentrales Auffangbecken" mitangelegt wird.
• devicelist und networkmap sind zu experimentellen Zwecken sowohl in getList als auch in setList hinterlegt. Beide Befehle funktionieren als set sowie auch als get und liefern dabei idente Ergebnisse.
• Derzeit zerlege ich das Ergebnis der Befehle aber nicht in einzelne Readings (wird bei einer größeren Anzahl von Geräten sehr schnell unübersichtlich), sondern stelle die komplette Antwort jeweils als ein Reading bereit. Schön wäre, wenn getList ein paar "gängige" Darstellungsformate für die Anzeige bereitstellen würde (json,raw,...).
• $EVTPART1 hatte ich bei networkmap auch mal als Platzhalter für das anzugebende Reading verwendet; dies wird an dieser Stelle aber scheinbar nicht aufgelöst und führte folglich auch nicht zum gewünschten Ergebnis. Daher habe ich die beiden Antwortkanäle in ein Reading umgeleitet, das dann als Antwort-Reading verwendet wird.
• graphviz liefert derzeit kein (sinnvoll) darstellbares Ergebnis zurück. Im Zusammenspiel mit mosquitto_[pub/sub] schaffe ich es auf prompt-Ebene, eine Grafik des aktuellen ZigBee-Netzes zu erstellen. Aus FHEM heraus und ohne mosquitto_[pub/sub] ist mir das bisher noch nicht gelungen ...

• Bzgl. autocreate von MQTT2_DEVICEs ist mir bei meinen Tests aufgefallen, dass readingList vorrangig ausgewertet wird - soll heißen: passt ein Ausdruck aus readingList, wird der bridgeRegexp nicht mehr angewendet.
• Folgerichtig kann ich in der oben dargestellten Definition in bridgeRegexp den ganz allgemeinen regulären Ausdruck (kein 0x notwendig und sogar friendly_names sind nicht tabu) verwenden und durch die passende Definition der readingList wird kein separates bridge-MQTT2_DEVICE zusätzlich angelegt.
• Sollte ein bridge-Topic auflaufen, das noch nicht über die readingList aufgefangen wird, würde natürlich weiterhin ein neues bridge-MQTT2_DEVICE angelegt, das dann nur dieses bislang unbekannte bridge-Topic enthält. In diesem Fall müsste man die ursprüngliche readingList entsprechend anpassen und anschließend das nicht gewollte bridge-MQTT2_DEVICE kurzerhand wieder löschen.
• Die readingList sollte schon recht vollständig sein. Wahrscheinlich fehlt aber noch ein Ausdruck für das remove-Topic - einen Löschvorgang musste ich bislang noch nicht durchführen ...
• Ob ein separates bridge-MQTT2_DEVICE angelegt wird oder nicht, könnte man also wahrscheinlich allein über die Definition einer entsprechenden readingList steuern; der Rest eines zigbee2mqtt-bridge-Templates könnte damit vermutlich vollständig allgemein gehalten werden.

[miggun]

Es gab ein Update von Shelly, jetzt wird energy nicht mehr gemeldet. Weder beim Shelly4Pro noch beim Shelly2. Der Rest funktioniert wie vorher.

Wobei nicht ganz wie vorher, jetzt sendet auch der Shelly4Pro stetig seinen Status, auch wenn kein Ausgang aktiv ist.

[miggun]

So, hier wie versprochen erst mal die Internals vom shelly2 im Roller-Mode:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CID        shellyswitch_32BD01
   DEF        shellyswitch_32BD01
   DEVICETOPIC MQTT2_shellyswitch_32__01
   IODev      MQTT2_SERVER
   LASTInputDev MQTT2_SERVER
   MQTT2_SERVER_MSGCNT 166
   MQTT2_SERVER_TIME 2019-01-10 22:16:46
   MSGCNT     166
   NAME       Lea_Rollladen
   NR         1785
   STATE      ???
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-01-10 21:56:46   announce_fw_ver 20190103-091640/v1.4.4@165d718b
     2019-01-10 21:56:46   announce_id     shellyswitch-32BD01
     2019-01-10 21:56:46   announce_ip     192.168.1.2
     2019-01-10 21:56:46   announce_mac    86F3EB32B
     2019-01-10 21:56:46   announce_new_fw false
     2019-01-10 21:56:46   online          true
     2019-01-10 22:16:46   pos             100
     2019-01-10 22:16:46   power           0.00
     2019-01-10 22:16:46   shellies/shellyswitch-32BD01/roller/0 stop
Attributes:
   IODev      MQTT2_SERVER
   readingList shellyswitch_32BD01:shellies/shellyswitch-32BD01/online:.* online
shellyswitch_32BD01:shellies/announce:.* { json2nameValue($EVENT, 'announce_') }
shellyswitch_32BD01:shellies/shellyswitch-32BD01/roller/0:.* shellies/shellyswitch-32BD01/roller/0
shellyswitch_32BD01:shellies/shellyswitch-32BD01/roller/0/pos:.* pos
shellyswitch_32BD01:shellies/shellyswitch-32BD01/relay/power:.* power
   room       MQTT2_DEVICE

Event monitor

Code Auswählen Erweitern

2019-01-10 22:34:39 MQTT2_DEVICE Lea_Rollladen shellies/shellyswitch-32BD01/roller/0: open
2019-01-10 22:34:39 MQTT2_DEVICE Lea_Rollladen power: 1.28
2019-01-10 22:34:40 MQTT2_DEVICE Lea_Rollladen shellies/shellyswitch-32BD01/roller/0: stop
2019-01-10 22:34:40 MQTT2_DEVICE Lea_Rollladen power: 0.00
2019-01-10 22:34:41 MQTT2_DEVICE Lea_Rollladen shellies/shellyswitch-32BD01/roller/0: close
2019-01-10 22:34:41 MQTT2_DEVICE Lea_Rollladen power: 1.08
2019-01-10 22:34:42 MQTT2_DEVICE Lea_Licht off
2019-01-10 22:34:42 MQTT2_DEVICE Lea_Licht shellies/shelly1-12B9BD/relay/0: off
2019-01-10 22:34:43 MQTT2_DEVICE Lea_Rollladen pos: 0
2019-01-10 22:34:43 MQTT2_DEVICE Lea_Rollladen shellies/shellyswitch-32BD01/roller/0: stop
2019-01-10 22:34:43 MQTT2_DEVICE Lea_Rollladen power: 0.00

[Beta-User]

Moin,
wenn du magst und nach gestern vormittag ein update gemacht hast, kannst du Rückmeldung geben, wie dir das von torte hier vorgeschlagene (und bereits via svn verteilte) template gefällt .

Einen ht hatte ich auch dazugepackt (ergänzt aber "nur" ein devStateIcon).

Fehlt eigentlich nur noch der 4-er als Einheitsdevice (wer das braucht, kann sich aber auch in den beiden tasmota-templates bedienen) .

Oder gibt es zwischenzeitlich weitere shellys?

[LudgerR]

Hallo,

Habe gerade meinen zweiten shelly1 für mqtt aktiviert und diesmal das vorgefertigte Template für shelly1 benutzt. Dabei ist mir aufgefallen das ein Reading für ../relay/0  zunächst erstellt, später jedoch nicht mehr abgedated wird.
Deswegen habe ich bei mir die readingList um

shelly1_2BE282:shellies/shelly1-2BE282/relay/0:.* shellies/shelly1-2BE282/relay/0

ergänzt.

Fhem hatte ich gestern noch per ,,update" aktualisiert.

Folgend die automatisch erstellte Config meines Shellys, die ich bis auf die o.g. Änderung nur um
event-on-change-reading  ergänzt habe.

Code Auswählen Erweitern


defmod MQTT2_shelly1_2BE282 MQTT2_DEVICE shelly1_2BE282
attr MQTT2_shelly1_2BE282 IODev MQTT2_FHEM_Server
attr MQTT2_shelly1_2BE282 event-on-change-reading .*
attr MQTT2_shelly1_2BE282 model A_10_shelly1
attr MQTT2_shelly1_2BE282 readingList shellies/shelly1-2BE282/relay/0:.* state\
shelly1_2BE282:shellies/shelly1-2BE282/input/0:.* shellies/shelly1-2BE282/input/0\
shelly1_2BE282:shellies/shelly1-2BE282/relay/0:.* shellies/shelly1-2BE282/relay/0\
shelly1_2BE282:shellies/shelly1-2BE282/online:.* online\
shelly1_2BE282:shellies/announce:.* { json2nameValue($EVENT, 'announce_', $JSONMAP) }
attr MQTT2_shelly1_2BE282 room MQTT2_DEVICE
attr MQTT2_shelly1_2BE282 setList off:noArg shellies/shelly1-2BE282/relay/0/command off\
  on:noArg shellies/shelly1-2BE282/relay/0/command on

setstate MQTT2_shelly1_2BE282 on
setstate MQTT2_shelly1_2BE282 2019-01-11 10:19:00 announce_fw_ver 20190103-091629/v1.4.4@165d718b
setstate MQTT2_shelly1_2BE282 2019-01-11 10:19:00 announce_id shelly1-2BE282
setstate MQTT2_shelly1_2BE282 2019-01-11 10:19:00 announce_ip 192.168.69.68
setstate MQTT2_shelly1_2BE282 2019-01-11 10:19:00 announce_mac 3E71BF2BE282
setstate MQTT2_shelly1_2BE282 2019-01-11 10:19:00 announce_new_fw false
setstate MQTT2_shelly1_2BE282 2019-01-11 10:19:00 online true
setstate MQTT2_shelly1_2BE282 2019-01-11 10:38:30 shellies/shelly1-2BE282/input/0 0
setstate MQTT2_shelly1_2BE282 2019-01-11 10:38:30 shellies/shelly1-2BE282/relay/0 on
setstate MQTT2_shelly1_2BE282 2019-01-11 10:38:30 state on


Ist das ursprünglich verwaiste Reading ../relay/0  bei mir nur Zufall oder ist es beabsichtigt?

VG


Ergänzung:

Habe eine weiteren shelly1 konfiguriert und die folgende Beobachtung gemacht:

Das ../relay/0  ist zunächst in der readingList  enthalten.  Nach Ausführung von set attrTemplate ist es immernoch vorhanden.
Jedoch nach dem ersten reboot des shelly1 verschwindet es.
Nach meiner anschließenden manuellen Hinzufügung bleibt es erhalten (auch nach weiteren reboots).

[Beta-User]

Ist das ursprünglich verweiste Reading ../relay/0  bei mir nur Zufall oder ist es beabsichtigt?

Vorhandene Readings werden (in dem Fall bzw. durch die derzeitige Fassung des template) nicht gelöscht, es ist also verwaist.

Ich würde allerdings dazu tendieren, das entweder (per template?) zu löschen, oder zusätzlich auf ein reading relay0 (ohne den MQTT-Pfad) zu mappen - Präferenz auf löschen.
Interessant ist aber das andere "Zeug":
- Braucht es das "announce"-Prefix?
- Macht es Sinn, den Schalter auf ein eigenes Reading zu mappen (input0)? Könnte man evtl. brauchen, um manuelle Schaltungen zu detektieren...
(die "0" für die Readings deswegen, weil es für die mehrkanaligen für mehr Klarheit sorgt, wo was herkommt).

[LudgerR]

Ergänzung:

Habe eine weiteren shelly1 konfiguriert und die folgende Beobachtung gemacht:

Das ../relay/0  ist zunächst in der readingList  enthalten.  Nach Ausführung von set attrTemplate ist es immernoch vorhanden.
Jedoch nach dem ersten reboot des shelly1 verschwindet es.
Nach meiner anschließenden manuellen Hinzufügung bleibt es erhalten (auch nach weiteren reboots).

Die anderen Readings wie announce werden ja automatisch erzeugt. 
Ich kann damit leben, dass ich  /relay/0  anschließend händisch hinzufügen muss.
Insgesamt finde ich es etwas verwirrend.

VG

[Beta-User]

Merke: readingList ist nicht dasselbe wie Reading.Die readingList wird durch das attrTemplate neu geschrieben, diese wird aber geändert und enthält ein mapping der message auf "state".

Durch einen Reboot des shelly werden keine Angaben in FHEM gelöscht, es werden höchstens durch die damit verbundenen Messages weitere Änderungen durch autocreate vorgenommen.

Du solltest mal den Verkehr auf dem MQTT-Server mithören (mosquitto_sub kann das auch bei einem MQTT2_SERVER).

Auf Basis des lists mal folgender erweiterte Vorschlag:

Code Auswählen Erweitern

name:A_10_shelly1
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly1 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\
  shellies/DEVNAME/relay/0:.* relay0\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
deleteReading DEVICE .*
attr DEVICE model A_10_shelly1

[LudgerR]

Ich hatte bei einem weiteren shelly mqtt Aktivierung offenbar einen snapshot mit "Raw Definition"  gemacht bevor 
"set attrTemplate" beendet war und mich damit selbst verwirrt (Asche auf mein Haupt!).

Eine Verkürzung der Readings finde ich gut.   

Die Frage ist nur

  input0 relay0  oder   input/0 relay/0

Die erste Variante passt mehr zu TASMOTA, die andere mehr zu Letscontrolit.

Zur Zeit bin ich noch in der Findungsphase welche Firmware ich auf meinen Sonoff und Shelly Geräten einsetzen werde. Um ein Votum zugeben bin ich noch zur kurz im MQTT Thema.

Bzgl. mosquito_sub  lässt sich der seperat installieren oder nur zusammen mit mosquito.  Die installation von MQTT.fix habe ich nicht weiterverfolgt nachdem dieser ein X11 Window oder ähnliches verlangte.

Ein link für die einfache Installation und Nutzung von mosquito_sub  wäre hilfreich.

VG

[Beta-User]

Hier geht es um die shelly-firmware. Da die mit MQTT gut kann und man ihr offensichtlich auch das "nach hause telefonieren" abgewöhnen kann, würde ich für diese Geräte auch die originale FW behalten (schon aus versicherungsrechtlichen Gründen).

Wie geschrieben war input0 etc. bedingt dadurch, dass ich das ggf. auch als Basis nehme für mehrkanalige templates und dann keine Verwirrung entstehen sollte. Ansonsten ist man in der Benennung ziemlich frei, sinnvoll sollte es eben sein. Dabei finde ich "besondere" Zeichen aber immer "schwierig", vor allem den dir-Marker "/". Wenn ihr einen Trenner haben wollt, wie wäre es mit relay_0?
Die "Kompabilität" mit anderen firmwares finde ich jetzt nicht sooo wichtig, kann das aber gerne berücksichtigen (mal abgesehen von "/", das gibt es nur auf klare Ansage, dass ihr das wollt und einer "Umleitung" (z.B. von .../relay/0 auf relay_1; die Zahlenwerte sollten konsistent sein und die Benennung international/englisch/ascii)).

mosquitto_sub (und ..._pub) ist Teil von mosquitto_clients und kann gesondert installiert werden. Allerdings kann insbesondere auch der MQTT2_SERVER für debugging genutzt werden und das direkte Absetzen von Befehlen (in den Tasmota-templates wird das teilweise gemacht; wenn ihr das hier auch haben wollt, um z.B. Statusmeldungen einmalig abzufragen usw., dann kann ich das ggf. berücksichtigen (aber nicht testen, bitte möglichst fertigen Code!)

[rudolfkoenig]

Allerdings kann insbesondere auch der MQTT2_SERVER für debugging genutzt werden [...]

Gilt fuer MQTT2_SERVER und MQTT2_CLIENT:
- Ebene 1, alle topics und messages: "attr mqtt2_server rawEvents", z.Bsp. im Event-Monitor (evtl. mit Filter) verfolgbar
- Ebene 2, kompletter MQTT Datenaustausch: "attr mqtt2_server verbose 5", hier wird ins FHEM-Log geschrieben, das kann man aber auch im Event-Monitor verfolgen.

[Beta-User]

Gilt fuer MQTT2_SERVER und MQTT2_CLIENT:
- Ebene 1, alle topics und messages: "attr mqtt2_server rawEvents", z.Bsp. im Event-Monitor (evtl. mit Filter) verfolgbar
- Ebene 2, kompletter MQTT Datenaustausch: "attr mqtt2_server verbose 5", hier wird ins FHEM-Log geschrieben, das kann man aber auch im Event-Monitor verfolgen.

Thx, hab's hier entsprechend verarbeitet: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#MQTT2_SERVER_und_MQTT2_CLIENT_f.C3.BCr_Debugging_nutzen