Support-Thread Modul 36_Shelly.pm

[matt_577]

Muss am Device etwas eingestellt werden, oder muss ich lediglich warten, bis das Modul angepasst ist?

Ich habe die Modulversion vom 16.08.2023. Bei mir werden viel mehr Readings angezeigt, u.a. Verbrauch. Ich habe das model-Attribut auf shellyplus1pm gesetzt.

Danke, das half auf Anhieb!

Gruß aus Oberfranken

matt

[matt_577]

Unter attributes, hab ich model shellyplug eingestellt.

In der Testversion des Moduls wird versucht, das model automatisch zu ermitteln. Lösche hierzu das Attribut model und setze

Code Auswählen Erweitern

get <device> model

Hi,

auch das hat wunderbar funktioniert!

Danke und

Gruß aus Oberfranken

matt

[Starkstrombastler]

Ab dem 27.10. wird das Shelly-Modul via regulärem Update verfügbar sein.

[loetmeister]

Mega update, vielen Dank Starkstrombastler!
Viele neue Funktionen und Readings für meinen shellyplusplugs.   

Würde damit auch der Passwortschutz der '2nd Gen PLUS devices' funktionieren? Da wird ja nur ein Passwort gesetzt, ohne Benutzernamen.
Aktuell scheint die Firmware aber kaputt zu sein... hatte mich fast ausgesperrt. 
https://www.shelly-support.eu/forum/thread/21937-password-protected-device-funktioniert-nicht-richtig/

Gruß,
Thomas

[x86]

Leider musste ich feststellen, dass bei mir seit gestern abend viele Funktionen unserer Rolladensteuerung (Auf/Ab via IT-Funkfernbedienungen, diverse Zeitschaltungen usw.) nicht mehr funktionierten und habe gesehen, dass das Shelly-Modul durch eine neue Version ersetzt wurde. Wir nutzen 6 Shelly-2.5-Module (1. Generation), die mit der alten Version bisher immer super funktioniert haben.

Hauptproblem ist nach meiner ersten Analye, dass der "state" nicht mehr "stopped" zurückgibt, wenn der Rolladen steht, sondern "pct-xx". Einige meiner Skripte fragen aber explizit das "stopped" ab, um Doppelbelegungen von Tasten zu ermöglichen (Auf/Stop/Ab/Stop im Wechsel).

Was ist der Grund für diese doch große Änderung (die man als "breaking change" bezeichnen könnte, was sie ja bei uns auch war)?
Eigentlich ist diese Info im state ja redundant, da es ja schon das "pct"-Reading gibt. Und es gibt, wenn ich das richtig sehe, jetzt kein Reading mehr, bei dem man direkt ablesen kann, ob der Rolladen gerade fährt oder steht. Oder?

Ich stehe jetzt vor der Möglichkeit, das alte Modul wiederherzustellen und vom Update auszuschließen (nebenbei ist das Modul doch auch um einiges größer geworden) oder meine Skripte alle umzubasteln und statt state eq "stopped" auf sowas wie substr(ReadingsVal("...","state",""), 0, 4) eq "pct-") oder so umzubauen.

Daher die Frage: wurde/wird sowas berücksichtigt und ist evtl. in Aussicht, dass diese Änderung im Verhalten des Moduls wieder rückgängig gemacht wird? Dachte ich frage mal, bevor ich jetzt mit dem Drumrumarbeiten anfange.

(Ist nicht als Kritik gemeint bzw. wenn, dann nur als Konstruktive - ich sehe schon, warum das neue Modul nötig wurde, angesichts der Vielfalt der neuen Module der 2. Generation, die vorher nicht unterstützt wurden, ich frage nur ob diese state-Änderung wirklich notwendig war/ist...).

Ist nur ne Frage.

Ein schönes Wochenende und viele Grüße!

[Starkstrombastler]

