Support-Thread Modul 36_Shelly.pm

[cwagner]

[gelöst mit Modul-Version v6.0.5-s29141 vom 2024-09-11]

Mit dem Ausbau meiner Shellys als Geräte im Modul 36_Shelly habe ich nun seit Einbindung eines Shelly
Plus 0...10V Gen. 2 bei jeder Änderung von pct zwei Einträge im Log, die ich mir nicht erklären kann:

Code Auswählen Erweitern

2024.09.04 15:14:16 1: [Shelly_response:onoff] returns without success for device DIM_Solarpumpe, cmd=?id=0&brightness=19 but ison= vs 4
2024.09.04 15:14:16 2: DIM_Solarpumpe: undefined value for source_4
Tatsächlich sind die Werte korrekt gesetzt und die Drehzahl der Pumpe ändert sich auch prompt. Auch werden die Werte in der Shelly-App angezeigt.
Der Dimmer ist grundsätzlich on und wird eigentlich auch nicht ausgeschaltet.

(Der Dimmer mit dem Addon oben drauf dient als PWM-Senke für Solarpumpe, die darüber geregelt wird).
Was mache ich falsch oder: Womit kann ich dienen zur Aufklärung?

Vielleicht mit einem Verbose?:

Code Auswählen Erweitern

2024.09.04 20:34:00 3: [Shelly_Set] calling for device DIM_Solarpumpe with command 'pct' and 1 parameters: 100
2024.09.04 20:34:00 4: [Shelly_Set] DIM_Solarpumpe channel is 0
2024.09.04 20:34:00 5: [Shelly_Set] DIM_Solarpumpe 'timer_0': no timer to add to pct
2024.09.04 20:34:00 4: [Shelly_Set] setting brightness for device DIM_Solarpumpe to 100
2024.09.04 20:34:00 4: [Shelly_HttpRequest] issue a non-blocking call to http://***.***.***.***/rpc/Light.Set?id=0&brightness=100, callback to Shelly_response, onoff
2024.09.04 20:34:00 5: [Shelly_HttpResponse] successfull: DIM_Solarpumpe returned 'null', transfering to JSON: {"cover":"successfull"}
2024.09.04 20:34:00 5: [Shelly_HttpResponse] DIM_Solarpumpe http://***.***.***.***/rpc/Light.Set?id=0&brightness=100 returned data: {"cover":"successfull"}
2024.09.04 20:34:00 4: [Shelly_HttpResponse] DIM_Solarpumpe: standard JSON decoding
2024.09.04 20:34:00 4: [Shelly_HttpResponse] DIM_Solarpumpe: forwarding JSON-Hash to func: main::Shelly_response
2024.09.04 20:34:00 4: [Shelly_response] device DIM_Solarpumpe has returned JSON for component onoff to set /rpc/Light.Set
2024.09.04 20:34:00 1: [Shelly_response:onoff] returns without success for device DIM_Solarpumpe, cmd=?id=0&brightness=100 but ison= vs 4
2024.09.04 20:34:00 4: [Shelly_response:onoff] received callback from DIM_Solarpumpe channel 4 is switched , no timer set
2024.09.04 20:34:00 2: DIM_Solarpumpe: undefined value for source_4
2024.09.04 20:34:00 4: [Shelly_response] scheduled status call for DIM_Solarpumpe in 0.4 sec
2024.09.04 20:34:01 4: [Shelly_HttpRequest] issue a non-blocking call to http://***.***.***.***/rpc/Shelly.GetStatus, callback to Shelly_status2G,
2024.09.04 20:34:01 4: [Shelly_status] DIM_Solarpumpe: Status-Timer restartet, update in 60 seconds
2024.09.04 20:34:01 5: [Shelly_HttpResponse] DIM_Solarpumpe http://***.***.***.***/rpc/Shelly.GetStatus returned data: {"ble":{},"cloud":{"connected":true},"input:0":{"id":0,"state":null},"input:1":{"id":1,"state":null},"light:0":{"id":0,"source":"HTTP_in","output":true,"brightness":100,"temperature":{"tC":63.5, "tF":146.3}},"mqtt":{"connected":false},"sys":{"mac":"***********","restart_required":false,"time":"20:34","unixtime":1725474841,"uptime":2666,"ram_size":253984,"ram_free":137468,"fs_size":393216,"fs_free":102400,"cfg_rev":19,"kvs_rev":0,"schedule_rev":0,"webhook_rev":0,"available_updates":{},"reset_reason":1},"wifi":{"sta_ip":"***.***.***.***","status":"got ip","ssid":"***.***.***.**","rssi":-73},"ws":{"connected":false}}
2024.09.04 20:34:01 4: [Shelly_HttpResponse] DIM_Solarpumpe: standard JSON decoding
2024.09.04 20:34:01 4: [Shelly_HttpResponse] DIM_Solarpumpe: forwarding JSON-Hash to func: main::Shelly_status2G
2024.09.04 20:34:01 4: [Shelly_status2G] device DIM_Solarpumpe of model shellyplus010v processing one-in-all status call
2024.09.04 20:34:01 4: [Shelly_status2G:sys] DIM_Solarpumpe: Processing sys values
2024.09.04 20:34:01 5: [Shelly_proc2G:status] DIM_Solarpumpe: hasconn=true
2024.09.04 20:34:01 5: [Shelly_status2G:sys] DIM_Solarpumpe: v1.4.2 no stable update, no beta update available
2024.09.04 20:34:01 5: [Shelly_rssi] returns -73 to device DIM_Solarpumpe
2024.09.04 20:34:01 4: [Shelly_status2G:network] DIM_Solarpumpe ethernet=-,wifi=***********7 @ -73
2024.09.04 20:34:01 5: [Shelly_status2G:input] Processing 2 input states for device DIM_Solarpumpe (shellyplus010v)
2024.09.04 20:34:01 4: [Shelly_status2G:input] Processing state of input 0 for device DIM_Solarpumpe
2024.09.04 20:34:01 4: [Shelly_status2G:input] Processing state of input 1 for device DIM_Solarpumpe
2024.09.04 20:34:01 4: [Shelly_status2G:light] Processing 1 light states for device DIM_Solarpumpe (shellyplus010v)
2024.09.04 20:34:01 5: [Shelly_status2G:light] Processing state of dimmer 0 for device DIM_Solarpumpe
2024.09.04 20:34:01 5: [Shelly_status2G:inttemp] DIM_Solarpumpe processed internal temperature
2024.09.04 20:34:01 4: [Shelly_status2G:addon] DIM_Solarpumpe: processing Shelly Plus Sensor Addon
2024.09.04 20:34:01 4: [Shelly_status2G] DIM_Solarpumpe: next 'GetStatus' update in 60 seconds

Christian

[Starkstrombastler]

was bedeuten im Logfile, z.B.nach einem shutdown restart / update all die vielen Einträge für praktisch alle meine Shelly-Rolladen_Devices

Das bedeutet das, was da steht: die in den Shellies eingetragenen Webhooks werden geprüft und ggf. aktualisiert. Enthält der Webhook ein CSFR-Token, so muss der Webhook auf dem Shelly aktualisiert werden, da nach einem Neustart von FHEM die Token neu vergeben werden. 
Den Verbose-Level werde ich aber noch erhöhen, und die beiden Meldungen zusammenfassen.

[Starkstrombastler]

Reading (Bsp online) wo ich  sofort sehe ob der betroffene Shelly im Wlan eingebucht ist

ganz so simple ist es dann aber doch nicht, weil ja zumindest die Pro-Geräte auch per LAN verbunden sein könnnen.
Denkbar ist aber ein neues Reading 'network_connection', welches die Werte offline, online, online (Wifi), online (LAN) annehmen kann.
Das lässt sich auch einfach in einer ReadingsGroup auswerten.

Deckt das deinen Bedarf ab?

[Wzut]

@Starkstrombastler, klingt gut BIG THX !

[Starkstrombastler]

Mit dem Ausbau meiner Shellys als Geräte im Modul 36_Shelly habe ich nun seit Einbindung eines Shelly
Plus 0...10V Gen. 2 bei jeder Änderung von pct zwei Einträge im Log, die ich mir nicht erklären kann

