Trigger a rule when a thing goes Offline because of COMMUNICATION_ERROR

Setup, Configuration and Use Scripts & Rules
1

Hello,

As I’m using the Velux KLF 200 bridge to control my blinds, I’m faced with the regular “zombie bridge” issue where the only solution is to disable the bridge in openHab, unplug, wait, replug the KLF200 and enable the bridge.
As I have a remote controlled socket on the KLF 200 power line, I can do that just fine manually via Main UI but this is somewhat tedious and I may not notice immediately when the KLF goes zombie.
As such, I would like to write a rule that triggers when the thing goes Offline because of a COMMUNICATION_ERROR state.

I have the following trigger:

triggers:
  - id: "1"
    configuration:
      thingUID: velux:klf200:4b425d26ec
      status: OFFLINE
    type: core.ThingStatusChangeTrigger

but I’m having a hard time figuring out how to specify the COMMUNICATION_ERROR part.

Would you have any suggestions for openHab 3.4.3?

2

Why not trigger on the COMMUNICATION_ERROR state instead of OFFLINE?

If you can’t do that, you’ll have to trigger some rule (maybe the same one) on COMMUNICATION_ERROR and set a timestamp. Then trigger some rule on OFFLINE and send your commands to the switch only if the OFFLINE was close in time to the COMMUNICATION_ERROR.

3

Because I have no idea how to do that. I mean, here are the choices I have in MainUI:

image
image618×372 5.76 KB

But if there’s a way to trigger on COMMUNICATION_ERROR directly, I’d gladly use that.

4

I thought the UI would let you type in the status, not just select one from the list (similar to Item triggers).

The COMMUNICATION_ERROR is a part of the status details. You could try changing it in the Code tab to OFFLINE (COMMUNICATION_ERROR) but there is no guarantee that will work.

If it doesn’t, trigger the rule just using OFFLINE. Then you can get the Thing and pull the details from the status.

GraalVM JS Scripting

var thing = things.getThing('velux:klf200:4b425d26ec');
if(thing.statusInfo == 'COMMUNICATION_ERROR') {
  // toggle the switch
}
else {
  console.info('Thing went offline for some other reason');
}

Unfortunately Blockly doesn’t expose the statusInfo in a block.

5

Thanks, I already have a JS script to do the on/off part, so adding the test in statusInfo is good for me.

6

I also faced the communication_error issue nearly ever 24 hours.

I was only using a random power supply from an old mobile phone.
After changing the power supply to the original, I have not seen the issue anymore.

Maybe that’s helpful for you

7

Yes, I believe it has to do with the power supply, but I am using the original one and it happens every once in a while.

Just for reference to others, the test has to be written like this in JS:

const bridge = things.getThing("velux:klf200:4b425d26ec");
if (bridge.statusInfo == "OFFLINE (COMMUNICATION_ERROR)")

The status info takes both parts, it’s not just empty COMMUNICATION ERROR as I originally expected.

8

I have just ordered additional smart plugs, one to be used for the KLF200 as it goes into zombie mode about once every month.

Do you remove power for a certain amount of time? (Like 10, 30 or 60 seconds).
Do you have to disable the binding during reset and enable after it?
Long story short, would you mind sharing your rule with actions?

9

Here is the entire definition, you’ll have to adjust for your items:

configuration: {}
triggers:
  - id: "1"
    configuration:
      thingUID: velux:klf200:abdcef
    type: core.ThingStatusChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "3"
    configuration:
      type: application/javascript;version=ECMAScript-2021
      script: >-
        (
          function()
          {
            const bridge = things.getThing("velux:klf200:abcedf");
            const aubess = items["aubess_power_outlett_state"];

            console.log("Veluf KLF status changed: " + bridge.status + " / " + bridge.statusInfo);
            if (bridge.statusInfo == "OFFLINE (COMMUNICATION_ERROR)")
            {
              console.warn("Veluf KLF is zombie, restarting it via the zigbee power socket");
              console.log("Veluf KLF zombie -> disable bridge");
              bridge.setEnabled(false);
              java.lang.Thread.sleep(2000);
              console.log("Veluf KLF zombie -> power off");
              aubess.sendCommand("OFF");
              java.lang.Thread.sleep(10000);
              console.log("Veluf KLF zombie -> power on");
              aubess.sendCommand("ON");
              java.lang.Thread.sleep(5000);
              console.log("Veluf KLF zombie -> enable bridge");
              bridge.setEnabled(true);
            }
          }
        )

        ();
    type: script.ScriptAction
10

Thank you so much!

With Autumn kicking in and the binding being far less active (less sunshade and window opening action), finetuning (and troubleshooting) my own rule would take beyond Christmas I’m afraid…

11

Aaaaaand it is beyond Christmas and the rule did not provide a successful reset yet. TBH today the bridge finally turned zombie for once. And the rule I made in rules DSL behaved correctly but did not solve the problem. I think due to a power outage one month ago due to which the Innr power plug did not reconnect to my hue bridge properly (I have two Innr plugs, both were unreachable after that time). My hypothesis is that the plugs probably want to connect to the bridge when it is not yet online, fail and don’t retry. I did not try to reconnect them on purpose, just because of this rule.

Anyway, my DSL rule looks like this:

// Triggers:
// - When velux:klf200:meterkast changed

// context: veluxreset-1
if (getThingStatusInfo("velux:klf200:meterkast").getStatusDetail().toString() == "COMMUNICATION_ERROR") {
	logWarn("VeluxWARN", "Velux KLF is zombie, restarting it via the power socket")
	logInfo("VeluxINFO", "Velux KLF zombie -> disable bridge")
	sendHttpPutRequest("http://localhost:8080/rest/things/velux:klf200:meterkast/enable", "text/plain", "false", headers, 1000)
	Thread::sleep(2000)
	logInfo("VeluxINFO", "Velux KLF zombie -> power off")
	Velux_Bridge_Smartplug.sendCommand(OFF)
	Thread::sleep(10000)
	logInfo("VeluxINFO", "Velux KLF zombie -> power on")
	Velux_Bridge_Smartplug.sendCommand(ON)
	VeluxEnableTimer = createTimer(now.plusSeconds(30))[|
		logInfo("VeluxINFO", "Velux KLF zombie -> enable bridge")
		sendHttpPutRequest("http://localhost:8080/rest/things/velux:klf200:meterkast/enable", "text/plain", "true", headers, 1000)
		VeluxEnableTimer = null
	]
}

Reason that it took three-and-half month to finally turn zombie:
I bought the Innr plugs only after the previous post (innr as these had the right dimensions not to block the plugs next to it and are compitable with the hue environment that is already present).
After incorporating them in hue, one wall switch of hue commanded a room i.s.o. a single light, took me a few weeks to figure out that mistake (turning off the bridge together with the light).
Had to turn of power a few times for other reasons and finally the power outage one month ago…

Now waiting for the next zombie state (plugs are paired again) :slight_smile:

12

Not sure if it will help:
After I moved the klf200 bridge closer to the roller shutters I want to control, I have not faced the communication error between klf200 and OH again. Maybe weak signal was causing this