Support-Thread Modul 36_Shelly.pm

[Xaneu]

Hallo,

auch von meiner Seite ein Dankeschön an Starkstrombastler für die Weiterentwicklung des Moduls.
'habe die neue (Test-)Version des Moduls mit meinem "shellyplus2pm" getestet, der seit ein paar Monaten wegen der fehlenden Unterstützung im Schrank lag.

Ich habe erst einmal keine schwerwiegenden Fehler/Probleme feststellen können.
Auch die anderen shelly-Komponenten, die ich schon in Betrieb hatte, zeigen keine Auffälligkeiten.

Auffallend ist hier (wie schon berichtet) die relativ große Gesprächigkeit in der FHEM-Log-Datei (auch unter Verbose 3 noch). Aber das ist ja nur zu Testzwecken.

Zuletzt habe ich dann testweise und aus reiner Neugier mal das Attribute ,,showunits" auf ,,original" gesetzt.
Hierbei zeigte sich, dass dann bei allen Shelly-Geräten die Einheiten angezeigt wurden (also nicht nur bei dem shellyplus2pm-Gerät).

Ist das so gewollt?
Denke es sollte so sein, dass es individuell bei jedem Gerät gesetzt werden kann bzw. wirken soll.
Oder?

Gruß
Xaneu

[Starkstrombastler]

Hallo Xaneu,

danke fürs Testen.

Zuletzt habe ich dann testweise und aus reiner Neugier mal das Attribute ,,showunits" auf ,,original" gesetzt.
Hierbei zeigte sich, dass dann bei allen Shelly-Geräten die Einheiten angezeigt wurden (also nicht nur bei dem shellyplus2pm-Gerät).

Das Attribut showunits soll wie alle anderen Attribute immer nur für das jeweilige Device gelten.
Dies und die weiteren gemeldeten "Auffälligkeiten" in der Testversion sollen mit der nächsten Version beseitigt sein, diese folgt in Kürze.
Showunits ist aber derzeit noch inkompatibel zum Shelly-Monitor.

Für den ShellyPlus2PM können mit dem Attribut "webhook" automatisiert Actions im Shelly angelegt werden, die bei entsprechenden Statusänderungen unverzögert eine Meldung an Fhem senden. Das ist sinnvoll, wenn der Shelly z.B. mittels Taster oder App bedient wird. Hat das funktioniert?

[RalfRog]

...
Showunits ist aber derzeit noch inkompatibel zum Shelly-Monitor.
...

Schön freue mich auf das Update.

Interessant auch, dass die Weiterentwicklung prinzipiell kompatibel zum Shelly-Monitor ist/bleibt 
Gibt es dabei Einschränkungen? Modelle, Readings?


Gruß Ralf

[Xaneu]

Hallo Starkstrombastler,

Für den ShellyPlus2PM können mit dem Attribut "webhook" automatisiert Actions im Shelly angelegt werden, die bei entsprechenden Statusänderungen unverzögert eine Meldung an Fhem senden. Das ist sinnvoll, wenn der Shelly z.B. mittels Taster oder App bedient wird. Hat das funktioniert?

'habe es gerade mit Setzen des Attributs "attr Test_shelly webhook WEB" getestet.
Anschließend zeigt der Event-Monitor mit jedem Ereignis an den Eingängen Einträge der folgenden Art:

Code Auswählen Erweitern

2023-05-02 18:54:56.231 Shelly Test_shelly relay_0: on
2023-05-02 18:54:57.379 Shelly Test_shelly voltage_1: 232.1 V
2023-05-02 18:54:57.379 Shelly Test_shelly inttemp: 45.8 °C
2023-05-02 18:54:57.396 Shelly Test_shelly voltage_0: 232.1 V

Es funktioniert also.
Mach es nicht Sinn diese Funktion (webhook-Richtung: shelly -> FHEM) standardmäßig zu aktivieren?
Jedenfalls hätte ich ein solches Verhalten erwartet bzw. ist ein solches Verhalten doch (immer) erwünscht.

Die andere Funktion (webhook-Richtung: FHEM -> shelly):

Ist im FHEMWEB-device ein Token definiert, wird dies im Webhook mit aufgenommen und bei Bedarf (z.B. bei fhem-Neustart) im Shelly aktualisiert.

habe ich nicht ganz verstanden.

Gruß
Xaneu

[Starkstrombastler]

Interessant auch, dass die Weiterentwicklung prinzipiell kompatibel zum Shelly-Monitor ist/bleibt 

Das ist zumindest die Absicht.

