MQTT2+Shelly: erste Konfiguration und template-Entwicklung

[seule3008]

Hallo,

Das Problem ist ja, das in der setList das off command scheinbar bei dem Shelly nur mit einem Device funktioniert. Steht auch schonmal irgendwo hier im Forum. Alle Versuche schalten immer nur ein Device, deswegen der Umweg über die structure. Evtl liegt es auch an dem Shelly template, aber das so umzuschreiben das das evtl doch geht übersteigt meine Fähigkeiten was das angeht.

Viele Grüße

Christian

[Beta-User]

Nochmal zur Klarstellung, weil du scheinbar immer noch mehreren Missverständnissen aufsitzt:
- Man kann mit Perl in der setList "allen möglichen Unfug" machen. Von mir gibt es z.B. für ebus Code (verteilt via attrTemplate), der bis zu 7 publishes absetzt, und Rudi hatte auch ein getestetes Beispiel, mit dem man mehrere Geräte schalten kann. Es ist also völlig flexibel, was man machen _kann_. Bei der ebus-Sache halte ich das für sinnvoll (weil man ein Wochenprofil aus technischen Gründen in 7 Tagesprofile aufsplitten muss), in anderen Fällen eher nicht, denn
- zu machen, was möglich ist, ist aber nicht immer sinnvoll, schon gleich nicht via "template":
-- andere Devices zu schalten, ist nicht unbedingt das, was der User erwartet => verwirrend, schlecht wartbar => "don't try this at home...". Das gilt insbesondere auch für die "Lösung" mit der structure (die ist überkomplex, siehe unten)
-- für "paralleles Schalten" gibt es andere, externe Lösungen (z.B. notify), die generischer sind, und bei denen dann die Querbeziehungen auch vial FHEMWEB visualisiert werden.

Kurz gesagt: Deine Lösung ist keine "gute Lösung" in dem Sinne, dass man das zur Nachahmung empfehlen sollte. Damit sollten wir diese OT-Diskussion jetzt aber beenden.

[87insane]

Hey zusammen,

das Template vom Shellyplus1pm ist noch nicht ganz rund.
Die JSON Map muss angepasst werden und sollte so aussehen:

Code Auswählen Erweitern

attr MQTT2_shellyplus1pm_7c87ce657e74 jsonMap params_switch_0_aenergy_total:aenergy_total switch_0_apower:apower switch_0_temperature_tC:temperature switch_0_temperature_tF:0 params_wifi_sta_ip:ip

Die radingsList:

Code Auswählen Erweitern

attr MQTT2_shellyplus1pm_7c87ce657e74 readingList $DEVICETOPIC/online:.* online\
  $DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  $DEVICETOPIC/status/mqtt:.* { json2nameValue($EVENT, 'mqtt_', $JSONMAP) }\
  $DEVICETOPIC/status/sys:.* { json2nameValue($EVENT, 'sys_', $JSONMAP) }\
  $DEVICETOPIC/status/switch_0:.* { json2nameValue($EVENT, 'switch_0_', $JSONMAP) }\
  fhem/rpc:.* { json2nameValue($EVENT,'rpc_',$JSONMAP) }

Und das devicetopic wird leider nicht gesetzt. Ich hab das manuell nachgetragen.
Zeile 3333 im Template solle von "attr DEVICE devicetopic DEV_TOPIC" glaube ich auf "attr DEVICE devicetopic BASE_TOPIC"

Und bei devStateIcon braucht man, keine doppelten ;;

Gruß,
87Insane

[Beta-User]

Hmm, vermutlich ist es jetzt immer noch nicht rund...

Warum DEV_TOPIC nicht aufgelöst wird, ist mir im Moment noch unklar, ich hatte das auf Basis eines vermutlich schon "versauten" listings gebastelt (=> wenn möglich ein "frisches" RAW liefern, wie autocreate es erzeugt).

"fhem/rpc" sieht in der readingList komisch aus, mir unklar, wer das wann warum erzeugt, aber für alle passend ist es ziemlich sicher nicht.

[87insane]

Ja mach ich dieses WE.