Hallo x86,
in den vergangenen Monaten hatten wir in diesem Thread einige Testversionen, wo diese Änderung dargestellt wurde. Bei den an den Tests beteiligten Usern gab es dazu keine Einwände. Aber es gibt natürlich eine Erklärung.

Hauptproblem ist nach meiner ersten Analye, dass der "state" nicht mehr "stopped" zurückgibt, wenn der Rolladen steht, sondern "pct-xx".

Grund für die Änderung ist die Darstellung des Zustandes mit devStateIcon siehe dazu auch diesen Beitrag.
Das Reading state nimmt die Zustände drive-up, drive-down und pct-xx an, wobei xx die auf 10er-Schritte gerundete Position ist. Damit ist der Unterschied zwischen Bewegung und Stillstand auch eindeutig.

Es gibt dann noch das Reading position, was die Werte opened, closed und pct-ii annimmt. ii ist hier der prozentgenaue Zwischenwert.
Außerdem das Reading pct um mit Alexa u.ä. kompatibel zu sein. pct nimmt immer prozentgenaue Werte 0...100 an.
Auch mit dem Reading Power kann zwischen Stillstand (power=0) und Bewegung unterschieden werden. Falls das attr showunits gesetzt ist, sollte dafür das Reading mit readingsNum() gelesen werden.

Die von dir beschriebene Funktion Auf/Stop/Ab/Stop entspricht dem one-button-mode (Gen.1) bzw. single-button-mode (Gen.2), welche direkt von den Shellies unterstützt werden. Ist das bei dir so in den Shellies eingestellt?  Oder machst du das durch zusätzlichen Code? Beschreibe doch deinen Aufbau und Funktion etwas ausführlicher, dann wird sich sicher auch eine zweckmäßige Darstellung im Modul realisieren lassen.

[Starkstrombastler]

Würde damit auch der Passwortschutz der '2nd Gen PLUS devices' funktionieren? Da wird ja nur ein Passwort gesetzt, ohne Benutzernamen.

Vom Anspruch her sollte der Passwortschutz funktionieren, in dieser Form ist er aber nicht getestet.

[x86]

Hi Starkstrombastler,
danke für deine schnelle und umfassende Antwort!

in den vergangenen Monaten hatten wir in diesem Thread einige Testversionen, wo diese Änderung dargestellt wurde. Bei den an den Tests beteiligten Usern gab es dazu keine Einwände. Aber es gibt natürlich eine Erklärung.

Hab ich jetzt auch gelesen, aber wenn alles läuft, schaut man halt nicht unbedingt regelmäßig in einen Support-Thread vorbei

Daher traf mich die Änderung halt etwas unverhofft. Aber - alles gut!

Ich konnte es jetzt durch zwei kleine Code-Änderungen (wie im vorigen Beitrag beschrieben) lösen.

Die von dir beschriebene Funktion Auf/Stop/Ab/Stop entspricht dem one-button-mode (Gen.1) bzw. single-button-mode (Gen.2), welche direkt von den Shellies unterstützt werden. Ist das bei dir so in den Shellies eingestellt?  Oder machst du das durch zusätzlichen Code? Beschreibe doch deinen Aufbau und Funktion etwas ausführlicher, dann wird sich sicher auch eine zweckmäßige Darstellung im Modul realisieren lassen.

Das, was letztlich Probleme gemacht hat, war die Funktion "Auf/Stop" bzw. "Ab/Stop", mit der ich die "ON" und "OFF" Tasten einiger IT-Funksteckdosen-Fernbedienungen belegt habe. Mit der linken Tastenreihe (die ON-Tasten) kann man die entsprechenden Rolläden AUF fahren und mit der rechten (OFF-Tasten) AB, und wenn man eine der Tasten nochmal drückt während der jeweilige Rolladen fährt, kann man ihn stoppen.

Aber wie du schon schreibst: am state lässt sich auch jetzt noch ablesen ob der Rolladen steht, nämlich wenn der state mit "pct-" beginnt. Alles wieder gut!