Verstehe ich das richtig, das Modul funktioniert hier an sich korrekt, nur die Logeinträge sind etwas "verworren"?

--> muss ich mir ansehen, Danke jedenfalls für den Hinweis.

[optimizer]

Die Zusatzeinträge im Log beim Shelly Dimmer0-10 kann ich bestätigen. Bei mir werden jedesmal zwei sinnlose Einträge geschrieben:

Code Auswählen Erweitern

2024.09.07 19:13:38 1: [Shelly_response:onoff] returns without success for device shelly_dimmer, cmd=?id=0&brightness=39 but ison= vs 4
2024.09.07 19:13:38 2: shelly_dimmer: undefined value for source_4

[cwagner]

Verstehe ich das richtig, das Modul funktioniert hier an sich korrekt, nur die Logeinträge sind etwas "verworren"?

Exakt, lieber Starkstrombastler, das Modul funktioniert, mich verwirren/irritieren nur diese stets wiederkehrenden Fehlermeldungen im Log.

Ich benutze bewusst pct statt dim, weil die Pumpe sich selbst bei 1% in einen deepsleep legt.

[sfh]

Hallo,

nach dem heutigen FHEM-Update habe ich kleinere Probleme mit 4 Shelly-Aktoren, die meine Rollläden steuern (2x Shelly 2.5 und 2x Shelly Plus2PM). Die grundsätzliche Funktion ist vorhanden, allerdings werden die Endstellungen nicht mehr erkannt. Auch wenn man die Rollläden direkt über die Taster am Aktor bedient, wird die neue Stellung vom Shelly-Modul nicht erkannt. Die Actions im Shelly sind richtig konfiguriert und mit der bisher verwendeten Modul-Version 5.21.1 hat das auch alles bestens funktioniert. Die Meldungen vom Shelly scheinen in FHEM anzukommen, denn man findet Einträge wie z.B. "/_set.command: is_open". Ich habe übrigens einen "interval"-Wert von 900 eingestellt und bei der nächsten zyklischen Abfrage stimmt auch alles wieder. Als Notlösung könnte ich das Interval wieder auf 60 setzen, schöner wäre aber eine direkte Reaktion auf die Actions vom Shelly. Oder hat sich bei den Einstellungen der Actions etwas geändert?

Viele Grüße, Scott

[Starkstrombastler]

Hallo sfh,

nach deiner Beschreibung scheint alles korrekt zu sein, und die Befehle für die Actions haben sich auch nicht geändert.

Da aber an vielen Stellen Fehler entstehen können, wäre es trotz

Die Actions im Shelly sind richtig konfiguriert

richtig, einmal auf die im Shelly hinterlegten Actions zu schauen. Bitte einmal für Gen1 bzw. Gen2 hier posten.

[sfh]

Da aber an vielen Stellen Fehler entstehen können, wäre es trotz

Die Actions im Shelly sind richtig konfiguriert

richtig, einmal auf die im Shelly hinterlegten Actions zu schauen. Bitte einmal für Gen1 bzw. Gen2 hier posten.

Hallo

und vielen Dank. Hier sind die Actions aus einem der Gen1-Shellies (Shelly 2.5), die ich nach FHEMWiki konfiguriert habe:

http://192.168.x.y:8085/fhem?XHR=1&cmd=set%20Roll.WohnL%20is_open
http://192.168.x.y:8085/fhem?XHR=1&cmd=set%20Roll.WohnL%20is_closed
http://192.168.x.y:8085/fhem?XHR=1&cmd=set%20Roll.WohnL%20stopped

