Support-Thread Modul 36_Shelly.pm

[RalfRog]

Ich fange nochmal an und verwende diese Schreibweise.
=>  http://192.168.178.99:8083/fhem?XHR=1&cmd=set%20Y175%20out_on%200
CSRF-Token hatte ich zu Test deaktiviert.

Zumindest, dass initial nichts angelegt wird ist klar 

[RalfRog]

So Fazit zum PlusPlug

Statt vorher http://11.12.13.24:8083/fhem?cmd=set%20Plug%20on habe ich deinem Beitrag #463 folgend
neu die Schreibweise http://11.12.13.24:8083/fhem?XHR=1&cmd=set%20Plug%20on verwendet.

• beim definieren des Attributs webhooks werden kein keine Actions automatisch angelegt
• Actions ohne  _  im Namen bleiben in Ordnung, egal wie geschrieben
• die Schreibweise der URL in den Actions mit "/fhem?XHR=1&cmd=set" wird nicht "kaputt" geschrieben (Ursache vermutlich der Token Mechanismus)
• bei aktivem CSRF-Token findet eine Aktualisierung der Actions mit dem Token statt

Die vorab angelegte Action wurde beim Anlegen des Attributs nicht verändert (der Namenskonvention folgend _Name_).

Code Auswählen Erweitern

2023.07.15 20:25:15.558 4: [Shelly_shelly] PPlug is a second Gen device
2023.07.15 20:25:15.561 4: [Shelly_shelly] issue a non-blocking call to http://10.20.30.94/rpc/Shelly.GetStatus
2023.07.15 20:25:15.569 4: [Shelly_shelly] issue a non-blocking call to http://10.20.30.94/rpc/Shelly.GetConfig
2023.07.15 20:25:15.580 4: [Shelly_shelly] issue a non-blocking call to http://10.20.30.94/rpc/Shelly.GetDeviceInfo
2023.07.15 20:25:15.590 4: [Shelly_webhook] device PPlug was called with command=Check
2023.07.15 20:25:15.593 4: [Shelly_webhook] device PPlug will be called by Webhook.
2023.07.15 20:25:15.598 4: [Shelly_webhook] issue a non-blocking call to http://10.20.30.94/rpc/Webhook.List
2023.07.15 20:25:15.607 4: [Shelly_shelly] PPlug: long update in 300 seconds
2023.07.15 20:25:15.769 4: [Shelly_proc2G] device PPlug processing component info
2023.07.15 20:25:15.773 4: [Shelly_proc2G:info] PPlug: processing the answer rpc/Shelly.GetDeviceInfo from Shelly_shelly()
2023.07.15 20:25:15.782 4: [Shelly_proc2G] device PPlug processing component config
2023.07.15 20:25:15.787 4: [Shelly_proc2G:config] PPlug: processing the answer rpc/Shelly.GetConfig from Shelly_shelly()
2023.07.15 20:25:15.797 4: [Shelly_proc2G] device PPlug processing component status
2023.07.15 20:25:15.801 4: [Shelly_proc2G:status] PPlug: processing the answer rpc/Shelly.GetStatus from Shelly_shelly()
2023.07.15 20:25:15.832 4: [Shelly_webhook] device PPlug was called with command=Check
2023.07.15 20:25:15.836 4: [Shelly_webhook] processing the webhook data for command=Check
2023.07.15 20:25:15.839 4: [Shelly_webhook] our counter says 1 webhooks on shelly
2023.07.15 20:25:15.843 4: [Shelly_webhook_url] calling url-builder with args: PPlug  0 ch:0 noe:0
2023.07.15 20:25:15.905 4: [Shelly_webhook_url] the host-ip of PPlug is: 10.20.30.40
2023.07.15 20:25:15.909 4: [Shelly_webhook_url] FHEMweb-device is: WEB
2023.07.15 20:25:15.912 4: [Shelly_webhook_url] FHEMweb port is: 8083
2023.07.15 20:25:15.916 4: [Shelly_webhook_url] FHEMweb-device "WEB" has port "8083" and webname "fhem"
2023.07.15 20:25:15.919 4: [Shelly_webhook_url] the token-string is:
2023.07.15 20:25:15.923 4: [Shelly_webhook_url] PPlug: the fhem command is: "get PPlug status"
2023.07.15 20:25:15.926 4: [Shelly_webhookurl] PPlug: &urls=[%22%26cmd=get%2520PPlug%2520status%22]
2023.07.15 20:25:15.988 4: [Shelly_webhook] shellies PPlug webhook 0 is http://10.20.30.40:8083/fhem?XHR=1&cmd=set%2520Plug%2520on
2023.07.15 20:25:15.993 4: [Shelly_webhook] 0 checking part1 of url:
http://10.20.30.40:8083/fhem?XHR=1    against
http://10.20.30.40:8083/fhem?XHR=1
   command is: "%26cmd=set%2520Plug%2520on"
