Auto Off: add multiple timers support.

[andyblac]

By this I mean if a Light was turned on via a sensor in HomeKit, activate the auto off, as now the auto off is reset on every time the light is turn on.

It would be good that the auto off does not get activated if someone turns of the light manaully via the physical switch, of course this need to be a checkbox for the user to decide how the auto off should be activated.

[rojer]

hm. ok, i guess we could convert auto-off from binary yes/no to no/yes, homekit only/yes, physical only/yes, both.
how does that sound?

[andyblac]

Yeah sounds good

[andyblac]

@rojer I have been thinking about this more, would it be posible to add a 2nd Auto Off timer that is only started if the relay is turned on via HomeKit ?

So 1 for physical switch and 1 for homekit side.

This would then allow the default auto off be say 20mins (used to turn off lights if some accidently left them on), but if relay was turned on via a HomeKit action, we could set that auto off for say 3 mins. and on every time the relay is turned on it resets.

i know homekit supports a "Turn Off after xxx", but i have found that it does not work well, and the count down reset does not always action on sensor detection.

[andyblac]

ok as the main shelly code has added more suport for other things since this request I'll update it here.

Can we add support for multiple auto timers as follows.

1. Physical switch action. (only started when the switch is pressed)
2. HomeKit action. (only started when HomeKit activated the relay)
3. REST API action. (this does not need to show in webUI but just a flag used the url. ie for 10min we could use http://192.168.3.49/rpc/Shelly.InjectInputEvent?id=1&event=2?autotimer=600000 / http://192.168.3.49/rpc/Shelly.SetState?id=1&type=0&state=%7b%22state%22%3atrue%7d?autotimer=600000

each of these timers need to work independently, but of cause if a timer is already started, and the physicle switch or HomeKit is actioned it stops the timer, and each can be set at same time with differant timer lengths.

ie
1: a shelly DW2 has http://192.168.3.49/rpc/Shelly.InjectInputEvent?id=1&event=2?autotimer=600000 as a action url. and the door is opened
2: light turns on and autotimer starts
3: person leaves the room, but leave door open, and press physicle switch to turn off light.
4: light turns off and autooff is stopped.

@rojer , @timoschilling is this something you could add ?

[socialsubs]

ok as the main shelly code has added more suport for other things since this request I'll update it here.

Can we add support for multiple auto timers as follows.

1. Physical switch action. (only started when the switch is pressed)
2. HomeKit action. (only started when HomeKit activated the relay)
3. REST API action. (this does not need to show in webUI but just a flag used the url. ie for 10min we could use http://192.168.3.49/rpc/Shelly.InjectInputEvent?id=1&event=2?autotimer=600000 / http://192.168.3.49/rpc/Shelly.SetState?id=1&type=0&state=%7b%22state%22%3atrue%7d?autotimer=600000

each of these timers need to work independently, but of cause if a timer is already started, and the physicle switch or HomeKit is actioned it stops the timer, and each can be set at same time with differant timer lengths.

ie
1: a shelly DW2 has http://192.168.3.49/rpc/Shelly.InjectInputEvent?id=1&event=2?autotimer=600000 as a action url. and the door is opened
2: light tunrs on and autotimer starts
3: person leaves the room, but leave door open, and press physicle switch to turn off light.
4: light turns off and autooff is stopped.

@rojer , @timoschilling is this something you could add ?

Thanks andyblac, the 3rd option is exactly what I requested in the #466.

[rojer]

in general, we tend to delegate all the "smarts" to homekit controllers. that said, if features are easy to implement and non-intrusive, i see no problem.
in this case, i think adding a "single shot auto-off" option to the RPC call (i.e. API) would be simple enough to do. no need to expose it in the UI and homekit (there' no way to do it anyway).

[andyblac]

in general, we tend to delegate all the "smarts" to homekit controllers. that said, if features are easy to implement and non-intrusive, i see no problem.
in this case, i think adding a "single shot auto-off" option to the RPC call (i.e. API) would be simple enough to do. no need to expose it in the UI and homekit (there' no way to do it anyway).

and point 1 / 2 ? doable ? , just HomeKit "turn off after" is awfull does not work reliably.

[rojer]

now, this is a bit too complicated to my taste. is it possible to do with automations instead?

[andyblac]

now, this is a bit too complicated to my taste. is it possible to do with automations instead?

not really, HomeKit "turn off after" is awfull does not work reliably.

[andyblac]

3 mins is about HomeKit max, else it just seems to forget to turn it off again, or did last time i tried to use it.

[rojer]

since this is not present in the stock firmware and there is already "turn off after" feature in homekit, i think this would be an overreach on our part.
if the feature doesn't work, it should be reported to apple and hopefully get fixed.

i am fine with implementing (3) - per-request auto off time override for the API, that's easy to do.

[andyblac]

since this is not present in the stock firmware and there is already "turn off after" feature in homekit, i think this would be an overreach on our part.
if the feature doesn't work, it should be reported to apple and hopefully get fixed.

i am fine with implementing (3) - per-request auto off time override for the API, that's easy to do.

turn off after does work as one off, just not with sensors verry well. using short timer it works just you can;t timer say 10mins / 20 mins, it the same with shortcuts, long timers dont work. it always been this way, lots of people have submitted bug reports apprently but it is never changed.

[andyblac]

@rojer can we go back to your 1st sugestion then?

hm. ok, i guess we could convert auto-off from binary yes/no to no/yes, homekit only/yes, physical only/yes, both.
how does that sound?

and option 3 aswell.