ShellyPlus2pm (und 3pm): template "shellyPlus_2pm_split" braucht Überarbeitung

[alkazaa]

Bei der Nutzung des template "shellyPlus_2pm_split" ist mir folgendes aufgefallen:

• Der Befehl "get <device> in-mode" (was immer der auch tun soll) läuft in ein time-out.
• Das kleine grüne Lämpchen im devStateIcon ruft bei Klick die website www.none.com auf.
• Der physikalische Zustand der externen Inputs der Switch-Kanäle wird nicht eingelesen.

Ich fühle mich (noch) nicht in der Lage, das template zu überarbeiten. Falls jemand sich da nützlich machen könnte, hätte ich hier die wesentlichen Teile des MQTT Traffic (aus 'Schow MQTT Traffic' kopiert, dann von mir formatiert):


Die regelmäßig erfolgenden Statusreports des Shelly sehen so aus:

Code Auswählen Erweitern

14:35:00.045 shellyplus2pm_d0ef76c732e4 shellyplus2pm-d0ef76c732e4/status/switch_0
{
"id":0,
"source":"MQTT",
"output":false,
"apower":0.0,
"voltage":235.7,
"freq":50.0,
"current":0.000,
"pf":0.00,
"aenergy":{
"total":0.000,
"by_minute":[0.000,0.000,0.000],
"minute_ts":1739453700
},
"ret_aenergy":{
"total":0.000,
"by_minute":[0.000,0.000,0.000],
"minute_ts":1739453700
},
"temperature":{
"tC":34.3,
"tF":93.8
}
}
14:35:00.079 shellyplus2pm_d0ef76c732e4 shellyplus2pm-d0ef76c732e4/status/switch_1
{
"id":1,
"source":"WS_in",
"output":false,
"apower":0.0,
"voltage":235.8,
"freq":50.0,
"current":0.000,
"pf":0.00,
"aenergy":{
"total":0.000,
"by_minute":[0.000,0.000,0.000],
"minute_ts":1739453700
},
"ret_aenergy":{
"total":0.000,
"by_minute":[0.000,0.000,0.000],
"minute_ts":1739453700
},
"temperature":{
"tC":34.3,
"tF":93.8
}
}Es gibt noch einen Teil mit rpc-Statusmeldungen, den ich im device disabled habe. Kann ich aber nachliefern, wenn gewünscht.

Beim Betätigen eines externen Schalters kommt dies (der gewünschte status des externen inputs wird hier als input_0 für den ersten Schalter gemeldet):

Code Auswählen Erweitern

15:47:26.030 shellyplus2pm_d0ef76c732e4 shellyplus2pm-d0ef76c732e4/status/input_0
{
"id":0,
"state":true
}
15:47:26.036 shellyplus2pm_d0ef76c732e4 shellyplus2pm-d0ef76c732e4/status/switch_0
{
"id":0,
"source":"switch",
"output":false,
"apower":0.0,
"voltage":237.2,
"freq":50.0,
"current":0.000,
"pf":0.00,
"aenergy":{
"total":0.000,
"by_minute":[0.000,0.000,0.000],
"minute_ts":1739458020
},
"ret_aenergy":{
"total":0.000,
"by_minute":[0.000,0.000,0.000],
"minute_ts":1739458020
},
"temperature":{
"tC":41.5,
"tF":106.8
}
}
Der response bei einem Schalter-Klick im web-interface des Shelly:

Code Auswählen Erweitern

15:54:30.356 shellyplus2pm_d0ef76c732e4 shellyplus2pm-d0ef76c732e4/status/switch_1
{
"id":1,
"source":"WS_in",
"output":false,
"apower":0.0,
"voltage":237.2,
"freq":50.0,
"current":0.000,
"pf":0.00,
"aenergy":{
"total":0.000,
"by_minute":[0.000,0.000,0.000],
"minute_ts":1739458440
},
"ret_aenergy":{
"total":0.000,
"by_minute":[0.000,0.000,0.000],
"minute_ts":1739458440
},
"temperature":{
"tC":41.6,
"tF":106.8
}
}
Und zu guter Letzt der MQTT traffic beim Schalter-Klick in FHEM:

