Timed Devices plugin

This plugin creates Indigo devices that are essentially timers with built-in triggers. The goal is to make some common tasks in Indigo simpler to setup, easier to maintain, and requiring fewer Indigo entities.

This plugin doesn't do anything that can't be accomplished in Indigo with a combination of Triggers, Variables, and Timers and/or Delayed Actions. However, I find it very helpful in accomplishing those things quickly and simply. I have seen a number of new users on the forums struggle with these sorts of tasks, and hope this may be useful to them as well.

Activity Timer devices

Activity Timer devices infer an ongoing activity from one or more momentary inputs. Devices will turn on if the number of inputs reaches a defined threshold within a defined period of time. Devices will expire (turn off) after a defined period of time with no additional inputs.

Once configured, these devices are simply ON to indicate recent activity and OFF to indicate no recent activity.

The most common use is inferring activity in a room or area by tracking motion sensors. I commonly wish to have more than one motion sensor activate before assuming a room is in use, and extend the timeout when one or more motion sensors are re-activated.

I first wrote the plugin for this scenario and in one case was able to replace 13 indigo entities (2 variables, 2 timers, and 9 triggers) with a single plugin device.

Threshold Timer devices

These devices are similar to Activity Timer devices, but are intended to track non-momentary inputs. Devices turn on when tracked inputs reach a defined threshold. When the count of inputs becomes less than the threshold a timer is started and devices turn off when the timer expires.

Once configured, these devices are simply ON to indicate recently reaching threshold and OFF to indicate not recently reaching threshold.

This is useful for motion sensors that remain on for an extended period and thus do not repeatedly trigger when additional motion is detected.

Persistence Timer devices

These devices track the state of a single device or variable, but only change state after the tracked entity state has persisted for a defined period of time.

Once configured, these devices are just ON or OFF to reflect the delayed/confirmed state of some other device or variable (eliminating the need for cancel-delayed-action actions).

An obvious example if you want to track if a door has been left open or closed, but ignore the door being opened or closed momentarily.

Lockout Timer devices

These devices track a single device or variable and change state immediately when the tracked entity changes, but will lockout (ignore) subsequent changes for a user-defined period of time. At the end of the lockout period, the plugin will reevaluate if the tracked entity has changed in the interim, and initiate another lockout period if it has.

Once configured, these devices are just ON or OFF to reflect the state of some other device or variable, but are guaranteed not to change more often than some pre-set period of time (allowing your triggered actions to complete before, say, reversing themselves).

This is useful when a device oscillates at its transition point. For example, a presence detector may report OFF-ON-OFF when exiting. Lockout Timer devices will react to the first change and ignore subsequent changes if the occur within the lockout period.

Alive Timer devices

These devices track whether single device or variable is alive and becomes OFF when the tracked entity hasn't changed for a user-defined period of time.

Once configured, these devices are just ON or OFF to reflect whether or not some other device or variable has been seen within some pre-set period of time.

The obvious use is battery-powered devices like sensors. Unlike the other device types, these will react to heartbeats even if none of device's states have changed value.

Running Timer devices

These devices track how long a single device or variable has been running and calculate accumulated ON times over various time periods.

Once configured, these devices are just ON or OFF to reflect whether or not some other device or variable is ON or OFF.

Device states report how long the tracked entity was ON during the current and prior hour, day, week, month, and year.

---

Details: https://github.com/kmarkley/Indigo-Time ... /README.md
Download: https://github.com/kmarkley/Indigo-Time ... ses/latest

[jay (support)]

Nice! Thanks once more for a great contribution.

Very plugin. I am trying this out on my pool refill project. See this post

Thanks. I'm just glad someone else finds it useful.

Lockout Timer devices.... Solution....

wired cameras (DSC) have no dwell time between triggers. Video Motion Detection (depending on software/purpose/setup) has no dwell time between motion detection versus zwave detectors which will only detect every so often...

I use a series of triggers that auto disable themselves (because I set them up before your plugin existed).

Example solution.... variety of motion sensors at the front entry to you house (Camera VMD, wired sensor, etc.). Since you probably don't get a new visitor every 15 minutes, use a lockout timer for those sensors so when you are performing a normal task (un-loading groceries from the car to the house) you aren't getting a ping on your phone every 2 seconds that there is something in your front yard.

I'm really looking forward to taking your plugin for a spin.... it will really clean up my trigger folders.

