[GELÖST] Doppelpunkt im MQTT Topic Namen

[reibuehl]

Hallo,

ich versuche gerade einen Shelly Plus 1 als MQTT2_DEVICE einzubinden. Schalten des  Ausganges funktioniert bereits, aber beim Einlesen des Status scheitere ich momentan noch daran, dass das vom Shelly dazu benutzte Topic einen Doppelpunkt enthält: Die Statusmeldungen des Shelly gehen immer an

Code Auswählen Erweitern

<konfigurierbares MQTT Präfix>/status/switch:0

Ich hab es in meinem Fall sowohl mit

Code Auswählen Erweitern

shellies/OG_WZ_Stehlampe/status/switch:0:.* { json2nameValue($EVENT) } als auch mit

Code Auswählen Erweitern

shellies/OG_WZ_Stehlampe/status/switch\:0:.* { json2nameValue($EVENT) } im ReadingsList versucht. In beiden Fällen bekomme ich aber keine Readings zurück.

Kann ich den Doppelpunkt irgendwie anders escapen?

Gruß,
Reiner

[Beta-User]

Nimm einen Punkt (regex).

[sash.sc]

Wende doch die Templates an.

[reibuehl]

Nimm einen Punkt (regex).

Danke @Beta-User ! Damit funktioniert es.

[reibuehl]

Wende doch die Templates an.

Das Konzept der Templates hab ich bisher noch nicht verstanden. Bei mir tauchen unter attrTemplates jede Menge wilder Templates auf darunter aber nur eines mit Shelly 1 im Namen. Da der Shelly 1 sich aber stark vom Shelly Plus 1/Shelly 1 Plus unterscheidet, wollte ich dieses Template nicht ausprobieren - zumal ich ja wie Anfangs gesagt, das ganze Konzept (noch) nicht verstanden habe...

[Beta-User]

Das Konzept der Templates hab ich bisher noch nicht verstanden. Bei mir tauchen unter attrTemplates jede Menge wilder Templates auf darunter aber nur eines mit Shelly 1 im Namen. Da der Shelly 1 sich aber stark vom Shelly Plus 1/Shelly 1 Plus unterscheidet, wollte ich dieses Template nicht ausprobieren - zumal ich ja wie Anfangs gesagt, das ganze Konzept (noch) nicht verstanden habe...

"Konzept" klingt hochtrabend...

Es wird per default eine "verkürzte Gesamtliste" angezeigt, damit man einen Eindruck davon bekommen kann, was es so alles gibt. Dinge, die offensichtlich keinen Sinn machen, werden weggefiltert oder gar nicht erst geladen, damit das "halbwegs" übersichtlich bleibt:
https://wiki.fhem.de/wiki/AttrTemplate#Warum_finde_ich_das_Template_xyz_nicht.3F

Daher taucht ohne passende readingList erst mal nur ein Shelly auf, statt ziemlich vieler Varianten. Dto. für Tasmota, ..., ...

Da du einen "V2-Shelly" hast, gibt es dafür eben noch nichts bzw. die "alten" passen nicht.

Um dafür was zu entwickeln, wäre ein RAW-listing vom gesamten Stand (wie von autocreate erzeugt) hilfreich, evtl. wird auch etwas "MQTT-Traffic" benötigt, da das hier etwas "speziell" zu sein scheint...

[reibuehl]

Mit einem per Autocreate angelegten Device kann ich leider nicht dienen, da mein MQTT über ein MQTT2_CLIENT Device und einen Mosquitto MQTT Server läuft und es dafür meines Wissens kein Autocreate gibt.

MQTT Traffic und einen Vorschlag für die readingsList und setList könnte ich aber liefern. Der v2 Shelly scheint per default nicht mehr unterhalb des Topics shellies/ zu posten sondern hat sich bei mir direkt unter der Root mit seinem Namen shellyplus1-<12-stellige ID> zu melden. Wenn man in der UI ein MQTT Präfix setzt, wird unterhalb dessen gepublished - aber dann direkt dort und nicht unter <MQTT-Präfix>/shellyplus1-<12-stellige ID> wie man vielleicht erwarten würde.

Als ReadingsList hab ich momentan diese beiden definiert:

Code Auswählen Erweitern

<MQTT-Präfix oder shellyplus1-<12-stellige ID>>/status/rpc:.* { json2nameValue($EVENT) }
<MQTT-Präfix oder shellyplus1-<12-stellige ID>>/status/switch.0:.* { json2nameValue($EVENT) }


Hier ein Beispiel-JSON für /status/rpc (MQTT-Präfix ist hier auf "shellies/OG_WZ_Stehlampe" gesetzt)

Code Auswählen Erweitern

{"id":0,"src":"shellyplus1-a8032abc41a8","dst":"shellies/OG_WZ_Stehlampe/status","result":{"was_on":false}}

und eines für /status/switch:0

Code Auswählen Erweitern

{"id": 0, "source": "MQTT", "output": true,"temperature":{"tC":56.0, "tF":132.8}}

Zum schalten verwende ich diese setList:

Code Auswählen Erweitern

off shellies/OG_WZ_Stehlampe/rpc {"id":0, "src":"shellies/OG_WZ_Stehlampe/status", "method":"Switch.Set", "params":{"id":0,"on":false}}
on  shellies/OG_WZ_Stehlampe/rpc {"id":0, "src":"shellies/OG_WZ_Stehlampe/status", "method":"Switch.Set", "params":{"id":0,"on":true}}

Es gibt beim umschalten noch eine ganze Reihe weiterer MQTT Messages, ich versuch mal einen ganzen Umschaltvorgang mitzuschneiden.

[rudolfkoenig]

Mit einem per Autocreate angelegten Device kann ich leider nicht dienen, da mein MQTT über ein MQTT2_CLIENT Device und einen Mosquitto MQTT Server läuft und es dafür meines Wissens kein Autocreate gibt.

Klar doch: es wird nur alles in ein einziges MQTT2_DEVICE reingekippt.
Wenn man diesen mit bridgeRegexp versieht, dann ist das fast so gut, wie ein MQTT2_SERVER

[Beta-User]

Mit einem per Autocreate angelegten Device kann ich leider nicht dienen, da mein MQTT über ein MQTT2_CLIENT Device und einen Mosquitto MQTT Server läuft und es dafür meines Wissens kein Autocreate gibt.

Wie Rudi schreibt: Doch, das gibt es, ist hier nur mit einiger Sicherheit nicht sinnvoll nutzbar. Die Alternative wäre, einen MQTT2_SERVER mit anderem Port anzulegen und einen der shelly erst mal darüber näher kennen zu lernen. (Fast so gut finde ich übertrieben...)

MQTT Traffic und einen Vorschlag für die readingsList und setList könnte ich aber liefern. Der v2 Shelly scheint per default nicht mehr unterhalb des Topics shellies/ zu posten sondern hat sich bei mir direkt unter der Root mit seinem Namen shellyplus1-<12-stellige ID> zu melden. Wenn man in der UI ein MQTT Präfix setzt, wird unterhalb dessen gepublished - aber dann direkt dort und nicht unter <MQTT-Präfix>/shellyplus1-<12-stellige ID> wie man vielleicht erwarten würde.

Bitte erst mal alles auf dem default lassen, eine "Startsequenz" mit "shelly[^/]+/..." ist auch ok (für späteres Filtern).

readingList wäre für's erste vermutlich besser nach diesem Muster (erst mal nur sehen, wo was herkommt):

Code Auswählen Erweitern

<MQTT-Präfix oder shellyplus1-<12-stellige ID>>/status/rpc:.* { json2nameValue($EVENT,'rpc',$JSONMAP) }
<MQTT-Präfix oder shellyplus1-<12-stellige ID>>/status/switch.0:.* { json2nameValue($EVENT,'',$JSONMAP) }