Code Auswählen Erweitern

16:01:35.286 SENT shellyplus2pm-d0ef76c732e4/rpc
{
"id":1,
"src":"fhem2shelly",
"method":"Switch.Toggle",
"params": {
"id":0
}
}
16:01:35.399 shellyplus2pm_d0ef76c732e4 fhem2shelly/rpc
{
"id":1,
"src":"shellyplus2pm-d0ef76c732e4",
"dst":"fhem2shelly",
"result":{
"was_on":false
}
}
16:01:35.419 shellyplus2pm_d0ef76c732e4 shellyplus2pm-d0ef76c732e4/status/switch_0
{
"id":0,
"source":"MQTT",
"output":true,
"apower":0.0,
"voltage":236.8,
"freq":50.0,
"current":0.000,
"pf":0.00,
"aenergy":{
"total":0.000,
"by_minute":[0.000,0.000,0.000],
"minute_ts":1739458860
},
"ret_aenergy":{
"total":0.000,
"by_minute":[0.000,0.000,0.000],
"minute_ts":1739458860
},
"temperature":{
"tC":41.2,
"tF":106.2
}
}

[Beta-User]

Hmmm, zumindest mal eine vorläufige Rückmeldung; bitte beachten: Ich habe gar keinen Shelly im Einsatz und kann das daher nur aus der Erinnerung und "von ferne" (teilweise) beantworten:

Der Befehl "get <device> in-mode" (was immer der auch tun soll) läuft in ein time-out.

Der timeout kommt m.E. daher, dass es keine (rechtzeitige) Rückmeldung auf die get-Anfrage gibt. Das war afair schon immer so, und hängt uU. davon ab, ob man den Shelly entsprechend konfiguriert hat (über die Änderungshistory der attrTemplate-file liese sich vermutlich die Quelle im Forum finden, aus der die Funktion kommt). Wenn man das nicht braucht, kann man den betreffenden getter ja löschen...

