I’m now about 30 days into HE, coming from ST. Because I’m unwilling to dump all of my Sylvania bulbs and strips, it’s taken several weeks of troubleshooting, trying HubiThings, and eventually adding a dedicated C7 for Zigbee, meshed with my C8 Pro. At this point I can be sure it’s not the Sylvania devices causing the issues.
I made the move to HE because there are numerous things I would like to accomplish that ST was never going to achieve, but I have now gained a new respect for what ST had eventually accomplished, which is HA for the brain dead. I get it that a lot of HE users are quite happy with RL, but I would take Smart Lighting on HE in a heartbeat.
Since I have something quite concrete in my RL log tonight I will just post that and see where this goes. This is by no means the only RL problem I’ve encountered, it’s just the latest one and the failure was massive. I cleared logs today when I updated to 2.3.8.120, so I have nothing further back than this. At 10:30 PM my Lights Out app runs for around 50 devices to turn them all off, and I have force enabled. Only one device was activated off before RL logged an error and then simply stopped executing.
There are obviously others more qualified than me to comment on this... but from your description and screenshots ( thankyou !! ), my guess would be.... Could one or more of the ~50 devices be in a state that causes the "Activate even if partially Activated..." or the "Force" to have issues assessing the state of the device?
Perhaps a way to try and troubleshoot this would be:
Try activating the RL setup manually using "Activate" option in the RL App. If this produces the same error, that is good in some respects because you have a repeatable issue. If that is the case.... Try taking devices in/out of the RL setup, perhaps starting with large numbers of devices, then trying in some way to zero in on the problematic device.
That's a program error. Could be corruption in the RL app instance. Could be a device driver issue. Based on what you've shown there are a few things to consider/try. When you ran this app as above did the Sunroom Light turn off or were there any logs for the device? If not, remove it from the app and try again. I'd try creating a new RL app instance to see if there is any corruption in the setup. Since you are just turning off lights I'd suggest using the 'Switch' capability for the dimmers. That shouldn't make a difference, but if it does that points to a driver issue.
Looking at the photos, I see a Sunroom Light East, a Sunroom Light West, and a Sunroom Table Light. However, the error points to just "Sunroom Light". So, I am wondering if you had originally had a device labeled just "Sunroom Light" and removed it or changed the name, then updated RL and forgot to click update for the changes to stick, or it somehow corrupted RL. The missing device by name would indeed create a null pointer error.
To be fair, I am just taking a guess. But, I always treat troubleshooting RL like Rule Machine. First step is ALWAYS open the instance and click Update and try to Activate (or in the case of RM, click Done then go back in and click Run Actions). This sometimes fixes corrupted rules.
Second step is to dig deeper into the logs and look at names, device ID's etc ESPECIALLY if I have changed a label or something.
Third step (or parallel to second step) is to manually run each action step until I see one that fails or none fail. In this case, manually activate each light one by one (edited to add, making sure that the labels are EXACTLY the same as what is shown in the RL or rule instance).
Alright, I will dig in. This RL instance was one of my original I set up and has run consistently (except for issues with my Sylvania Zigbee devices. I changed a bunch of these around so I will now completely recreate the rule from scratch when I get home this evening.
This doesn’t answer your question but may help in general. Create a group with all 50 lights and enable group messaging. This does a number of things.
Zigbee lights will turn on/off together instead of in a random “popcorn” fashion.
Lower mesh traffic - one command instead of 50.
Easier to maintain rules if you add or remove lights.
I had issues with only 9 exterior lights before I started using groups. This was also before I moved my lights to a dedicated hub so there were other issues.
I do something similar and even include some switches with the group. When I change to bedtime mode I have a rule that turns off that group. Works like a charm.
I truly am taking everyone's input to heart, but I need a solid foundation to begin with. Can someone precisely explain the following text between the red parentheses?:
The buttons work as a manual means to run the activate/turn off actions. The 2nd sentence isn't really clear, and I'm not sure exactly what it is meant to say.
Yes, and it's the second part that I cannot understand.
I've recreated the RL app, Lights Out and it works better (no logged failure) but not perfect. Actually, things are working a lot better because all my Zigbee devices are stable.
The issue I'm having includes a couple Z-Wave devices. Two different RL apps see the state of my devices differently, though one app is a clone of the other. I first assembled Lights Out, then cloned it for Lights On, and I've been testing all my lights in the house and doing a walk-through. There's not a problem turning everything on with Lights On, but Lights Off doesn't turn off anything that it sees the state as already being off, regardless of setting "Force" and "Activate if partially activated." The log bears this out. Here's the screenshots of how RL sees these devices at the same point in time with refreshing the browser.
The second part says "Means to activate" defines how the Activate button gets pressed automatically, and that "Means to turn off" defines how the Off button gets pressed automatically. It is the Room Light instance itself that is activated, leading it to perform the "Act" action on devices, or turned off, leading it to perform the "Off" action (or off presets, but let's not get into that).
I'm not sure it's a good idea to have two RL instances referencing the same devices.
Both should be handled in a single RL instance : Lights On with "Means to Activate" and Lights Out with "Means to turn off"
Do you really need the force option on every device ?
I don't use Lights On. I created it for testing. I use Lights Off to activate the turning off of lights. I do this 3 times a day using Morning Reset, Evening Reset, and Lights Out. Morning and Evening do turn on 3 or 4 devices, so activating for off is a necessity. In Lights Out, there is no way to turn that on, as Activate and Turn Off do the same thing.
As for Forcing everything, I'm just trying to achieve consistency until I see things working the same every time.
That's a lot of devices. I don't have any with that many. Hopefully others with large device lists may chime in (maybe @jtp10181). You may need to break the list up into a more than 1 segment. Also, platform version 2.3.8.122 is out and fixes the 'Force' issue.
I do have a RL to shut down everything that may have been turned back on and left on, at 11PM
If I am still up at this time I have noticed the whole z-wave mesh seems to lock up for 5-10 seconds after this RL fires off. It still does work every time though. I may need to move this to RM to stagger it out, to avoid bogging the mesh.
There should not be anything mysterious going on here. I cannot see where the number of devices should be an issue, nor whether I’m calling to activate on vs. off, nor whether two child apps reference the same devices.
It shouldn’t matter if I have devices grouped, or not, when it comes to all devices responding when they are called (and not all are being called for a reason(s) I cannot understand). Grouping may affect performance, but it shouldn’t affect execution.
Honestly, the issue now seems to be isolated to how RL sees the state of my devices. We'll see if this last update fixes the Force issue. This stuff is binary, is it not? I’m not trying to be snotty about it. I just don’t think it should be this difficult. Furthermore, ST was handling all of this without a hitch, using Smart Lighting.
As for jamming up the mesh, most of these devices don't have to respond since they are already in their end state. During testing, this evening, they were all having to respond, but the issue I'm having is isolated to the devices that are showing their state incorrectly in RL's State table.
"means to activate" and "means to turn off" are separate sections that get configured in the UI. The sentence is stating that these two sections run (maybe should say "trigger") the activation as a whole. I am betting they chose not to say trigger because they really do more than that. You can add options, such as activating even if the lights report on, or limiting when the activation takes place. So, that is the heart of the room lighting rule.
I understand all that. Upon re-reading the reason for my confusion is that I didn't read the whole paragraph, just the highlighted sentences. The sentences highlighted don't pertain to one another. The manual testing buttons is not a core function of the app, and probably should be the last sentence of the paragraph. Documentation is hard.