2023.07.15 20:25:15.996 4: [Shelly_webhook] 0 check is OK, nothing to do

Die ganze Sache funktioniert aber von Handling her auch ohne Modul genau so (aus meiner Sicht). Liegt aber vermutlich an noch fehlenden Anteilen für den PlusPlug.
Die Readings "webhook_cnt" & "webhook_ver" könnten verwendet werden.

Nach Reaktivierung des CSRF-Tokens wird es beim nächsten zyklischen Update eingefügt. VORTEIL Modul -> Satz und Sieg     
Bedingung: fhem?XHR=1&cmd=...  (in der Hilfe erwähnenswert)


Was kann ich dir zuliefern?

[benz_freak]

Diese Logzeile ist hilfreich und führt zur Zeile 2128 in 36_Shelly.pm. Die Zeile muss wie folgt lauten:

Code Auswählen Erweitern

    my $comp = AttrVal($name,"mode","relay");
Damit läuft es jetzt, Danke.

[Starkstrombastler]

Was kann ich dir zuliefern?

Ich fasse mal deine Testergebnisse wie folgt zusammen:

• Der Webhook-Mechanismus funktioniert vom Grundsatz her
• Es gibt noch einige Schwächen/Fehler im Code (allgemein oder speziell bzgl. ShellyPlug)
• Die Bedeutung der ACTIONS der Shellies dürfte vielen Nutzern unbekannt sein.

zu 1.
Grundlagen sind in der Hilfe/Commandref dargestellt, aber wahrscheinlich viel zu "spröde". Der Mechanismus kann wahrscheinlich im FhemWiki "Modul Shelly" besser dargestellt werden.
  --> Ich werde mir mal eine tiefergehende Struktur für den Artikel überlegen, Vorlagen gibt's wahrscheinlich reichlich. Vorschläge?

zu 2.
Punkt für Punkt abarbeiten. Ich selbst habe auch ein unerwünschtes Verhalten ("kaputt schreiben") im Zusammenhang mit dem Löschen von Devices entdeckt.
  --> Fehler beheben --> neues Update

zu 3.
Das Thema ist an sich unabhängig von Fhem, da mit den Actions die Shellies untereinander oder auch mit anderen Geräten/Systemen kommunizieren können. Das schließt auch die Shellies der 1. Gen mit ein. Ich kann mir dafür einen eigenen Artikel im FhemWiki vorstellen. Wahrscheinlich findet man im Netz auch brauchbare Vorlagen.
  --> das ist eine Einladung an die Community!

[carlos]

Hallo,
Ich habe die Vermutung, daß die Modelle irgendwie nicht gleich behandelt werden:

Ein shellyplus1pm:

Readings:

Code Auswählen Erweitern

relay on 2023-07-15 10:08:58
state on 2023-07-15 17:35:07
bei state würde ich gerne OK sehen!

Ein shellyplus2pm:

Readings:

Code Auswählen Erweitern

relay_0 on 2023-03-09 11:36:59
relay_1 on 2023-03-09 11:36:59
state OK 2023-07-16 11:46:02

Bei shellyplus1:

Readings:

Code Auswählen Erweitern

relay off 2023-07-16 09:29:19
state off 2023-07-16 09:29:19
Auch hier bei state würde ich gerne OK sehen!

Das state reading ist doch der Status des Shelly oder sehe ich das falsch?
Könnte man das vereinheitlichen? Oder ist das so gewollt?

EDIT:
Als Erweiterung wären noch jeweils die Namen vom Shelly selbst mit Input und Output Namen als reading nicht schlecht.

Gruß

Hubert

[Starkstrombastler]

Das state reading ist doch der Status des Shelly oder sehe ich das falsch?
Könnte man das vereinheitlichen? Oder ist das so gewollt?

Nun, was ist der Status?
Allgemein wird in Fhem das reading 'state' auf das Internal 'STATE' abgebildet, und dieses wiederum mittels devStateIcon grafisch dargestellt.
Das funktioniert aber nicht so einfach, wenn ein Gerät mehrere Kanäle hat (z.B. Shelly2.* im Relay-Modus). Hier muss der User das Verhalten mittels dem Attribut 'stateFormat' festlegen.

Insofern ist das beschriebene Verhalten genau so wie es sein soll.

Als Erweiterung wären noch jeweils die Namen vom Shelly selbst mit Input und Output Namen als reading nicht schlecht.

Naheliegend wäre es, den Namen des Shelly (aus Device Info des Shelly) mittels Attribut mit dem Namen des Fhem-Devices gleich zu schalten. Kommt mit dem nächsten Update.

Bei den Namen der Eingänge, Ausgänge bzw. Kanäle allgemein müssten das Attribut 'defchannel' und angelegte Proxy-Devices berücksichtigt werden. Das wird etwas länger dauern...

[hauwech]

Hallo zusammen,
was muß man denn einstellen, wenn man vom shellyplus1pm die Meßreadings haben möchte (power usw.)?
Wenn man einen shellyplus1pm als fhem Device anlegt, kriegt er automatisch das model shellyplus1pm verpaßt. Wenn ich das model einmal auf generic umstelle und dann wieder shellyplus1pm auswähle, kommen auf einmal mehr Attribute, die man aber nicht verwenden kann. Wenn ich versuche, wie im Wiki empfohlen, mode auf "relay" zu stellen, kommt die Meldung, das sei für dieses Device nicht möglich.
Beim shellyplug z.B. tauchen die Meßreadings automatisch nach dem Define auf.

Gruß Roland

[Starkstrombastler]

Hallo Roland,

es gibt noch einen kleinen Bug in der aktuellen Version, den kannst du durch Ändern in der Zeile 2128 der 36_Shelly.pm leicht ändern, siehe Beitrag hier:

Diese Logzeile ist hilfreich und führt zur Zeile 2128 in 36_Shelly.pm. Die Zeile muss wie folgt lauten:

Code Auswählen Erweitern

    my $comp = AttrVal($name,"mode","relay");

Wenn du das änderst, kommen alle Readings automatisch herein. Damit es besser lesbar ist, kannst du noch z.B.

Code Auswählen Erweitern

attr <name> showunits normal2 festlegen (wird mit der nächsten Aktualisierung sichtbar).

Der Bug wird mit dem nächsten Update behoben.

Es wird stets die Möglichkeit angeboten, einen Shelly als model generic zu betreiben und dann werden alle Attribute sichtbar. Beim Zurückgehen auf das tatsächliche model werden die Attribute nicht erneut ausgeblendet. Das kannst du erreichen, indem das Device mittels DEF oder defmod ... neu definiert wird.
Die Empfehlung im Wiki bezieht sich im Übrigen auf die diversen Shelly2, weil die tatsächlich im relay oder roller mode betrieben werden können.
ShellyPlug ist mit Firmware der 1. Gen, das wird im Modul separat behandelt.

[curt]

Real fehlt (mir) ein reading, welches die Zustände "fährt hoch", "fährt runter", "nix passiert" haben kann. Falls es das schon gibt habe ich es übersehen.

schau dir mal das Reading 'state' an: es nimmt beim Fahren die Werte 'drive-up' bzw. 'drive-down' an. Und im Stillstand zeigt es die ungefähre Position in der Form 'pct-ii'.

Ist nicht ganz ideal, aber das nehmen wir. Und damit spätere Nutzer auch etwas davon haben, beschreibe ich meinen Weg und das Ergebnis - es geht um die Einbindung in FTUI3. Hinweis: Das ist ein Template für FTUI3, ich habe ja viele einzubindende Rollläden...

Ausgangsbedingung ist, dass ich eine ganze Anzahl von Rollläden habe. Weiterhin gibt es in diesem Haus ein Nutzerverhalten, was für Rollläden nur die Zustände "auf" und "zu" gibt; das heißt, dass für die Bewohner ein halb geöffneter Rollladen im realen Leben als Fehlerzustand gilt.

