Timer 0.8.1 test (Homey V3) - 0.7.3 beta (Homey V2) - v0.4.3 stable (Homey V1.5) - (fka Then More) add Timers to temporarily turn on devices

Timer - fka Then More
Timer adds more options to the then column in your flows, to enable devices for a given amount of time.

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 :wink:
If you are missing functionality let me know as well, and maybe I can add it in a new version


  • 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.2 revoked

  • 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


  • fixed an issue, causing timers to not being able to reset/extend when retriggered

Great app now i can delete a lot of flows with timers

can you explain a bit more why this app is easier to use / work with when compared to countdown?


I just use the existing delay button in the action cards to create a simple countdown action (e.g. turn light on and 5 minutes later off)

1 Like

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.

Great work!
Question: What’s the use of the shorter timeout setting?

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.

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.

Hi! I’ve posted a question regarding Then More and the Aqara app here:

Would be great if you could help me out on the Then More part :pray:

Hello Jan Willem, I want to help you, but don’ t understand what you want. I contacted you ons slack, so we can elaborate on your wishes

I found the bug that introduced the problems @jnwllm was experiencing and fixed it in 0.3.1

Due to a refactoring I missed the renaming of a property, causing timers to not being able to reset, making the entire app a lot less useful…

0.3.1 is now stable

I added a new Beta (v0.4.0) that adds a settings page, which gives an overview of the running timers

1 Like

I am still on V1.5.13 and the app was updates to 0.42 last night and now it is not working anymore with this error

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

1 Like

I did install the stable V0.3.1 and then it works

Good to hear.

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.

1 Like

Now the app is back at 0.42 as stable and nor working anymore.
I hope the 0.43 will be released very soon

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

Done, 0.4.3 should be available