Rule for retrying an action that didn't take - zwave

Tags: #<Tag:0x00007f616fa57008>

Anyone got a rule for checking for an action, ie turn a plug off, that it has actually done it? and if not retry it.

I’ve got a zwave plug, that no matter how many times I heal, or move it - seems to have become non smart. (its about 2.5m from the controller and in proximity to 4 other zwave devices within 2 m…ie its right in the middle. Some times it works, but reently it hasnt’ been, through multiple 2.5.x versions). What seems to happen is I give it a command, it goes offline, then receives a power update that brings it back online.

Anyway, I have a proxy switch on it, that I turn off, and so far my rule will check if the proxy switch is off, but did I still get a power reading from the device. So if it’s supposed to be back on I issue a postUpdate to the real switch item, start a timers, then when that expires send an off command to it.

rule "Night Coffee Machine Still On"
when
    Item zwave_switch_coffee_machine_watts changed
then
    logInfo("Coffeemachine-Check","Received Coffee machine power update: " + zwave_switch_coffee_machine_watts.state)
        if (coffee_machine_proxy.state == OFF && zwave_switch_coffee_machine_watts.state > 0)
        {
            logInfo("CoffeeMachine-Night","Coffee machine is supposed to be off")
            zwave_switch_coffee_machine.postUpdate(ON)
            if (MachineOffTimer === null)
            {
                logWarn("CoffeeMachine-Night","Starting timer to turn off machine")

                MachineOffTimer = createTimer(now.plusMinutes(5)) [|
                    zwave_switch_coffee_machine.sendCommmand(OFF)
                    logWarn("CoffeeMachine-Night","Turning Off Machine Again")
                    MachineOffTimer=null   // reset the timer
                ] //HeatingBoostTimer = createTimer(now.plusMinutes((heating_boost_time.state as DecimalType).intValue)) [|
            }
        }
end

I’m not convinced its going to work…and I’ll need a reverse one as well, if power is 0 and it’s supposed to be ON, postUpdate(OFF) and turn on again.

It’s so annoying as this switch has been running fine for years…but I’m about to replace it with a tasmota flashed smart plug.

then
   try {
      // do some stuff
   }
   catch(Throwable t) {
      logError("Error", "Some bad stuff happened in my rule: " + T.toString)
   }
   finally {
      // always runs even if there was an error, good place for cleanup
   }

Have you considered that the device might be faulty? Commands get sent to devices 10 or 12 times before the device gets
Marked offline. The controller will try 3 or 4 times, and the binding will repeat this 3 times - if there is no ack from the device then it is marked offline. This has not changed for a very very long time.

If the receiver in the device is faulty, then it would not receive the command and it will be marked offline.

1 Like

i guess could be. But wouldn’t that also affect it sending reports back?

It also seems intermittent. It’s a few years old, and hooked to a coffee machine that would give it a fairly hard duty cycle.

btw the just moved it and swapped another for the coffee machine. the old coffee machine one thats been moved i can get to respond ina different location (its a lot closernto the controller) through one wall.

No it would not necessarily impact reports back. If the receiver in the device was not working then it would not receive commands, but if the transmitter was working it would still be as to send reports.

1 Like

It could just be a noisy environment then. If it’s not able to receive the commands then this seems the most likely issue.

What frequency is your z wave device working in, and is it near to a microwave?

If a microwave at 2.4GHz affects an 800 MHz or 900 MHz Z-Wave device the microwave is very defective.

Perhaps you are thinking of Zigbee that operates near the 2.4 GHz RF band worldwide?

Whatever nz/AU is. 890 something I think. And no we don’t have a microwave.

There was that one TV that took out a whole village…!

But yes, it’s unlikely to be a microwave.

Definitely not a microwave then.

Any other appliances nearby? As @chris mentions, the area around your coffee pot might be noisy. Is it in a kitchen? It’s just that you have intermittent issues (a particular appliance being on?), and don’t see issues when you move the device elsewhere…

1 Like

Sits next to a rocket espresso machine. But has done for over a year. Not aware of any other changes that would have affected it.

I’ll try another in that spot and move that old node 13 somewhere else.

@denominator
Try catch won’t work with rule DSL. If an error occure basically the rule is aborted and try catch will not function

@psyciknz
I have not done this myself for z-wave. There should be any need for it. I would check my z-wave network with z-wave heal etc.
I have done this for IKEA Ansluta (predecessor of trådfri)

This is a bit ugly but I show it anyway:

items

Switch MyLightProxy "Proxy item for actual item"
Switch MyLight "Actual zwave device"

rules

var Timer mRetryLightTimer = null
var int mRetryLightExecutions = 0
val int mRetryLightMaxNumnberOfExecutions = 10
val int mRetryLightDelay = 5

rule "RetryLightRuleOff"
when
    Item RetryLightProxy changed to OFF
then
     if (mRetryLightTimer !== null) {
        mRetryLightTimer.cancel()
        mRetryLightExecutions = 0
    } 
        logInfo("RetryLightProxy", "RetryLightProxy OFF Triggered")
        MyLight.sendCommand(OFF)
        mRetryLightTimer = createTimer(now.plusSeconds(MyLightDelay)) [|
          MyLight.sendCommand(OFF)
          mRetryLightExecutions++
          if (mRetryLightExecutions >= MyLightMaxNumberOfExecutions) {
              mRetryLightExecutions = 0
              mRetryLightTimer = null
          } else {
             mRetryLightTimer.reschedule(now.plusSeconds(MyLightDelay))
          }
        ]
end

rule "RetryLightRuleOn"
when
    Item RetryLightProxy changed to ON
then
    if (mRetryLightTimer !== null) {
        mRetryLightTimer.cancel()
         mRetryLightExecutions = 0
    } 
    logInfo("RetryLightProxy", "RetryLightProxy ON Triggered")
    MyLight.sendCommand(ON)
     mRetryLightTimer = createTimer(now.plusSeconds(MyLightDelay)) [|
        MyLight.sendCommand(ON)
        mRetryLightExecutions++
          if (mRetryLightExecutions >= MyLightMaxNumberOfExecutions) {
               mRetryLightExecutions = 0
              mRetryLightTimer = null
          } else {
             mRetryLightTimer.reschedule(now.plusSeconds(MyLightDelay))
          }
        ]
end

Thanks, yeah I’d tried with system wide heal on and off, and it was intermittent again.

Single device heal I was never able to do as even though for a while it was responding, it wouldn’t complete initialisation, would stay in ALIVE: DYNAMIC VALUES.