Support-Thread Modul 36_Shelly.pm

[gvzdus]

heißt das, dass im Shelly Modul die Readings für den Shelly3EM so bleiben können wie sie sind?

Ich würde schon vorschlagen, von "energy_returned" auf "energyReturned" zu gehen. Ich habe das so aus der Shelly-Doku von CoIoT übernommen.

Jetzt steuert der Shelly3EM meinen Victron und die OpenWB.

Gibt es eigentlich Erfahrungserte zur Genauigkeit der Shelly-Meter? Ein User hier im Forum hatte über 5% Abweichung bei einem ShellyPro3EM berichtet.
[/quote]

Eigentlich bin ich ganz happy nach den ersten Stunden: Auch, wenn gerade mehrere kW Ströme auf den Phasen fließen, regelt das selbst berechnete "power" aus dem Shelly 3EM den Speicher ganz gut an die Stromzählerwerte dran.

Saldierend kann ich keine Abweichung berechnen, da ja beim Shelly die Phasen einzeln saldiert werden, während "für uns Stromkunden" der Gesamtsaldo relevant ist. Das müsste jemand ohne PV beobachten.

[RalfRog]

ShellyMonitor habe ich angepasst

heißt das, dass im Shelly Modul die Readings für den Shelly3EM so bleiben können wie sie sind?

Hmmm...
Würde bedeuten, dass man 2 Sätze Readings hat. Einmal von Monitor energyReturned (per Multicast gepushed) und aus dem Modul energy_returned (per Intervall gepolled).
Die Bezeichnung des Monitors ist die, die auch in CoIot definiert ist (siehe <IP>/cit/d).

Edit
Hab ne Screenshot der cit/d - Ausgabe angehängt

[Starkstrombastler]

Ich würde schon vorschlagen, von "energy_returned" auf "energyReturned" zu gehen.

Danke für die Klärung, hab' nicht gecheckt, was im Monitor angepasst wurde. Mein Vorschlag: In der nächsten Testversion werden beide Readings parallel gesetzt, "energy_returned" wird dann in der übernächsten Version entfernt. User können somit ihre Settings anpassen.

In meiner eigenen Testumgebung habe ich für einen ShellyBulb im White-Modus einen Readings-Konflikt mit dem Monitor:
cloud           disabled
config          transition=5000 [channel 0]
ct              3000
energy          0.20
firmware        v1.13.0
network         connected to 192.168.10.222
network_disconnects 10
pct             7
power           0
relay_0         off
source          timer
state           off
timer           0
Da der ShellyBulb/white kein Relais und auch nur einen Kanal hat, wird im Modul der "state" auf "on" und "off" gesetzt.
Das Reading "relay_0" kommt vom Monitor und wirkt hier eher verwirrend.

[gamauf]

...
Solange wird hier mit Testversionen arbeiten, kann es schon mal vorkommen, dass Attribute in nicht vorgesehener Weise setzbar sind.
...

Das war nicht als Kritik, sondern als Frage/Feedback gemeint.
Mir ist schon klar, dass wir hier "work in progress" sind und mit soetwas zu rechnen ist.

Danke für deine Antworten!

[gvzdus]

In meiner eigenen Testumgebung habe ich für einen ShellyBulb im White-Modus einen Readings-Konflikt mit dem Monitor:
...
Da der ShellyBulb/white kein Relais und auch nur einen Kanal hat, wird im Modul der "state" auf "on" und "off" gesetzt.
Das Reading "relay_0" kommt vom Monitor und wirkt hier eher verwirrend.

Tja, was schlägst Du vor?
Den Plug_S z.B. schreibt ShellyMonitor als "relay", während Shelly auch "state" nimmt.
Jetzt überlege ich: Sollte ich, wenn ein Gerät nur einen "relay" hat, immer "state" als Ziel nehmen?
Dann gäbe es also für alles von Shelly 1 über 1pm u.s.w. nur noch "state", während es beim 2.5 dann "relay_0" und "relay_1" hieße.