Das RPC erscheint auch erst nach dem ersten schalten. Ist quasi ein zusätzlicher back Channel. Aktuell sendet das Template mit fhem rein.
Der Eintrag erscheint auch erst nachdem man einmal einen Befehl aus fhem heraus sendet. Mir ist noch nicht klar, wie das Gerät gebunden bleibt bei mehreren shelly. Normal ist da shelly-id:fhem/....

Ein neues autocreate wird aber helfen....meld mich.

[Beta-User]

Hmm, scheint dann vom ESP aus dem JSON entnommen zu werden und nochmal als Bestätigung gepublisht... Dann sollte man es ignorieren, oder der Sendepfad im JSON müßte angepaßt werden.
(Wer denkt sich so einen m.E. unnötig komplizierten Code aus...)

[87insane]

Hey - Anbei mal alles was ich so getestet habe...

frisches RAW von einem PLUS 1PM:

Code Auswählen Erweitern

defmod MQTT2_shellyplus1pm_7c87ce658380 MQTT2_DEVICE shellyplus1pm_7c87ce658380
attr MQTT2_shellyplus1pm_7c87ce658380 readingList shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/online:.* online\
shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/status/sys:.* { json2nameValue($EVENT) }\
shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/status/mqtt:.* { json2nameValue($EVENT) }\
shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/status/switch_0:.* { json2nameValue($EVENT) }\
shellyplus1pm_7c87ce658380:mqttexplorer/rpc:.* { json2nameValue($EVENT) }\
shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/events/rpc:.* { json2nameValue($EVENT) }
attr MQTT2_shellyplus1pm_7c87ce658380 room MQTT2_DEVICE

setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 12:56:54 IODev MQTT2_FHEM_Server
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:30 aenergy_by_minute_1 0.000
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:30 aenergy_by_minute_2 0.000
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:30 aenergy_by_minute_3 0.000
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:30 aenergy_minute_ts 1640433748
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 aenergy_total 0.000
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 apower 0.0
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 available_updates_beta_version 0.9.2-beta2
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 cfg_rev 4
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 connected true
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 current 0.0
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 dst shellyplus1pm-7c87ce658380/events
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 fs_free 233472
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 fs_size 458752
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 id 0
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 mac 7C87CE658380
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 method NotifyStatus
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 online true
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 output false
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:53 params_events_1_cfg_rev 4
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:53 params_events_1_component mqtt
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:53 params_events_1_event config_changed
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:53 params_events_1_restart_required true
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:53 params_events_1_ts 1640433773.82
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 params_mqtt_connected true
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 params_switch_0_id 0
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 params_switch_0_voltage 224.9
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 params_sys_available_updates_beta_version 0.9.2-beta2
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:53 params_sys_restart_required true
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 params_ts 1640433790.80
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 params_wifi_rssi -45
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 params_wifi_ssid KA-nG-WLan_2.4Ghz
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 params_wifi_sta_ip 192.168.20.138
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 params_wifi_status got ip
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 ram_free 178512
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 ram_size 249536
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 restart_required false
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:30 result_was_on true
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 source init
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 src shellyplus1pm-7c87ce658380
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 temperature_tC 44.4
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 temperature_tF 111.9
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 time 13:03
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 unixtime 1640433790
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 uptime 14
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 voltage 224.9


Im Shelly MQTT kann eingestellt werden:
- RPC status notifications over MQTT - an/aus
- Generic status update over MQTT - an/aus
auch MQTTS wäre möglich.

Zur Erklärung der readingsList:
Wenn beide o.g. Optionen aus sind, bekommt man nur folgendes Reading:

Code Auswählen Erweitern

shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/online:.* online

Wenn Generic status update over MQTT aktiv ist bekommt man:

Code Auswählen Erweitern

shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/status/sys:.* { json2nameValue($EVENT) }
shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/status/mqtt:.* { json2nameValue($EVENT) }
shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/status/switch_0:.* { json2nameValue($EVENT) }

Wenn RPC status notifications over MQTT aktiv ist bekommt man:

Code Auswählen Erweitern

shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/events/rpc:.* { json2nameValue($EVENT) }

Die Zeile aus dem Pfad:

Code Auswählen Erweitern

