expire set to minutes, hours or anything > 29seconds never shoots. settings up to 29 seconds works as designed, expire=“30s, OFF” or more doesnt. I cant recreate that problem on dummy items or other devices managed via MQTT, like tasmota.
but I can recreate this symptom on all my shelly switches…
I know about the shelly binding but I prefer a common management for tasmota and shelly (some shellys are tasmota flashed)…
can someone recreate this behaviour or know how to solve this?
If another binding is repeatedly updating the state of the item to be the same state it already was, the expiration timer will continue to be reset into the future. Dedicating an item to the expiration function (so it doesn’t receive repeated updates from another binding) would avoid unwanted behavior, should it apply in your case.
you`re right, Shelly is updating that item every 30sec:
so, expire works fine on my tasmota devices because the item listens on the state topic that is only updated once when the switch is triggered. further to that there is a tele topic which by default sents its status every 5 minutes.
but the shelly switch item has no seperate state or tele topic, so the way to go is like @denominator said via a dummy Timer item or even better, simply flash tasmota to shelly
I’ll dig further into MQTT, powerretain might be another thing to improve a smarthome precision but as long as OH and MQTT broker reside on the same machine, that won`t improve anything I guess. QoS level 2 sounds interesting but tasmota doesn’t support that. I figured out that tasmota publishes a state topic on reboot, may be it does so also during reconnect to the broker (and reset the expire timer again…)
I think the most stable solution to expire a switch is to outsource “expire” to the device itself (autopower on shelly or PulseTime on tasmota).
do you agree and is there some kind of “best-practice” manual for MQTT-OH-device?
You might clarify what you want to happen, before selecting the means to do it. Must this thing turn off EVERY time it is turned on? Will you ever need to override that? What is to happen if a repeat on-instruction comes along during the already-on delay period? Would you ever want a flexible time delay, or a conditional “only if xx”?