I think I may have already posted about this previously, I've not got to the bottom of it. I've a Room Lighting rule for my Landing lights and it works correctly maybe 9 out of 10 times. I'm using the built in Hubitat Hue Bridge integration. The rule:
Landing S1 and Landing S2 are scenes imported from Hue. When we walk upstairs either the pressure mat on the stairs or the landing PIR (it's an implant in a PIR, hence 'contact') will trigger the scene S1. After one minute of inactivity the lights should turn off. As said 9 out of 10 times (guesstimate) everything works. When it fails, the logs end at 'wait over' after the minute but the lights don't turn off. On those occasions I always find the following error in the log for the Hue Bridge device. This only ever appears on the occasions when the rule doesn't complete and the lights don't turn off:
However once that error from the Hue device appears in the logs, the RL logs continue normally right up to the point of failure but nothing at all happens or is logged after 'contact stays time over'. Here is the last of the motion sequence and logging after that error. Nothing happens:
I have also been getting the same error. Mine occur from Rule Machine instead of RL. I have not reported yet due to the difficulty to get the error to happen inside a 30 minute debug window. I decided to reply to show @johnwill1 is not the only person experiencing the issue. For my part, I will try to debug further.
This error is related only to parsing incoming events from the Hue Bridge and wouldn't have any effect on commands failing to complete. However, it could (temporarily) cause a problem with some automation if you depend on a specific state for that automation and the next Hue Bridge poll hasn't happened yet (and this makes it not see that state yet) -- or if you have polling disabled entirely, which is not the default setting and also not recommended.
I'm not sure what's going on in your case but don't see anything to suggest RL thinks something is wrong, but I also don't see it logging any attempt to send an off, which should happen if something isn't restricting that.
This error would not be coming from an app, just the Hue Bridge driver.
You can delete the scheduled job that disables debug logging if you want to, but if it's just for the above error, no need. This is a known, occasional error that happens on occasion with incoming data from the Hue Bridge eventstream but, again, wouldn't have any affect on outbound traffic, much less on other devices/drivers. More information, likely in your apps/automations, would be needed to figure out what's happening in your case.
As said, the last three times the lights failed to turn off at the end of the actions after 'wait over' that error for the Hue Bridge device is there. There's nothing in the rule to prevent it turning off as both contacts have been closed for 1 minute. I turn off the group in the Home app (Hue is linked directly to Homekit) and that doesn't show in the logs (I'm expecting 'Landing (Hue Group) switch is off' for the device regardless of where the command came from). After that when I get up in the night everything works normally.
I'm fairly sure I didn't change anything regarding polling when I installed the app, but it is showing Disabled?
But again, this error is only related to parsing incoming events from the Hue Bridge (and that could be why you don't immediately see the change from Home, but it should recover if the error wasn't caused directly by that change). It again wouldn't affect outbound commands, but from the RL logs, it's apparent it's not even trying. I'm not sure why. That would usually be some restriction in the app, perhaps the state of the group, but the Logs are normally informative as to why. (You could demonstrate at least the fact that this parsing error on the Bridge doesn't affect anything else by running the "Off" command from the device detail page yourself. It should work.)
I've probably misunderstood the V1, V2 information and thought that it was unnecessary on newer Hue hubs. I'll set it to 1 minute if that was the default.
In my case the errors seem to be related to the long fade of my living room lights in the evening. Seems to work fine.
Maybe a bit more than you think. It happens every evening from 1 to a few times. I'm not overly concerned but I could start a new thread if you want to pursue.
No need. The actual frequency will depend on how much data the Bridge sends to your hub at once, which will depend on your Hue system, its size, and what you do with the devices. It seems to correlate with larger amounts of data, which naturally seem like it would come along with changes to a large number of Hue devices at the same time. This is known. The only question is why the data isn't coming in as a single chunk, which is being investigated.
But again, all this affects is incoming data, and polling will catch it up eventually (just like it always had to on previous versions anyway).
Unknown, but Victor does not see any clear indication of truncation on the hub side (and it's interesting that the apparent length is different each time, so it's likely not just hitting some limit).
