It is inspired by the possibilities provided by the CountDown app, but easier (and probably a bit more efficient) to use. Also thanks to other apps, like blowfish for getting me started and Heimdall for providing some examples of the code/API.
Please let me know if it works for you as well, so I can promote it to stable. For now it works for me
If you are missing functionality let me know as well, and maybe I can add it in a new version
TODO
Implement a capability listener to process updates of changed capability values for devices on which a timer has run
Version history
v0.8.1 test - Homey V3
fix an issue of reading a capability value
v0.8.0 test - Homey V3
Upgraded to SDKv3
v0.7.3 beta - Homey V2 Only
Fixed a bug where timers wouldnât start anymore, after you manually turned off a device while the timer was still running
v0.7.2 beta - Homey V2 Only
updated athom api library, since it caches capability values, without updating them, but unfortunately without improvements
So implemented a dumb cache overwrite myself
v0.7.1 alpha - Homey V2 Only
refactored code to be more consistent
Fix retreiving capability value, instead of set
Probably fixed an issue, where old capability values got lost
Handle missing reference to previous timer, by logging warnings
TODO: find out how to get an up to date capability value
v0.7.0 alpha - Homey V2 Only
Removed instance caching of API results in app
Fixed a bug when filtering on devices, while zone name isnât available anymore
v0.6.2 beta - Homey V2 Only
fixed selecting devices blocking
fixed missing reference to event listener, making the app crash blocking
extra cache clear of api, to force update device state
updated athom api
v0.6.1 beta - Homey V2 Only
fixed settings page, that could contain timers that where already expired
v0.6.0 beta - Homey V2 Only
cancel timer when light turned off manually
handle name changes of devices
v0.5.0 beta
version 0.4.1 with new API compatibility for Homey V2
v0.4.3 stable
promoted 0.4.1 as stable, bumped as v0.4.3
v0.4.2revoked
update for Homey V2. But incompatbile with V1.5 without proper compatiblity requirement
v0.4.1 beta/stable
added detail view for timer settings
v0.4.0 beta
added a settings page to give an overview of running timers, renamed from ThenMore to Timer
v0.3.1
fixed an issue, causing timers to not being able to reset/extend when retriggered
This is not a countdown action but a delay. Countdown is used very often by lots of peeps to keep the lights on while there is movement. Delay actions cannot be used for that while the countdown actions are perfect for this. The delay cannot be stopped or overruled while the countdown action can be stopped and/or reset at any moment.
@rhannink you can of course use two action cards, one to turn it on, and one to turn it off, but (as Rocodamelshe says as well) this has one shortcomming: your lights go off after the timer, which cannot be reset. So say for instance you trigger your doorbell at 20:00 so your lights go on at 20:00 and will turn off at 20:05. However when you ring again at 20:04 your lights are still on, but will be turned on again (which doesnât make any difference), and get turned off at 20:09 as well. The first timer is however still running, so at 20:05 your lights are turned off again, which is annoying when you just reached your door. So you switch on your lights with a switch, but since the second timer is running as well, they are again turned of automatically at 20:09. If you now turn on your lights again at 20:09 with the switch, you now have to turn off your lights with the switch yourself, since no timers are running. You probably understand this, but who else in your house knows this?!
That is why people install the countdown app, which is used to (re)set a countdown timer which will turn of the device(s) when the timer reached 0. triggering the timer (by pressing your doorbell) will reset the timer, so extending the time your light will be kept on. @Jeroen_Somhorst This however requires at least two flows to be defined. One triggering the countdown timer, and one turning the lights off when the timer has run out (and nicer one to turn lights on when the timer has started). It gets even harder when you want you have (multiple) lights to turn on, only when they are not already on. Or when they have to restore to their original brightness when they where already on (I have a flow where I increase the brightness of the lights at my frontdoor when someone rings, keeping them bright as long as my motion sensor in my hall registers I am still in the hall).
With this app you can control the timeout of your devices, even based on multiple flows. Every flow can also have different timeout values as well, and you can define the strategy you prefer: keep the longest timeout (the value of the trigger, or the currently remaining timeout) or set the timeout of the current trigger; without turning the lights off in between.
Thanks.
The keep shorter timeout is maybe a bit too much. I used sensible defaults for all options, so keeping things at default would probably give you the desired effect, but to answer your question:
The keep shorter timeout option can be of use when you have multiple triggers for the same device, that have different timeout values. For instance two motion sensors. When the first triggers a light with a timeout for 1 minute, ande the other sensor tirggers the same light but you set the timeout for 2 minutes, if is easy to say you now expect the light to be kept on for 2 minutes.
But what if you trigger the sensors the other way around? First setting it for 2 minutes, and then 1 minute. Should I keep the timer for the remaining of the 2 minutes (when more than 1), or reset it to 1 minute anyway? This is the strategy that you can configure with this setting.
Ok.
I think the timouts settings is only relevant with the setting âControl it anywayâ.
If I understand the usage correctly I suggest renaming settings like this:
Keep longest timeout
Shortest timeout wins
If this setting is removed I would like to have the first alternative permanent.
Hmm, I couldnât test this, because my Homey is updated to V2.
My guess is, this is because of the Athom API library upgrade Iâve done.
I will promote 0.4.1 as stable and replace 0.4.2 with 0.5.0 adding a config change to require V2.
It will take some time before Athom has approved all of this
Iâve bumped some versions. Expect V0.4.3 as stable (replacing incompatible V0.4.2) compatible with Homey V1.5
Donât upgrade to Beta V0.5.0 this is only compatible with Homey V2, but I added this as an requirement as well, so it probably shouldnât be possible to update to this version anyway.
Yes I know. Unfortunately the backend of the app-store at Athom promoted all versions of the app, not the version I intended to promote. As mentioned I posted new versions, but it is up to Athom to inspect them first.
In the meanwhile you can install any version via CLI if you are known to GIT and the athom-cli tool. But I will ask some persons if they can inspect as soon as possible. Shouldnât be too hard with only some version bumps