Aber noch was: bei mir läuft FHEM auf einem alten, noch übrigen, für sonst nichts mehr zu gebrauchendem aber für FHEM (macht bei uns nicht viel mehr als die Rolladensteuerung per Funk und noch ein paar andere Zeitschaltungen) noch sehr gut läuft. Aber - viel Reserve ist halt nicht, insofern bin ich immer einer der ersten, der Performanceeinbußen bei "komplexer gewordenen" Modulen zu spüren bekommt (von so Sachen wie fhempy ganz zu schweigen)...

Und so fiel mir nach dem Update jetzt auf, dass der Pi etwas mehr "zu tun" hat, das sehe ich an der CPU- und Temperaturkurve und ich habe auch den Eindruck, dass die Rolläden etwas träger auf die Tasten reagieren. Als erste Maßnahme habe ich mal die verbosity auf 2 runtergestellt, bei 3 (hatte ich bislang) loggt das neue Modul jede Minute in die Logdatei (Flash, langsame SD-Karte...), dass es in 60 Sekunden wieder was loggt.

Gibt's noch irgendwas, mit dem man die Performance des neuen Moduls etwas streamlinen könnte?

Aber: es läuft alles, die Unterschiede sind kaum merklich, man sieht es halt nur im CPU-Graph, dachte nur, ich frag trotzdem mal. Eventuell hat ja noch jemand die Feststellung gemacht.

Beste Grüße und in jedem Fall nochmal tausend Dank fürs Kümmern um das Modul!!

[Starkstrombastler]

Hallo x86, ich freue mich, dass es jetzt wieder bei dir läuft.

Gibt's noch irgendwas, mit dem man die Performance des neuen Moduls etwas streamlinen könnte?

Das umfangreiche Loggen ist der Entwicklung geschuldet. Wenn aber keine Probleme auftauchen reicht verbose=1 aus.

Das Shelly-Modul pollt die verknüpften Devices, d.h. es werden regelmäßig Abfragen gesendet und dann die Antworten ausgewertet.
Wenn du auf dem Shelly2.5 ColoT aktivierst, kannst du auch den ShellyMonitor nutzen, z.B.:

Code Auswählen Erweitern

define Monitor ShellyMonitorDamit sendet der Shelly von sich aus Statusmeldungen, die in das Device geschrieben werden. Das Polling Intervall kann dann auf einen deutlich größeren Wert gestellt werden.

Außerdem kannst du auf dem Shelly Actions ROLLER OPEN URL, ROLLER CLOSED URL und ROLLER STOP URL definieren. Damit sendet der Shelly bei entsprechender Statusänderung, z.B. nach Tasterbetätigung, von sich aus an FHEM und du bekommst eine nahezu verzögerungsfreie Aktualisierung.

Code Auswählen Erweitern

http://192.168.178.107:8083/fhem?cmd=get <device-name> status
Leerzeichen sind mit %20 zu maskieren.
Auch damit können die Polling Intervalle deutlich vergrößert werden.

[DerTom71]

Vielen Dank an Starkstrombastler für das überarbeitete Modul.

