Support-Thread Modul 36_Shelly.pm

[Starkstrombastler]

Shelly Plus 2PM (Doppelsteckdose)
Shelly Plus 1PM (Steckdose)
Shelly Plus Plug S (einzelne Geräte)

am Wochenende sollen noch folgen:
Shelly Plus 2PM (Doppellichtschalter)
Shelly Plus 1PM (Einzellichtschalter)
Shelly Plus i4 (Szenenauswahl)

Da die Shelly Plus 2PM in meiner Testumgebung vorhanden sind, sollten diese auf Anhieb funktionieren, auch mit automatisch angelegten Webhooks.
Shelly Plus 1PM auch, aber der ist bisher nicht getestet.
Zum i4 siehe Posting oben, Thema ist in Arbeit.

[Starkstrombastler]

Rename von "returnedTTL" zu "energy_returnedTTL", dann steht es beisammen und ist leichter zu efassen.

--> nächste Modulversion.

Aber:
In der FHEM-Welt gibt es ja bereits diverse Zähler. Kennt jemand einen Ansatz für FHEM-einheitliche Leistungs- und Energie-Readings? Immerhin steht das EM in FHEM ja für Energie-Monitoring.

Auch der ShellyPro3EM wird vom Modul unterstützt. Hat das bereits jemand ausprobiert und die verschiedenen Attribute getestet?

[Starkstrombastler]

ich habe einen neuen Shelly Uni.
Die Temperatur wird in den Readings angezeigt.
Die gemessene Spannung vom ADC und der Status der Sensor-Eingänge fehlen aber.

Die Spannung sollte mit der letzten Modulfassung vom 6. Mai ausgewertet werden.  Welche Readings fehlen denn genau? Bitte das Ergebnis von 
<ip-adresse_des_Shelly>/status
 hier posten.

[RalfRog]

@Starkstrombastler:

Im log ist nach dem Restart und vorheriger Definition meines Plug als shellybulb:

Code Auswählen Erweitern

2023.05.13 09:05:04.846 1: [Shelly_get_model] standard decoding: has invalid JSON data for device Shelly_Plug
2023.05.13 09:05:04.851 1: [Shelly_get_model] decoded JSON with relaxed decoding for device Shelly_Plug
2023.05.13 09:05:04.852 1: [Shelly_get_model] discovered model=shellyplug for device Shelly_Plug
2023.05.13 09:07:52.739 2: Defined real device Shelly_Plug for 11.12.13.19 as model shellyplug
2023.05.13 09:07:52.742 1: Assigning device Shelly_Plug SHELLYID DF2674

Ist das Verhalten des Moduls ein falsch gesetztes Model auch nachträglich zu korrigieren korrekt?

[Lichti]

Beim Uni fehlen (Version vom 6.Mai):
Spannung vom ADC
Status vom Input 1
Status vom Input 2

Hier der Status vom Uni:

Code Auswählen Erweitern


wifi_sta
connected true
ssid "FDW30"
ip "192.168.178.60"
rssi -52
cloud
enabled true
connected true
mqtt
connected false
time "18:01"
unixtime 1683993665
serial 167
has_update false
mac "C45BBE6C639D"
cfg_changed_cnt 0
actions_stats
skipped 0
relays
0
ison false
has_timer false
timer_started 0
timer_duration 0
timer_remaining 0
source "http"
1
ison false
has_timer false
timer_started 0
timer_duration 0
timer_remaining 0
source "http"
inputs
0
input 0
event ""
event_cnt 1
1
input 0
event ""
event_cnt 1
adcs
0
voltage 0
ext_sensors
temperature_unit "C"
ext_temperature
0
hwID "28146495f0ff3ce6"
tC 23.88
tF 74.97
ext_humidity {}
update
status "idle"
has_update false
new_version "20230503-102354/v1.13.0-g9aed950"
old_version "20230503-102354/v1.13.0-g9aed950"
ram_total 50776
ram_free 36832
fs_size 233681
fs_free 141815
uptime 26229


[RalfRog]

Rename von "returnedTTL" zu "energy_returnedTTL", dann steht es beisammen und ist leichter zu efassen.

--> nächste Modulversion.

Aber:
In der FHEM-Welt gibt es ja bereits diverse Zähler. Kennt jemand einen Ansatz für FHEM-einheitliche Leistungs- und Energie-Readings? Immerhin steht das EM in FHEM ja für Energie-Monitoring.