[RalfRog]

Den Plug_S z.B. schreibt ShellyMonitor als "relay"

• Beim 3EM ist es auch relay (cit/d = relay_0) und im state steht im alten Modul aber ok (woraus auch immer das abgeleitet wird) => neues Modul on/off
  
  
• Wie du schreibst bei 1PM, Plug-S, PlugPlus-S relay und state on/off altes und neues Modul (auch hier cit/d = relay_0)

Das relay (oder relay_0) ist irgendwie einleuchtender. Inhaltlich ist es identisch zu state - bei anderen Switches ist mit state on/off meist auch der Schaltzustand abbildet. Zu bedenken gäbe es vielleicht noch den Umstand der SW-Eingänge (Wert 0/1) an die ja (default, veränderbar) das Relais gekoppelt ist.
Allerding klappt wahrscheinlich ein einfaches set <device> on/off nur wenn es an den state gekoppelt ist, oder?

[Starkstrombastler]

Zur anstehenden Diskussion zum Zusammenwirken der Shellies der ersten Generation mit dem ShellyMonitor habe ich nachstehende Zusammenfassung aufgestellt.

Im Shelly Modul ist für die Gen1-Devices folgende Logik wirksam:
A): Bei Geräten mit einem Relais wird der Zustand des Kanals gleichlautend in die Readings "state" und "relay" geschrieben ("on","off").
B): Bei Geräten mit einem Dimmer wird der Zustand des Kanals in das Reading "state" geschrieben ("off" oder Prozentwert).
C): Bei Geräten mit mehreren Relais wird der Zustand der Kanäle in Readings "relay_0|1..." geschrieben, das Reading "state" erhält den Wert "OK".
D): Bei Geräten mit zwei Relais im Roller-Mode wird der Zustand des Rollos in das Reading "state" geschrieben.
E): Bei Geräten mit mehreren Dimmern wird der Zustand der Kanäle in Readings "state_0|1..." geschrieben, das Reading "state" erhält den Wert "OK".

Bei allen Geräten wird im Fehlerfall eine Fehlermeldung (z.B. "Error") in das Reading "state" geschrieben.

zu den Geräten A) gehören alle Shelly1, ShellyPlug, ShellyUni, aber auch ShellyEM und Shelly3EM.
zu den Geräten B) gehören ShellyDimmer und alle ShellyBulb sowie ShellyRGBW im Color Mode
zu den Geräten C) gehören alle Shelly2 (im Relay Mode), Shelly4Pro
zu den Geräten D) gehören alle Shelly2 (im Roller Mode)
zu den Geräten E) gehört nur der ShellyRGBW im White Mode

Wie sieht die Logik für den ShellyMonitor aus?

[gvzdus]

ShellyMonitor ist viel systematischer gefasst (hoffe, pah bleibt jetzt ruhig).
Du hast im Code die Tabelle, die 1:1 vom Shelly-Modul kopiert ist:

# Copied from 36_Shelly, keep up to date..:
my %shelly_models = (
    #(relays,rollers,dimmers,meters,NG)
    "generic" => [4,4,4,4,0],
    "shellygeneric" => [4,4,4,4,0],

Im Monitor-Modul sind die Zeilen ab ca. 724 relevant: Im Prinzip wird alles in den nativen Reading-Namen geschrieben. Gibt es in der "shelly_models"-Tabelle nur eine 1, dann heißt der Wert "power" (und nicht "power_0"). Daher auch "relay_0": Der Bulb hat in der Definition keinen Relay, daher wird auch "relay_0" beschrieben (denn 0!=1).
"state" wird nur beim Roller-Mode beschrieben - ich fand' "state" immer einen unsystematischen Bastard.
Aber wir können das jetzt gerne mal sauber ziehen, sodass es wirklich keinen Unterschied macht, ob ShellyMonitor oder Shelly den Status schreibt.

[Starkstrombastler]

ShellyMonitor ist viel systematischer gefasst (hoffe, pah bleibt jetzt ruhig).

Das kann schon sein, ShellyMonitor kam später und macht auch weniger. Das ist sicher von Vorteil, wenn Code neu aufgesetzt wird. Für mich ist das, was im Shelly Modul für die Gen1 codiert ist gewisssermaßen "Erbmasse", nicht zuletzt weil dies so bei hunderten Usern produktiv im Einsatz ist. Neben ein paar Bugs habe ich den Code hier und da etwas generischer gefasst, aber Readings sind vom Ansatz her unverändert geblieben.

Im Prinzip wird alles in den nativen Reading-Namen geschrieben.

Die Shellies haben vom Design her drei verschiedene Outputs, nämlich relay, roller und lights (dimmer). Außerdem gibt es noch meters und inputs.

Bei einkanaligen Shellies wird der Kanalstatus in state geschrieben. Ausnahme: Relais-Typen, hier wird zusätzlich das Reading relay beschrieben (*).

Bei mehrkanaligen Shellies wird  der Kanalstatus in Readings entsprechend der Output-Typen geschrieben, nämlich:
relay_0|1...
roller_0|1...  (wird erst mit dem Gen2-Dual-Shutter relevant)
state_0|1...  (müsste eigentlich dimmer_0|1... etc heißen oder light_0|1...)  (**)
Das erscheint mir doch logischer als bei einem Shelly, welcher definitiv kein Relais besitzt, ein Reading relay_0 zu beschreiben.

Zur Ausnahme (*) kann ich mir vorstellen, auf das Reading relay zu verzichten, damit weiterhin Befehle set device on|off|... ohne Zusatzaufwand funktionieren. Bei den mehrkanaligen Shellies wird dies durch das Attribut defchannel bzw. durch das Generien von readingsProxy-Devices erreicht.

Zu Ausnahme (**) hat vielleicht jemand einen griffigen Namen für entsprechende Readings, um somit nicht in Konflikt mit state zu stehen. dimmer oder light sind auch nicht optimal, wenn z.B. mit einem ShellyRGBW 24V-Heizkörperventile angetrieben werden.

[gvzdus]

Ich kann die Hässlichkeit schon nachvollziehen.
Ich habe erstmal geändert, dass bei allen Geräten, die laut Spec "0 Relais" haben (also Bulb, Dimmer, u.s.w.) nicht relay_0 geschrieben wird, sondern "state".

Die Version packe ich vorerst nicht ins SVN, sondern hänge sie an.

Nach dem Einspielen (+ "reload 36_ShellyMonitor") der Tipp:
Aufräumen (Löschen aller Bestandsreadings) mit "deletereading .* relay_0"

[RalfRog]

Nur zur Sicherheit:
Trotz Angabe "$Id: 36_ShellyMonitor.pm 26929 2022-12-29 19:28:42Z gvzdus $" im Anhang der #564
basiert die Version aber auf dem letzten
Update im SVN 27691 "$Id: 36_ShellyMonitor.pm 27961 2023-09-13 12:05:24Z gvzdus $"

Also quasi "alles drin".

Gruß

[gvzdus]

Ja! 
Ich pfusche auf meinem Live-System rum, teste, und kopiere dann rüber auf den Laptop und checke ein.

[gvzdus]

Die Version war buggy.
Ich habe eine korrigierte Version jetzt mit diversen Geräten (Bulb, Plug-S, 2.5 Rollermode, 2.5 Relaismode) getestet und ins SVN eingespielt.

[RalfRog]

Ok
Oberflächlich scheint/schien 3EM,1PM Energy ok.

Schau ich mal genauer mit der SVN-Version und steck den Plug-S und Shelly1 dazu.

[gvzdus]

Falls Du heute Abend noch nichts vor hast
Hier ist sie schon mal (bis auf die SVN-Versionsnummer)