Ich habe eine kleine Fehlerkorretur: Bei meinem Shelly Pro 2 wird kein reading inttemp erstellt.
Wenn man Zeile 3383-3388 (# temperature not provided by all devices) aus der vorherigen if-Abfrage (Zeile 3352: if($comp eq "roller" ...) rausnimmt, dann funktioniert es.

Ich habe einen Wunsch. Könnte man für Shelly Gen 1 noch die reading rssi, ssid mitaufnehmen? Ich habe das bei mir folgend gelöst. Nach Zeile 2581:

Code Auswählen Erweitern

if($jhash->{'wifi_sta'}{'rssi'}) { readingsBulkUpdateMonitored($hash,"network_rssi",$jhash->{'wifi_sta'}{'rssi'}.$si_units{rssi}[$hash->{units}]); }
if($jhash->{'wifi_sta'}{'ssid'}) { readingsBulkUpdateMonitored($hash,"network_ssid",$jhash->{'wifi_sta'}{'ssid'});}


[JWRu]

Ab dem 27.10. wird das Shelly-Modul via regulärem Update verfügbar sein.

Ich habe vorhin mein "exclude_from_update" gelöscht und ein vollständiges FHEM-Update gezogen.
Die Shellies scheinen zu fuktionieren, aber mein Log wird seitdem mit solchen Meldungen vollgespamt:

Code Auswählen Erweitern

2023.10.29 11:44:59 3: [Shelly_status] ShellyPlug05: next update in 60 seconds
2023.10.29 11:44:59 3: [Shelly_status] ShellyPlug04: next update in 60 seconds
2023.10.29 11:44:59 3: [Shelly_status] ShellyPlug01: next update in 60 seconds
2023.10.29 11:44:59 3: [Shelly_status] ShellyPlug02: next update in 60 seconds
2023.10.29 11:44:59 3: [Shelly_status] ShellyPM102: next update in 60 seconds
2023.10.29 11:45:01 3: [Shelly_status] ShellyPlug08: next update in 60 seconds
2023.10.29 11:45:01 3: [Shelly_status] ShellyPlug03: next update in 60 seconds
2023.10.29 11:45:01 3: [Shelly_webhook] proceeding with command 'Check' for device Shellyplus2PM01
2023.10.29 11:45:01 3: [Shelly_webhook] proceeding with command 'Count' for device Shellyplus2PM01
2023.10.29 11:45:01 3: [Shelly_shelly] Shellyplus2PM01: long update in 60 seconds, Timer is Shelly_shelly
2023.10.29 11:45:01 3: [Shelly_status] ShellyDimmer01: next update in 60 seconds
2023.10.29 11:45:01 3: [Shelly_status] Shellyplus2PM01: next update in 60 seconds
2023.10.29 11:45:01 3: [Shelly_status] Shellyplus2PM01: next update in 60 seconds
2023.10.29 11:45:01 3: [Shelly_webhook] proceeding with command 'Check' for device Shellyplus2PM01
2023.10.29 11:45:01 3: [Shelly_webhook] proceeding with command 'Count' for device Shellyplus2PM01
2023.10.29 11:45:01 3: [Shelly_status] Shellyplus2PM01: next update in 60 seconds
2023.10.29 11:45:58 3: [Shelly_status] ShellyPlug06: next update in 60 seconds
2023.10.29 11:45:59 3: [Shelly_status] ShellyPM101: next update in 60 seconds
2023.10.29 11:45:59 3: [Shelly_status] ShellyPlug05: next update in 60 seconds
2023.10.29 11:45:59 3: [Shelly_status] ShellyPlug01: next update in 60 seconds
2023.10.29 11:45:59 3: [Shelly_status] ShellyPlug04: next update in 60 seconds
2023.10.29 11:45:59 3: [Shelly_status] ShellyPlug02: next update in 60 seconds
2023.10.29 11:45:59 3: [Shelly_status] ShellyPM102: next update in 60 seconds
2023.10.29 11:46:01 3: [Shelly_status] ShellyPlug08: next update in 60 seconds
2023.10.29 11:46:01 3: [Shelly_webhook] proceeding with command 'Check' for device Shellyplus2PM01
2023.10.29 11:46:01 3: [Shelly_webhook] proceeding with command 'Count' for device Shellyplus2PM01
2023.10.29 11:46:01 3: [Shelly_shelly] Shellyplus2PM01: long update in 60 seconds, Timer is Shelly_shelly
2023.10.29 11:46:01 3: [Shelly_status] Shellyplus2PM01: next update in 60 seconds
2023.10.29 11:46:01 3: [Shelly_status] Shellyplus2PM01: next update in 60 seconds
2023.10.29 11:46:01 3: [Shelly_webhook] proceeding with command 'Check' for device Shellyplus2PM01
2023.10.29 11:46:01 3: [Shelly_webhook] proceeding with command 'Count' for device Shellyplus2PM01
2023.10.29 11:46:01 3: [Shelly_status] Shellyplus2PM01: next update in 60 seconds
2023.10.29 11:46:01 3: [Shelly_status] ShellyPlug03: next update in 60 seconds
2023.10.29 11:46:01 3: [Shelly_status] ShellyDimmer01: next update in 60 seconds

[Nobbynews]

Die Shellies scheinen zu fuktionieren, aber mein Log wird seitdem mit solchen Meldungen vollgespamt:

Code Auswählen Erweitern

attr TYPE=Shelly verbose 2beendet das.
Alternativ könnte @Starkstrombastler diese Einträge ja in verbose 4 verschieben.

Ansonsten: Tolle Arbeit. Danke!

[Nobbynews]

Hallo Starkstrombastler,

nach dem update auf die neue Version ist mir aufgefallen, das es bei den Shellyplug sehr lange dauert, bis eine Rückmeldung im device angezeigt wird.
Auch ein Erhöhen des timeout auf 60s hat keine Besserung gebracht.
Dadurch wird im Log immer angezeigt:

Code Auswählen Erweitern

2023.10.29 14:14:31 1: PERL WARNING: Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 5167.
2023.10.29 14:14:31 1: stacktrace:
2023.10.29 14:14:31 1:     main::__ANON__                      called by fhem.pl (5167)
2023.10.29 14:14:31 1:     main::readingsBulkUpdate            called by ./FHEM/36_Shelly.pm (4555)
2023.10.29 14:14:31 1:     main::readingsBulkUpdateMonitored   called by ./FHEM/36_Shelly.pm (2841)
2023.10.29 14:14:31 1:     main::Shelly_proc1G                 called by ./FHEM/36_Shelly.pm (2453)
2023.10.29 14:14:31 1:     main::Shelly_status                 called by ./FHEM/36_Shelly.pm (2389)
2023.10.29 14:14:31 1:     main::__ANON__                      called by FHEM/HttpUtils.pm (755)
2023.10.29 14:14:31 1:     main::__ANON__                      called by fhem.pl (781)
2023.10.29 14:14:55 1: PERL WARNING: Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 5167.
2023.10.29 14:14:55 1: stacktrace:
2023.10.29 14:14:55 1:     main::__ANON__                      called by fhem.pl (5167)
2023.10.29 14:14:55 1:     main::readingsBulkUpdate            called by ./FHEM/36_Shelly.pm (4555)
2023.10.29 14:14:55 1:     main::readingsBulkUpdateMonitored   called by ./FHEM/36_Shelly.pm (2841)
2023.10.29 14:14:56 1:     main::Shelly_proc1G                 called by ./FHEM/36_Shelly.pm (2453)
2023.10.29 14:14:56 1:     main::Shelly_status                 called by ./FHEM/36_Shelly.pm (2389)
2023.10.29 14:14:56 1:     main::__ANON__                      called by FHEM/HttpUtils.pm (755)
2023.10.29 14:14:56 1:     main::__ANON__                      called by fhem.pl (781)
2023.10.29 14:15:19 1: PERL WARNING: Use of uninitialized value $1 in concatenation (.) or string at ./FHEM/36_Shelly.pm line 3971.
2023.10.29 14:15:19 1: stacktrace:
2023.10.29 14:15:19 1:     main::__ANON__                      called by ./FHEM/36_Shelly.pm (3971)
2023.10.29 14:15:19 1:     main::Shelly_onoff                  called by ./FHEM/36_Shelly.pm (1958)
2023.10.29 14:15:19 1:     main::Shelly_Set                    called by fhem.pl (3975)
2023.10.29 14:15:19 1:     main::CallFn                        called by fhem.pl (1966)
2023.10.29 14:15:19 1:     main::DoSet                         called by fhem.pl (1998)
2023.10.29 14:15:19 1:     main::CommandSet                    called by fhem.pl (1278)
2023.10.29 14:15:19 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2859)
2023.10.29 14:15:19 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (981)
2023.10.29 14:15:19 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (609)
2023.10.29 14:15:19 1:     main::FW_Read                       called by fhem.pl (3980)
2023.10.29 14:15:19 1:     main::CallFn                        called by fhem.pl (784)
2023.10.29 14:15:20 1: PERL WARNING: Use of uninitialized value $1 in string ne at ./FHEM/36_Shelly.pm line 4015.
2023.10.29 14:15:20 1: stacktrace:
2023.10.29 14:15:20 1:     main::__ANON__                      called by ./FHEM/36_Shelly.pm (4015)
2023.10.29 14:15:20 1:     main::Shelly_onoff                  called by ./FHEM/36_Shelly.pm (3977)
2023.10.29 14:15:20 1:     main::__ANON__                      called by FHEM/HttpUtils.pm (755)
2023.10.29 14:15:20 1:     main::__ANON__                      called by fhem.pl (781)
2023.10.29 14:15:20 1: [Shelly_onoff] returns without success for device Shelly6, cmd=http://192.168.2.235/rpc/Switch.GetStatus? but ison=off 
Beim Einschalten beträgt die Verzögerung ca. 5s, beim Ausschalten > 25s.