Betroffen sind aber nur die kabelgebundenen Shellies der ersten Generation. Die Shellies der zweiten Generation unterstützen das von Shelly-Monitor genutzte Protokoll nicht.

Mach es nicht Sinn diese Funktion (webhook-Richtung: shelly -> FHEM) standardmäßig zu aktivieren?

Mit dem Attribut hat der Nutzer die Möglichkeit, die FHEMWEB-Instanz, an welche der Shelly sendet, auszuwählen.

Ist im FHEMWEB-device ein Token definiert, wird dies im Webhook mit aufgenommen und bei Bedarf (z.B. bei fhem-Neustart) im Shelly aktualisiert.

Das ist so realisiert, um unabhängig von weiteren Sicherheitseinstellungen zu sein. Wenn also im FHEMWEB-device das Attribut csfrToken mit einem festen Wert oder random gesetzt ist, holt sich das Shelly-Modul den Token und baut ihn in der auf dem Shelly hinterlegten URL ein. Das sieht dann z.B. so aus (siehe in der Shelly-Webseite unter Settings - Actions):

Code Auswählen Erweitern

http://192.168.178.100:8084/fhem?XHR=1&fwcsrf=csrf_445253534353513564&cmd=set%20ShellyTest%20out_on%200
Dass auf dem Shelly URLs hinterlegt werden können ist nicht neu, das gibt es auch schon in der ersten Generation. Neu ist, dass die URLs vom Shelly-Modul automatisiert erstellt werden können. Der Nutzer kann die URL aber auch ändern oder für andere Actions kopieren.
Mit obiger Beispiel-URL wird folgender Befehl an Fhem gesendet:

Code Auswählen Erweitern

set ShellyTest out_on 0

[Xaneu]

Alles klar und danke für die umfangreiche Erklärung.

Gruß
Xaneu

[Starkstrombastler]

Hier wie angekündigt eine aktuelle Test-Version des Moduls. Neben diversen Korrekturen wird auch der ShellyPro3EM unterstützt. Bitte die angebotenen Attribute durchprobieren!

[RalfRog]

Im ersten Step habe ich die Version auf mein Testsystem geladen und nach shutdown restart einen Shelly Plug S angelegt (Gen1)

=> Für den Plug funktioniert die Modellerkennung nicht.
=> Welche Bedeutung haben die unten aufgeführten Meldungen?

Code Auswählen Erweitern

2023.05.05 13:38:37.510 5: [Shelly_Set] calling for device Plug with command ?, without value
2023.05.05 13:38:40.488 4: [Shelly_Get] receiving command get Plug ?
2023.05.05 13:38:54.744 5: [Shelly_Attr] Plug: called with command set for attribute verbose and value 4
=> dann Model gesetzt
2023.05.05 13:38:54.843 4: [Shelly_Get] receiving command get Plug ?   
Ablauf

• Plug kommt sofort mit "state ok"
• legt die Readings an
    2023-05-05 13:33:11 cloud disabled
    2023-05-05 13:33:11 firmware v1.10.1
    2023-05-05 13:34:11 inttemp 31.21
    2023-05-05 13:33:11 network connected to 11.12.13.19
    2023-05-05 13:33:11 state OK
• nach verbose 5 sieht man im Log: "Model of device Plug is generic and mode is . Updates every 60 seconds"
• nach setzen des korrekten Model kommen die fehlenden Readings
    2023-05-05 13:33:11 cloud disabled
    2023-05-05 13:44:55 energy 60220
    2023-05-05 13:33:11 firmware v1.10.1
    2023-05-05 13:44:55 inttemp 30.6
    2023-05-05 13:33:11 network connected to 11.12.13.19
    2023-05-05 13:44:55 overpower 0
    2023-05-05 13:44:55 power 3.32
    2023-05-05 13:44:55 relay on
    2023-05-05 13:44:55 state on
• Statusabfrage für die Messwerte kommen korrekt im Intervall

Denke das sieht gut aus (abgesehen von der Autoerkennung). 


spielen mit Attributen (viele gelten ja beim Plug nicht)

• keine Auswirkung, egal welcher Attributwert gesetzt ist:  "attr <name> showunits none|original|normal|normal2|ISO"
  Insbesondere rechnet hier das Modul schon aus den Wattminuten des Devices Wattstunden aus. Original sieht man bisher nie. D.h. der Wert oben "energy 60220 " sieht im Device ja so aus "total":3613200"
  Kommando zurück, ich hatte das Intervall auf 0 stehen. Funktioniert 
  -> mehr bleibt beim Plug nicht 
  

