Support-Thread Modul 36_Shelly.pm

Begonnen von Prof. Dr. Peter Henning, 03 Februar 2021, 08:03:09

Vorheriges Thema - Nächstes Thema

Starkstrombastler

Zitat von: mcfly71 am 13 Oktober 2025, 09:43:19Anscheinend sind unsere beiden Fragen uninteressant....
Ein bischen Geduld bitte, ich hab' im Moment andere Dinge um die Ohren
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

chrisz

Hallo,

habe folgende Fehlermeldung:

2025.10.16 10:05:09 1: [Shelly_getModel] /shelly: device Gardenlights is of type 'SPSW-202XE12UL' but we have no key of that name, proposed model is 'generic'
2025.10.16 10:05:09 1: [Shelly_getModel] no mode/profile found for device Gardenlights
2025.10.16 10:05:09 2: (Shelly_HttpResponse:no-hash) Device Gardenlights has Error 'Gardenlights: error in command: id or component not found', state is set to 'Error'

Anscheinend ist das ein neuer Typ? Es handelt sich um einen Shelly2 Pro. Kann ich das kurzfristig selber "fixen"?

Grüße,
Chris

Starkstrombastler

Zitat von: chrisz am 16 Oktober 2025, 11:16:39[Shelly_getModel] /shelly: device Gardenlights is of type 'SPSW-202XE12UL' but we have no key of that name, proposed model is 'generic'
Es handelt sich hier wohl um einen Shelly, welcher in Nordamerika vertrieben wurde; er ist auch nicht in der Shelly-Dokumentation enthalten.

Du kannst das selbst fixen, indem du das Attribut model setzt:
attr <name> model shellypro2
Das Modul wird passend ergänzt.
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

cruser1800

Hallo,

ich habe ein Shelly 2PM Gen4 für die Jalousiesteuerung. Beim Einbinden bekomme ich nur ERROR angezeigt.

Zitaterror in command: id or component not found

Ist diese Modul noch nicht eingebunden?

Habe ich die Möglichkeit es irgendwie wenigsten die Steuerung für hoch und runter hinzubekommen?

Danke

Lutz


cruser1800

Habe es gefunden! Musste das Model setzen!

olwaldi

#1205
Habe 3 neue Shelly 1 mini gen3 in Betrieb genommen. Funktionieren problemlos. An den Shellies sind jeweils Taster angeschlossen. Hier würde ich mir wünschen, daß beim Drücken des Tasters via Shelly Action der Zustand an fhem gesendet wird.

Ich verstehe die fhem Doku so, daß die erforderlichen Shelly Actions von fhem aus automatisch angelegt werden können durch
attr Shelly-Device webhook WEBapiWEBapi ist ein mit csrftoken geschütztes FHEMWEB device. Leider hat das Kommando keinerlei Wirkung (auch keine Fehlermeldung). Auffällig ist allerdings, daß die fhem-GUI beim Eingeben dieses Attribute mein FHEMWEB device gar nicht anbietet, lediglich WEB.

Oder ist hierbei die Authentifizierung auf dem Shelly ein Problem? Vermutlich eher nicht, da ja die "normalen" Kommandos wie on/off prima funktionieren.

Oder stimmt die Doku, und webhook zum automatischen Anlegen von Actions auf dem Shelly funktioniert gar nicht für gen3 Shellies?

Sicherheitshalber habe ich noch mittels update fhem aktualisiert.

Grüßle, Michael

Nachtrag: Es gibt doch eine Fehlermeldung im Logfile:
2025.10.19 17:32:04 1: [Shelly_getModel] no mode/profile found for device EGLightBackmodel steht auf shellyplus1.
Auch m.E. merkwürdig: Wenn ich das Attribut model ändern will, gibt es nur die Auswahl zwischen none und shellyplus1.

olwaldi

Habe mein Problem selber lösen können - den wesentlichen Hinweis habe ich im zugehörigen Entwicklerthread gefunden.

1. Attribute webhook "zu Fuß" setzen durch
attr EGLightFront webhook WEBapiIn der GUI wird nur "WEB" angeboten, was bei mir nicht paßt.

2. Actions automatisch generieren lassen durch
set EGLightFront actions create allFunktioniert in der GUI. Man muß aber die Syntax kennen - hier "create all". Ich hatte zunächst nur create versucht.

3. Benötigte Action in der Shelly-Web-GUI aktivieren:
Actions -> _INPUT.BUTTON._PUSH_(Input(0)) einschalten.

Und schon wird fhem über das Drücken des Tasters am Shelly informiert.