Hier ein Beispiel-JSON für /status/rpc (MQTT-Präfix ist hier auf "shellies/OG_WZ_Stehlampe" gesetzt)

Code Auswählen Erweitern

{"id":0,"src":"shellyplus1-a8032abc41a8","dst":"shellies/OG_WZ_Stehlampe/status","result":{"was_on":false}}

und eines für /status/switch:0

Code Auswählen Erweitern

{"id": 0, "source": "MQTT", "output": true,"temperature":{"tC":56.0, "tF":132.8}}

Aua, das sieht nach Arbeit aus... Für FHEM völlig ungeschicktes Format, tief verschachtelt, wer braucht denn sowas...?!?

(@Rudi: Ich fürchte, das wird sich irgendwie zu einer Art Standard entwickeln).

Zum schalten verwende ich diese setList:

Code Auswählen Erweitern

off shellies/OG_WZ_Stehlampe/rpc {"id":0, "src":"shellies/OG_WZ_Stehlampe/status", "method":"Switch.Set", "params":{"id":0,"on":false}}
on  shellies/OG_WZ_Stehlampe/rpc {"id":0, "src":"shellies/OG_WZ_Stehlampe/status", "method":"Switch.Set", "params":{"id":0,"on":true}}

Auch "abartig überkompliziert", aber immerhin funktioniert es...

Vermutlich sollte man wenigstens empfangsseitig sowas wie eine Art Wrapper um json2nameValue() rumbasteln, ähnlich der Lösung von ebus. Dafür müßten wir aber vermutlich erst mal eine Art Überblick haben, in welche Richtung das ganze generell künftig gehen soll. Habe zwar bei Shelly gelesen, dass eine neue API in Vorbereitung ist, aber das hier ist das erste dazu, das bei uns hier aufgeschlagen ist...
Schauen wir mal.

[reibuehl]

Hier der Mitschnitt eines Ein- und eines Ausschaltens per FHEM/MQTT wenn im Shelly nur die Default MQTT Option "RPC status notifications over MQTT" gesetzt ist:

Code Auswählen Erweitern

shellies/OG_WZ_Stehlampe/rpc {"id":0, "src":"shellies/OG_WZ_Stehlampe/status", "method":"Switch.Set", "params":{"id":0,"on":true}}
shellies/OG_WZ_Stehlampe/status/rpc {"id":0,"src":"shellyplus1-a8032abc41a8","dst":"shellies/OG_WZ_Stehlampe/status","result":{"was_on":false}}
shellies/OG_WZ_Stehlampe/events/rpc {"src":"shellyplus1-a8032abc41a8","dst":"shellies/OG_WZ_Stehlampe/events","method":"NotifyStatus","params":{"ts":1636377320.45,"switch:0":{"id":0,"output":true,"source":"MQTT"}}}

shellies/OG_WZ_Stehlampe/rpc {"id":0, "src":"shellies/OG_WZ_Stehlampe/status", "method":"Switch.Set", "params":{"id":0,"on":false}}
shellies/OG_WZ_Stehlampe/status/rpc {"id":0,"src":"shellyplus1-a8032abc41a8","dst":"shellies/OG_WZ_Stehlampe/status","result":{"was_on":true}}
shellies/OG_WZ_Stehlampe/events/rpc {"src":"shellyplus1-a8032abc41a8","dst":"shellies/OG_WZ_Stehlampe/events","method":"NotifyStatus","params":{"ts":1636377325.59,"switch:0":{"id":0,"output":false,"source":"MQTT"}}}

Und hier das gleiche nur diesmal über das Web UI ausgelöst:

Code Auswählen Erweitern

