Deconz-rest-plugin: TRADFRI Motion sensor dark function

Created on 11 Sep 2020  Â·  14Comments  Â·  Source: dresden-elektronik/deconz-rest-plugin

Describe the question or issue you are having

Sorry if this has been discussed but I did not find anything. Im tying to use the TRADFRI motion sensor in a room with another "standard" ceiling light - thus it should only trigger when its dark in the room. There is a day / night switch on the device which should exactly work that way, however the motion sensor triggers anyway.
REST shows dark : true when
a) Mode selector is on day (constant true)
b) Mode selector is on night (still constant true)

In my understanding, if on night mode there should be dark : false if the room is not dark. However, neither turning on the ceiling light (LEDs - does the sensor needs a specific wavelength for detection) nor daylight (that would rule out the latter) sets the state to dark : false

Is my sensor faulty? Anyone else having issues and / or information on thresholds? Are there better sensors, e.g. the Hue version?

Environment

Vanilla set-up with newest versions from 06/09/20 - can't get to my gateway right now sorry

Raspberry Pi, raspberry II, deConz service, phoscon, REST-API for debugging

User Question stale

Most helpful comment

The Trådfri motion sensor isn't a proper sensor; it's a controller. It controls bound lights directly, without involvement of the Trådfri hub. When it detects motion, it sends an _On with Timed Off_ command. This causes the lights to turn on, and turn off automatically, after the specified time (in the _On Time_ parameter). On the old model, this time could be set using the dial, on the new model, it's fixed to 3 minutes. The sensor does not send a message when it no longer detects motion. The sensor will only send a second message that it still (or again) detects motion, shortly before the lights would turn off. When the device is set to _Night_ mode, and there is enough light, it sets the _Accept only when on_ parameter. This causes the bound lights to ignore the command, unless they're already on. So the "sensor" does "trigger" always, irrespective of _Day_ vs _Night_ setting and the amount of light it detects.

You can issue the _On with Timed Off_ command manually from the GUI, to familiarise yourself with how it works.
Screenshot 2020-09-12 at 00 07

Upon pairing a Trådfri motion sensor, the REST API plugin creates a group and binds the client _On/Off_ cluster to this group. This causes the sensor to send the _On with timed off_ commands to the bound group. When adding that group to a light (using the Zigbee _Groups_ cluster) or when adding the light ID to the group resource (using the API), the sensor controls the light as it would when setup using the Trådfri hub.

Because technically group commands are broadcasts, the gateway device receives these as well. It dissects the command, updating the sensor resource's state and config attributes from the Zigbee parameters:

  • state.presence is set to true;
  • state.dark is set to false when _Accept only when on_ has been set, and true when it hasn't. So when the sensor is in _Day_ mode, state.dark will be true always;
  • config.delay is set to the _On Time_ parameter;
  • config.group is set to the group ID that the command was sent to.

So state.dark is updated only when the "sensor" "reports" motion. And the new model only "reports" motion once every three minutes.

Because the sensor doesn't send any message when it no longer detects motion, the REST API plugin courteously resets state.presence to false. It should do so after config.delay seconds, so that state.presence matches the state of the lights. Unfortunately, user settable config.duration overrides the config.delay value, causing all sorts of issues. When set too short, it resets state.presence before the sensor is capable of sending another command. Best set config.duration to 0, so the API plugin uses config.delay instead.

As I understand, Phoscon, unlike the old web app, doesn't support the bound group (apparently it's too confusing). Instead, it "plays sensor" with the controller. It creates rules to control the lights (through a group), based on changes to state.presence. That will work only when the rules consider both state.presence and state.dark, and when config.duration is set to 0. Neither is the case with the sensors and rules you've listed above.

The Hue motion sensor works very differently from the Trådfri motion sensors. It is a proper sensor, in that it reports motion using a server _Occupancy Sensing_ cluster, instead of controlling lights using a client _On/Off_ cluster. It has three sensitivity levels (the outdoor sensor even has five), settable over Zigbee and supported by the API. It also reports when it no longer detects motion. The threshold for that is settable through the _PIR Occupied to Unoccupied Delay_ attribute, which the API exposes as (read/write) config.delay. So there's no need for config.duration. Also, the Hue motion sensor reports the light level (through the server _Illuminance Measurement_ cluster). The API translates this state.lightlevel to state.lux, state.dark and state.daylight. For the latter, config.tholddark and config.tholdoffset define the thresholds, so you can define yourself when there's "enough" light.

