Rule Repeat Action

[GatVlieg]

Below is the True Action of a straight Rule

I'm trying to understand the REPEAT portion...

What I want:

• Delay the action for 5 minutes (assuming it doesn't get cancelled)
• Do the Action (an Off event in this case for a light switch followed by a Refresh)
  --- At this point the rule should be False & cease/exit
• But in the event the switch isn't Off, for whatever reason, repeat the True Action at 1 minute intervals (Off & then Refresh)

Is this the correct way to implement it?
Is this what will actually happen?

Thanks in advance
J

[ogiewon]

What type of device and what driver is the Kitchen Counter?

[GatVlieg]

Just a light switch. One of those "faulty" non-plus GE models.

[Edit: Would it matter?]

[bravenel]

You shouldn't have to do this, and I recommend against it. See this post:

Why does a refresh request cause dimmers to report false physical events and turn on/off or set level?

There is a problem we have come to realize with using Rule Machine to poll devices the way people are doing it. We put a sniffer on a SmartThings hub to see what they are doing. We didn't have 50 devices to check with, only a few, so we don't know what changes with lots of devices. The sequence goes like this starting every 10 seconds: Poll device 1 Get response from device 1 wait ~1 second poll device 2 Get response from device 2 wait ~1 second poll device 3 Get response from device …

[GatVlieg]

Bruce, I meet all 3 of your criteria for this device in my RM rule:

(1) the device does not report physical on/off events, (2) you need physical on/off events for an automation or Dashboard display, and (3) it is an older non-Z-Wave+ device.

[GatVlieg]

So lets for argument say I change my action to this:

(Eliminated the Refresh)

Still need to understand the effect of the Repeat action...

Thanks
J

[bravenel]

@GatVlieg

This one is going to wait 5 minutes, then turn off the light, and continue to turn it off every minute until it is turned on, at which it would stop turning it off over and over again. If it is turned on during the 5 minute wait, it won't do anything until the next time the rule fires.

My suggestion about not doing this is that it leads you down a path of trying to put diapers on things, and pretty soon you have a mess on your hands. Better plan, IMO, is to get us to fix the underlying cause than to put diapers on the problem. But, choice is good.

[GatVlieg]

As always Bruce, thanks for your invaluable input.
I'll not diaper / band-aid it as you say, but never the less it is good to understand the concept.

J

[ogiewon]

@GatVlieg

Edit: Would it matter?

Yes, it does matter a little. That device should be using the "Generic Z-Wave Switch", as that driver assumes it is not going to get a response back from the device (IIRC). As a result, it immediately updates the status and sends an event when an automation changes the state of the switch. So, it really does not make a lot of sense to bother refreshing that switch since the state will be what was commanded already. Think of it as 'fire and forget' and 'hope the switch does what it was told to do.' The Z-wave (non Plus / non properly reporting) switches should use this driver.

The "Generic Z-Wave Smart Switch" does not behave this way (IIRC). It sends the Z-Wave command to the switch. The switch has to send a status report back to the hub for the driver to change the state of the switch and send an event. The Z-Wave Plus switches should use this driver.

Again, this was my understanding from a few months ago when these drivers were released/revised.

[GatVlieg]

You're correct; I am using the Generic version.

J

[ogiewon]

@GatVlieg

You're correct; I am using the Generic version.

LOL - they both have 'generic' in their names...

[GatVlieg]

OK, good point - the NON-Plus generic versions!