shellyplus1pm_7c87ce658380:mqttexplorer/rpc:.* { json2nameValue($EVENT) }
ergibt sich aus dem sende JSON... Ich habe das mal extra angepasst um zu zeigen was sich ändert...

Das hier wäre ein normales toggle via MQTT:

Code Auswählen Erweitern

{
  "id": 0,
  "src": "mqttexplorer",
  "method": "Switch.Toggle",
  "params": {
    "id": 0
  }
}
die src Zeile entscheidet über den Namen der dann erscheint.

Was damit wieder auf deine Aussage trifft. Ggf den Sender mit "BASE_TOPIC" versehen?

[Beta-User]

Was damit wieder auf deine Aussage trifft. Ggf den Sender mit "BASE_TOPIC" versehen?

Weiß nicht recht, das ist unschön, v.a., weil das "unendlich" ist: mqttexplorer/rpc
Mein Eindruck ist weiter, dass das nicht richtig durchdacht ist.

Im Moment neige ich eher dazu, den "fhem"-Zweig mit einem leeren Perl ins Nirvana zu schicken bzw. ggf. fhem2shelly daraus zu machen, damit man das direkt mit einer ignoreRegexp am IO rausfiltern kann. Wenn man den originalen Topic nehmen würde, hat man eine Doppelung von Senden und Empfangen auf demselben Topic, und das geht gefühlt gar nicht.

Siehe auch https://forum.fhem.de/index.php/topic,124995.0.html, da schlagen sich auch ein paar Leute mit Fragen rund um plus1pm@MQTT rum...

[87insane]

Habe meinen Ansatz mal eingefügt...

https://forum.fhem.de/index.php/topic,124995.msg1196882.html#msg1196882

[Beta-User]

Habe meinen Ansatz mal eingefügt...

Danke für's Testen.

Habe aus den weiteren Bausteinchen jetzt wieder eine aktualisierte Fassung für die attrTemplates gebastelt, da war leider manches eher noch unausgereift.
Jetzt sollte es für den plus1pm passen, und ich hoffe auch für den normalen plus1.

Weiter habe ich eine erste Variante für den shelly4pro eingecheckt, damit sollten sich die Dinger auch zumindest mal schalten lassen.

Insgesamt gefallen mir die Teile nicht, die sind nochmal gesprächiger als normale Shelly, und das Format, in dem die Daten dann ausgetauscht werden, ist auch nicht "meins". Dazu dann noch unerklärliche Unterschiede in dem, was die 1-er machen zu dem, wie es beim 4-er ist. Grausam...

Mittelfristig würde ich anregen, die ganze Vorverarbeitungs-Arbeit in eine myUtils auszulagern und da auch gleich "eocr"-Prüfungen mit einzubauen. Da es zuhauf schon Beispielcode für ähnliche Aufgaben gibt, wäre ich ausgesprochen erfreut, wenn sich darum mal jemand anders kümmern würde - wenn ich auf den Gedanken käme, einen Shelly neuerer Bauart zu erwerben, hätte ich nämlich sofort den Impuls, das Ding auf Tasmota umzuflashen...

[gvzdus]

Herzlichen Dank!

Ich denke, "als FHEM" kommen wir nicht daran vorbei, die Shellys allesamt zu unterstützen - so fehlgriffig das Protokoll auch sein mag. Schön, wenn es jetzt einen Weg für gleich 3 Geräte mehr gibt!

Nein, ich kann Dir nicht folgen . Du bist mir jetzt mit 2 Schritten voraus:
a) das Problem zu verstehen
b) das Problem zu lösen

[Beta-User]

Herzlichen Dank!

Gerne . Danke zurück für's "Spielzeug".

Ich denke, "als FHEM" kommen wir nicht daran vorbei, die Shellys allesamt zu unterstützen

Schon klar, aber Werbung mache ich für den Sch... nicht. Es werden Unmengen an unnützer Info recht regelmäßig in einem völlig kruden Format versendet. Ist imo nicht "MQTT"-like, das sollte "leichtgewichtig" sein und sparsam. Basta!

Nein, ich kann Dir nicht folgen . Du bist mir jetzt mit 2 Schritten voraus:
a) das Problem zu verstehen
b) das Problem zu lösen