Persistence Timer - Logic "Any"...

Has this disappeared?

I'd like to use this to track if a motion sensor hasn't changed state for 12 hours, which means the battery is likely dead/dying, but I'm only getting Simple and Complex?

Peter

Persistence Timer - Logic "Any"...
I'd like to use this to track if a motion sensor hasn't changed state for 12 hours, which means the battery is likely dead/dying, but I'm only getting Simple and Complex?

"Any" doesn't make sense for Persistence Timers because these devices track other devices/variables with a delay for persistence/confirmation -- if they went ON with any change, they would never go back OFF.

You can do want you want with an Activity Timer device -- these are the only ones that expire on their own. Set a threshold of 1, a single device/state, and a logic of "Any".

(BTW, because of the reset feature on Activity Timer devices, you can actually have two timers for a single device. Trigger one when state reset becomes true and another when state expired becomes true. )

In that case, your Readme needs updating then

It still has Any for persistence timers.


Sent from my iPhone using Tapatalk Pro

.... it will really clean up my trigger folders.

This was my motivation for writing it. I was frequently confused by triggers I made myself...

In that case, your Readme needs updating then :-)

Thanks. Copy/paste error. Will fix.

Just wanted to say thanks. I've started using your plugin in a limited capacity but it's proving it's use already and I expect I will expand on its use.

Mike

Ditto; I've already replaced a huge custom script that relied on loads of variables and associates timestamp triggers with a small number of timers.


Sent from my iPhone using Tapatalk Pro

I have a question on the operation of a Persistence Timer. This is being used to track a switch that is closed when the water in a swimming pool is below a certain level, and open when the water is above that level (i.e. "full"). Here is the device configuration:

Device Settings...

Screen Shot 2017-08-19 at 08.29.05.png (102.06 KiB) Viewed 12960 times

I would expect this to set itself to On any time the monitored switch goes Off, and to set itself to Off after 10 On observations, at 1 minute intervals, from the switch.

In general, it seems to do that. However, I also see the following every 10 minutes (assuming the pool is full)

19 Aug 2017, 05:25:10
Timed Devices "Pool Full State" off
Timed Devices "Pool Full State" on

19 Aug 2017, 05:35:13
Timed Devices "Pool Full State" off
Timed Devices "Pool Full State" on

19 Aug 2017, 05:45:16
Timed Devices "Pool Full State" off
Timed Devices "Pool Full State" on

19 Aug 2017, 05:55:18
Timed Devices "Pool Full State" off
Timed Devices "Pool Full State" on

19 Aug 2017, 06:05:21
Timed Devices "Pool Full State" off
Timed Devices "Pool Full State" on

Since I have checked the box to not suppress logging of on/off events, I would assume I should see a log entry overtime the state changes, not every 10 minutes when the timer expires but the state hasn't changed.

Is this the way the plugin should operete> Or, Am I misunderstanding something?

And, BTW, thanks again for a quite useful plugin.

Haven't you got your On Persist and Off Persist the wrong way round? (Not the inputs - which you've correctly reversed)

Are you wanting this timer to go On when the pool is fully-full?

So lapping water as it gets nearly full won't turn it on, but water when it's stayed full for 10 minutes will do?

If so, set On Persist to 10 minutes, and Off Persist for some value (how many seconds of constant "not full" readings from switch before the timer goes off, ie says the pool really isn't full rather than someone dive bombing in it).


Sent from my iPad using Tapatalk Pro

I would expect this to set itself to On any time the monitored switch goes Off, and to set itself to Off after 10 On observations, at 1 minute intervals, from the switch.

Not quite. With your configuration, the plugin device will turn On after the monitored switch has been Off for one second, and turn Off after the switch has remained On for 10 full minutes. Every time the monitored switch changes state, the plugin notices and cancels or restarts the timers (i.e. there is no 'sampling'). If this is not the behavior you want maybe you could describe your intent in a little more detail.

All that said, I still don't understand why you are getting those log entries.

I would assume I should see a log entry overtime the state changes, not every 10 minutes when the timer expires but the state hasn't changed.

Could you elaborate? Are you saying the monitored switch state hasn't changed, the plugin device state hasn't changed, or both? If the monitored switch is changing, it would be helpful to see those changes in context with the plugin device log.

I have made the debug logging a bit more helpful and released an update. If you're still having issues, you can update the plugin and post the debug log.