Not sure what you mean here…?
I have several of these timers in rules which track increase/decrease of temperature, humidity and barometric pressure. They run up a counter on each change until a time limit e.g. 10 continual increases in 3 hours represents a rapid humidity increase and then triggers an Alexa warning on change in weather conditions. They then reset and so on. These are first versions, with no ‘reset to’ button and not even the add2, subtract2 fields.
I comment as the later version, I have a Presence Detection and another running random lights (with Mariano’s Random Mirror) are Ok, but these older versions are just not running for a few days now. True I should look at the rules and find out why, but I asked you in case it’s a problem of version out of date.
UPDATE
The version has no influence - no reason to believe that there is any issue there. 
Still unable to discover why after several days, starting and stopping the timer manually a few times, they started running again. 
Has coincided with the problem this last week on Location modes - well documented on another thread - and although I can’t find the connection its the only thing I can think of.
I’ve been using and tinkering with your devices in various ways pretty much since the start, and just want to say that this Counter Utility (and your other virtual devices) has been the source of great function and loads of interesting tinkering for my own amusement.
Something that I’ve often had use for in the IF part of a routine - and had to find other creative ways to implement - would be to make use of the current counter value for comparison when using the duration element as trigger . So instead of setting a duration value and selecting from the existing ‘matches’, ‘equal & above’, ‘equal & below’ and ‘range’, an additional option for ‘matches counter’ would ignore the set value and just use whatever the current value of the counter is at runtime to match against.
In this way an event could start the timer and set the counter to a specific circumstantial value, which the utility would then use to trigger an event as soon as the duration value matches the current set counter value (and neither of those are necessarily static values as the counter could be increased/decreased or the duration reset on the fly during running). Either way, a routine would trigger whenever duration = counter. So now instead of having multiple routines set up to fire for each potential duration value (and it would have to incremental to reduce the number of instances), you could have a single routine with a highly variable trigger period based on input received at start and during runtime.
What do you think? Is this just the ramblings of the insane, or does it make sense? Perhaps I missed something it can already happen in such a way? Love to hear your thoughts on this.
E
1 Like
I can’t see that option either using the latest 2023-04-24 version and I’ve only had the hub for two months so I never installed old versions. Android by the way.
It works through the advanced SmartThings website though, so I guess the only workaround is using Rules API for this command.
Edit: And I’ve created another one and it appears, strange indeed!
Thanks very much for this! I just added the device and a few routines to track furnace on-time and signal when the filter needs replacing. Perfect for this application. Much appreciated.