On the downside, the Hue motion sensor is useless when deCONZ is down, as it cannot control lights directly, without help from the gateway. Oddly, it does carry the needed clusters for that on endpoint 0x01, but we haven't been able to bring those to use.

All 14 comments

Note that the Trådfri motion sensor isn't a sensor proper; it acts as a controller. state.dark is updated from the _Only when On_ parameter to the _On with Timed Off_ command that the device sends when it detects motion. Note that after sending the command, the new model will wait close to three minutes before sending another command.

The sensor button day/night work like this:

If set to night - works only at night
If set to day - works day and night

if it's day and the sensor is set to "night" it should not trigger. If set to "day" and its actually day it will trigger, it will also triger during night. So, you can only control, if you want to work during the day or not, at nights its always working.

There was a good manual I cant find right now to share.

edit:

OK, I found the manual. Check page 21-22-23
https://www.ikea.com/de/de/assembly_instructions/tradfri-funk-bewegungsmelder__AA-2140125-1_pub.pdf

Note that the Trådfri motion sensor isn't a sensor proper; it acts as a controller. state.dark is updated from the _Only when On_ parameter to the _On with Timed Off_ command that the device sends when it detects motion. Note that after sending the command, the new model will wait close to three minutes before sending another command.

Sorry Im not 100pct sure what to make of this reply other than im screwed with the IKEA sensors. Since there’s another issue which I think is closely related to your replay of the sensors not being real sensors, see 2 below, I do think I will use my return option as long as its there and get Hue motion sensors which the expectance that they will work better.

1) Will the Hue sensors allow better timing and also only triggering when the room is NOT lighted by ambient or other lights? The manual does say so...

2) The switch override as _advertised_ in the PHOSCON doc does not work with the TRADFRI motion sensors - as soon as there is a trigger, the lamps will go into their motion scheme and turn off even if I had them switched on by a switch with the checkmark set in Phoscon.

The sensor button day/night work like this:

If set to night - works only at night
If set to day - works day and night

if it's day and the sensor is set to "night" it should not trigger. If set to "day" and its actually day it will trigger, it will also triger during night. So, you can only control, if you want to work during the day or not, at nights its always working.

There was a good manual I cant find right now to share.

edit:

OK, I found the manual. Check page 21-22-23
https://www.ikea.com/de/de/assembly_instructions/tradfri-funk-bewegungsmelder__AA-2140125-1_pub.pdf

Thanks - the main question I do not understand is just how the sensor detects day and night. If its ambient lighting (?), It does not seem to react on the ceiling light being on, either due to wavelength issues or something else...

FWIW: Is there an in between in pricing with solid function? IKEA is 10€, Hue is 35€ - thats gonna hurt....

Sorry for the amount of posts. I managed to check some more...The dark state may be false, but hardly reproducible, only by direct light to the sensor by a flashlight. Even then, when dark : false, the sensor and the group connected via Phoscon triggers! ...Seems to be a threshold issue here. Additionally, theres a lot of clutter in REST. I have the sensor call attached with the groups related to the single motion detector. I wonder about..
1) the setup with the groups obviously created by Phoscon
2) the duration being 12 (seconds?) which seems very short compared to what I read on other issues with the sensors

Any insights here?