Während der Attributtesterei gab es einmal:  PERL WARNING: Use of uninitialized value $attrVal in string eq at ./FHEM/36_Shelly.pm line 826.
=> if( $attrVal eq "none" || $cmd eq "del" ){

[Starkstrombastler]

2023.05.05 13:38:37.510 5: [Shelly_Set] calling for device Plug with command ?, without value
2023.05.05 13:38:40.488 4: [Shelly_Get] receiving command get Plug ?
2023.05.05 13:38:54.744 5: [Shelly_Attr] Plug: called with command set for attribute verbose and value 4
=> dann Model gesetzt
2023.05.05 13:38:54.843 4: [Shelly_Get] receiving command get Plug ?

Meldungen zur Autoerkennung sehen wir da nicht, weil zum Zeitpunkt des Define der Level noch niedriger war. Die Befehle set <device> ? bzw. get <device> ? kommen wohl von FHEMWEB und dienen dem Aufbau der Dropdown-Menus. Das war wohl auch schon in der ursprünglichen Fassung so, nur mit dem Unterschied, dass diese dort nicht geloggt wurden.

Model of device Plug is generic

Als Attribut model wurde also zunächst generic angelegt, richtig? Das ist immer dann der Fall, wenn sich der Shelly mit einer ID "type" meldet, die hier im Modul nicht bekannt ist. Bitte hierzu folgende Anfrage an den Shelly Plug absetzen:  <ip-adresse>/settings
Die Antwort sollte in etwa so aussehen:

Code Auswählen Erweitern

  device:
       type:    "SHPLG-S"
       .....    ......

[RalfRog]

Als Attribut model wurde also zunächst generic angelegt, richtig? Das ist immer dann der Fall, wenn sich der Shelly mit einer ID "type" meldet, die hier im Modul nicht bekannt ist. Bitte hierzu folgende Anfrage an den Shelly Plug absetzen:  <ip-adresse>/settings
Die Antwort sollte in etwa so aussehen:

Code Auswählen Erweitern

  device:
       type:    "SHPLG-S"
       .....    ......

Ja genau generic wurde angelegt/angenommen (Das Attribut wird nicht angelegt/gesetzt. Auch nicht model = generic).
Ich habe es händisch gesetzt.

Klar das Model ist : SHPLG-S  (Ausgabe settings -> {"device":{"type":"SHPLG-S",)

[RalfRog]

Als nächstes habe ich meinen Shelly 3EM eingebunden. Sieht auch prima aus.

Autoerkennung funktioniert und die Readings sind soweit gleich da.
Auch die in der alten Version fehlenden Reading wie current, energy_returned & pf .
Er kennt ja an sich auch noch die Gesamtleistung total_power.

Code Auswählen Erweitern

"device":{"type":"SHEM-3"
"emeters":[
  {"power":84.83,"pf":0.50,"current":0.74,"voltage":224.95,"is_valid":true,"total":282410.1,"total_returned":28608.0},
  {"power":89.72,"pf":0.71,"current":0.56,"voltage":225.37,"is_valid":true,"total":308194.0,"total_returned":0.0},
  {"power": 3.05,"pf":0.06,"current":0.23,"voltage":224.93,"is_valid":true,"total":365555.4,"total_returned":0.0}],
"total_power":177.6
Das Modul scheint zusätzlich die Werte zu errechnen:

• apparentpower_x
• reactivepower_x
• energyTTL
• powerTTL
  => oder ist das der Originalwert total_power?

Die Rechenwerte finde ich an sich ok (man braucht manches Usereading nicht), da die ja teilweise in der 2GEN auch vorkommen.
Die Frage (insbesonde an die Mitleser) wäre, ob eine eindeutige Unterscheidung von Gerätewerten und Rechenwerten Sinn macht.


Mehr Geräte hab ich leider nicht.
Ach doch... hab noch nen 1PM in der Schublade.

[RalfRog]

Wenn noch mehr gute Rückmeldungen kommen kann ich nur sagen: Klasse gemacht     Toll! und danke für die Arbeit.

[Starkstrombastler]

Ja genau generic wurde angelegt/angenommen (Das Attribut wird nicht angelegt/gesetzt. Auch nicht model = generic).
Ich habe es händisch gesetzt.

Klar das Model ist : SHPLG-S  (Ausgabe settings -> {"device":{"type":"SHPLG-S",)

Da müssen wir mal schauen, was ander User berichten. Bei mir funktioniert die Autoerkennung des ShellyPlugS.

Das Modul scheint zusätzlich die Werte zu errechnen:

• apparentpower_x
• reactivepower_x
• energyTTL
• powerTTL
  => oder ist das der Originalwert total_power?

Ja das stimmt, Werte werden berechnet. Auch PowerTTL wird als Summe der Einzelwerte bestimmt und sollte damit um eine Kommastelle genauer sein.   returnedTTL fehlt noch, wird ergänzt.

[RalfRog]

Da müssen wir mal schauen, was ander User berichten. Bei mir funktioniert die Autoerkennung des ShellyPlugS.

Seltsam...
Ich guck mal ob ich mit global verbose 5 beim define was sehen kann.

[RalfRog]

Hi
wenn du einen Tipp hast bau ich gern ne Zeile "Debug/Log" in den Code. Z.B. zur Ausgabe des rohen Rückgabewertes aus /settings

Ich glaube hier liegt das Problem:

Code Auswählen Erweitern

2023.05.05 17:28:16.931 5: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.05.05 17:28:16.937 4: [Shelly_Get] receiving command get Shelly_Plug ?
2023.05.05 17:28:17.080 4: http://10.20.30.90/settings: HTTP response code 200
ok GEN1 ==>>  2023.05.05 17:28:17.084 5: HttpUtils http://11.12.13.19/settings: Got data, length: 1778
2023.05.05 17:28:17.087 5: HttpUtils response header:
HTTP/1.1 200 OK
Server: Mongoose/6.18
Connection: close
Content-Type: application/json
Content-Length: 1778
2023.05.05 17:28:17.091 5: [Shelly_get_model] Shelly_Plug: received 1778 byte of data from device

Nok Antwort ==>>  2023.05.05 17:28:17.098 5: [Shelly_get_model] has invalid JSON data for device Shelly_Plug

2023.05.05 17:28:17.105 5: Starting notify loop for Shelly_Plug, 1 event(s), first is Error
2023.05.05 17:28:17.113 5: End notify loop for Shelly_Plug
2023.05.05 17:28:17.120 4: http://10.20.30.90/rpc/Shelly.GetDeviceInfo: HTTP response code 404
2023.05.05 17:28:17.123 5: HttpUtils http://10.20.30.90/rpc/Shelly.GetDeviceInfo: Got data, length: 9
2023.05.05 17:28:17.127 5: HttpUtils response header:
HTTP/1.1 404 Not Found
Server: Mongoose/6.18
Content-Type: text/plain
Connection: close
Content-Length: 9
Hier die Daten mit dem Browser abgerufen, wird korrekt dargestellt:

Code Auswählen Erweitern

{"device":{"type":"SHPLG-S","mac":"3C6105DF2674","hostname":"shellyplug-s-DF2674","num_outputs":1,"num_meters":1},"wifi_ap":{"enabled":false,"ssid":"shellyplug-s-DF2674","key":""},"wifi_sta":{"enabled":true,"ssid":"nochnWLAN","ipv4_method":"dhcp","ip":null,"gw":null,"mask":null,"dns":null},"wifi_sta1":{"enabled":false,"ssid":null,"ipv4_method":"dhcp","ip":null,"gw":null,"mask":null,"dns":null},"ap_roaming":{"enabled":false,"threshold":-70},"mqtt": {"enable":false,"server":"10.20.30.41:1883","user":"","id":"shellyplug-s-DF2674","reconnect_timeout_max":60.000000,"reconnect_timeout_min":2.000000,"clean_session":false,"keep_alive":60,"max_qos":0,"retain":true,"update_period":30},"coiot": {"enabled":true,"update_period":300,"peer":""},"sntp":{"server":"10.20.30.1","enabled":true},"login":{"enabled":false,"unprotected":false,"username":"solar"},"pin_code":"","name":"Solar_Plug","fw":"20210323-105718/v1.10.1-gf276b51","discoverable":false,"build_info":{"build_id":"20210323-105718/v1.10.1-gf276b51","build_timestamp":"2021-03-23T10:57:18Z","build_version":"1.0"},"cloud":{"enabled":false,"connected":false},"timezone":"Europe/Berlin","lat":50.986938,"lng":6.890820,"tzautodetect":false,"tz_utc_offset":7200,"tz_dst":true,"tz_dst_auto":false,"time":"16:39","unixtime":1683301181,"led_status_disable":true,"debug_enable":false,"allow_cross_origin":false,"actions":{"active":false,"names":["btn_on_url","out_on_url","out_off_url"]},"hwinfo":{"hw_revision":"prod-190516","batch_id":1},"max_power":500,"led_status_disable":true,"led_power_disable":true,"relays":[{"name":null,"appliance_type":"General","ison":true,"has_timer":false,"default_state":"on","auto_on":0.00,"auto_off":0.00,"schedule":false,"schedule_rules":[],"max_power":500}],"wifirecovery_reboot_enabled":false}