"none" kommt vermutlich daher, dass das Reading "ip" nicht (mehr) existiert. Die Info scheint "umgezogen" zu sein und man müßte das jsonMap anpassen (in https://forum.fhem.de/index.php?msg=1293513 waren noch beide Infos da). Habe nur etwas Bauchweh, dass das dann für andere User wieder nicht paßt...*

Wie das mit dem physikalischen Zustand gemeint ist, kann ich grade nur bedingt nachvollziehen. Vermutlich gibt es aus dem gezeigten JSON heraus auch irgendein Reading, aber wie das umzubenennen oder sinnvoll zu verwerten ist, müßte mir ggf. noch jemand erklären...

*Zu der IP-Geschichte dann erst mal im anderen Thread betr. Lamellen.

[alkazaa]

Kurze Rückmeldung zum ,ip': das Shelly meldet in der Tat keinerlei ip-Adresse zurück.

Zum Punkt 'input': das topic heißt input_0 bzw. input_1, siehe Anfang des 2. code-Blocks im ersten Beitrag.

[Beta-User]

Hmm, die IP kommt auch nicht nach einem reboot des Shelly? (ggf. unter anderem Namen?)

Zum dem "input"-Dingens habe ich jetzt mal "auf Verdacht" auch was eingecheckt, bitte um Rückmeldung, ob sich das jetzt so verhält wie du gerne hättest?

(Verfügbar per update ab morgen kurz vor 8 oder per direktem svn-Download).

[alkazaa]

Zum dem "input"-Dingens habe ich jetzt mal "auf Verdacht" auch was eingecheckt, bitte um Rückmeldung, ob sich das jetzt so verhält wie du gerne hättest?

Ein großes Dankeschön! Deine Änderung des template tut was sie soll!

Sorry für meine (inzwischen wieder gelöschten) Beiträge, die haben dich (und ein paar andere) kostbare Le[b|s]enszeit gekostet. Ich war von der Komplexität der vielen MQTT messages einigermaßen verwirrt worden.

[Beta-User]

Ein großes Dankeschön! Deine Änderung des template tut was sie soll!

Danke für die Rückmeldung!

Sorry für meine (inzwischen wieder gelöschten) Beiträge, die haben dich (und ein paar andere) kostbare Le[b|s]enszeit gekostet. Ich war von der Komplexität der vielen MQTT messages einigermaßen verwirrt worden.

Schade eigentlich - das war zumindest mal ein erster Eindruck von den Doppelungen etc., die die firmware da bereithält.

Imo sollte jemand sich wirklich mal intensiver mit den diversen Einstellungsmöglichkeiten befassen, so dass wir am Ende dann "nur noch" das abonnieren und auswerten, was tatsächlich erforderlich ist. Das ganze ist in FHEM mehr oder weniger aus der Hüfte geschossen gewachsen, aber richtig gut strukturiert ist das noch viel weniger wie schon bei den Shelly der ersten Generation...

[alkazaa]

Schade eigentlich - das war zumindest mal ein erster Eindruck von den Doppelungen etc., die die firmware da bereithält.

OK, dann stelle ich hier den MQTT-Traffic des ShellyPuls2pm nochmal ein. Aber hier nur als screenshots, ist wegen der roten Event-Markierungen übersichtlicher. Textdateien gern als PN.

Betrachtet sind die zwei MQTT Benachrichtigungsstufen 'RPC Status Notification' und 'Generic Status update', die einzeln oder beide aktiviert sein können.
Du darfst diesen Dateianhang nicht ansehen.

Nur RPC Notifications (alle 60 sec, dieses Intervall ist nicht änderbar):
Du darfst diesen Dateianhang nicht ansehen.

Wird bei dieser Einstellung der externe Schalter (Kanal2 = input_1) bestätigt:
Du darfst diesen Dateianhang nicht ansehen.

Nur Generic Status Update (alle 60 sec)
Du darfst diesen Dateianhang nicht ansehen.

Wird bei dieser Einstellung der externe Schalter (Kanal2) bestätigt:
Du darfst diesen Dateianhang nicht ansehen.

Man erkennt, dass es ausreicht, nur eine der beiden Benachrichtigungsgruppen zu aktivieren.
Ich hab bisher zwei dieser Shelly-Typen im Cover-Mode für Raffstorestuerungen genutzt und dabei nur den 'Generic Status' Teil aktiviert, weil nur dann auch zeitnah benachrichtigt wurde, wenn die Raffstores per Schalter am Fenster gefahren werden. Deshalb hatte ich intuitiv das gleiche für die Shellies im Schalter-Mode probiert. Aber das dafür zuständige template wertet vor allem die RPC Status notifications aus.

Ich würds am besten finden, wenn man auch in dieser Situtation ein template hätte, dass 'Generic Status' Dinge topics liest. Alle relevante Info ist ja in beiden Datensätzen enthalten, wenn ich das richtig sehe. Sehe ich inzwischen anders, siehe nächsten Beitrag.

[alkazaa]

Ich habe den Zustand und das Verhalten des durch autocreate erzeugten FHEM devices in den beiden Situationen "nur Generic status update aktiv" und "nur RPC status notifications aktiv" (und ohne Anwendung eines template) nochmal im Detail angeschaut:

Die erzeugte readingList, wenn beim autocreate nur Generic status update aktiv ist:

Code Auswählen Erweitern

shellyplus2pm_d0ef76c732e4:shellyplus2pm-d0ef76c732e4/status/switch_1:.* { json2nameValue($EVENT, 'switch_1_', $JSONMAP) }
shellyplus2pm_d0ef76c732e4:shellyplus2pm-d0ef76c732e4/status/switch_0:.* { json2nameValue($EVENT, 'switch_0_', $JSONMAP) }
shellyplus2pm_d0ef76c732e4:shellyplus2pm-d0ef76c732e4/status/input_1:.* { json2nameValue($EVENT, 'input_1_', $JSONMAP) }
shellyplus2pm_d0ef76c732e4:shellyplus2pm-d0ef76c732e4/status/input_0:.* { json2nameValue($EVENT, 'input_0_', $JSONMAP) }Die beiden letzten Zeile tauchen erst auf, nachdem jeweils der externe Schalter für input_ bzw. input_0 betätigt wurde

Die erzeugte readingList, wenn beim autocreate nur RPC status notifications aktiv ist

Code Auswählen Erweitern

shellyplus2pm_d0ef76c732e4:shellyplus2pm-d0ef76c732e4/events/rpc:.* { json2nameValue($EVENT, 'rpc_', $JSONMAP) }Hier erzeugt das Betätigen der externen Schalter keine weiteren Einträge in der readingList.


Die folgenden MQTT traffic Auszüge sind dann nur für den Fall "nur RPC status notifications aktiv" 

MQTT traffic beim periodischen Report (alle 60 sec):

Code Auswählen Erweitern

17:59:00.066 shellyplus2pm_d0ef76c732e4 shellyplus2pm-d0ef76c732e4/events/rpc {"src":"shellyplus2pm-d0ef76c732e4","dst":"shellyplus2pm-d0ef76c732e4/events","method":"NotifyStatus","params":{"ts":1739897940.00,"switch:0":{"id":0,"aenergy":{"by_minute":[0.000,0.000,0.000],"minute_ts":1739897940,"total":0.000},"ret_aenergy":{"by_minute":[0.000,0.000,0.000],"minute_ts":1739897940,"total":0.000}}}}
17:59:00.088 shellyplus2pm_d0ef76c732e4 shellyplus2pm-d0ef76c732e4/events/rpc {"src":"shellyplus2pm-d0ef76c732e4","dst":"shellyplus2pm-d0ef76c732e4/events","method":"NotifyStatus","params":{"ts":1739897940.00,"switch:1":{"id":1,"aenergy":{"by_minute":[0.000,17.208,0.000],"minute_ts":1739897940,"total":1.043},"ret_aenergy":{"by_minute":[0.000,0.000,0.000],"minute_ts":1739897940,"total":0.000}}}}
MQTT Traffic nach Software switching in der web-Oberfläche des device:

Code Auswählen Erweitern

17:53:32.627 shellyplus2pm_d0ef76c732e4 shellyplus2pm-d0ef76c732e4/events/rpc {"src":"shellyplus2pm-d0ef76c732e4","dst":"shellyplus2pm-d0ef76c732e4/events","method":"NotifyStatus","params":{"ts":1739897612.65,"switch:1":{"id":1,"apower":0,"current":0,"output":false,"pf":0,"source":"WS_in"}}}
MQTT traffic nach Betätigung des externen Schalters (switch1):

Code Auswählen Erweitern

17:55:24.497 shellyplus2pm_d0ef76c732e4 shellyplus2pm-d0ef76c732e4/events/rpc {"src":"shellyplus2pm-d0ef76c732e4","dst":"shellyplus2pm-d0ef76c732e4/events","method":"NotifyStatus","params":{"ts":1739897724.45,"input:1":{"id":1,"state":true}}}
17:55:24.518 shellyplus2pm_d0ef76c732e4 shellyplus2pm-d0ef76c732e4/events/rpc {"src":"shellyplus2pm-d0ef76c732e4","dst":"shellyplus2pm-d0ef76c732e4/events","method":"NotifyStatus","params":{"ts":1739897724.45,"switch:1":{"id":1,"apower":0,"current":0,"output":false,"pf":0,"source":"switch"}}}
MQTT traffic nach Laständerung (Leuchtmittel nach dem Shelly ausgeschaltet):

Code Auswählen Erweitern

17:57:35.926 shellyplus2pm_d0ef76c732e4 shellyplus2pm-d0ef76c732e4/events/rpc {"src":"shellyplus2pm-d0ef76c732e4","dst":"shellyplus2pm-d0ef76c732e4/events","method":"NotifyStatus","params":{"ts":1739897854.91,"switch:1":{"id":1,"apower":0.0,"current":0.000}}}
Vielleicht hilft das bei der Verschlankung des split-templates für das ShellyPlus2pm. Ich selber versuche mich jetzt auch daran, bin aber noch immer irgendwo in der Lernkurve.