Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TRADFRI Motion sensor dark function #3247

Closed
max3-2 opened this issue Sep 11, 2020 · 14 comments
Closed

TRADFRI Motion sensor dark function #3247

max3-2 opened this issue Sep 11, 2020 · 14 comments

Comments

@max3-2
Copy link

max3-2 commented Sep 11, 2020

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

@ebaauw
Copy link
Collaborator

ebaauw commented Sep 11, 2020

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.

@morfei1
Copy link

morfei1 commented Sep 11, 2020

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

@max3-2
Copy link
Author

max3-2 commented Sep 11, 2020

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.

@max3-2
Copy link
Author

max3-2 commented Sep 11, 2020

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...

@max3-2
Copy link
Author

max3-2 commented Sep 11, 2020

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

@max3-2
Copy link
Author

max3-2 commented Sep 11, 2020

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"
  },

@max3-2
Copy link
Author

max3-2 commented Sep 11, 2020

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
  },

@ebaauw
Copy link
Collaborator

ebaauw commented Sep 11, 2020

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.

@morfei1
Copy link

morfei1 commented Sep 12, 2020

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.

@ebaauw
Copy link
Collaborator

ebaauw commented Sep 12, 2020

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.

@max3-2
Copy link
Author

max3-2 commented Sep 12, 2020

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.

@max3-2
Copy link
Author

max3-2 commented Sep 17, 2020

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

@stale
Copy link

stale bot commented Oct 11, 2020

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.

@stale stale bot added the stale label Oct 11, 2020
@stale
Copy link

stale bot commented Oct 18, 2020

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.

@stale stale bot closed this as completed Oct 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants