Rule Machine failure

Again, I'll say that my understanding RM is not strong. I don't use it much.

However, perhaps it is a RM bug, because I tried using a non-triggered rule a while ago on a switch and it never worked. I converted the rule to a triggered rule and it worked 100% of the time. Therefore my conclusion was that a triggered rule was necessary to activate in response to device events.

1 Like

Regular rules should work fine with switches... I have a number of them. As long as the device creates an event when its status changes, it should be OK for use as a rule truth condition.

But a trigger should work fine, too. :slight_smile:

I typically use regular rules when I have both true and false actions.... Triggered if I only have one or the other.

On the OPs item, I would probably use a trigger. When true, delayed action turn off. Then maybe a completely separate 2nd rule to periodically refresh, if needed like the OP said.

2 Likes

So we're back to looking at the switch again. I'm curious as to what make/model it is. The older GE Z-Wave switches were terrible at reporting events.

I was meaning to reply to this too. I've seen that myself, however a browser page refresh always fixes it. Can you try that next time and see if that helps.

The RM rule is above in the original post.

Oh, and if it is a standard zwave switch (and not zwave plus or zigbee) you really should add it to the Z-Wave Poller app, instead of doing an RM with refreshes...

Or replace it with a z-wave plus or zigbee switch. Those should never need proactive polling/refresh.

A normal rule without triggers gets subscriptions to every condition device.

A trigger or triggered rule gets subscriptions to the trigger devices.

1 Like

Yeah I don't know. Once again I don't trust hubitat's state for sh*t, so I've rejiggered the rule such that I've added a repeat loop to the true condition.

In that case when the switch is on it should try to stop it every 1m (with a 4m delay) until truth change. Maybe

I dunno this all gets too logically complicated. The idea is if the switch is stuck on it'll keep trying to shut off rather than just missing once and then its stuck on forever.

Again, what type of device is the switch???

Because HE's state updating works just fine... Typically where there are gaps or bad function is due to poor end devices, bad drivers, or custom virtual devices.

Why don't you set up a separate rule (or Z-Wave poller as suggested above) to handle the refresh every minute or whatever, then focus on the correct logic on this rule to turn the device off after it turns on? Might be less confusing than trying to do both in one shot.

As others have said above, I think you're fighting a device or driver problem, not a RM problem. Need to get Hubitat to see the correct device state before any rules associated to the device will work correctly.

It's a ge zwave plus switch, an in wall one. Discovered as a Generic Z-wave Smart Switch

Maybe not rely on state?

This could work, but again this is just supposed to be a failsafe.

In normal operation, my Home Assistant rule shuts the switch off based on water temp. The every 4m trigger could shut the switch down even though temp hasn't been reached.

Again, the fact that both rules failed, for me, points to the fact that hubitat had the switch state wrong. I've seen this happen dozens of times where I'm sending off commands to a device that hubitat already thinks is off and nothing happens.

From my original comment.

I have z-wave poller running too but that particular switch isn't available as a choice in z-wave poller. I don't know why.

If you change the driver to Generic Z-Wave Switch (no smart) it will be available to Poller.

1 Like

Ah thanks!

What's the difference?

"Smart" means it's a switch that returns status.. no need for a poll or refresh option on the Device page.

Without a "capability poll" in the driver, it isn't selectable in ZWave Poller.

1 Like

My comment about GE was directed at the OP.. That said, there have been reports of the Monoprice switches failing to report switch events back to the hub unless refreshed. Seems like resetting the switch has been the fix, at least in this case.

I guess that's the equivalent of the GE air gap fix.

1 Like

I use the GE Z-Wave Plus 14291 in-wall switch to control a fan motor; Every few weeks it gets into a state where it fails to report physical switch events . Cycling the air gap switch fixes it. I haven't noticed it fail to report digital events but I don't trust it....

1 Like

@bill For the GE z-wave plus switches... I have dozens of the GE z-wave plus switches in service, and 100% of them report status as expected, 100% of the time.

Thoughts:

  1. Maybe you are having z-wave mesh/routing issues? Have you tried running a z-wave repair on the network?
  2. Maybe you have a weak z-wave network? Maybe the messages are getting sent, but lost/not making it to the hub? Could consider adding a few more plug-in/hard wired devices between the switch and hub location, and then doing a z-wave repair.
  3. You could try the GE Z-Wave Plus Switch device driver I published. May/may not help - but shouldn't hurt in any case. I did do a few things differently on status update in it, though, so there is a chance it could help.
  4. You could have a defective device, I guess. But that sounds unlikely.
  5. If it is a high load device being driven, maybe the switch is incompatible with the load? Maybe the start/in rush voltage is too much for it? Maybe there is a grounding issue?

@Tony This is very weird, and sounds like an incompatible load (maybe in rush current is too high with the fan?) or a bad switch. Definitely NOT something I've seen on any of my 14291 switches - and I have a LOT of them.

1 Like