"2": {
    "config": {
      "alert": "none",
      "battery": 100,
      "delay": 180,
      "duration": 12,
      "group": "3",
      "on": true,
      "reachable": true
    },
    "ep": 1,
    "etag": "20e642b3ebe54acbabcb39a2fea5f385",
    "lastseen": "2020-09-11T20:03Z",
    "manufacturername": "IKEA of Sweden",
    "modelid": "TRADFRI motion sensor",
    "name": "Melder Bad",
    "state": {
      "dark": true,
      "lastupdated": "2020-09-11T20:03:26.753",
      "presence": false
    },
    "swversion": "2.0.022",
    "type": "ZHAPresence",
    "uniqueid": "58:8e:81:ff:fe:2e:9c:97-01-0006"
  },
  "4": {
    "config": {
      "duration": 60,
      "on": true,
      "reachable": true
    },
    "etag": "099b0a1aa80ca56c16bec5b458ea4952",
    "manufacturername": "Phoscon",
    "modelid": "PHOSCON_VPIR",
    "name": "VPIR Bewegung Bad",
    "state": {
      "lastupdated": "2020-09-11T20:05:19.056",
      "presence": false
    },
    "swversion": "1.0",
    "type": "CLIPPresence",
    "uniqueid": "vpir-1599765256710"
  },
  "5": {
    "config": {
      "on": true,
      "reachable": true
    },
    "etag": "099b0a1aa80ca56c16bec5b458ea4952",
    "manufacturername": "Phoscon",
    "modelid": "PHOSCON_FSM_STATE",
    "name": "FSM_STATE Bewegung Bad",
    "state": {
      "lastupdated": "2020-09-11T20:05:19.056",
      "status": -1
    },
    "swversion": "1.0",
    "type": "CLIPGenericStatus",
    "uniqueid": "fsm-state-1599765256710"
  },

And some more digging into rules...Sensor 4 and 5 seem to be virtual. Those trigger the lights group and get set by sensor 2 which the the physical. The dark attribute, however, is never used. Thus, the motion sensor supplies an attribute which should stop deconz from turning on the group, but it is not handled. Thus, regardless of dark : false the group turns on.

I cant be the first reporting this...What am I doing wrong? Rules GET below with group two connections (this is the group in question...)

"8": {
    "actions": [
      {
        "address": "/sensors/5/state",
        "body": {
          "status": 1
        },
        "method": "PUT"
      },
      {
        "address": "/groups/2/action",
        "body": {
          "on": true
        },
        "method": "PUT"
      },
      {
        "address": "/groups/2/action",
        "body": {
          "bri": 191,
          "on": true,
          "transitiontime": 20
        },
        "method": "PUT"
      }
    ],
    "conditions": [
      {
        "address": "/sensors/1/state/daylight",
        "operator": "eq",
        "value": "false"
      },
      {
        "address": "/sensors/5/state/status",
        "operator": "gt",
        "value": "-1"
      },
      {
        "address": "/sensors/4/state/lastupdated",
        "operator": "dx"
      },
      {
        "address": "/sensors/4/state/presence",
        "operator": "eq",
        "value": "true"
      }
    ],
    "created": "2020-09-10T19:14:16",
    "etag": "7a250f66e83d4e97422103cf3a1476a9",
    "lasttriggered": "2020-09-11T20:19:57",
    "name": "pir-fsm-state-start",
    "owner": "618457B954",
    "periodic": 0,
    "status": "enabled",
    "timestriggered": 121
  },
  "11": {
    "actions": [
      {
        "address": "/sensors/5/state",
        "body": {
          "status": 3
        },
        "method": "PUT"
      },
      {
        "address": "/groups/2/action",
        "body": {
          "on": false
        },
        "method": "PUT"
      }
    ],
    "conditions": [
      {
        "address": "/sensors/5/state/status",
        "operator": "eq",
        "value": "2"
      },
      {
        "address": "/config/localtime",
        "operator": "dx"
      },
      {
        "address": "/sensors/5/state/status",
        "operator": "stable",
        "value": "PT00:01:28"
      }
    ],
    "created": "2020-09-10T19:14:16",
    "etag": "7a250f66e83d4e97422103cf3a1476a9",
    "lasttriggered": "2020-09-11T20:16:37",
    "name": "pir-fsm-state-dimm2",
    "owner": "618457B954",
    "periodic": 0,
    "status": "enabled",
    "timestriggered": 16
  },
  "12": {
    "actions": [
      {
        "address": "/sensors/5/state",
        "body": {
          "status": 2
        },
        "method": "PUT"
      },
      {
        "address": "/groups/2/action",
        "body": {
          "bri": 127,
          "transitiontime": 100
        },
        "method": "PUT"
      }
    ],
    "conditions": [
      {
        "address": "/sensors/5/state/status",
        "operator": "eq",
        "value": "1"
      },
      {
        "address": "/config/localtime",
        "operator": "dx"
      },
      {
        "address": "/sensors/5/state/status",
        "operator": "stable",
        "value": "PT00:00:32"
      },
      {
        "address": "/sensors/4/state/presence",
        "operator": "eq",
        "value": "false"
      }
    ],
    "created": "2020-09-10T19:14:16",
    "etag": "7a250f66e83d4e97422103cf3a1476a9",
    "lasttriggered": "2020-09-11T20:18:48",
    "name": "pir-fsm-state-dimm1",
    "owner": "618457B954",
    "periodic": 0,
    "status": "enabled",
    "timestriggered": 56
  },
 "16": {
    "actions": [
      {
        "address": "/sensors/4/state",
        "body": {
          "presence": false
        },
        "method": "PUT"
      },
      {
        "address": "/sensors/5/state",
        "body": {
          "status": -1
        },
        "method": "PUT"
      }
    ],
    "conditions": [
      {
        "address": "/groups/2/state/any_on",
        "operator": "ddx",
        "value": "PT00:00:04"
      },
      {
        "address": "/groups/2/state/any_on",
        "operator": "eq",
        "value": "false"
      },
      {
        "address": "/sensors/5/state/status",
        "operator": "stable",
        "value": "PT00:00:05"
      },
      {
        "address": "/sensors/5/state/status",
        "operator": "gt",
        "value": "0"
      }
    ],
    "created": "2020-09-10T19:14:54",
    "etag": "7a250f66e83d4e97422103cf3a1476a9",
    "lasttriggered": "2020-09-11T20:12:17",
    "name": "pir-fsm-reset-after-off",
    "owner": "618457B954",
    "periodic": 0,
    "status": "enabled",
    "timestriggered": 60
  },
  "17": {
    "actions": [
      {
        "address": "/sensors/4/state",
        "body": {
          "presence": false
        },
        "method": "PUT"
      },
      {
        "address": "/sensors/5/state",
        "body": {
          "status": -1
        },
        "method": "PUT"
      }
    ],
    "conditions": [
      {
        "address": "/groups/2/state/any_on",
        "operator": "eq",
        "value": "false"
      },
      {
        "address": "/sensors/5/state/status",
        "operator": "eq",
        "value": "-3"
      }
    ],
    "created": "2020-09-10T19:14:54",
    "etag": "7a250f66e83d4e97422103cf3a1476a9",
    "lasttriggered": "2020-09-10T19:35:44",
    "name": "pir-fsm-reset-after-off-master",
    "owner": "618457B954",
    "periodic": 0,
    "status": "enabled",
    "timestriggered": 1
  },