Rechts gibt es Knöpfe für "aufmachen" und "zumachen", die Farbe signalisiert, welche Richtung sinnvoll ist: Wenn der Rollladen schon zu ist, ist "zumachen" ausgegraut. Links ist der Zustand des Rollladen, darauf kann man zudem auch klicken, dann wird "Stop" ausgelöst.

Hier der FTUI3-Code:

Code Auswählen Erweitern

<ftui-row>
 <ftui-label margin="-1px 0 0 0" class="size-0">{{Roll_Name}}</ftui-label>
</ftui-row>
<ftui-row>
 <ftui-column>
  <ftui-row>
          <ftui-icon margin="0 -15px 0 0" size="3" @click="javascript:sendFhem('set {{Roll}} stop')"
           [name]="{{Roll}}:state | map('drive-up:arrow-up, drive-down:arrow-down, pct-0:window-shutter, pct-100:window-shutter-open, .*:window-shutter-alert')"
           [color]="{{Roll}}:state | map('drive-up:my_signalgreen, drive-down:my_signalgreen, pct-0:my_blue, pct-100:my_yellow, .*:my_signalred')">
   </ftui-icon>
  </ftui-row>
 </ftui-column>
 <ftui-column>
  <ftui-row>
   <ftui-button [(value)]="{{Roll}}"
               states="open" fill="none">
    <ftui-icon margin="-1px -10px 0 0" name="arrow-circle-up" class="size-0"
           [color]="{{Roll}}:state | map('pct-0:my_green, pct-100:my_grey2, pct-.*:my_green, .*:my_grey2')">
    </ftui-icon>
   </ftui-button>
  </ftui-row>
  <ftui-row>
   <ftui-button [(value)]="{{Roll}}"
               states="closed" fill="none">
    <ftui-icon margin="-1px -10px 0 0" name="arrow-circle-down" class="size-0"
           [color]="{{Roll}}:state | map('pct-0:my_grey2, pct-100:my_green, pct-.*:my_green, .*:my_grey2')">
    </ftui-icon>
   </ftui-button>
  </ftui-row>
 </ftui-column>
</ftui-row>

Der Aufruf des Templates:

Code Auswählen Erweitern

      <ftui-grid-tile row="2" col="8" height="1" width="1" color="my_grey3">
       <ftui-content file="./roll_unten/template_rollladen.html"
                Roll_Name="Terrasse links"
                Roll="Roll_WZ_Terrasse_links">
        </ftui-content>
      </ftui-grid-tile>


[curt]

• Der Webhook-Mechanismus funktioniert vom Grundsatz her

zu 1.
Grundlagen sind in der Hilfe/Commandref dargestellt, aber wahrscheinlich viel zu "spröde". Der Mechanismus kann wahrscheinlich im FhemWiki "Modul Shelly" besser dargestellt werden.
  --> Ich werde mir mal eine tiefergehende Struktur für den Artikel überlegen, Vorlagen gibt's wahrscheinlich reichlich. Vorschläge?

Da biete ich mich doch glatt als Testuser, als Versuchskaninchen an:

* Ich würde gern wissen, was das eigentlich ist - es sind wohl verschiedene URL, die bezogen auf die IP des Shelly irgendwas auslösen. Damit ergibt sich die erste Frage: Wofür könnte man das brauchen? Kann das was, was man über FHEM nicht kann? Oder worin liegt der Vorteil?

* Wenn ich die URL genutzt habe, gibt es (las ich im Augenwinkel) ein Feedback. Wie sieht das aus? Was kann ich damit anstellen?

* Wichtig ist zudem ein simples, sofort einleuchtendes Beispiel.

Hoffe geholfen zu haben.

[Starkstrombastler]

Ich würde gern wissen, was das eigentlich ist - es sind wohl verschiedene URL, die bezogen auf die IP des Shelly irgendwas auslösen.