Auch der ShellyPro3EM wird vom Modul unterstützt. Hat das bereits jemand ausprobiert und die verschiedenen Attribute getestet?

Hallo Starkstrombastler

Im Zusammenhang mit dem Shelly_Monitor (von  gvzdus) gibt es auch noch eine Unsauberkeit, deren Verursacher vermutlich ich bin.

Zum Jahreswechsel hatte ich gvzdus kontaktiert (https://forum.fhem.de/index.php?msg=1253662) und er hat den Shelly 3EM ergänzt und die Maßeinheit Wh/Wm für Energie korrigiert.
Auf meinen Vorschlag hin hat er noch das Readings ""energyReturned" nachgepflegt. Aus jetziger Sicht ist die Namensgebung sicher unglücklich (ich hatte mir damals keine tieferen Gedanken gemacht).

Besteht die Möglichkeit einer Abstimmung um das praktikabel (auch im Hinblick auf Gen2 Namensgebung) hinzubekommen?


Gruß Ralf

[THZ_Haus]

zu a) wie lautet denn bei den auffälligen Shellies das Internal 'SHELLY' ? Falls das nicht vorhanden ist, bitte über den Browser folgende Anfrage absetzen:  <ip-adresse_des_Shelly>/settings
Die Antwort des Shelly unter device:type:  hier posten (z.B. "SHBLB-1").

Habs gerade geprüft, Auszug:
device   
type   "SHBDUO-1"

Dann ist das Umstellen auf "shellybulp" auch falsch, und der Typ SHBDUO-1 wird noch nicht unterstützt?

[Starkstrombastler]

Ist das Verhalten des Moduls ein falsch gesetztes Model auch nachträglich zu korrigieren korrekt?

An sich schon, weil es für jede Shelly-Hardware eben nur ein Model gibt, was diese Hardware abbildet. Mit Einführung der Autoerkennung wäre es vielleicht am besten, ganz auf das Attribut 'model' zu verzichten. Außer man möchte, dass ein Gerät als 'generic' dargestellt wird. Ein weiterer Grund für das Attribut wäre eine nicht erfolgreiche Autoerkennung.
Und so ist die Autoerkennung auch umgesetzt: bei erfolgreicher Autoerkennung wird eben nur das erkannte model und 'generic' als Auswahl für das Attribut 'model' zugelassen. Außerdem werden alle (na ja: die meisten) nicht relevanten Attribute herausgenommen. Bei nicht erfolgreicher Autoerkennung werden alle model und 'generic' angeboten.

Allerdings besteht derzeit noch ein Problem, dass sich die Autoerkennung bei Neustart nicht genau so wie gerade beschrieben verhält.

[RalfRog]

Bei mir ist das aktuell kein Problem, da das Modul ja meine bescheidenen drei kennt.

Ich denke mal laut.
Wenn das Modul einen (neuen) Typ nicht kennt ist das Modell generic zwar ok aber vielleicht passt ein anderes Modell besser, dass manuell gesetzt wird.
Wie wäre die Vorgehensweise
- kein Modell gesetzt -> Autoerkennung, ggfs. generic
- generic gesetzt -> Autoerkennung weil möglicherweise Verbesserungen
- spezifisches Modell gesetzt, per Autoerkennung nicht mehr überschreiben

[RalfRog]

