Rules fail to fire with conditions on DDF devices

[ebaauw]

Describe the bug

Some rules don't fire, when conditions are based on attributes of devices exposed through DDFs. After changing the DDF status from Gold to Draft, the rules fire again.

Steps to reproduce the behavior

I noticed this for the Hue motion sensor, where I have a rule with:

  "conditions": [
    {
      "address": "/sensors/222/state/presence",
      "operator": "eq",
      "value": "true"
    },
    {
      "address": "/sensors/222/state/presence",
      "operator": "dx"
    },
    {
      "address": "/sensors/221/state/status",
      "operator": "gt",
      "value": "-1"
    },
    {
      "address": "/sensors/221/state/status",
      "operator": "lt",
      "value": "4"
    }

It seems like the dx condition on presence isn't firing.

Expected behavior

Rules should work independent of how device is exposed (through legacy C++ code or through DDF).

Screenshots

n/a

Environment

• Host system Raspberry Pi
• Running method: Raspbian
• Firmware version: 26400500, but also others
• deCONZ version: 2.71.1, but also earlier versions
• Device: RaspBee I, but also others
• Do you use an USB extension cable: (yes / no) -- only relevant for ConBee I/II
• Is there any other USB or serial devices connected to the host system? If so: Which?

deCONZ Logs

Additional context

I'm not exactly sure what's going on. I think some rules that should be triggered by daylight or dark are failing as well (also Hue motion sensor). It would seem the web socket events are issued alright.

[Thomas-Vos]

Another example of a rule which is not triggered on motion: https://gist.github.com/Thomas-Vos/c8d9029aee793cc43926ffba8696e818

[ebaauw]

Here's the ZHALightLevel:

  "conditions": [
    {
      "address": "/sensors/1/state/daylight",
      "operator": "eq",
      "value": "true"
    },
    {
      "address": "/sensors/298/state/daylight",
      "operator": "eq",
      "value": "true"
    }
  ],

Both with DDF and legacy code, the web socket notification includes the change to daylight, but only with the legacy code, the rule system is evaluating a rule event:

Jul 03 21:40:24 pi3 deCONZ[5138]: 21:40:24:265 rule event /sensors/298/state/daylight: 0 -> 1

[SwoopX]

What's remarkable that I previsouly also had issues with the rules (on the frient MOSZB-140), but haven't noticed since I had a double bottom in my automation system. The last fix in this regard made it work again, w/o double bottom. Below my rule

"16": {
    "actions": [
      {
        "address": "/lights/17/state",
        "body": {
          "on": false
        },
        "method": "PUT"
      }
    ],
    "conditions": [
      {
        "address": "/sensors/115/state/presence",
        "operator": "eq",
        "value": "false"
      },
      {
        "address": "/sensors/115/state/lastupdated",
        "operator": "dx"
      },
      {
        "address": "/sensors/57/state/power",
        "operator": "gt",
        "value": "2"
      },
      {
        "address": "/sensors/57/state/power",
        "operator": "lt",
        "value": "50"
      }
    ],
    "created": "2022-03-05T19:06:13",
    "etag": "e6249b262487f3b73ddd0ed87be4ec36",
    "lasttriggered": "2022-07-03T11:21:51",
    "name": "ku.rule.dahAutoOff",
    "owner": "9B0B7F1117",
    "periodic": 0,
    "status": "enabled",
    "timestriggered": 20
  }

[ebaauw]

I think a dx on lastupdated works alright, but not on another attribute. Also for rules without dx or ddx, attribute value changes aren't considered for rules events.

[snozzlebert]

Is this the same as #6149 ? A rule based on the open attribute.

[ebaauw]

I think it is. There seems to be a DDF for lumi.sensor_magnet, but not (yet) for the lumi.sensor_magnet.aq2.

[Thomas-Vos]

The last few months I had issues with rules not firing for my Aqara multi sensor (lumi.weather). The rules use DX on state/humidity. They just didn't trigger at all when they should.

Today I tried changing the DDF status to Draft, just like Erik did in the issue. Now they work again! So it looks like this issue does also affect other types of DDF devices.

[bee-con]

It would be nice to see this fixed. Just created a rule in hue essentials to have a Philips sensor switch on lights when movement is detected while it is dark, and the rule does not work.
Can also confirm that the rule does work, if the DDF status is set to draft.
Will retest again with DDF status set to Gold once a fix is available.

[popy2k14]

Also my rules created in Hue Essentials coming from aqara motion sensor doesn't fire. Also after recreation of the rules.

Looking forward to an fix.

[Maart3nL]

I Have the same issue, solution for now is to set the DDF status of the motion sensor to draft.
last night i found out that the DDF status resets after a reboot so it would be really nice if this can be fixed

[bee-con]

last night i found out that the DDF status resets after a reboot

What I did:

Copied the file for my sensor from /usr/share/deCONZ/devices/philips to /home/pi/.local/share/dresden-elektronik/deCONZ/devices.

Renamed the copied file (added suffix _DRAFT).

Opened the file (right click sensor in deCONZ, edit DDF, File -> Open).

Edited the file, changing the status to draft, and then save it using File -> Save.

Then chose File -> Hot reload.

Had an involuntary reboot a few days ago, due to a short power blackout, and my settings survived the reboot.

HTH

See here: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/DDF-cheat-sheet

All DDF provided directly with deCONZ typically reside in /usr/share/deCONZ/devices/ on a Linux system and are loaded first. However, files residing in the home directory of the user running deCONZ (e.g. /home/<DECONZUSER>/.local/share/dresden-elektronik/deCONZ/devices) will override the pre-packaged files to allow users to amend and keep their own files if desired.

[Helox]

Yes seems like the same issue, do note that it was working in 2.15.02, after my upgrade to 2.17.00 I tried reverting to each minor version until everything was working again. However I cannot confirm if this error is also caused by the "dx" condition.

Updating the DDF status to Draft does not resolve the issue in my setup.

[Mathmxp]

Will this be fixed in the next release? I tried the latest beta but the problem still persists.

[Mimiix]

Asked @manup to check in.

[manup]

Assigned to v2.18.1-beta, I'm looking at it in the debugger it's a bit fiddly.

[manup]

Turns out the missing part was that the DDF didn't set the Event::num() which is used in the rules.
Beside the fix in #6288 I've spotted another problem in the device state machine which is fixed in #6289.