Zur Erläuterung zitiere ich mal aus der Wikipedia: Remote Procedure Call (RPC; englisch für ,,Aufruf einer fernen Prozedur") ist eine Technik zur Realisierung von Interprozesskommunikation. Sie ermöglicht den Aufruf von Funktionen in anderen Adressräumen. Im Normalfall werden die aufgerufenen Funktionen auf einem anderen Computer als das aufrufende Programm ausgeführt.
In einfachen Worten: Das wird vom Shelly-Modul zur Kommunikation zwischen Fhem und den Shellies benutzt. Dazu sendet Fhem eine Anfrage an den Shelly, und dieser liefert eine Antwort. Das ganze in einem festen Intervall, z.B. 60 Sekunden (Polling). 
Die Shellies bieten aber auch die Möglichkeit bei Eintreten bestimmter Ereignisse von sich aus Meldungen abzusetzen, auf den Shellies nennt sich dies actions.

Beispiel
Ereignis: Ein am Shelly angeschlossener Schalter wurde betätigt
Ergebnis: Der Ausgang (Relais) des Shelly wurde eingeschaltet
Action:   Der Shelly sendet eine Meldung an ein anderes Gerät (Shelly, Fhem, oder etwas anderes)

Die Action muss aber auf dem Shelly hinterlegt sein, wie sonst soll der Shelly wissen, was zu tun ist?
Und genau daraum kümmert sich der Webhook-Mechanismus im Shelly-Modul: Für alle Ereignisse, welche die diversen Shellies kennen, werden Meldungen in Richtung Fhem auf dem Shelly angelegt (URLs). Das hat den Vorteil, dass die Informationen nicht erst beim nächsten Polling, sondern sofort bei Fhem ankommen.

Zur Illustration stelle man sich einmal eine Bestandinstallation mit einem 230V Bewegungsmelder vor. Dessen Ausgang wird an einen detached Eingang eines Shelly angeschlossen. Eine auf dem Shelly angelegte Action sendet eine URL an Fhem und Fhem kann mit den gewohnten Methoden reagieren. Im Beispiel wird der Ausgang des Shelly eingeschaltet, sofern es Nacht ist.

anderes Beispiel:
Nutzer betätigt Taste am Rollo -> Rollo fährt hoch -> Shelly meldet an Fhem 'Rollo fährt hoch'
Rollo kommt oben an -> Shelly meldet an Fhem 'Rollo geöffnet'

Der Webhook-Mechanismus des Shelly-Moduls ist derzeit noch in Entwicklung, es gibt noch ein paar Stellen wo es noch nicht richtig läuft. Aber wenn es dann funktioniert, muss sich ein Nutzer nicht zwangsläufig damit beschäftigen.

Zur Vollständigkeit muss aber noch erwähnt werden, dass die Shellies auch noch die Protokolle MQTT und ColoT (nur Gen1) beherrschen, aber diese sind nicht Bestandteil des hier diskutierten Shelly Moduls.

[RalfRog]

Hi
Curt schau dir das mit den Actions mal direkt auf dem Shelly an.

Ich hätte folgende Anwendung:
Ich nutze einen 1PM (Gen1) um den Ertrag meines BKW zu messen. Man kann den Eingang SW vom Shelly unabhängig vom Relais (Stichwort Detach) betreiben. Das tue ich - ein Reed-Kontakt gibt den Zustand des Garagentors auf SW weiter.
So kann ich den Zustand des Tores sehen. Abhängig davon wie das Poll-Intervall eingestellt ist - mehr oder weniger schnell.
Wenn man nun nicht jede Minute pollen möchte kann man eine Action auf dem Shelly hinterlegen. Sobald sich der Zustand am SW-Eingang ändert meldet der Shelly spontan und selbständig.
In meinem Fall könnte er dann per URL (Action im Shelly) etwas an Fhem senden (CSRF Token Problematik beachten)

Code Auswählen Erweitern

http://FHEM-IP:8083/fhem?XHR=1&cmd=setreading Tor offen
Starkstrombastler unterstützt das mit dem Webhook-Mechanismus.
Er schaut unter anderem nach ob eine Action hinterlegt ist und korrigiert wenn nötig die hinterlegte URL - ergänzt z. B. das gerade aktuelle Token.

Gruß Ralf

[curt]

Ich danke euch beiden für die Erklärung. Eigentlich wollte ich dazuschreiben, dass damit ein Teil des Wiki-Artikels schon geschrieben ist ... bis mir auffiel, dass die Problematik ja auch auf shellyplus2pm zutrifft: Die Teuerste bedient den Rolladen vom Tastenfeld. Gna.

Ich befürchte, ich werde auch ganz praktisch Versuchskaninchen. Aber nicht gleich heute ... die nächsten Tage.

[spi3845]

Hallo zusammen,

ich habe einen Shelly Plus 1 per Shelly Modul angebunden. Im Shelly sind Action-URLs hinterlegt, um das Schalten des Relays und des (detached) Eingangs ("Button") an fhem zu signalisieren. Fhem selbst fragt den Shelly zusätzlich alle 60 Sekunden ab.

Was ich nicht hinbekomme, ist den Zustand der Readings button und relay sauber zu loggen - event-min-interval interessiert meinen Shelly nicht, es werden nach der eingestellten Zeit keine Events generiert und es landet nichts im FileLog. Für event-on-change und event-on-update habe ich unterschiedliche Einstellungen versucht, hat am Ergebnis nichts geändert.

Es werden nur state und inttemp regelmässig ins FileLog geschrieben, relay und button nicht. Und ich würde diese beiden Readings gerne einmal in der Minute sehen, auch wenn sie sich nicht geändert haben.

Damit mein Plot nicht abreißt, habe ich im FileLog

addLog Haustuer:button.*:60,Haustuer:relay.*:60

gesetzt, damit die Einträge dort auftauchen, aber das Verhalten von event-min-interval verstehe ich nicht.

Hätte jemand eine Erklärung parat?

Danke,
Sebastian

Code Auswählen Erweitern

Internals:
  DEF        192.168.251.40
  DURATION  0
  FUUID      643c0fc6-f33f-4699-c064-6862c9486b3b5bc9
  INTERVAL  60
  NAME      Haustuer
  NR        871
  STATE      Öffner
1:off
Schloss
2:on
Empfang
3:OK
  TCPIP      192.168.251.40
  TYPE      Shelly
  eventCount 94491
  READINGS:
    2023-07-19 15:02:32  button          on
    2023-07-19 15:24:22  inttemp        53.3
    2023-07-19 04:01:47  network        <html>connected to <a href="http://192.168.251.40">192.168.251.40</a></html>
    2023-07-19 15:03:50  relay          off
    2023-07-19 15:24:22  state          OK
Attributes:
  comment    devStateIcon = 1.on:10px-kreis-gruen:noFhemwebLink 1.off:10px-kreis-weiss:noFhemwebLink 2.on:10px-kreis-gruen:noFhemwebLink 2.off:10px-kreis-rot:noFhemwebLink 3.OK:10px-kreis-gruen:noFhemwebLink 3.*:10px-kreis-rot:noFhemwebLink .*::
stateFormat = {sprintf("Relay\n1:%s\nButton\n2:%s\nStatus\n3:%s", ReadingsVal($name,"relay","0"), ReadingsVal($name,"button","0"), ReadingsVal($name,"state","0"))}
  devStateIcon 1.on:10px-kreis-gruen:noFhemwebLink 1.off:10px-kreis-weiss:noFhemwebLink 2.on:10px-kreis-gruen:noFhemwebLink 2.off:10px-kreis-rot:noFhemwebLink 3.OK:10px-kreis-gruen:noFhemwebLink 3.*:10px-kreis-rot:noFhemwebLink .*::
  event-min-interval .*:60
  group      Haustür
  interval  60
  model      shellyplus1
  room      EG,Status
  shellyuser admin
  stateFormat {sprintf("Öffner\n1:%s\nSchloss\n2:%s\nEmpfang\n3:%s", ReadingsVal($name,"relay","0"), ReadingsVal($name,"button","0"), ReadingsVal($name,"state","0"))}
  userReadings button
  webCmd    :


[RalfRog]

Hallo
Um Events zu loggen müssen sie überhaupt erstmal erzeugt werden. Die Event* Attribute filtern die Events - wenn kein Event da war hilft auch keines der Attribute es her zu zaubern.
(andersherum wird ein Schuh draus: wenn alle 15 sek. ein Event entsteht würdest du mit "event-min-interval .*:60" dafür sorgen, dass es nur alle min. 60 sek. durchkommt und geloggt wird)

Ich meine beim OriginalModul irgendwo in den Erklärungen von PAH gelesen zu haben, dass intern im Modul nur dann Events erzeugt werden wenn die ausgelesenen Werte  sich geändert haben. Da gibt es wohl unterschiedliche Funktionen (readingsBulkUpdateIfChanged) in FHEM für die Developer.

Wenn Starkstrombastler das Modul-Gerüst so belassen hat, wird sich daran nichts geändert haben.

Ich habe an meinem Shelly1PM gerade nachgeschaut. Das Reading relay hat auch einen "alten" Zeitstempel 3.6 (firmware sogar 16.5.).