Rule Machine failure

Just noticed my hot water return loop pump was running when it shouldn't have been and shut it off with alexa. Luckily it was only on for an hour or so, but having it run makes my tankless hot water heater run continuously too so its very not good.

I have the following rm rule to shut it off, and another out of band rule (on another system) that sends hubitat an MQTT command to shut if off when the water temp is above a threshold as as well, but both failed.

switch off Hot Water Loop was turned off[digital] DEVICE digital 2019-02-07 01:04:09.421 AM PST
switch on Hot Water Loop was turned on[digital] DEVICE digital 2019-02-06 12:09:13.395 AM PST

I'm pretty sure the problem is one that I've seen many times now with hubitat, and that is that no matter how I poll and refresh my devices, hubitat still routinely is out of sync with the actual state of the device. The pump is on and hubitat thinks its off so all rules fail until I shut it off with alexa.

This problem is pervasive and so far unsolved after several months now. I'm running out of patience with hubitat. I don't trust this damn thing AT ALL.

The title of your post is Rule Machine failure, but then you go on to say that the state of your switch is out of sync with Hubitat. So it's not really a RM issue, its an issue with the switch not updating state correctly. Would that be a fair statement?

If so, what kind of switch are you using? Is it a Zigbee or Zwave switch? I suggest the focus being on placed on figuring out why that switch is not properly reporting. Once you solve that your rules should work fine.

3 Likes

And if the switch is Zigbee, do you have any Zigbee bulbs on the hub that act as repeaters? Sylvania/Osram bulbs are notoriously bad repeaters that tend to drop packets on busy meshes. I ditched mine and got Sengled bulbs and solved my Mesh problems. You can also use a hue hub to run the bulbs.

I see this issue where devices don’t report accurate state on dashboards all the time. It’s so bad I have a refresh action that refreshes certain important device every 10 minutes. I also add a refresh in rules where things are being turned on and off to deal with this issue. I’ve reported this a time or two, but nothing gets fixed. Without these refreshes the WAF is a big ole 0. And this will be the same for new users.

I see it with Sengled bulbs, the 3 models of zwave plus smart plugs sold by Monoprice and other zwave plus light switches.

I’m not running any bulbs that act as repeaters, only Sengled bulbs. I’ve also got my Zigbee network dialed in now so that every device is getting a strong connection.

There are times where the device page for a device will reflect the accurate state while a dashboard state will be inaccurate and then there are times when both the device page and the dashboard page will be inaccurate to the actual state. This makes a real mess of rules that are based on an accurate reported state.

1 Like

Well, if it is wrong on the device page it should pretty much always be wrong on the dashboard - as that is where the dashboard gets its value...

It "shouldn't" be different on dashboard versus device page, but I have seen that many times, too. I typically just refresh the DASHBOARD web page view, and then it is correct again.

its a zwave switch. its unclear to me how it failed and its now hard to find forensic evidence. It appears from the data above that hubitat thought the switch was On, which points to an RM failure, Since the rule simply loops every few minutes to shut the switch off it ever finds it on, but if that's the case I don't understand how or why my home assistant rule to shut the switch off would have failed as well. The only scenario where that makes sense is if the switch state was wrong.

Either way, either the RM rule failed to fire correctly, or the switch state was wrong. It's one of the two and both point to hubitat.

Yes they both point to the hub, but the resolution and troubleshooting are 100% different depending if the RM should have fired (and didn't) or if the device status was incorrect.

You really need to dig in on that and determine which was the root cause. You will make 0% progress, or get any meaningful external help, until you do that.

1 Like

Before I was doing all of the refreshing RM failures happened because the state was inaccurate.

Again, to reiterate srwhite's point... And this might sound like semantics, but that is NOT an RM failure...

If the device status doesn't change, RM did exactly what you programmed it to. Not a failure.

If the status did change and the RM didn't fire - then that is an RM failure.

I am only harping on this as it changes the troubleshooting and investigation work greatly which one actually happened.

So RM is looking at status change? The RM rule as I have it written:

Select conditions: Switch on
Define Rule: Switch on
Select Actions for True: Delayed Off: Switch: 4 minutes
Refresh: Switch
Select Actions for False: Repeat every 5 minutes (stop)
Refresh: Switch

So if the switch state was indeed On from 12:09 to when I shut if off by hand at 1:04, it seems to me that the rule failed every 5 minutes for an hour since Switch ON would have been true on each run.

What is "stop on truth change?" what's that supposed to do?

Bill -
RM works off of events, not state change - per se.

So in your example, when the device creates a "switch on" event, then that RM rule would go true. When the device makes a "switch off" event, then it would go false.

If the end device makes no events at all for any reason, then the RM rule stays wherever it was (true or false).

Or if a poorly written driver changes state, but doesn't create an event for it, then the RM would do nothing then as well.

1 Like

I'm confused on something from your RM rule.. Based on your screenshot there is no trigger. What is causing this rule to run? You mention it's looping, but that's only happens when the false condition is met. As soon as the rule goes true it will stop running as there's nothing to trigger it and no action for "TRUE" to cause it to repeat.

What am I missing? I think you ned to evaluate your trigger conditions too.

The Trigger is the switch going from Off to ON.

4 min later he wants the switch to go Off. And by doing so, refresh the switch every 5 min.

2 Likes

That's the rule. I don't see a trigger unless it's from another rule.

i.e.

I am not understanding how this rule can be called without a trigger, unless it's called from another rule.

the Rule under discussion is the failsafe rule. Assuming it's not a red herring, I'd expect there's the "real Rules" in operation too.. which is causing the Hot water demand, turning on the switch. This one is just to prevent runaway.

That's correct. The trigger is when the switch comes on. I'm trying to get it to shut off 4m after it comes on no matter what. I don't want it to ever run longer than 4m.

If the switch says its off I want to make sure its off by refreshing every 5 minutes.

Do I need to add a loop to the true condition too? Would that be safer?

Again, and perhaps I'm missing something, there is no event subscription for the rule he posted. So aside from the repeat action for FALSE, what keeps that rule evaluating when the TRUE condition is met.

I'll admit I'm not a RM expert, so my own understanding might be off here.

@srwhite It's not a "triggered rule" just a rule with conditions

Can you post a screenshot of that RM rule so we can see how that is setup?

I have an outdoor shower near my pool. It also has a tankless heater. I don't want it left on, using water and electricity.

My Rule is a trigger "Every 20 min." I then turn off the switch. Yes, on rare occasions, that would prematurely cut the shower. Don't care :smiley: excessive use is what I prioritize for mine.