Die Actions bei den Gen2-Shellies sind im gleichen Format und es sind nur die 3 wie oben definiert. "Cover opening" und "Cover closing" habe ich weggelassen.

[Buxkugel]

Hallo erstmal.
Ist zwar mein erster Beitrag, aber ich lese hier schon lange mit und habe bisher alle meine Problemchen auch damit lösen können.

Aber hier hänge ich mal dran, da mir das von sfh geschilderte Verhalten ebenfalls aufgefallen ist.

Für meine Rollladensteuerung nutze ich Shelly Plus 2PM, alle mit der aktuellen Firmware 1.4.2.
Das Shelly-Modul hat die Version 6.00.2 vom 24.08.2024. Somit sollte eigentlich alles auf dem aktuellen Stand sein.

Bei dem Attribut event-on-change-reading habe ich die Readings state und pct eingetragen (nutze ich beide in DOIFs), die eingetragenen Actions im Shelly (über das Attribut webhook) aktualisieren bei mir aber nur noch das Reading state sofort, das Reading pct für die Position wird jetzt erst mehr oder weniger später im zyklischen Intervall (60 sek.) aktualisiert... eben das von sfh beschriebene Verhalten.

Das ich das pct-Reading für Meldungen über die aktuellen Rollladenöffnungen an Telegram nutze (DOIF mit einem 30 sek. resetwait-Timer), bekomme ich jetzt oft Zwischenmeldungen über die Positionen, das war vorher (alte Firmware, altes Modul) definitiv nicht so.
Ich habe als Workaround jetzt erstmal den resetwait-Timer im DOIF auf 90 sek. erhöht, damit bekomme ich dann auf jeden Fall nur die eine gewünschte Meldung über die letzte Stop-Position.
Das Reading state nutze ich für die Steuerung der Rollläden per DOIF mit Zigbee-Schaltern (über deconz/ConBee2), je nach state (fährt oder stop) führt der Taster halt die passende gegenteilige Aktion aus.
Da dieses Reading über die eingetragenen Actions im Shelly immer noch sofort aktualisiert wird, funktioniert dies weiterhin äußerst zuverlässig.

Was mir noch aufgefallen ist:
ich wollte die Actions in den Shellys mal löschen und neu eintragen (man versucht ja dann so einiges), aber...
Lösche ich das Attribut webhook, sollten ja auch die Actions in den Shellys gelöscht werden.
Soviel zur Theorie, das hat vor dem Update auch funktioniert, jetzt musste ich sie aber von Hand löschen!
Dann habe ich das Attribut webhook wieder gesetzt und gehofft, dass die Actions wenigstens wieder neu eingetragen werden, aber auch dies hat leider nicht mehr funktioniert und ich musste erneut Handarbeit leisten.
Am Verhalten geändert hat sich dadurch aber leider überhaupt nichts. 

Irgendwas ist da faul... 

[Starkstrombastler]

Hier sind die Actions aus einem der Gen1-Shellies (Shelly 2.5), die ich nach FHEMWiki konfiguriert habe:

http://192.168.x.y:8085/fhem?XHR=1&cmd=set%20Roll.WohnL%20is_open
http://192.168.x.y:8085/fhem?XHR=1&cmd=set%20Roll.WohnL%20is_closed
http://192.168.x.y:8085/fhem?XHR=1&cmd=set%20Roll.WohnL%20stopped

Die Actions bei den Gen2-Shellies sind im gleichen Format und es sind nur die 3 wie oben definiert. "Cover opening" und "Cover closing" habe ich weggelassen.

Da muss ich leider feststellen, dass im Wiki die Angaben für is_open und is_closed angepasst werden müssen: Diese Befehle sind ja für das Erreichen der Endlage vorgesehen, und dafür unterstützen die Gen1-Shellies keine Actions. Es hat aber augenscheinlich trotzdem funktioniert, weil das Modul bei Eintreffen dieser Befehle einen "get ... status" absetzt, und damit wird dann das tatsächliche Geschehen erfasst.
Auch habe ich den Teil XHR=1 aus dem Wiki entfernt, weil ich nicht erkennen kann, wofür das nützlich ist, das hatte ich nur vom ursprünglichen Modul übernommen.
Damit lauten die URLS für die Gen1-Shellies:

Code Auswählen Erweitern

http://192.168.x.y:8085/fhem?cmd=set%20Roll.WohnL%20opening
http://192.168.x.y:8085/fhem?cmd=set%20Roll.WohnL%20closing
http://192.168.x.y:8085/fhem?cmd=set%20Roll.WohnL%20stopped
Zum eigentlichen Problem komme ich in meiner Antwort zum Beitrag von Buxkugel...

[sfh]

[...]
Damit lauten die URLS für die Gen1-Shellies:

Code Auswählen Erweitern

http://192.168.x.y:8085/fhem?cmd=set%20Roll.WohnL%20opening
http://192.168.x.y:8085/fhem?cmd=set%20Roll.WohnL%20closing
http://192.168.x.y:8085/fhem?cmd=set%20Roll.WohnL%20stopped

Ich habe jetzt einen der Gen1-Shellies nach diesem Schema angepasst und ein wenig experimentiert. Steuert man diesen mit set gerät pct wert, dann wird die neue Stellung richtig angezeigt, auch bei den Endwerten 0 und 100. Bei Steuerung über set gerät closed bzw. set gerät open wird die Endstellung hingegen nicht erkannt und erst beim nächsten Polling korrigiert. Steuert man den Rollladen über die Taster am Shelly, dann werden auch weiterhin keine Änderungen erkannt. Allerdings kann man beim Reading /_set.command schön verfolgen, was am Rollladen passiert. Die Actions werden also offensichtlich korrekt übermittelt.

Einen der Gen2 habe ich ebenfalls geändert und nun alle 5 Actions definiert. Hier funktionieren jetzt alle set-Kommandos korrekt. Aber auch hier werden Bedienungen direkt am Shelly nicht vom Modul erkannt und erst beim nächsten Polling aktualisiert. Aber die Übermittlung der Actions klappt, denn das Reading /_set.command zeigt alle Aktivitäten korrekt an.

[Starkstrombastler]

Hallo zusammen,

das grundsätzliche Problem bei Rollos ist ähnlich dem Verhalten von Dimmern (mit Rampe) oder von on/off-for-timer Schaltvorgängen: Es interessieren die Zustände direkt nach dem Einschalten, und dann möchte man möglichst schnell das Ende des Vorganges signalisiert bekommen.
Und dabei können die Dinge auf unterschiedlichen Weg ausgelöst werden.
Dazu kommt, das die Shellies auch in gewisser Weise getaktet werden. Wird bei einer Rollofahrt der Status zu früh abgerufen, dann ist die Leistung noch 0 Watt, was irgenwie blöd ist. Also mit Timer so ca. 1 sec verzögert abfragen.....
Im Modul ist dabei leider einiges mit den Timern aus den Fugen geraten und der Status wird zu oft oder garnicht abgerufen.

Lösche ich das Attribut webhook, sollten ja auch die Actions in den Shellys gelöscht werden.

Das stimmt so nur teilweise, es sollten keinesfalls Actions gelöscht werden, die auf andere Weise angelegt worden sind. Es hat sich aber gezeigt, dass dieser Automatismus an seine Grenzen stößt und sich insbesondere nach einem Absturz von Fhem nicht mehr vernünftig synchronisiert.
Actions können nach wie vor via Fhem angelegt und gelöscht werden, aber das muss manuell angestoßen werden (bei Gen1 noch nicht voll vorhanden).

[JWRu]

Seit dem letzten Update steht bei meinen Gen.2 Devices im Reading firmware "v1.4.2(check internet for firmware v1.3.3)".
Was bedeutet die Angabe in Klammern?