Ggf. sollte die Auswahlbox für das Attribut webhook nicht nur "WEB" sonderrn alle verfügbaen FHEMWEB devices anbieten.


Grüßle, Michael
 

Prof. Dr. Peter Henning

Zitat von: olwaldi am 20 Oktober 2025, 09:53:44Ggf. sollte die Auswahlbox für das Attribut webhook nicht nur "WEB" sonderrn alle verfügbaen FHEMWEB devices anbieten.
Tut sie auch - keine Ahnung, welcher Konfigurationsfehler das bei olwaldi verhindert.

Zitat von: olwaldi am 20 Oktober 2025, 09:53:44Man muß aber die Syntax kennen
Dafür gibt es doch die Dokumentation...

LG

pah

olwaldi

Zitat von: Prof. Dr. Peter Henning am 20 Oktober 2025, 18:08:18
Zitat von: olwaldi am 20 Oktober 2025, 09:53:44Man muß aber die Syntax kennen
Dafür gibt es doch die Dokumentation
Ich bin ein begeisterter Dokuleser (bei neugekauften Geräten bin ich immer enttäuscht, wenns kaum Text in den Bedienungsanleitungen gibt). Aber das "create all" habe ich in der commandref nicht gefunden.
Dort steht auch explizit "gen2", daher dachte ich zunächst, daß gen3-Geräte nicht unterstützt würden.
Habe auch etwas im Source-Code gestöbert und dort nicht verstanden, warum mein FHEMWEB Device nicht angezeigt wird. Hätte lieber einen Codefix vorgeschlagen statt nur einen Bug zu melden.

Grüßle, Michael


uli-bs

Moin,
ich habe hier ein Problem, bei dem ich mal einen Denkanstoß brauche.

Hier läuft auf einem RaspPi (3) eine recht alte (outdated) FHEM Installation, die bisher aber alles so gemacht hat wie ich wollte.
Mit MAX!, MQTT für Tasmota/ESPhome Devices und eben diversen Shellys für Licht und Rollläden, da hat sich nichts verändert.
Nun sind hier praktisch ausschließlich Shellys (FW 1.14) der ersten Generation verbaut (1er, Plugs, Dimmer, 2.5er) und letztere haben durch den defekten Elko angefangen zu spinnen. Soweit die Vorgeschichte.

Der Erste war der 2.5 vom Rollo in der Küche, das fuhr zwischendurch manchmal unmotiviert wieder hoch (Default bei "Power on") -> Elko getauscht, alles wieder gut.
Dann machte, rund 2 Wochen später, das Rollo im Wohnzimmer denselben Spaß, das Ding deaktiviert und einen "Sack" Elkos bestellt...

Jetzt trat zusätzlich der Effekt auf, dass alle möglichen Gerätschaften, die über Shellys gesteuert werden, ein Eigenleben entwickelten. Alle andere Geräte und auch die Shelly, die auf Tasmota umgeflasht sind, sind "gesund".

Lampen gingen nach Belieben z.T. in schneller Folge ein/aus, Rollos (3 mit Shelly-Steuerung) fuhren auf/ab, stoppten willkürlich, alles ohne erkennbaren Grund. Auch bei den betroffenen Devices ist nicht unbedingt ein System erkennbar.

Mittlerweile sind bei allen 2.5ern die Elkos getauscht (3 von 4 waren mehr oder weniger kapazitätsarm), aber an dem beschriebenen "Ghosting" ist keine Änderung erkennbar.

Die Verbindungen nach außen (Alexa und Remotezugriff) habe ich natürlich auch testweise unterbunden und auf Systemseite auch (schon davor) "fail2ban" installiert um den Systemschutz zu erhöhen, die lokalen PCs (Virus) kann ich ebenfalls ausschließen.

Aber irgend etwas triggert die Shellys, die führen die entsprechenden Befehle aus und melden dann, lt. interner Debuginformation, den Status auch an FHEM zurück.

Einzige sinnvolle Erkenntnis, die ich habe, ein Reboot oder "shutdown restart" löst das Problem für kurze Zeit (0,5 - 1 Std.), dann triggert das Schalten eines der Geräte den "Spaß" wieder.

In den FHEM-Logs habe ich nichts gefunden was mich weiterbringt, darum jetzt hier die Frage nach Ideen...

Was mir nicht hilft, ist das System auf einen aktuellen Stand zu bringen, das ist zwar geplant, aber es lief bisher über Jahre, genauso wie es eben ist. Weitere Informationen bitte gern nachfragen.


Und meinen Respekt für das Lesen des langen Textes.