Deconz-rest-plugin: Not able to detect when a device is powered on

[Ofenhed]

In #170 it's stated that using reachable dx will still trigger when reachable goes from true to true. This seems to no longer be the case.

I'm trying to use a lamp as a switch for other lamps using a flag. I have the following rules:

{
  "actions": [
    {
      "address": "/sensors/3/state",
      "body": {
        "flag": false
      },
      "method": "PUT"
    }
  ],
  "conditions": [
    {
      "address": "/lights/8/state/reachable",
      "operator": "dx"
    },
    {
      "address": "/lights/8/state/reachable",
      "operator": "eq",
      "value": "true"
    },
    {
      "address": "/sensors/3/state/flag",
      "operator": "eq",
      "value": "true"
    }
  ],
  "created": "2019-11-08T07:45:41",
  "etag": "fc124d2e58be9a46952a2b7fe929c39e",
  "lasttriggered": "none",
  "name": "If flag is true, set it false when middle light is reachable",
  "owner": "F6428A0970",
  "periodic": 0,
  "status": "enabled",
  "timestriggered": 0
}

{
  "actions": [
    {
      "address": "/sensors/3/state",
      "body": {
        "flag": true
      },
      "method": "PUT"
    }
  ],
  "conditions": [
    {
      "address": "/lights/8/state/reachable",
      "operator": "dx"
    },
    {
      "address": "/lights/8/state/reachable",
      "operator": "eq",
      "value": "true"
    },
    {
      "address": "/sensors/3/state/flag",
      "operator": "eq",
      "value": "false"
    }
  ],
  "created": "2019-11-08T07:46:38",
  "etag": "e7220cdf73d700f1bbe6812f6b5fd1f4",
  "lasttriggered": "2019-11-08T08:59:31",
  "name": "If flag is false, set it true when middle light is reachable",
  "owner": "F6428A0970",
  "periodic": 0,
  "status": "enabled",
  "timestriggered": 1
}

They only seem to trigger when the lamp has been turned off long enough for reachable to turn false. Is this a bug, new intended behavior, or am I missing something? The update shows up in the WebSocket.

[ebaauw]

In #170 it's stated that using reachable dx will still trigger when reachable goes from true to true.

That’s incorrect. A condition with a dx operator should trigger only when the value actually changes. That’s why you need to put in a dx for lastupdated for switches, as the buttonevent value doesn’t change.

The update shows up in the WebSocket.

Only when websocketnotifyall is set.

I'm trying to use a lamp as a switch for other lamps using a flag.

Note that reachable probably doesn’t behave as you want/expect. Also note that you don’t want to power down ZigBee routers (smart lights).

[Ofenhed]

That’s why you need to put in a dx for lastupdated for switches, as the buttonevent value doesn’t change.

Is there any way to use the reachable attribute the way I'm trying to? Since lights doesn't have the lastupdated it kind of limits my options.

Note that reachable probably doesn’t behave as you want/expect. Also note that you don’t want to power down ZigBee routers (smart lights).

I know that reachable takes a very long while to turn false, but if I could detect when the device connects that would be enough. Are you saying that I can't do that at all, or that initial connection doesn't differ from continuous connection? I would like to have a setup where I don't power down the lights, but that's currently not an alternative. Are there negative side effects I'm missing, apart from reducing the network range?

To go back to the other question, is there no way to send a default state as OP is trying to do in #170?

[Ofenhed]

The perfect attribute would be lastpowerup, where a dx of lastpowerup would detect when a device is started. This would require the device to supply an uptime, so I don't find it likely to be possible to implement. Just dreaming.

[ebaauw]

I know that reachable takes a very long while to turn false, but if I could detect when the device connects that would be enough. Are you saying that I can't do that at all, or that initial connection doesn't differ from continuous connection?

There's no such thing as connections in ZigBee. It's just messages. The device sends a _Device Announcement_ message when it joins the network, after a power up, or after actually joining (as in obtaining the network key). deCONZ marks reachable as false, when it hasn't received any messages from the device for an extended period of time (typically because the device doesn't respond to deCONZ polling its state).

Are there negative side effects I'm missing, apart from reducing the network range?

Some end devices (sensors, wireless switches) don't react well to their parent router going MIA. Xiaomi end devices won't look for a new parent, and become unreachable. Others could actually leave the network, requiring a reset and repair (of the end device).

To go back to the other question, is there no way to send a default state

I tried in the distant past (before the Hue lights supported power-on settings) bluntly to send the desired state every second or so. I more or less managed to do so (on the Hue bridge), but the issue is changing the desired state. Updating scenes from rules didn't work as expected/desired, so it boils down to some pre-defined desired states with associated static scenes. I did a writeup of this on the Hue developers forum, https://developers.meethue.com/forum/t/is-there-a-way-to-change-the-startup-color/4009/127?u=ebaauw.

The perfect attribute would be lastpowerup, where a dx of lastpowerup would detect when a device is started. This would require the device to supply an uptime, so I don't find it likely to be possible to implement. Just dreaming.

I think for API 2.0 we should handle reachable on device level (not on the current level of resource, related to endpoint and cluster). We could expose an attribute related to the last message received (lastseen) and another one related to the last device announcement received (lastannounced). These times would be kept by the REST API plugin, just like lastupdated.

Better ditch reachable altogether. You could have stable rules on lastseen to conclude that a device has gone MIA (did we implement the stable operator in the deCONZ REST API yet?) and dx rules on lastannounced to see when a device has reset or powered on.

[Ofenhed]

Thank you for clearing this up for me. I really think the changes you talk about for API 2.0 sounds great.

I'll leave the status of this issue to you, in case you want to use it to track the API changes.

[Smanar]

I would also like a function like this one. But it seem I m the only one ^^ > https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1436

When a device join the network, it send some "state" to update the home application but if it come after an accidental power off, it need to take the value from the application not the reverse.

On older version, like @Ofenhed I used the "rechable" field to detect when a bulb join the network after a power off and set it with good setting, but not possible ATM.

I know its not possible using this field now, but not sure It's something impossible with zigbee.
When a device join for the first time the network, we have "join" request, but if the device join the device after a power off, we have "rejoin" request, we just have to take a look on this one, no ?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.