The two automations it is a part of (verified on the Device page) are one that turns it on before sunset, and the second isn't active until 11, and the light turned off earlier than that, so that automation also seems to be innocent. All the automations w/that light on the ST side have been paused or disabled.
Tried to look at logs but the light isn't listed in the log page (because it's connected via HubConnect?) Events has this below. The "on" events from 8PM and later are me turning the lights back on after I notice they are off.
Is there an easy way to see what is turning off the light?
Did you look at the ST logs in the IDE? It should show what turned off the light..
I looked at the log of a light switch that is still connected to ST in my system. If the light was switched via HE there is an entry that ST[remote] sent the on or off command
Thanks, definitely the Hubitat hub turning it off:
"Hubitathub (online) sent off command..."
Detailed event info below. Not quite sure which of the IDs provided I can try to match up to an Automation in Hubitat that is sending the "off" command. I have looked at my two active Hubitat automations for that switch, and neither appears to be the culprit, hoping something in the above information is the pointing finger. I thought maybe this:
If it is the Habitat remote app turning it off then you need to go back to HE and try and track it down. You know what time the command came from HE so look in the logs at that time and see if that gives you any clues.
You say you looked on the device page and it listed two apps that can control the light. Perhaps you should look at them closer, or post a screen shot of the rules. if they are in RM, Are they RM rules or one of the built in apps?
Thanks. The two automations are in Motion Lighting and the Simple Automations apps, so it's are pretty easy to determine that they should not be turning off the light.
One of them only runs between 11 and 7 AM (the light was turning off during the day):
I've looked at the logs for the two automations. There is no log specifically for the actual device in HE that I can find...on the Logs page the device just does not appear. Maybe due to being a hubconnect device coming from ST. There is no "enable logs" option the device page.
There are logs for the two automations (one paused, one active) but they don't show enough past activity for some reason to see events from yesteray when this was happening. When I look at the logs in Past Logs, the logs end with "Loading past logs" but no additional information ever loads, so I can't see anything older than this morning. Example below.
"
I turned on the light this AM and am going to wait to see what happens. I have the hub set to reboot every night, so if there was some temporary issue that a reboot might fix (had another issue recently w/a device that a reboot fixed) then it might (hopefully) be a non-issue as of today. Guess I'll have to wait and see.
I'm also going to comb through my other automations one more time even if they don't mention the cabinet lights just in case I missed something. Operator error is always a very likely issue...
Thanks...as I said in my initial post I did verify the automations it's included in on the device page:
The two automations it is a part of (verified on the Device page)...
So I know which automations it's included in, but have looked at them carfully (and posted the details above) and neither should be able to turn the light off at the times when it was going off (last night before 10PM).
I've had the switch on all morning, and it hasn't turned off on its own, so I'm thinking the nightly (3AM) scheduled Hubitat hub reboot has fixed whatever the issue is. So I'm starting to put my happy face on again.
But given the other device issue from a few days ago that was resolved by a reboot, it seemed like a little "free" insurance to ensure that any odd issues get cleared up and the hub is refreshed before I start my day.
I do the same w/my phone, but that's weekly as my S10 is extremely reliable and rarely has any issues.
W/the HE it looks like I've already run into two issues that required reboots to resolve (the first one a few days ago and now this one), and I have just barely started to migrate devices from ST (only moved over a handful). I have to admit I'm a little concerned about that. Hopefully the 2.2.3 release that's being worked on will help in that area as well as the other Zwave pairing issues they are working on.
I know some people feel the need to reboot, but with a healthy system you just shouldn't have to do it nightly, or even weekly for that matter.
I would spend some time to try and figure out at what point did you need to do this, maybe you added a certain device or something? From there try to track down what device or what automation is causing issues.
Of course you're right, I agree that rebooting at night doesn't solve the problem, and it won't help if it comes up during the day when we're using our automations.
But lazy me was thinking that if I end up not having any problems during the day by rebooting at night, the nightly reboot becomes an easy crutch. Not the best approach...
I did try to track down the other device issue and didn't find anything ovbious. My efforts weren't extensive or heroic, though. In the case of this issue I have found nothing over the past day or so that indicates why the device was turning off, and no one has had a "look here" suggestion that has led to an answer, so I'm kind of stuck at this point. I am heading off now to do a detailed review of all my automations just to make sure that one of them didn't get the cabinet lights included accidentally at some point.
I'm so ashamed... Do you guys have to be right all the time?!?
I'd like to see the second automation that comes on at 11. I had a similar issue where i had to specify both the valid on times as well as the off times.