Interval steht auf 30s.

Bin daher wieder auf die letzte Version von pah zurückgewechselt.
Damit habe ich keine signifikante Verzögerung in der Rückmeldung.

Norbert

[x86]

Außerdem kannst du auf dem Shelly Actions ROLLER OPEN URL, ROLLER CLOSED URL und ROLLER STOP URL definieren. Damit sendet der Shelly bei entsprechender Statusänderung, z.B. nach Tasterbetätigung, von sich aus an FHEM und du bekommst eine nahezu verzögerungsfreie Aktualisierung.

Genauso hab ich es sogar tatsächlich von Anfang an gehabt, und bei externer Bewegung der Rollläden (via Wandtaster) updatet sich das Ganze auch sofort. Ich hab "interval" nie gesetzt, es war immer auf 60, auch wenn's nicht nötig war, aber es hat auch irgendwie nie wirklich geschadet.

Aber du hast recht, ich habe es jetzt mal auf 300 gesetzt. Der einzige Wert, der sich automatisch updated ist die inttemp der Shellys und die interessiert mich eigentlich herzlich wenig, vor allem nicht minütlich.

Somit hoffe ich mal, dass es jetzt evtl. etwas weniger CPU-Last erzeugt.

Unabhängig davon:

Alternativ könnte @Starkstrombastler diese Einträge ja in verbose 4 verschieben.

