HUEDevice - dimUp killt laufenden on-for-timer

Begonnen von DS_Starter, 26 September 2021, 09:23:28

Vorheriges Thema - Nächstes Thema

DS_Starter

Hallo,

eine meiner HUE Leuchten schalte ich mittels notify mit on-for-timer ein.
Gewundert habe ich mich dass manchmal die automatische Abschaltung nicht funktioniert hat.

Nun habe ich festgestellt, dass es dann passiert wenn nach on-for-timer ein dimUp-Kommando (in meinem Fall) ausgeführt wurde. Das kommt natürlich vor, wenn ich die Lampe nach dem Einschalten mit on-for-timer hochdimmen will.

So wie ich es sehe, wird die laufende setExtension gecancelt.
@justme1968, würdest du es dir evtl. mal anschauen ?

Danke und VG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

justme1968

das ist normal und bei allen anderen fhem devices auch so. ein on-for timer oder off-for-timer wird durch ein nachfolgendes kommando abgebrochen. das ganze gilt bei hue auch für den device internen timer und ich vermute das gilt auch für hm oder andere.

wenn du mehr einfluss auf den timer haben möchtest. musst du ihn explizit und unabhängig machen. z.b. mit einem benannten sleep.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

DS_Starter

Danke justme, ich habe mir auch schon beholfen mit defmod at ...
Wollte es nur bekanntgeben. Mir war die Generalität dieses Verhaltens nicht bewußt weil ich recht selten die on-for-timer Funktion bei Leuchten nutze.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Beta-User

Wenn  SetExtensions involviert sind, kann man das dadurch gesetzte Internal auswerten/vorab auf Vorhandensein checken und dann nach dem dimUp-Befehl dann den SE-Command dann einfach nochmal abfeuern.

Zur Klarstellung: Ich halte es  nicht für einen Fehler, wenn nachfolgende Kommandos die vorhergehenden "killen", wenn man es anders haben will, muss man den Zusatz-Aufwand m.E. in Kauf nehmen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DS_Starter

Da ist ein simples


set <Lampe> on; defmod <Lampe>.off at +00:20 set <Lampe> off


aber viel einfacher statt des on-for-timer zu handhaben für einen User.
Nur meine Meinung ...
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter