Modul 36_Shelly.pm

[KyleK]

Häh? Was ist denn das bitte für eine Antwort? Was hat den event-on-change-reading damit zu tun?

Anyway, der Fehler liegt im Modul:
Im Status eines Shelly 1 gibts kein Attribut "overpower", das gibts nur beim Shelly 1PM.
Das Modul macht hier aber keine Unterscheidung.

Fix:

Code Auswählen Erweitern


--- /opt/fhem/FHEM/36_Shelly.pm2020-12-03 19:44:58.869791001 +0100
+++ 36_Shelly.pm        2020-12-03 19:44:58.869791001 +0100
@@ -962,7 +962,9 @@
       $ison =~ s/1|(true)/on/;
       $overpower = $jhash->{'relays'}[$i]{'overpower'};
       readingsBulkUpdateIfChanged($hash,"relay".$subs,$ison);
+      if($overpower){
       readingsBulkUpdateIfChanged($hash,"overpower".$subs,$overpower);
+      }
       if($model =~ /shelly(1|(plug)).*/){
         readingsBulkUpdateIfChanged($hash,"state",$ison)
       }else{


[JWRu]

Aber doch nicht, wenn ich das über die REST-Schnittstelle anstoße.

Das stimmt. Sorry, ich hatte den Befehl erstmal aus FHEM ausprobiert, bevor ich alle URLs ändere.

By the way:
Die Output-On URL wird getriggert, wenn der Dimmer eingeschaltet ist und man ihn über die Weboberfläche dimmt, nicht aber beim Dimmen über den angeschlossenen Taster.
Man muß also auch die Button-URLs für den Refresh verwenden.

[max333]

Danke ersteinmal für das Shelly Modul. Jedoch ist es bisher das einzigste Modul, welches NUR über die IP und nicht über den Hostname kommunizieren kann.

Bitte abändern.

[Prof. Dr. Peter Henning]

Bitte abändern.

Nö.

LG

pah

[cs-online]

Bitte abändern.

...wenn man hier neu ist, muss man ggf. nochmal an der Ausdrucksweise arbeiten, vielleicht bekommt man dann auch eine positivere Antwort....

[Adimarantis]

Hallo,

ich habe nach wie vor das Problem, dass meine Shelly1 folgende Warnings im Log erzeugen:

Code Auswählen Erweitern

2020.12.18 13:55:58 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4825.
2020.12.18 13:55:58 1: stacktrace:
2020.12.18 13:55:58 1:     main::__ANON__                      called by fhem.pl (4825)
2020.12.18 13:55:58 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/36_Shelly.pm (965)
2020.12.18 13:55:58 1:     main::Shelly_status                 called by ./FHEM/36_Shelly.pm (919)
2020.12.18 13:55:58 1:     main::__ANON__                      called by FHEM/HttpUtils.pm (639)
2020.12.18 13:55:58 1:     main::__ANON__                      called by fhem.pl (755)

Soweit ich dass sehe wird in Zeile 965 der Parameter "overpower" abgefragt, welche von den 1ern nicht geliefert wird.

Code Auswählen Erweitern

readingsBulkUpdateIfChanged($hash,"overpower".$subs,$overpower);

Ich kommentiere die Zeile jetzt immer aus, da ich nur Shelly1 habe. In der Zeile drauf würde aber sowieso abhängig vom Modell (1/plug) einer Unterscheidung getroffen.
Man könnte die "overpower" Abfrage einfach in den entsprechenden "if"-Zweig verschieben.

Oder habe ich jetzt irgendwas falsch konfiguriert oder übersehe etwas?
(FHEM und Shelly heute auf aktuellste Version geupdated)

Danke & Gruß,
Jörg

[KyleK]

Gleiches Problem bei mir auch.
Ich hab weiter oben auch einen Patch gepostet, aber der Modulautor hat entweder keine Zeit oder keine Lust das zu ändern

[Prof. Dr. Peter Henning]

@Adimarantis: Sehe ich mir an - da ich aktuell keine 1er in Betrieb habe, fällt mir das nicht auf.

LG

pah

@KyleK:

Modulautor hat entweder keine Zeit oder keine Lust

Jedenfalls kein Interesse, halbgare Patchvorschläge zu übernehmen.Vorschlag: Auf andere Software oder andere Hardware wechseln.

[KyleK]

@pah, ich verstehe nicht warum du mit deiner überheblichen Art andauernd (neue) Nutzer vergraulst?
Was bitte hast du davon?

Wenn mein Patch halbgar ist, dann tut mir das leid, meine Perl-Kentnisse sind basic. Dann machs halt besser. Für meinen einen Shelly1 funktioniert es wie erwartet.
Und: Nur weil du meinen Patch nicht magst werde ich kaum das System wechseln.

[JWRu]

Auch finde die Kommunikation des Modulautors gewöhnungsbedürftig. Es gibt halt bei FHEM eine große Bandbreite an Mitwirkenden.
Auf der anderen Seite machen alle Modulautoren das freiwillig in ihrer Freizeit. Von daher kann man aus meiner Sicht als Anwender keine Forderungen stellen.
Wer mit dem Modul nicht zufrieden ist, kann ja immer noch zu MQTT wechseln.

[Prof. Dr. Peter Henning]

Wer mit dem Modul nicht zufrieden ist, kann ja immer noch zu MQTT wechseln.

Eben, ich bitte darum. Siehe den allerersten Post in diesem Thread. Und wenn wir dann noch auf alle Teilnehmer verzichten, die sich zum Richter über andere Menschen berufen fühlen, kann das auch etwas werden.

LG

pah

[max333]

Ich verwende viele verschiedene Module von FHEM, aber ich kenne bisher nur das 36_Shelly.pm, welches keinen Hostnamen akzeptiert.

Früher oder später stolpert jeder über eine neu zugewiesene IP...


Für alle die, die den Hostnamen oder die IP nutzen wollen:

alle {TCPIP} durch {host} ersetzen und momentan bei den Zeilen 158 und 159 eine Raute am Anfang hinzufügen, muss dann so aussehen:

#  return "[Shelly] Invalid IP address ".$a[2]." of Shelly device"
#    if( $a[2] !~ m|\d\d?\d?\.\d\d?\d?\.\d\d?\d?\.\d\d?\d?(\:\d+)?| );

zum Schluss

reload 36_Shelly.pm

Leider muss das nach jedem Update wiederholt werden bis es endlich eingepflegt wird.

[Prof. Dr. Peter Henning]

bis es endlich eingepflegt wird.

Oh, das kann bis zum Sankt Nimmerleinstag dauern...

@Adimarantis: Auf Grund der netten Anfrage war es mir eine Freude, das Problem zu beheben.


LG

pah

[amenomade]

Früher oder später stolpert jeder über eine neu zugewiesene IP...


Für alle die, die den Hostnamen oder die IP nutzen wollen:
...
Leider muss das nach jedem Update wiederholt werden bis es endlich eingepflegt wird.

Oder in der Box / im Router dem Gerät eben eine feste IP zuweisen.

[caldir65]

Moin,

mal was ganz anderes: gibt es evtl. ein Changelog zum Modul? Einfach mal aus Interesse gefragt

Gruß, Christoph