are you on .124 (beta) or .123 (production)?
1 Like
Oh crud. I thought I was on the latest production, but indeed I'm on .124 (the beta).
(in fact, I waited for 2.5.0 to come out of beta before doing the migration)
It's probably not a factor, anyway, but you could revert to it, couldn't you? Maybe it'll shake something loose.
I just did.
1 Like
Vaya con Dios
Fails the same way on 2.5.0.123.
I’m out of ideas, but that doesn’t mean that much.
Out of curiosity, if you go to the app status (circled i) and check the event subscriptions
Check the status is the driver. After 2.5.0.123, when my switches were controlled digitally, the status in the driver did not update. Light on but driver showed off. So automations broke. The first work around was too refresh at the driver which corrected the status in the driver and allowed to animation to function. Added in a refresh to the rule which fixed it. Not all drivers are affected but the one I was using was.
It is seems to be not just Simple Automation.
"Off" processing seems to be not happening for rules in both Room Lighting and Motion and Mode Lighting rules. (details in a moment)
This is a Room Lighting Rule that is also losing the "off" event.
And the log. At 19:06.113 it says "off in 1 minute", but the off event never fires.
After a few minutes, I clicked the "Off" button on the Room Lighting page and you can see it actually turned it off.
This makes no sense to me! Right now all the devices controlled by Room Lighting and Mode/Motion Lighting are all stuck on.
I just noticed that Mode Manager didn't change the mode from Day to Evening.
So I finally concluded that the scheduler is not working correctly. I went into Logs -> Hub Events and am getting a schedulerError every time the system boots:
dev 1744 is a Wyze Cam device from WyzeHub.
A search on "schedulerError" shows me a number of threads of people with similar problems.
So based upon Release 2.3.4 Available - #5 by gopher.ny I opened http://hubitat-hub/hub/advanced/deleteDeviceJobs/1744 and rebooted.
The schedulerError went away and things seem to be working again.
Whew.
2 Likes
@gopher.ny I would suggest a small change that would have made this so much less of a hair-pulling event:
If a schedulerError fires and causes the scheduler to not run, then there should be an alert on the hub UI. Possibly the alert should point to a doc page with instructions on how to proceed (open the Hub Events page and invoke the appropriate endpoint).
5 Likes
Congrats.
Esoteric Endpoints are the only way to delete them? That really should be spelled out.
2 Likes
Good point. Since it's not something we're comfortable auto fixing behind the scenes, there should be an alert. Next build.
2 Likes
Not since June ‘25. You’re more likely to bump into Lord Lucan on here than Bravenel!