The Trådfri motion sensor isn't a proper sensor; it's a controller. It controls bound lights directly, without involvement of the Trådfri hub. When it detects motion, it sends an _On with Timed Off_ command. This causes the lights to turn on, and turn off automatically, after the specified time (in the _On Time_ parameter). On the old model, this time could be set using the dial, on the new model, it's fixed to 3 minutes. The sensor does not send a message when it no longer detects motion. The sensor will only send a second message that it still (or again) detects motion, shortly before the lights would turn off. When the device is set to _Night_ mode, and there is enough light, it sets the _Accept only when on_ parameter. This causes the bound lights to ignore the command, unless they're already on. So the "sensor" does "trigger" always, irrespective of _Day_ vs _Night_ setting and the amount of light it detects.

You can issue the _On with Timed Off_ command manually from the GUI, to familiarise yourself with how it works.
Screenshot 2020-09-12 at 00 07

Upon pairing a Trådfri motion sensor, the REST API plugin creates a group and binds the client _On/Off_ cluster to this group. This causes the sensor to send the _On with timed off_ commands to the bound group. When adding that group to a light (using the Zigbee _Groups_ cluster) or when adding the light ID to the group resource (using the API), the sensor controls the light as it would when setup using the Trådfri hub.

Because technically group commands are broadcasts, the gateway device receives these as well. It dissects the command, updating the sensor resource's state and config attributes from the Zigbee parameters:

  • state.presence is set to true;
  • state.dark is set to false when _Accept only when on_ has been set, and true when it hasn't. So when the sensor is in _Day_ mode, state.dark will be true always;
  • config.delay is set to the _On Time_ parameter;
  • config.group is set to the group ID that the command was sent to.

