Rules not completely firing

I'm wondering if I'm trying to do too much in a rule or if there is something else wrong. Many times, when I trigger a rule, not everything that is supposed to happen will happen, but if I either try the rule again after a few minutes or if I hit each switch in the web console the hub can still control the items that didn't turn on or off with the rule trigger.

For example, I have "Good Morning" which has two separate trigger rules. One trigger is when it is 5:00am the other trigger is for a "Good Morning" virtual switch if I wake up before 5 am. Both triggers activate the same good morning actions rule.

What should happen is the kitchen, living room, outside porch, downstairs light, fish tank light, and a iris power plug should all come on, and the mode should switch to Day.

Often, only the mode will switch to Day and the fish tank light will come one when the rule is first triggered. If I hit the virtual switch, the living room and kitchen will come on. Hitting it again, the downstairs light will come on, etc.

As much as I love the idea of local processing on the hub, at the moment, I cannot trust the hub to do what I tell it, especially if I'm away with my family or even if I'm just leaving my wife home. I went to hubitat thinking local processing would be an improvement over SmartThings and their cloud, but I can't leave it like this. Any help or suggestions would be appreciated.

In your rules, do you have your virtual switches turning off after a delay? Sometimes, if a delay is not used, the virtual switch will turn off before all actions are completed, basically making the rule ‘false’.
Edit: And I just realized my explanation doesn’t explain the 5:00am trigger

I do and I've modified rule triggers to get around it or at least try to see if that was the issue. Several over my rules used to be triggered by either a time being between a certain minute (ie. 5:00-5:01 am) OR by the virtual switch which the rule wouldn't he turn off after 30 seconds so it could be used again.

I separated the triggers so that there is still a virtual switch that will get turned off after 30 seconds if I use it, but the time trigger is now separate and set for 5:00am and doesn't use the virtual trigger or turn that virtual switch off at all.

Edit: I just saw your edit as I typed this reply. Thank you for your thoughts though! :slightly_smiling_face:

Could you post some screenshots of your rules? The logical minds here could probably figure it out quickly.

Below is my good morning rule. It is triggered by one of two other trigger rules that are either at 5:00 am which runs the rule or by turning on a virtual switch which runs the rule and then turns off the switch after 30 seconds.

Fish tank light and living room heater are both iris smart plugs. Kitchen light is a virtual switch that turns on two light strips in the kitchen. Outside Left and outside right are two Osram RGBW bulbs on my porch. Downstairs light and living room light are a GE Link bulbs.

If I’m understanding you correctly, you’re having an issue with mostly zigbee bulbs/switches not turning on consistently?

Could this be an issue with a weak zigbee mesh or interference?

I'm not sure if the mesh is the issue or not. I am able to control all the devices individually. It is usually just an issue when I run a rule to turn on or off mulitple things at once.

If you setup a duplicate rule with nothing but virtual devices that will determine if it is a rule or a device issue...

1 Like

You can depend on the rules to fire as long as they are built correctly. The RM isn't as complex as webCoRE, but it definitely does do what you tell it to. You are doing capture/restore, refresh and poll. Why do you have that set, are these switches/devices not reporting their state every time? I'd look there for answers.

I don't see the conditions of your rule, only the actions, so difficult to see what might also be influencing the result. Please post so we can try to help further.

1 Like

Try removing the 'Fade: 0' portion of the dim command. Just leave the fade field blank. Some devices do not like having the fade field set and will ignore the command.

Also, on devices that you are issuing a DIM command, there is usually no reason to also issue an ON command to it. A light that is OFF will usually turn on when told to DIM to a certain level.

By minimizing the number of Zigbee and Z-Wave commands being issued, I would think things would be more reliable.

Also, do you have any RESTRICTIONS on this Rule based on Mode?

This is true for all the built in drivers, setLevel > 0 will always turn a device on if it is off.

2 Likes

The rule I posted an image of has two separate triggers set up. One is when I turn on a virtual switch, the other is at a certain time. I'm not running any commands for capture or refresh or poll. I'm not sure where you're seeing that.

For the dimming to turn on, I found that it does not always behave this way, but even where I set a dim, it does not always behave that way. For example, my kitchen light is just set to turn on, but occasionally it will turn on to only 10% or so despite the fact that it was at 100 when I turned it off and I'm just turning it back on. Hubitat also reports it at being at 100% so I have to turn it down and then back up to get it to 100 again.

Oops! My apologies. I was looking at another post while replying to yours. I do that sometimes.
Your conditions are joined with the OR operator, the AND operator, or they were selected together, giving you [ANY] as the condition?

My conditions are two separate trigger rules, one condition each. One is if I hit the good night switch, the good night actions fire. The other is if it is 1am with the restriction of any mode except night.

That sounds like a device or driver issue. I get some bad behavior from my Sengled Element Plus bulbs every so often.

This can happen if you do a setLevel 0, which is generally a bad idea, since it leaves it to the device to determine what to do, some will turn off, then set the internal level to some minimum value, 10 or 20 pct, some will set the level to 0, but not issue an off or level report ect... this can be dealt with in our drivers, if setLevel 0 is simply an alias for off, however we haven't imposed that restriction.

1 Like

I'm going to chime in here too. I was looking for clues to my problem and this is very similar. Mine however is my goodnight routine. Taken directly from ST and their built in "Goodnight" automation. Which essentially triggers to turn off ALL (well almost all) my lights and then set the mode to sleep. So far from owning the Hubitat. I've had to hit that goodnight switch at LEAST 3 times to get everything to turn off. Most of the time it leaves on a light or three. Sometimes groups of lights. Again...this all worked as expected in ST turning off all the lights almost at once (more so in like a 1.2.3.4.5 type order) but usually all lights off within it at max 5 seconds.

Is something over running the commands somehow?

Did this issue of rules not completely firing ever get explained? I think I'm experiencing the same issue. I've found that if a rule action turns off much more then 4 devices, it becomes unreliable.

This seems to be the same issue I have reported here