Rule machine fails to execute off command

So I have a rule to flash a light in the family room, but it failed several times to issue the off command. Maybe there is a better way to do this? It was working for months and now it fails to issue the off command.
C8pro hub 2.4.4.151
Here's the rule, and I even added a second "off" command, but when it fails no "off" command is ever issued, at all


sTATS

you can see below at 12:00 the wait was over and rule never generated "off", yet at 12:05 it worked correctly.

I've even recreated the rule, tried update rule and the failure still happens

I never had much luck using Flash. I always ended up just doing a loop.

It's been awhile since I tried it but it seemed it was the same issue. Sometime it would work and sometimes it would not stop.

Your logs would indicate that the issue isn't with Rule Machine. The off command is clearly executed as an Action.

However, apparently the device isn't responding to the "off" command.

What device is this? And how is it paired to Hubitat?

2 Likes

Thanks Aaiyar and Yes at 12:05 it worked correctly, but I don't see an off command at 12;00, the rule failed to generate it. That's what I meant, it will work fine, and then during a particular cycle the "off" is never sent.
It's a Sylvania recessed can light. I can issue "flash" and "off" from the device page and it works without issue.

1 Like

Try converting that first “off” command to “on”. I have found that to turn some of my lights off that implement “flash“, to stop the flashing, I have to actually issue an “on” command, followed by an “off” command.

2 Likes

@Rxich - I'll bet you that @John_Land has hit the nail on the head. My recollection is that for those devices that don't natively support a "flash" command, flash is simply alternating on and off commands.

Maybe if your bulb is in an "off" state when the off command has to be sent, the command isn't sent?

Certainly worth trying @John_Land's suggestion.

1 Like

I certainly can do that, but it's the rule that fails to send off, or at least it's not logged. I do see the rule behaving on other occasions tho and the off command is sent and logged.
Looks like rule machine failed to send an off, unless the logs aren't accurate

You might try putting a 1 second delay between your 2 OFF actions.

I can do that, I only added 2 "offs" when I noticed a single one was being missed(rule didn't send) I can easily turn off the light from my phone or a button on my desk. The bulb itself reliable stops flashing when off is commanded.

Agreed

I just did some testing directly from the device page, and made the following observations.

If my light was in an "off" state, and I pushed the "flash" button, the light would flash as expected. However, the switch status remained "off" the entire time. So clicking on the "Off" button would not stop the flashing.

I needed to first push the "on" button, which turned on the light steady, and then press the "Off" button.

If the light was already "on" when I pressed "flash", the light would flash, but the "status" would remain on. Then when I pressed "off" it went off immediately.

Summary :
It appears that the light's "status" does not change when you press "flash". If you started with the lamp off you would first need to turn it on, before you could stop flashing by sending the "off" command.

2 Likes

Hmm, what was the device? My Sylvania hats reliably repond to off when flashing, and in the device page they flip to "on" when the flash command is issued. And off stops them immediately.

Maybe no one can see above in the logs where "off" was never sent at the 12:00:18:41 mark after the wait expired

The device was a Z-Wave plugin lamp dimmer. I also tested with some Z-Wave wall switches that behaved the same way. The status remained "off" despite clicking the "refresh" button during the flashing.

When testing some Zigbee smart bulbs, the status would change to "on", when I pressed refresh, and then immediately show "off" until I pressed "refresh" again.

That may happen if the Hub doesn't see the status as being on.

Might be worth trying to send an "on" followed by an "off" at the end of the wait period.