Shelly Dimmer2: BUG in Shelly-FW oder Shelly.pm Problem?

Begonnen von TubeHead, 31 Oktober 2024, 11:40:17

Vorheriges Thema - Nächstes Thema

TubeHead

Hallo liebe Leute,

meine Frage richtet sich an alle, die mit dem Dimmer2 von Shelly arbeiten und natürlich an @Starkstrombastler als Maintainer...

Inzwischen hat es den letzten HM-Dimmer gerissen, welcher nun auch durch einen Dimmer2 ersetzt wurde. Da die bisherigen Dimmer in Räumen verbaut sind, welche eher nie per FHEM angesteuert wurden, sondern direkt per Taster im Raum, ist mir das Problem erst jetzt aufgefallen.

Im Dimmer kann ich über die WebGUI den Parameter On/Off Transition time, milliseconds im Bereich bis 5s vorgeben; ist bei allen Dimmern auf 2500ms gesetzt.
Wenn ich einen beliebigen Dimmer2 über den angeschlossenen Taster bediene, dann funktioniert das wunderbar und der Dimmer fährt sanft von off bis zum zuletzt eingestellten Wert hoch resp. von dort beim nächsten Tastendruck sanft wieder auf off.
Sende ich aber per FHEM ein "on" resp. "off" an den Dimmer, so wird bei allen Dimmern der besagte Parameter ignoriert und die Dimmer schalten das Leuchtmittel ohne Verzögerung an resp. aus.
Dieses Problem tritt bei der Firmware 20230913-114008/v1.14.0-gcb84623 ebenso auf, wie bei der (ewigen) Beta 20231107-164738/v1.14.1-rc1-g0617c15.

Ist dieses Problem bekannt? Und wenn ja, wie lässt sich das beseitigen resp. gibt es dafür einen Workaround?

EDIT:
Dazu gibt es auch einen Thread im Shelly-Forum: https://community.shelly.cloud/topic/3053-transition-time-ignored-while-switching-per-wlan/




RalfRog

#1
Hallo
Ich habe so ein Teil nicht. Aber lt. Hilfe gibt es unterschiedliche Kommandos zum "schalten" => set <name> dim
Ggfs. als Workaround.


ZitatFür Shelly Dimmer Devices (model=shellydimmer oder model=shellyrgbw und mode=white)

  • set <name> on|off|toggle [<channel>]
    schaltet Kanal <channel> on oder off.

  • set <name> pct <1...100> [<channel>]
    Prozentualer Wert für die Helligkeit (brightness). Es wird nur der Helligkeitswert gesetzt ohne das Gerät ein oder aus zu schalten.

  • set <name> pct 0 [<channel>]
    Das Gerät/Kanal wird ausgeschaltet, der vorhandene Helligkeitswert bleibt unverändert.

  • set <name> dim <0...100>[:<transition>] [<channel>]
    Prozentualer Wert für die Helligkeit (brightness). Es wird der Helligkeitswert gesetzt und eingeschaltet. Bei einem Helligkeitswert gleich 0 (Null) wird ausgeschaltet, der im Shelly gespeicherte Helligkeitswert bleibt unverändert. Optional kann mit Doppelpunkt getrennt die Transit-Zeit 'transition' in Sekunden vorgegen werden.

Gruß Ralf
FHEM auf Proxmox VM Bookworm (Futro S740) - nanoCUL, HM-MOD-RPI-PCB und MAX!Cube über LAN
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder sowie Shelly 3EM, 1PM, PlugS und IT Schaltsteckdosen

TubeHead

Jo Dank dafür. Die habe ich aber (fast) alle schon durch.

on|off|toggle generiert halt das sofortige ein/ausschalten wie dargestellt.

pct ist keine Option, da ein Senden des pct-Wertes ebenfalls sofort auf den übergebenen Wert springt.

aBär:

set <name> dim <0...100>[:<transition>] wäre ggf. eine Option, einen Workaround zu bauen, wenn es gelingt, den letztmalig eingestellten Wert von pct zu lesen. Das werde ich mal ausprobieren, ob das geht. Von daher ein guter Hinweis, der mich evtl. weiterbringt!

RalfRog

#3
Je nach Forscherdrang kannst du bei Gen1 Devices über die Entwicklertools des Browsers vermutlich relativ leicht sehen was beim wunschgemäßen Einschalten über das Webinterface des Shellies gesendet wird und es mit dem Log in Verbose 5 vergleichen wenn du über FHEM schaltest.
(Beispielbild vom Einschalten meines PlugS => Einschalten per http://<IP>/relay/0?turn=on  // der Dimmer ist lt. API analog http://<IP>/light/0...)
FHEM auf Proxmox VM Bookworm (Futro S740) - nanoCUL, HM-MOD-RPI-PCB und MAX!Cube über LAN
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder sowie Shelly 3EM, 1PM, PlugS und IT Schaltsteckdosen

TubeHead

#4
Ja, das ist auch eine gute Idee mit den DevTools vom FF.

Ich habe aber gerade mal testweise ein
set SH_SD01 dim 50:2500 an den Dimmer gesandt. Lt. Definition sollte er auf 50% dimmen und sich dabei 5 Sekunden Zeit lassen. Tut er aber nicht. Ist sofort auf 50% ohne jedwede Verzögerung.
Auf dem Wege klappt das also, leider leider, auch nicht  :(

BTW: Über die WebGUI des Dimmer2 wird
    http://192.168.1.87/light/0?turn=off
gesendet

Starkstrombastler

Zitat von: TubeHead am 31 Oktober 2024, 11:40:17Wenn ich einen beliebigen Dimmer2 über den angeschlossenen Taster bediene, dann funktioniert das wunderbar und der Dimmer fährt sanft von off bis zum zuletzt eingestellten Wert hoch resp. von dort beim nächsten Tastendruck sanft wieder auf off.
Sende ich aber per FHEM ein "on" resp. "off" an den Dimmer, so wird bei allen Dimmern der besagte Parameter ignoriert und die Dimmer schalten das Leuchtmittel ohne Verzögerung an resp. aus.
Ich habe hier einen ShellyDimmer2 mit FW v1.14.0 und der funktioniert so wie von dir gewünscht. Sowohl bei Tasterbedienung als auch über das Shelly-Modul wird entsprechend der im Shelly gespeicherten Transition-Time gedimmt.

Das Log dazu sieht so aus:
2024.10.31 21:10:02.814 4: [Shelly_Set] switching channel 0 for device Y190 with command ?turn=on, FF=2
2024.10.31 21:10:02.815 4: [Shelly_HttpRequest] issue a non-blocking call to http://192.168.178.190/light/0?turn=on, callback to Shelly_response, onoff
2024.10.31 21:10:02.847 4: [Shelly_HttpResponse] Y190 http://192.168.178.190/light/0?turn=on returned data: {"ison":true,"source":"http","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","brightness":84,"transition":0}
(Im Return-String wird nur der Wert von ison aktualisiert, der Rest ist eine Kopie des vorhergehenden Status)

Ebenso tuts auch der Dim-Befehl mit Transition...

Am besten erstmal den Shelly rebooten und dann neu kalibrieren.
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

TubeHead

#6
Zitat von: Starkstrombastler am 31 Oktober 2024, 21:35:27Ebenso tuts auch der Dim-Befehl mit Transition...
Nope. Macht hier keiner der Dimmer (5 Stück), auch der letzte, nagelneue nicht.

Zitat von: Starkstrombastler am 31 Oktober 2024, 21:35:27Am besten erstmal den Shelly rebooten und dann neu kalibrieren.
Habe den neuen gerade mal neu gestartet und an dem Test-Leuchtmittel (60W Glühfaden) kalibriert... Das Gleiche in grün... Leider...

EDIT:
Gerade mit dem ältesten Dimmer das gleiche Spiel gemacht: Reset, Kalibrierung gelöscht, Reset, Kalibrierung neu (LED dimmbar), Reset, "set SH_SD04 dim 50:2500" -> Gleiche Problem wie gehabt...

Ich verstehe nicht, wieso das bei Dir funktioniert, bei mir mit insg. 5 Dimmern aus (ich meine) 5 Jahren bei keinem einzigen davon...


Neuer Tag, neues Rätsel:
Nach dem 4. Kaffee bin ich noch mal beigegangen und etwas herumgetestet, dieses mal nach Liste und am vorgesehenen Einbauort (Holde war etwas unwirsch, das sie kein Licht im WZ hat...):

1. Senden on/off direkt via http aus dem FF (192.168.1.87/light/0?turn=on|off)
 -- FUNKTIONIERT --

2. Senden on/off/toggle aus Kommandozeile FHEM (set SH_SD01 on|off|toggle)
 -- FUNKTIONIERT --

3. Senden cmd3|4 aus dem DOIF (set set_311l_ta cmd3|cmd4)
 -- FUNKTIONIERT --

4. Senden on/off via HM6TA2 (HM-PB-6-WM55) an das DOIF (set SH_SD01 on|off)
-- FUNKTIONIERT NICHT --

... das raff ich nicht  :o  >:(

(Video dazu unter https://steamradio.de/sh/dimmer2_vs_DOIF.mp4 / Sieht man nicht gut. Das langsame hoch-/runterdimmen kann man am "Pumpen" der Helligkeitsregelung vom SmartPhone erkennen

TubeHead

#7
So... Nach noch mehr Tassen Kaffee und einer IBU800 habe ich nun eine Lösung und wohl das Problem ausgemacht...

Problem ist nicht das Shelly.pm Modul (sorry @Starkstrombastler; meine Blödheit vermutlich), sondern eher, wie DOIF einen externen Trigger verarbeitet; zumindest glaube ich das jetzt.
Wenn ich das DOIF mit einem HM 6-Fach Taster in der üblichen Art mit [HM6TA2_2:?Short.*] anfahre, aber mit [HM6TA2_2:?Long.*] dimmen will, brauche ich ein DO always. Das aber sorgt bei dem [HM6TA2_2:?Short.*] wohl für eine Mehrfach-Triggerung. Wenn ich DO always weglasse, funktioniert [HM6TA2_2:?Short.*] resp. der Dimmer einwandfrei, aber dann kann ich mit meinem Konstrukt nicht mehr dimmen.

Also habe ich alle umgebaut und nun folgendes:

defmod set_311l_ta DOIF ([HM6TA2_2:?Long.*]) (set SH_SD01 pct {([SH_SD01:pct]+5)}) \
    DOELSEIF ([HM6TA2_1:?Long.*]) (set SH_SD01 pct {([SH_SD01:pct]-5)}) \
    DOELSEIF ([HM6TA2_2:?Short.*] and [SH_SD01] eq "off") (setreading $SELF pct [SH_SD01:pct], set SH_SD01 on)\
    DOELSEIF ([HM6TA2_2:?Short.*] and [SH_SD01] eq "on" and [SH_SD01:pct] < 100) (setreading $SELF pct [SH_SD01:pct], set SH_SD01 pct 100) \
    DOELSEIF ([HM6TA2_2:?Short.*] and [SH_SD01] eq "on" and [SH_SD01:pct] == 100) (set SH_SD01 pct [$SELF:pct]) \
    DOELSEIF ([HM6TA2_1:?Short.*]) (set SH_SD01 pct [$SELF:pct], set SH_SD01 off)

attr set_311l_ta repeatsame 20:20

setstate set_311l_ta cmd_3
setstate set_311l_ta 2024-11-01 13:49:01 Device SH_SD01
setstate set_311l_ta 2024-11-01 13:49:00 cmd 3
setstate set_311l_ta 2024-11-01 13:49:00 cmd_event HM6TA2_2
setstate set_311l_ta 2024-11-01 13:49:00 cmd_nr 3
setstate set_311l_ta 2024-11-01 13:49:00 e_HM6TA2_1_events commState: CMDs_done
setstate set_311l_ta 2024-11-01 13:49:00 e_HM6TA2_2_events triggerTo_VCCU: Short_148_ack
setstate set_311l_ta 2024-11-01 13:49:01 e_SH_SD01_STATE on
setstate set_311l_ta 2024-11-01 13:48:58 e_SH_SD01_pct 23
setstate set_311l_ta 2024-11-01 13:47:16 mode enabled
setstate set_311l_ta 2024-11-01 13:49:00 pct 23
setstate set_311l_ta 2024-11-01 13:49:00 state cmd_3

Da ist noch ein kleines WAF++ hinzugekommen (Zeile 4&5), aber ansonsten funktioniert das nun so.
Einziges Manko ist, das beim Dimmen irgendwann der Dimmer auf einen ERROR läuft, weil (dimmer):pct dann irgendwann über 100 resp. unter 0 läuft; macht nichts kaputt und daher nehme ich das in kauf.

Den "dimup/dimdown" Befehl habe ich absichtlich nicht genommen, da der in 25% Schritten springt (und ich nicht weiß, wie man das ändern kann)

Einzige Fragen, die bei mir jetzt noch offen sind:

1. Kann man dimup/dimdown irgendwie von den 25% Sprüngen weghelfen, und wenn ja, wie? Würde das ERROR-Problem beseitigen...

2. Gibt es eine elegante Möglichkeit, beim aktuellen Hoch- resp Runterdimmen auf 0% resp. 100% zu begrenzen?

Starkstrombastler

Zitat von: TubeHead am 01 November 2024, 14:05:191. Kann man dimup/dimdown irgendwie von den 25% Sprüngen weghelfen, und wenn ja, wie? Würde das ERROR-Problem beseitigen...
attr <name> dimstep <integer> oder
set <name> dimup <value>
Zitat von: TubeHead am 01 November 2024, 14:05:192. Gibt es eine elegante Möglichkeit, beim aktuellen Hoch- resp Runterdimmen auf 0% resp. 100% zu begrenzen?
Beim Auswerten des Set-Befehls wird auf 0 bzw. 100 begrenzt. Wie entsteht bei dir ein Fehler/welcher?
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

TubeHead

#9
Zitat von: Starkstrombastler am 01 November 2024, 14:22:21attr <name> dimstep <integer>oder
set <name> dimup <value>

Genial! Vielen lieben Dank!

Zitat von: Starkstrombastler am 01 November 2024, 14:22:21wird auf 0 bzw. 100 begrenzt. Wie entsteht bei dir ein Fehler/welcher?
Das betrifft nur meine aktuelle Steuerung des pct-Wertes mit Rauf-/Runterzählen ala...
set SH_SD01 pct {([SH_SD01:pct]+5)}Daher ja meine Frage, ob der dim-Schritt sich anpassen lässt, um genau diesen Fehler zu vermeiden

Ich mache an anderer Stelle aber sowas Ähnliches mit dem Rauf- und Runterzählen, da es anders nicht geht (ESP -> Frequenzumrichter). Da fange ich die Werte über ein ganz übles Dummy/DOIF-Konstrukt ab (frag lieber nicht ^^). Deshalb interessierte es mich, hier eigentlich OT, ob es da eine elegante Lösung der Begrenzung gibt... Ist aber nebensächlich...

EDIT:
set <name> dimup <value> funktioniert zwar, aber der pct-Wert wird erst beim Loslassen der Taste um den eingestellten Wert erhöht. repeatecmd und/oder repeatesame sind hier ohne Wirkung, DO always ebenso.