Eine interessante Option wäre den Input als Reading darzustellen (SW Eingang gibts ja an vielen Shelly's).
Man kann den SW vom Relay "detach'en" und damit als Sensor (z.B. auf/zu) nutzen.
(Ich versuche das gerade mit dem Shelly1 am Garagentor umzusetzen und greife erstmal auf JSONMOD zurück)


Edit:
Hat sich wohl erledigt.
Auch bei Gen1 (zumindest am Shelly1) kann das Attribut "showinputs" auf "show" gesetzt werden und dann erscheint das Reading "button".
Die Funktion ist also schon da 


Gruß Ralf

[mkriegl]

Da die Shelly Plus 2PM in meiner Testumgebung vorhanden sind, sollten diese auf Anhieb funktionieren, auch mit automatisch angelegten Webhooks.
Shelly Plus 1PM auch, aber der ist bisher nicht getestet.
Zum i4 siehe Posting oben, Thema ist in Arbeit.

Hätte ich weiter oben gelesen, dann hätte ich auch die aktuelle Version gesehen    .. danke schon mal dafür. Was mir aufgefallen ist:
- bei Statistics wandert "state" mit in Statistiken ein. Macht aber eher keinen Sinn
- meine Shelly Plus Plug S werden erkannt, werfen dann aber meist "Error" oder "Model shellypluspug identified" aus. Daten werden nicht aktualisiert - nur vielleicht mal bei einem Neustart von fhem - attr wurde aber beim definieren korrekt erkannt

Wenn ich für den PlusPlugS Daten liefern soll, kann ich das gerne machen. Danke schon mal für die Arbeit am Modul

Gruß .. Max

[Starkstrombastler]

Hallo Testergemeinde,

es stehen ja noch einige Rückmeldungen zum i4, Uni, Duo-Bulb und PlusPlugS aus. Ich habe mir jetzt diese Shellies bestellt, denn rein theoretisch ist es schwer bis unmöglich die Shellies korrekt abzubilden (zumindest für mich). Mit einer echten Testumgebung mit Schaltern und Lasten sieht das ganz anders aus. Und für irgendetwas werden die Teile dann auch gut sein.

Also wenn die Teile nächste Woche ankommen werde ich mich erstmal darum kümmern.
Wir können dann auch die Diskussion zur Gestaltung der Readings bei den diversen EnergyMetern führen, aber in den nächsten Tagen stehen erstmal andere Dinge an. Vielleicht findet ja jemand bis dahin eine brauchbare Grundlage bei anderen Modulen zu EnergyMetern.

Gruß
Bernhard

[WhyTea]

Hallo.
@Starkstrombastler Ich freue mich auch sehr darüber das Du Dir die Arbeit machst und das Modul von PAH weiterentwickelst und pflegst. Danke!

Momentan nutze ich noch die offizielle Version 4.01 des Moduls.

Da ich bisher nur gen1 Shellys habe sollten die auch mit Deiner Weiterentwicklung soweit ich gelesen habe problemlos laufen.
Es liegen aber schon einige Zeit zwei Shelly Plus 1PM bei mir rum die ich gerne einsetzen würde.

Wie sollte ich eine Migration durchführen? Einfach das Modul ersetzten und ein restart von Fhem?
Oder müssen /sollten die bereits definierten Geräte neu angelegt werden?
Wichtig ist natürlich auch, wie kann ich im Bedarfsfall zurückgehen?

Gruß
Daniel

[RalfRog]

...
Wir können dann auch die Diskussion zur Gestaltung der Readings bei den diversen EnergyMetern führen, aber in den nächsten Tagen stehen erstmal andere Dinge an. Vielleicht findet ja jemand bis dahin eine brauchbare Grundlage bei anderen Modulen zu EnergyMetern.
...

Bestimmt sinnvoll. Hoffe es können viele zum Stand der diversen EnergyMeter beitragen. Ich hab nur die Shellies und eine HM-Steckdose.
Ich fasse nach meinem Urlaub mal meinen Ist-Stand zusammen.

Gruß Ralf

[Starkstrombastler]

Wie sollte ich eine Migration durchführen? Einfach das Modul ersetzten und ein restart von Fhem?
Oder müssen /sollten die bereits definierten Geräte neu angelegt werden?
Wichtig ist natürlich auch, wie kann ich im Bedarfsfall zurückgehen?

Sofern man über eine eigene Testumgebung verfügt, sollte man "in Entwicklung befindliche Module" ersteinmal dort ausprobieren. Ansonsten ist grundsätzlich eine vorherige Sicherung/Backup sinnvoll.
Es reicht, das Modul im Moduleordner abzulegen und einen Restart von Fhem durchzuführen. Damit die Testversion bei einem Update nicht von der offiziellen Version überschrieben wird, muss das Attribut

Code Auswählen Erweitern

attr global exclude_from_update 36_Shelly.pm gesetzt bzw. erweitert werden.

Für das Zurückgehen muss die Testversion wieder durch die letzte offizielle Version ersetzt werden (z.B. mittel "update") und Fhem neu gestartet werden. Eventuell von der Testversion neu angelegte Readings (und ggf. in den Shellies abgelegte Actions) müssen manuell entfernt werden.

Bei der Einbindung von Testversionen in eine vorhandene Fhem-Umgebung bitte immer beachten, dass sich Readings, Attribute oder auch die grundsätzliche Funktionalität ändern können!