Das "Problem" besteht aus mehreren Stufen:
Zum einen muss man erst mal rausfinden, in welchem Format der Shelly das jeweils haben will. Schon das scheint etwas speziell zu sein, verschärft wird das leider durch $DEVICETOPIC-Nutzung - wenn man das via attrTemplate und "copy"-Befehlen macht, muss man nämlich erst die internen Daten bereinigen, was am einfachsten geht, wenn man die DEF anfasst - dabei geht aber leider das Internal DEVICETOPIC hops.... Hat etwas länger gebraucht, bis ich da draufgekommen bin .

Dann ist der "Rückweg" auch mehrfach nicht so einfacht:
- unterschiedliche Topics bei shellyplus1 und shelly4pro;
- "true" statt "on" => man braucht Ersetzungen, die aber nicht zu unscharf sein sollten, damit man nicht an anderer Stelle unbeabsichtigte Nebenwirkungen hat;
- und zu guter Letzt ist die interne Datenstruktur verschachtelt, so dass man erst mal ziemlich lange (und nicht "standardkonforme") Reading-Namen bekommt, die man dann wieder gradeziehen darf... Das ganze beim shelly4pro über einen "Einheitstopic", so dass man erst mal aussortieren muss, für was man sich beim einzelnen Kanal eigentlich interessiert...

Klarer jetzt?

[87insane]

Ich versuche im Thread zur Anbindung weiter zu helfen. Hier sind aber eher FHEM Themen das Problem...
Egal...

Zeile 3364 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L3364) ist noch nicht korrekt.
So sieht es bei einem 1pm bei mir aus:

Code Auswählen Erweitern

params_switch_0_aenergy_total:aenergy_total switch_0_apower:apower switch_0_temperature_tC:temperature switch_0_temperature_tF:0 params_wifi_sta_ip:ip

Nun hast du fhem2shelly aus dem RPC gemacht. Ich habe noch keinen wirklichen Nutzen gefunden für den Zweig. Ggf. an der Bridge ganz rauß nehmen?
Ich hoffe das Allterco auch wieder normal wird und nicht den ganzen Inhalt einen Zweiges, einfach in ein JSON packt. Ich schließe mich da Beta-User an -> schlimm!

[Beta-User]

Hmm, vermutlich paßt das noch nicht so ganz mit dem jsonMap, aber das "Problem" ist auch, dass die readingList geändert ist. Damit müßten die "0_"-Wurmfortsätze in der Regel eigentlich insgesamt ziemlich weg sein (?).

Den Topic-Beginn "fhem2shelly/" kann man mAn. guten Gewissens in die ignoreRegexp eines jeden IO mit reinnehmen, das ist im attrTemplate nur drin, weil vermutlich ein Teil der User nicht mitbekommt, dass es "Murks" ist, die Anweisung wieder auszuwerten... Anscheinend ist das mit der "src" aber "mandatory" (die Doku des Herstellers ist nicht ganz eindeutig). Daher ist es eben jetzt "zwangsabgeleitet" auch via readingList - doppelt genäht hält besser...

Sorry für den etwas unvollständigen Zwischenstand, mir war erst mal wichtig, dass das mit dem Schalten reibungslos funktioniert und hatte dann gestern keine Lust mehr, das komplett auch noch auszutesten und zu optimieren. Ist ja jetzt kein Hexenwerk mehr...

[Beta-User]

Wegen eurer Ratereien im shellyplus1pm-Thread:
Das Mapping für state hatte ich mit einer "remote"-Instanz ausgetestet, aber ohne die Einstellungen zu sehen, welche die firmware hatte. Ich gehe davon aus, dass die "default" war, firmwarestand könnte ich notfalls nochmal checken.
Falls (!) die shelly-2.gen. aber "alle" so ticken wie der  4er, könnte man auch einfach dessen readingList (für den 1. Kanal, ggf. etwas verändert) nehmen, und die weiteren Topics einfach nach Nirvana "ableiten".

Man sollte sich halt auf einen Stand einigen, auf dem die Einstellungen sein sollten (möglichst: nichts ändern), und dann die aktuellste firmware zugrunde legen (notfalls: die beta!, falls die "einfacher" oder "anders" ist, was die Datenstrukturen angeht).