Hi @Fredrik_Palsson , I’m having problems with my Cloud backups, it’s not fault of your very useful app, but - seems the size of Adv. Scheduler is the highest from my all aps I’m using (~50) - do you think it could be streamlined ? Maybe you are compiling it with some libraries not being used anymore ?
Luckily, as you implemented RAW backup and restore, I was able to remove app, do the backup and restore successfully (so that you know it works flawlessly) 
Thank you 
@Sharkys: Fixed now in 0.4.13. Thanks for letting me know!
wow, from 70MB to 6MB, nice job !
@Sharkys: It was a one liner change. Got a suggestion from the Homey developer community on the slack channel. It worked. 
Unfortunately there was a bug in versions 0.4.14 - 0.4.15 creating startup problems. Most likely corrected now. I hope the few hours they were live did not create too much problems…
@Fredrik_Palsson , when you will be around again … may I ask you, is it possible that app have lost previous great storage optimisation? Seems it’s taking again 67MB…
Thank you 
Made a new fix, to reduce storage. I’m baffled it increased again…
Seems to be fine again, thank you !
I wonder if I’m really the only Homey user fighting with insufficient memory and related backup problems
Still seems to grab a bit more memory than it used to. I only have one active schedule and it’s now at ~17MB, before the SDKv3 rewrite it was steady at a tad above 7 MB.
Isn’t it only temporary for you ? I have three schedulers and currently I’m on 8.8MB only, which is absolutely fine
Maybe it will settle at a lower value in time, it’s been a bit over 12h since the update so perhaps I should give it a bit more time. But either way, the memory footprint has consistently been higher after the rewrite. Apart from some peaks at ~30MB it’s usually been at 10 - 12 MB. Not an alarming figure in absolute terms but quite a big increase in relative terms.
But maybe it’s just par for the course, I see some other apps that seem to suffer from the same symptom. Maybe SDKv3 comes with a higher memory demand.
At the same time as going from SDK2 to SDK3 I changed moments lib to luxon. Apart from that there were no obvious changes that should account for a higher memory usage. I would guess the usage of SDK3 is the main thing. I will however ask in the developer forum for experience with this.
The number of schedules beeing setup, and the number of triggers in these should at most account for bytes or kilobytes, not megabytes.
Tonight is the night. Let’s see if the DST change works as expected. Please report any strange behaviour.
for the first time no problem during the time change. well done and thank you
Same here, no problems seen during the night. Thanks!!
Hi @Fredrik_Palsson , I wonder now, is there some way to check if particular schedule is or is not enabled ? Might be useful for seasonality reasons…maybe I have overseen it ? Thank you.
Hi. I created a schedule for 31min before sunset. It trigger OK, but also seem to trigger every night at 00:00. I will check if this is also the case for my old schedule for 30 min before sunset.
Are you asking if there is a way to retrieve info in a flow or similar to determine if a schedule is enabled?
If you do not figure this out, could you send me your config (”Raw settings” tab)? Send a private message.
Yep = the schedule can be enabled-disabled, within the app settings, but can’t be determined, if it’s on or off. Also having ability to enable/disable schedule plan would be useful.