So state.dark is updated only when the "sensor" "reports" motion. And the new model only "reports" motion once every three minutes.

Because the sensor doesn't send any message when it no longer detects motion, the REST API plugin courteously resets state.presence to false. It should do so after config.delay seconds, so that state.presence matches the state of the lights. Unfortunately, user settable config.duration overrides the config.delay value, causing all sorts of issues. When set too short, it resets state.presence before the sensor is capable of sending another command. Best set config.duration to 0, so the API plugin uses config.delay instead.

As I understand, Phoscon, unlike the old web app, doesn't support the bound group (apparently it's too confusing). Instead, it "plays sensor" with the controller. It creates rules to control the lights (through a group), based on changes to state.presence. That will work only when the rules consider both state.presence and state.dark, and when config.duration is set to 0. Neither is the case with the sensors and rules you've listed above.

The Hue motion sensor works very differently from the Trådfri motion sensors. It is a proper sensor, in that it reports motion using a server _Occupancy Sensing_ cluster, instead of controlling lights using a client _On/Off_ cluster. It has three sensitivity levels (the outdoor sensor even has five), settable over Zigbee and supported by the API. It also reports when it no longer detects motion. The threshold for that is settable through the _PIR Occupied to Unoccupied Delay_ attribute, which the API exposes as (read/write) config.delay. So there's no need for config.duration. Also, the Hue motion sensor reports the light level (through the server _Illuminance Measurement_ cluster). The API translates this state.lightlevel to state.lux, state.dark and state.daylight. For the latter, config.tholddark and config.tholdoffset define the thresholds, so you can define yourself when there's "enough" light.

On the downside, the Hue motion sensor is useless when deCONZ is down, as it cannot control lights directly, without help from the gateway. Oddly, it does carry the needed clusters for that on endpoint 0x01, but we haven't been able to bring those to use.

FWIW: Is there an in between in pricing with solid function? IKEA is 10€, Hue is 35€ - thats gonna hurt....

IMHO, yes there is Aqara "motion" sensor which is about the price tag of Tradfri, but much smarter than it. Though not as good as Philips.

I have no first-hand experience with the Aqara motion sensor. It does not send a message when it no longer detects motion, so you need to use config.duration. Normally it only sends the next motion detected message after 60 to 90 seconds, but there’s a hardware mod to change that.

First of all - thank you for your patience and the detailed answer. I had an idea of how (and why not really good) the TRADFRI motion „devices“ work, but the very detailed explanation helps again.

That will work only when the rules consider both state.presence and state.dark, and when config.duration is set to 0.

While the latter is easily achieved, the rules come from PHOSCON. So a correct registration of ambient light cannot be easily achieved (via PHOSCON...)?
To be more clear: I got my motion „device“ so far that it shows dark : false, still a motion event will trigger the light. Im testing this by having the sensor under direct light and check REST. the lights are off, the last motion event is long ago. If I then trigger motion, I still get dark : false but the group turns on...

it "plays sensor" with the controller. It creates rules to control the lights (through a group), based on changes to state.presence.

This seems to be the reason an switch override for a motion controlled light is canceled with the first motion event, which is not how it is stated on the PHOSCON documentation. Can this be fixed? Is this something for a new issue? Currently, TRADFRI motion and switches in the same group will not work as expected I guess.

FWIW: Is there an in between in pricing with solid function? IKEA is 10€, Hue is 35€ - thats gonna hurt....

IMHO, yes there is Aqara "motion" sensor which is about the price tag of Tradfri, but much smarter than it. Though not as good as Philips.

Thank you for the idea. Since there are again some issues to be expected, I tend to bite the bullet and get Hues instead of having more trouble.

I switched to Hue and most of the issues are resolved. Some of the question above persists if anyone has an idea...

As there hasn't been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

As there hasn't been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it isn't solved, request to get this opened again.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mathos77 picture mathos77  Â·  100Comments

plum59 picture plum59  Â·  104Comments

rtenklooster picture rtenklooster  Â·  116Comments

smartypantsuk picture smartypantsuk  Â·  239Comments

PremiumUsername picture PremiumUsername  Â·  500Comments