Had these back in Mar/Apr - opened bunch of tickets, never got anywhere, left with no choice to rebuild the rules. Which I did… now they are misfiring again in the same way…
Out of curiosity, does it work with CoRE?
Does any other device fail?
2 Likes
Was just scratching my head wondering the same thing. Makes no sense to fire at 4:53 when it’s set for 8:30. @JH1 can you post a snapshot of the SL instance?
1 Like
Haven’t tried with CoRE. For one this was intermittent. So it could take months to determine. Two, I prefer SL for things it can handle and this is as simple as it could get.
Perhaps ST could learn something about their system and root out a bug if they actually tried to troubleshoot this rather than just tell me to rebuild the rule. I know that’s an easy way to take it off their plate, but it doesn’t solve anything and nothing is learned.
I had several of these back in Mar/Apr… I can’t remember all which ones were failing, but will look back through my tickets. This round, this is the first or only one I have noticed so far.
Sure, I did… it’s in the OP. Can you not see it? Click on it.
I found a promising correlation, not sure if this is related and not sure how to interpret this entirely…
But… I do have a cron job that cycles the security gateway the ST Hub uses to connect to the intertubes, that is probably firing at 445am. You can see the activity in the hub logs, but I don’t know what each of these logs mean. Nor should that cause a rule to fire at at the wrong time.
More reason for ST to own this and investigate.
I agree, BUT you are really looking for trouble by restarting your hub every day. The only explanation I can think of, is that when the hub powers up is looking for pending events and fires them. It’s definitely a good indication that rebooting your hub causes the SL instance to fire. It shouldn’t, but obviously it does. @jody.albritton @slagle
I’ve had many weird things happening when hub reboots. That’s why I wanted control over when it’s done. Sensors freezing, garage door opening, presence sensors arriving and a whole host of issues…
2 Likes
Not the ST hub, the gateway it connects to. If it’s related, should be resolved.
Your ST hub rebooted…based on your logs.
Are you sure? I can’t force it to.
I am fairly certain that is simply the ST hub loosing connectivity and then re-establishing due to the gateway it connects to is recycling.
I never reboot mine on purpose. Data point.
2 Likes
Positive! May not have been you, then. But certainly your hub was dead at 4:45AM
You’re positive it power cycled or positive it lost connectivity.
My guess reading the logs is soft booted.
Even if your hub stayed up on reconnect to the cloud it probably looked at the buffer to see if anything was missed while off line. For whatever reason maybe yesterdays ‘off’ command was still sitting there and re-fired.
It is very suspect that the hub came back at 4:53 and that is when the job misfired.
1 Like
Ok, I was going by “hub has disconnected”, which I thought it appears only on power cycle. But I had to do try it…
Network disconnected
Power disconnected
Looks like there is a catchall on power loss…
1 Like
Oh I agree. Only ST can say if that correlation is causation, and if so, resolve it.
I did verify the gateway it connects to was rebooted at 445am. I moved that to cron job to 245am now, not because I believe that will resolve it, but if the SL rule starts firing at 245ish, then the correlation-causation link becomes stronger.
If this is linked, I could make my own life easier by moving the cron to 9am and avoid having my fan turned off in the middle of the night because the job fires at 830 automatically, but then I won’t learn anything. Maybe I should move this to 1130pmish…
Interesting.
I wonder what that catchall does. Could be good or bad depending on yours setup. Hopefully it doesn’t open your garage.