shellies/OG_WZ_Stehlampe/events/rpc {"src":"shellyplus1-a8032abc41a8","dst":"shellies/OG_WZ_Stehlampe/events","method":"NotifyStatus","params":{"ts":1636377035.20,"switch:0":{"id":0,"output":true,"source":"WS_in"}}}

shellies/OG_WZ_Stehlampe/events/rpc {"src":"shellyplus1-a8032abc41a8","dst":"shellies/OG_WZ_Stehlampe/events","method":"NotifyStatus","params":{"ts":1636377039.50,"switch:0":{"id":0,"output":false,"source":"WS_in"}}}


Wenn man "Generic status update over MQTT" auch einschaltet, kommt zusätzlich noch eine Message je Schaltvorgang, die ich für Aussagekräftiger halte und deshalb bei meiner ReadingsList mitverwendet habe:

Code Auswählen Erweitern

shellies/OG_WZ_Stehlampe/status/switch:0 {"id": 0, "source": "MQTT", "output": true,"temperature":{"tC":57.0, "tF":134.6}}

shellies/OG_WZ_Stehlampe/status/switch:0 {"id": 0, "source": "MQTT", "output": false,"temperature":{"tC":57.1, "tF":134.7}}

Sonst sendet er noch ein paar Meldungen beim booten/restart oder wenn umkonfiguriert wird. Falls die von Interesse sind, kann ich die auch noch posten.

[reibuehl]

Wenn ich keinen MQTT-Präfix setze, sieht ein Schaltvorgang über die Web UI so aus:

Code Auswählen Erweitern

shellyplus1-a8032abc41a8/events/rpc {"src":"shellyplus1-a8032abc41a8","dst":"shellyplus1-a8032abc41a8/events","method":"NotifyStatus","params":{"ts":1636379194.60,"switch:0":{"id":0,"output":true,"source":"WS_in"}}}

shellyplus1-a8032abc41a8/events/rpc {"src":"shellyplus1-a8032abc41a8","dst":"shellyplus1-a8032abc41a8/events","method":"NotifyStatus","params":{"ts":1636379264.10,"switch:0":{"id":0,"output":false,"source":"WS_in"}}}


Das es ändert sich also das Topic und der Wert in "dst".

[rudolfkoenig]

(@Rudi: Ich fürchte, das wird sich irgendwie zu einer Art Standard entwickeln).

Das war bestimmt jemand mit SOAP Vergangenheit, der es nicht ertraegt, wenn etwas einfach ist. Oder ein Elektriker
Fuer eine Hilsfunktion brauchen wir eine Liste aller Inputs und gewuenschten Outputs.

[Beta-User]

Hmm, das war (leider) irgendwie in der Form zu erwarten.

Die "Umwandlung" von true=>"on" findest du z.B. in 6channel_ethernet_board_6input_split. Das Problem scheint mir "nur" zu sein, dass das Ganze zu einer "Umetikettierungsorgie" wird. Übergangsweise läßt sich das sicher irgendwie lösen, aber es gefällt mir nicht und ist ggf. auch fehleranfällig.

Falls ein paar Leute mitlesen, die die "große weite" API-Welt etwas mehr im Blick haben: Gibt's da einen roten Faden, in welche Richtung sich das entwickeln wird/soll, den man ggf. berücksichtigen könnte, um das ganze irgendwie generischer anzugehen...? Das sieht mir irgendwie nach "neuen Standards" aus, die uns noch öfter begegnen werden. Oder ist das eben nur eine "Shelly-Sonderlocke" wie unter https://shelly-api-docs.shelly.cloud/gen2/ beschrieben?

@Rudi: Da ist das generisch beschrieben, allerdings ist unklar, wie "änderungsfest" das ist. Weiter vermute ich, dass auch pah sehr daran interessiert wäre, eine generische Lösung zu haben, die man auch mit dem Shelly-Modul nutzen kann...
(Wenigstens sind es nicht sekündlich 300 Events, verteilt auf 72 Topics...)