Work perfect, thanks for quick fix.
1 Like
@Arie_J_Godschalk
The first update today didnāt did the trick.
The last update today works fine. (1.4.0)
It still starts the stopwatch, pause is working and stopping the stopwatch is removing the stopwatch.
Thanks for youre work.
1 Like
I still experience same issue when app updates. The trigger card doesnāt trigger when a step is reached.
Iām presently at work and will be home in a week and a half, I will then replace the trigger cards with new ones to see if it makes any difference. I have for now turned off auto update of app. My Homey have not been updated or restarted since my first report, but I assume same issue still is present for me. Thanks for checking anyway!
1 Like
Are you on 1.4.0?
Because 1.3.* still had a few bugs.
Hi @Arie_J_Godschalk
Yes, there was 3 updates today and last one was 1.4.0.
I reset my transitions, adjusted them and got my variables updated later in the afternoon.
1 Like
@Arie_J_Godschalk I am thinking of having a timer for each sensor I want to surveil as the battery notification is not always so reliable. Is running many timers adding any big load on the Homey?
I am not familiar with the implementation in this app but know that there are good and bad ways to implement timers. 
Well, thatās not really a question i wished would be asked, because i donāt really like the answer. 
So, iām gonna be as honest (and i guess blunt) about it as i can be:
Chronograph and the Countdown App from @ralfvd (and also the Better Logic app) both have a few poorly designed mechanics in them.
And while the overhead is not really a big thing to Homey when using a few timers, the issue is that, both apps currently are build in a way that, the more timers your have (active) the (unneedingly) bigger the overhead becomes.
I hope to change it for Chronograph but also for countdown when i have the time for it. Itās not that important.
- The issue with Chronograph:
Chronograph has a main method that updates all active Timers/stopwatches/transitions (TST from now on), all information about them and on the devices.
There is no interval running this at all! (i guess a good thing).
Because, and this is imho the bad thing, it getās executed/update on (almost) every change on every transition/timer/stopwatch.
So, start a timer? Update all TSTs that are running. Stop a timer, change a timer, resume a timer or stopwatch? Update all TSTs.
Letās just say, this is not how i would have done this: each TST should be responsible for itās own updates only. This would prevent/decrease an ever increasing overhead.
On the other hand, when you have just a few timers running, the update is hardly ever triggered. The longer the timers, the less updates. - The issues with the Countdown App.
Itās way less of a memory issue currently imho, but still.
Every second (so, Countdown cannot handle something smaller then a second!) it will itterate through all exsisting countdowns and update them.
While this method is not bad itself, what is being executed for each countdown (called a variable:number because it was a copy/paste and edit from the Better Logic App) is way more memory heavy than should be (still very small considering what it does, but in percentage, the overburden could be massivly reduced).
For instance: Countdown and BetterLogic donāt remember the Variables themself, but only keep them in the Stored App Settings. Issue is, it needs to be retieved from that all the time, thus giving it a new set of variables all the time and a full value-comparison needs to be done for all countdowns.
And there comes the next part of the issue: old convertions because Homey had some bad design when BetterLogic and Countdown were first written.
To compare each countdown, it still convertās strings/texts into numbers to compare.
Thus: Each second, all variables are ārebuild in memoryā from Settings into new arrays through Json, so new object(references etc.) and to find the varaiables, you need to search them again (references are different, the old variables donāt exists anymore in this new list).
Now, to get back to your question: If you plan on a lot of long-running / permanantly-running timers i think the Countdown app might be a better solution for you. Itās memory overhead is lower when you have the same amount (a lot) of active timers.
But in both cases, the overhead is still neglable i guess for most use-cases. I just donāt like the implementation personlly.
And Countdown and BetterLogic are both pretty easy to improve there memory-performance. Chronograph would be a bit harder to adjust the updates to singlulair updates, but when i finish that, it should have the same memory performance and overheads.
But Chronograph has Stopwatches and transitions, and timers with smaller units then seconds.
EDIT
The Timer mechanism of Chronograph is beautifully written. Itās just a shame that all TST are updated when any TST (needs to be) is updated.
Iāll show an example of this in a minute.
Here
Will give you this:
I am curios tho, why do you want timers?
You want a flow that runs every day/hour to check all batteries and alert you about the ones that are low?
Sorry for asking 
That was what I was afraid about.
Good to hear that you will refactor this in the future.
Well, I have different ideas how to secure that my sensors are still alive.
Every time a sensor reports (say movement):
- restarts a timer with 24 hours timeout and disabled the flow for 6 hours. If timer finishes you know it is dead.
- disable the flow. Then, at eg. 20:00, using Homeyscript, check if all expected flows are disabled and re-enable.
- Use Insights in some way to once daily retrieve info whether the sensor has reported or not.
Choice 2 is the best but has no knowledge, yet, about scripting Homey. Have started to look for how-toās and node.js coding thou.
What is your opinion?
1 Like
The battery info is not reliable and neither is āSensor not reportedā¦ā card.
I had a movement sensor that did report every day, but not movementā¦
Currently I sm using Sets with a State for each sensor to activate at reporting. Once daily I check whether all Stateās are activated and then deactivates them.
I am not so fond of timers either.
1 Like
So, let me clarify this for me, and please confirm if so: You want to check (for instance every hour) of certain devices have certain values/capabilities/fields that have not changed in the last 24 hours?
Right?
Because enabling and disabling flows: Thats also very, very heavy on homey and i prefer to not do that, or at least as less as possible.
Yeah I think thatās correct (is a bit confused about thinking the other way around); once a day I want to check that a movement sensor has reported movement at least once the last 24 hours.
That was an interesting way to look at the problem from another point of view. 
1 Like
Always good now and again
I think i have a way, way, way better solution for you.
Hang on a minute, need to check and add something
1 Like
Okay, ready: You need to update the Device Capabilities App to version 2.8.3 which is in review/test right now.
I have added three tokens to the Retrieve Insights flowcard:
The next card Retrieves the Insights from my BathroomMotionSensor from 0 (zero) minutes ago, so, the current one. I have added Changed On, Changed On UTC tick and Duration till now (in MS).
You can use this card to check if the duration-till-now-tag is more then 24 * 60 * 60 * 1000 (=86400000).
If so, add this to an alert.
Here you go:
[tef:FLOWS:"H4sIAAAAAAACA81Y72vcOBD9V4wpFI5VKsuyfvhb24Oj14+FgyOEZSSNsiZee8/2Jg25/O83Xu9uuu2Gui09GsImtuTRzJv3nuR9SLdp+ZB6k2XCRGQYo2FSWc1MYQyLWaEQMkCd63Fek5bp667C5M+L5I829H4F9U36+LhIb8dhmyFEtJJp9BmTksKARWBeeG0Dz+nXHMK8gWHA7v51jd2QLtKBbvVDVzXXu3DDblp98U+97Wkaq4aL3/G28vgWNuCquhoq7A+hppHkZGgMAml5+ZBWNEMHnUeJgYWCA5MQC+YsGgZa88glYgyRkhiDfcCmb7s+uWu7G8om8Sv0Nz0NYloO3RYXqR/X5cEV0fPITHCSEFOSGY858z5mXhaAeQzjvI9pmSm+SO/3f1taYtWu8b5cQwPX2JV1e115ij/meQtdBa7GZY/Dcg/HhA34oWobuqCqL1MVFSijFVMKCejCegaukKxw3EWOKJRV6dUOgYdj0PH/ipKa1yZCA9b4eaPGTkO9He8nO4yNNV5lRWQ+hkA4cMGsKxzLc4PGCReFk3scPkFh6jbsOr8raBacV7SeFy5zKDkzaC2TQkRGyzmmnOVcgvVg5FT0lOXf7Tbx0CQ1Dsmwqvok1u1d0m2b5G6FTXJPw3fQDIsEwa+SVbvtkth2SdVQeo1Hys+3ddtRpHus6VG6cSyFPu+qMKzSstnW9SJdYXW9Gg5XY41NO+CI2ax+nbJFmBO2wGZTflUPE4kmqiz9YeR+SRQ7SyPOCy2dDEwTakxGnTG7AxOkcTpKwtQeaRR26x1JlJOUfBFzpql3VBJkzETOqfG5AK6NkzL7hER4h9fE5r7fySt5A+GGRroRnKdEj8Ghhm69XLf7ZPdBPrt7jcNE60mW/eEyQt0jxW22a4ddG6lRI1NnFTv1QPGpBzn/qmKvD+bl2yZU+8zaYUQ3jwZ0EUhmUQpakPptUCGLOQkGtDKRqErojhmSpLkhE9aOBaNptg5EbEqXKROUDVnMafzYC9+uN9DBMBLTSL77WaTLF6FrN0N7g82L5bHZZTmHfWUZthSQ5g9VXTdE9BGzTFoD6BX5Q0Hqtj6QZZIseVCZRLC5CCdqq2LybnjZJ3XbEFAkOJKYkMlvieKHj4xSfUZVB9gFn6+sWSBPXbVmdldn+/C3NO1n+fDl5ZlC/p0T/OrqKMSkaZukw37TNn11ixe79s8q79S2pPj5tiXyIkdLm4U0mabNIqPdQKFmtCNII1W+o9gztuW8tCjBMOsNPYt05gEeSBB5QfTLEaUMz9vWe9ySuP5H05pV6qlpSfkjpiVlIXJZ0PnI0flI2qhoIyYDoES0QemjQPFkWgIVbf/oiRaKzlWIlhmRZUznGeqgIs3W32taM7h33rRmlXBqCTMwm2sJ3wTJL2kJE8nPGsKs4k4NoVA/3xAk1zY6D9RxQ1wpMuq90YZ5CzETCNob8ZwhoEAuBRlCBvSEBA1sNAgmOTqhBb04ePWE+Nu/kvd0XGzJCz4MeHPz7AmmbdoYn547XD4n//HyS/XPqutU/YX5oSML5FkWaDdFMkImfe4YBDozZM5aYUFmquBP6i98BKHJQYMTns7i3jELmg5Yuc+LSDtvEeA71T+HaOfVP6uEU/XPwGyu+r8Jkl9S/V8y/KwTzCp07wRyglmfN9l1S9LBPc6bbb9aDvhx+BzdXbBtT3obX/onAL78JmIx4Tjr6wyau6YExnyGYdOXr17BprqAgbK7ILK+Gheje7dA76ljAuPAuzH6iPUuxTL9EaQJxsfHq8f/AB8k6nmCEQAA":/tef]
This is not very memory heavy, since you donāt need to activate much and donāt use any variables, flows or triggers for the sensors, you just run a flow to periodicly check the already existing insights.
Works for numbers and OnOff.
This is the best performance-wise solution i can think of.
2 Likes
You are working fast.
Sound like a really great way to do this, will test it later (my boss wants my attention some hours more ).
I think I will need to learn more about the Homey, to understand what is load heavy and not when constructing my flows.
I am thinking about starting with Homeyscript but as that is what I do all day at work I like to āprogramā with cards.
A smaller answer or difference between Chronograph and Countdown, performancewise:
Countdown
When you need a lot of longrunning countdowns/timers active all the time OR when you need a few long running timers AND a few very short timers (like a few seconds), Countdown is by far the better chooise performancewise. In my opinion.
Chronograph
When you need (stopwatches or transitions ofc or) a lot of countdowns, but only a few active at the same time, then Chronograph is by far the better chooise, again, performancewise in my opinion.
So if you have a lot of timers/countdowns to switch of lights or devices after an x number of minutes, then Chronograph is better performing.
Didnāt the Countdown app iterate through all timers every second?
Maybe less memory heavier than Chronograph but this will be heavier on the CPU load??!!
1 Like
Yes, but what the Countdownapp does every itteration is less heavy.
So if you have a lot of active ones, and you just need it updated every second, the countdown is less heavy (altho, it creates Tags/Tokens and updates them every second).
So if they are all active a lot, Chronograph is requires more memory resources than the countdown app.
Well, depends on how you look at it. Percentagewise i think you could get a few hundreds of countdowns and it would still be a small workload for Homey, barely noticeable.
(This goes for the countdowns and times, not flows that get triggered ofc.)
And, there are a load of worse option to use, like minute(or faster)-based-flow-triggering, thatās why more heavy for Homey then the itteration of countdown or Chronograph.
Chronograph becomes more heavy with more active timers/transitions/stopwatches, espesially with short durations.
But when there is no active TST, Chronograph is not even running anything at all. So then itās by far the least heavy one.
Ah, thanks for enlightening me.
So, install Chronograph but add no timers 
Chronograph will be really good when you have refactor it.
1 Like
Absolutely
1 Like
