@John_Land I'm not looking to run rules from Schedule Manager at startup.
I already have a startup rule that operates much like your idea by using a Wait For low CPU condition. In my case Ithere is a Wait For preceding each Run Rule.
What I am asking is that each child app in Schedule Manager run and set the outputs to the last scheduled value.
Perhaps there is a way to keep track of all the executed chrons so only the ones that were skipped while the hub was down need to be done at startup.
Just noodling here. What if each time-based rule set a datetime hub variable (HV) with the time of completion (last action or so in the rule). A separate rule, run at a reboot, looks at each time stamp for an HV (e.g., hvSetLightSwitchMode) and if the time is less than X hrs/mins ago, then run the corresponding rule actions, otherwise skip to the next HV.
@evcallia
The Hub Variable update has continued to work great.
Just found an anomaly this afternoon. I can delete any entry for a switch or shade until I get to the last one. Then no matter how it's configured you can't delete it. If you used a Hub Variable it can't be deleted.
The one that isn't deleted always goes back to the Hub Variable and Sun Variable check boxes being cleared and all days checked. For shades the switch/dimmer selection doesn't matter.
You can create a new one, then delete the previous one, then the new one can't be deleted.
Since I have been using Hub Variables on every device, I haven't checked out devices that never had a Hub Variable.
Having at least one schedule per device is by design. When you remove the last schedule, it is in fact removing the schedule, but then adding a new default one (which is why the check boxes reset). If you don't want any schedules for the device you should remove the device from the device drop down. That'll remove it form the table altogether.
Related to running the app when the hub boots up. Had an issue with my hub last night. It hung up late in the evening. Had to do a soft reset this morning.
It appears that the Schedule Manager child apps run sometime after midnight to set the chron values for the day, because none of the child apps are working today.
There seems to be nothing a user can do to get the child apps to set all of their chron values. Changing a time value worked for that switch. So would have to update every switch timing that is after the boot time
Could you have the child apps set their chron values at boot up or give us a way to force the child apps to do that from RM?
You're correct. At 1am every morning the variables are refreshed. This really only effects two things though, schedules that use sunrise/sunset or hub variable times. For schedules that don't use either of those, they'd be unaffected.
The side effects for sunrise/set would be that it uses yesterdays times which would likely not make much of a difference. If the schedule used a hub variable, then it could potentially be missed, but even that would be odd as I'm subscribing to changes to the variable and it should have rescheduled it at the time the variable changed.
In any case, in order to have all of the crons updated and rescheduled, all you have to do is open and then save the app. Alternatively, in the "Advanced Options", there's an option to "Update/Store schedules without hitting Done" which will do the same thing.
On another note, I'm going to have a look at providing some of this hub boot up functionality you mentioned. May be a while though as I haven't had much time to work on this.
All of my schedules use Hub Variables which have date and time values.
I need to look at making them time only or sunrise/sunset offsets. Originally I had to use date/time values in RM conditional actions.
By using Schedule Manager I may be able to those conditions to time only.
Thanks for looking into this issue.
BREAKING CHANGE - OAuth required to edit schedules
Schedules will continue to run even if oauth is not enabled
Modernize UI - Better looking table, popup system for inputs
Add ability to manually refresh OAuth token
Add support for button devices - push, doubleTap, hold, release
Refresh schedules when hub restarts
Configuring OAuth
The child app requires OAuth in order to edit schedules. You can enable this by opening the Hubitat sidenav and clicking "Apps Code". Find "Schedule Manager (Child App)" and click it. This opens the code editor. On the top right, click the three stacked dots to open the menu and select "OAuth" > "Enable OAuth in App".
If you ever update your OAuth token, you must click 'Refresh OAuth Token' in the 'Advanced Options' of each child instance in order for the app to get the new token.
Now that Hubitat can control my shades to specific levels at specific times using the dimmer functionality and has the ability to recover the appropriate device state at boot up, there is one more idea that came to mind.
Since I have a set of rules to set the shade height to keep sunlight off certain parts of the floor, would it be possible to set the status of an entry in Schedule Manager to not recover to that state since the shade height rules are in control during that time?
It's not that big of a deal, the shades would go open or closed right after boot up, then the shade height rules would take over. Those rules run every 2 minutes.
hmm, I'm not sure I follow. Are you asking to have an option for the hub reboot restore to only take place between certain times? If so, that would be possible.
Alternatively, you could use the "Only run schedules when specific switch is set" option. If you do this, when your other app is in control you could set a virtual switch "disable shades schedule" and when this switch is on the schedule would skip handling the hub reboot.
Hopefully a better explanation.
Need to flag some Schedule Manager entries so that when an entry is the latest one for a device that the device will not be set to the value of that entry when run during boot up or by selecting the Run Now button.
My use case is that after the selected entry, until the next entry, my rules to set the shade level to block the sunshine from the carpet or an area on the desk will be active during that time. Those rules will take care of positioning the shades at boot up.
Oh, I see. So for each specified time, an option for it to "restore at hub boot". If this specific time happened to be the most recent run, then skip setting that device altogether (as opposed to defaulting to the next most recent time that does have the restore option set).
As an example, if I have a schedule that looks like this and a hub reboot took place at 10am, then no restore for the device should take place because the most recent run would have been 9am and the restore is set not to run.