Ja, da wär ich auch für. Also dieser Eintrag "next update in nnn seconds", das ist ja wirklich eher was sehr debug-mäßiges, das würd ich mindestens bei 4 sehen.

Viele Grüße und einen schönen restlichen Sonntag!

[Starkstrombastler]

nach dem update auf die neue Version ist mir aufgefallen, das es bei den Shellyplug sehr lange dauert, bis eine Rückmeldung im device angezeigt wird.

Hier hat sich bei der Vorbereitung auf Shellies, welche nur Gen-2-Befehle annehmen, ein Bug eingeschlichen. Das betrifft alle Shellies mit Relais! Eine neue Version wird eingestellt und ist morgen via regulärem Update verfügbar.

Die Shellies scheinen zu fuktionieren, aber mein Log wird seitdem mit solchen Meldungen vollgespamt:

Na ja, Meldungen sind ja gewollt, daher kein Spam. Sind aber auf einen höheren Level geändert.

Ich habe eine kleine Fehlerkorretur: Bei meinem Shelly Pro 2 wird kein reading inttemp erstellt.

Der Pro2 hat keine Leistungsmesseung, richtig? Daher habe ich die Temp-Abfrage nach dem if der Leistungsmessung verschoben.

Könnte man für Shelly Gen 1 noch die reading rssi, ssid mitaufnehmen?

Ist im nächsten Update auch mit drin.