IKEA Trådfri motion sensor detection

[kabal00]

Hi all,

I have a strange behavior of my IKEA Trådfri motion sensor which has been perfectly synchronized with the deConz software (installed on raspberry pi 3B+). But after a motion has been detected all of my bulbs within deconz will be shown as triggered (ON), but they are definitely OFF. The bulbs are from OSRAM and IKEA and I am using Homebridge which works great, except this issue.

Does anybody know what I need to do?

Thanks in advance

[Cybersmurfen]

I got the same behaviour. All lights shows on when a motion is detected.

It is the new waterproof detector - FW: 2.0.022 - the old detectors runs FW: 1.2.214

[Cybersmurfen]

Well. I deleted the Trådfri sensor from deconz. If I don't reset the sensor it will keep triggering all lights.

[avakarev]

I have issues with new model of motion control too.
The old model E1525 (2017) is fine
The new model E1745 (2019, IP44) cause deconz to report bulbs are on while they are off. Also deconz doesn't report motion events following the first "presense: true" till "presense: false".

[ebaauw]

Maybe the new model sends different ZigBee commands/command parameters? It’s definitely different hardware, no dials, no duration setting, but a 30% vs 100% brightness setting. Do you have the sensor on Day or on Night setting?

[avakarev]

@ebaauw Hard to say if it's on Day or on Night, there is no indicator anymore on the back. Now there is just a toggliing button, and I think it's supposed to be indicated by gateway/app what's the current settings (and it doesn't indicate it for a moment). In my case, it's set by default, I didn't modify it. The older E1525 has default mode is set to "on Day". Here is how back side looks of E1745 now:

[avakarev]

@ebaauw This is how response of GET /sensors/<id> looks like:

{ config:
      { alert: 'none',
        battery: 87,
        delay: 180,
        duration: 60,
        on: true,
        reachable: true },
     ep: 1,
     etag: '32101bc3e3b2992cb8f7efd5e68cb04d',
     manufacturername: 'IKEA of Sweden',
     modelid: 'TRADFRI motion sensor',
     name: 'Bathroom Motion Sensor R',
     state:
      { dark: true,
        lastupdated: '2019-07-14T21:08:45',
        presence: false },
     swversion: '2.0.022',
     type: 'ZHAPresence',
     uniqueid: '14:b4:57:ff:fe:52:3c:3a-01-0006' }

[Cybersmurfen]

@avakarev - if you push the toggle button once, the sensor shows if it is day or night with a small red indicator just next to the button. If you push it again it changes mode.

[ebaauw]

Hard to say if it's on Day or on Night, there is no indicator anymore on the back. Now there is just a toggliing button

The IKEA "manual" seems to suggest there's a LED that lights up. Maybe I'm too optimistic reading it.

This is how response of GET /sensors/ looks like:

Thanks. Some observations:

• Unsurprisingly, it has the same manufacturer name and model (or the REST API plugin wouldn't have exposed it already).
• config.delay is consistent with the fixed duration of 3 minutes from the manual.
• What really worries me is the lack of a config.group, suggesting the sensor hasn't been bound to one. The old model would select a random group on reset and send groupcast commands by default, but apparently this model sends a broadcast by default (which causes deCONZ to mark all lights as on). But somehow the lights themselves don't turn on...
• state.dark is true which means that either:
  • The sensor is on Day mode;
  • The sensor is on Night mode, and it's actually dark enough to turn on the lights.

Can you try the following:

• In the GUI, bind the client OnOff cluster of the motion sensor to a group. Trigger the motion sensor and check that config.group is created.
• Run deCONZ with --dbg-aps=2 and observe the logfile for something like:

  Jul 15 12:09:00 pi1 deCONZ[1121]: 12:09:00:346 APS-DATA.indication srcAddr: 0xe9b9, srcEp: 0x01 dstAddrMode: 1, profile: 0x0104, cluster: 0x0006, lqi: 255, rssi: -55
  Jul 15 12:09:00 pi1 deCONZ[1121]: 12:09:00:346 	asdu: 0162420058020000
  Jul 15 12:09:00 pi1 deCONZ[1121]: 12:09:00:347 button 1002 On with timed off
  

  The asdu means the following:

  0162420058020000
      | | |   + 0x0000: _Off Wait Time_: 0.0s
      | | + 0x0258: _Timed Off_: 60.0s (i.e. `state.delay` ==> 60)
      | + 00: _Accept only when on_ is not set (i.e. `state.dark` ==> `true`)
      + command: 0x42: _On With Timed Off_
  

• Add a light to the group, and see if the motion sensor will control it. Even if the light won't turn on, the REST API plugin should only mark the light(s) in the group as on, instead of all lights.

[tubalainen]

Hard to say if it's on Day or on Night, there is no indicator anymore on the back. Now there is just a toggliing button

The IKEA "manual" seems to suggest there's a LED that lights up. Maybe I'm too optimistic reading it.

This is how response of GET /sensors/ looks like:

Thanks. Some observations:

• Unsurprisingly, it has the same manufacturer name and model (or the REST API plugin wouldn't have exposed it already).

• config.delay is consistent with the fixed duration of 3 minutes from the manual.

• What really worries me is the lack of a config.group, suggesting the sensor hasn't been bound to one. The old model would select a random group on reset and send groupcast commands by default, but apparently this model sends a broadcast by default (which causes deCONZ to mark all lights as on). But somehow the lights themselves don't turn on...

• state.dark is true which means that either:

  • The sensor is on Day mode;
  • The sensor is on Night mode, and it's actually dark enough to turn on the lights.

Can you try the following:

• In the GUI, bind the client OnOff cluster of the motion sensor to a group. Trigger the motion sensor and check that config.group is created.

• Run deCONZ with --dbg-aps=2 and observe the logfile for something like:

  Jul 15 12:09:00 pi1 deCONZ[1121]: 12:09:00:346 APS-DATA.indication srcAddr: 0xe9b9, srcEp: 0x01 dstAddrMode: 1, profile: 0x0104, cluster: 0x0006, lqi: 255, rssi: -55
  Jul 15 12:09:00 pi1 deCONZ[1121]: 12:09:00:346 	asdu: 0162420058020000
  Jul 15 12:09:00 pi1 deCONZ[1121]: 12:09:00:347 button 1002 On with timed off
  

  The asdu means the following:

  0162420058020000
      | | |   + 0x0000: _Off Wait Time_: 0.0s
      | | + 0x0258: _Timed Off_: 60.0s (i.e. `state.delay` ==> 60)
      | + 00: _Accept only when on_ is not set (i.e. `state.dark` ==> `true`)
      + command: 0x42: _On With Timed Off_
  

• Add a light to the group, and see if the motion sensor will control it. Even if the light won't turn on, the REST API plugin should only mark the light(s) in the group as on, instead of all lights.

Hi! Can confirm that the new IKEA sensor is behaving oddly. It does not create the config.group and "ghosts" all lights in deconz to "ON" on motion detected. Ive tried the @ebaauw way described above with no success.

How ever, can confirm that the sensor is VASTLY more sensitive than the old one. Hoping for a solution. <3

[avakarev]

@ebaauw

The IKEA "manual" seems to suggest there's a LED that lights up. Maybe I'm too optimistic reading it.

I can confirm the back side shows the state and it was on Day mode.

Unfortunately I don't have the access to conbee stick / deconz at the moment so can't provide the logfile / debug output. Hopefully some users of E1745 sensor can help with that.

@ebaauw Thank you for your involvement and attempt to help!

[Ergerbolt]

Hi there,

same problem for me. Exactly same behavior.

[JustAnotherUserName87]

Hi,

I have the same problem. Unfortunately I only have the newer sensor.

[LJSven]

Same here!

[Michaelnorge]

same here!

[ebaauw]

Made my semi-annual trip to IKEA this weekend, because I needed some new batteries and I long wanted to try the outlet with on/off switch. Unfortunately, the motion sensors were sold out completely, both old and new model. So I got a SYMFONISK instead...

Still waiting on the FYRTUR, so I might actually visit them again by the end of the month.

[Michaelnorge]

I have arround 20 Trådfri plug sockets.
I synchronized two of the new motion sensors from Trådfri and got the same problems like described here.

Even after deleting the motion sensors the items keep turning on my lights.
I needed to reset them.

After that almost all of my plug sockets were offline. I needed to resynch them.

I don´t think that there is someone who will fix this problem.
The first entry here is about a month ago and still nothing happend...
Bummer! :-(

[ebaauw]

Even after deleting the motion sensors the items keep turning on my lights.

That is to be expected. The motion sensor sends a broadcast command to turn on all lights. This works without any interference from deCONZ, so removing the motion sensor from deCONZ won't change this. You need to remove the motion sensor from the network (by resetting the motion sensor).

I needed to reset them.
After that almost all of my plug sockets were offline. I needed to resynch them.

Again, this is to be expected. When you reset the sockets, they are removed from the network.

I don´t think that there is someone who will fix this problem.
The first entry here is about a month ago and still nothing happend...

Becasue no-one has provided the info we need to fix it. To gather the info myself, I need the device...

[tubalainen]

Even after deleting the motion sensors the items keep turning on my lights.

That is to be expected. The motion sensor sends a broadcast command to turn on all lights. This works without any interference from deCONZ, so removing the motion sensor from deCONZ won't change this. You need to remove the motion sensor from the network (by resetting the motion sensor).

I needed to reset them.
After that almost all of my plug sockets were offline. I needed to resynch them.

Again, this is to be expected. When you reset the sockets, they are removed from the network.

I don´t think that there is someone who will fix this problem.
The first entry here is about a month ago and still nothing happend...

Becasue no-one has provided the info we need to fix it. To gather the info myself, I need the device...

I can provide the info needed (I hope...), just tell me what you need. Screendumps of info, debug?

//T

[ebaauw]

See #1676 (comment)

[triumvirrr]

@ebaauw
I tried the suggested steps.

1. I am sorry, but I did not entirely understand the first step, what to do exactly and where to look for config.group. Probably I need the GUI for this? My Raspberry runs headless at the moment.

2. My sensor sends the folllowing command when motion is detected:
   09:20:11:389 APS-DATA.indication srcAddr: 0x98be, srcEp: 0x01 dstAddrMode: 1, profile: 0x0104, cluster: 0x0006, lqi: 103, rssi: -78
   09:20:11:389 asdu: 011a420008070000

3. Binding the sensor to a group of lights does not change its behaviour, still all lights are ghost-on after a movement.

I will happily make further tests, especially test 1, with your guidance.

[ebaauw]

Ad 2. I assume the sensor is on Day mode, and it’s light enough? This is the expected On with timed off command, with Accept only when On cleared and a 3-minute timed off. Same as the old motion sensor, I don’t understand why the lights don’t respond. Must be something special with the group. I’m not sure if that can be seen in the log, I probably need ZigBee sniffing output.

How did you bind the sensor for 3 if you don’t understand 1? Yes, you need the GUI for this.

[triumvirrr]

Yes, the example was in day mode with sufficient light.

Coming back to your test #1:
I do not understand what you mean with "the client OnOff cluster of the motion sensor" and I do not know where to look for config.group. Could you assist me with some hints?
Test #3 could be done via the web interface.

Just to be clear:
The issue is not, that the lights do not go on.
The issue is, that ALL the lights, regardless of their configuration regarding the motion sensor (in my case mostly a bunch of Osram Smart+ Plugs) are marked as on, although they (probably) are not. In fact, they keep the physical state as before but are shown to be on for 1 minute. This false state is then also passed on to Openhab which causes quite some mess.

I have collected further logs, perhaps they are useful:
Night mode:
16:48:41:728 APS-DATA.indication srcAddr: 0x98be, srcEp: 0x01 dstAddrMode: 1, profile: 0x0104, cluster: 0x0006, lqi: 247, rssi: -60
16:48:41:728 asdu: 0130420108070000
...
16:49:49:015 aps request id: 214 prf: 0x0000 cl: 0x0031 timeout (confirmed: 1) to 0x000D6FFFFE45ADBA (0x98BE)
16:49:49:094 aps request id: 214 finished, erase from queue

Night mode, light setting "dimmed" (instead of 100%) in the motion sensor:
16:55:04:344 APS-DATA.indication srcAddr: 0x98be, srcEp: 0x01 dstAddrMode: 1, profile: 0x0104, cluster: 0x0006, lqi: 111, rssi: -77
16:55:04:344 asdu: 0132420108070000
...
16:56:13:015 aps request id: 228 prf: 0x0000 cl: 0x0031 timeout (confirmed: 1) to 0x000D6FFFFE45ADBA (0x98BE)
16:56:13:095 aps request id: 228 finished, erase from queue

Additional information:
The sensor is shown with "power source: main" and has lost 13% of its battery in one day. I do not know if this is helpful or if it correlates to the problem.

[ebaauw]

I do not understand what you mean with "the client OnOff cluster of the motion sensor" and I do not know where to look for config.group. Could you assist me with some hints?

In the deCONZ GUI, you see the device's end points and clusters: blue for the server clusters and grey for the client clusters. You need to bind the client On/Off cluster 0x0006 to a group, using the Bind Dropbox panel. This is what it would look like for the old model:
.

Make sure to wave in front of the sensor to wake it, and press Bind. Wave again after half a minute or so to make the sensor (hopefully) send a command to the bound group, and the REST API should show config.group when GETting the /sensors resource. For the old model, it would be something like:

$ ph get /sensors/9
{
  "config": {
    "alert": "none",
    "battery": 34,
    "delay": 60,
    "duration": 60,
    "group": "3797",
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "45ba72f1e5fa02ab0e4cb28e7f83dff7",
  "manufacturername": "IKEA of Sweden",
  "modelid": "TRADFRI motion sensor",
  "name": "TRADFRI motion sensor ",
  "state": {
    "dark": true,
    "lastupdated": "2019-08-12T18:25:29",
    "presence": false
  },
  "swversion": "1.2.214",
  "type": "ZHAPresence",
  "uniqueid": "00:0b:57:ff:fe:22:cf:5f-01-0006"
}

The issue is not, that the lights do not go on.
The issue is, that ALL the lights, regardless of their configuration regarding the motion sensor (in my case mostly a bunch of Osram Smart+ Plugs) are marked as on, although they (probably) are not.

The issue is that the motion sensor sends a command that deCONZ thinks turns on all lights, but that the lights seem to ignore. This first part makes me thing it's a kind of broadcast command, which we hope to change to a groupcast by binding the sensor to a group. The second part is really interesting, but might not be an issue if don't need the sensor to control the lights directly, without using the gateway.

In fact, they keep the physical state as before but are shown to be on for 1 minute

I suppose until next polled by deCONZ, so the timing might differ per light and will depend on the number of lights in your network.

I have collected further logs, perhaps they are useful:

Cool. Yes they are. I think I managed to confuse myself once again. ASDU xxxx 42 00 0807 0000 is turning the lights on unconditionally (i.e. when the sensor in on Day, or when the sensor is on Night and it's dark); ASDU xxxx 42 01 0807 0000 is prolonging the on duration when the lights were already on, or does nothing when the lights were off (i.e. sensor is on Night, but it's not dark).

The really interesting part is that the same payload seems to be used for the Dimmed setting. Either the sensor sends another command after this one (I'd expect cluster 0x0008 or maybe 0x0005), or it uses another broadcast address (not visible in the log). I'm afraid this might be another IKEA special, similar to the way the remote handles changing colour or colour temperature.

The timeouts on the ZDP (profile 0x0000) requests are unrelated. This is deCONZ trying (and failing) to get some network info from the sensor.

[ebaauw]

Oh, and it would help to have the GUI screenshots of the new model. In particular: is it now an HA / Zigbee 3 device, like the On/Off switch, or still a ZLL device; and does it have an 0xFC7C cluster.

[BeamMeUpTo]

Hi all of you ;),

I will try to send additional information - so here first is the screenshot of the new ikea motion sensor from the deCONZ gui:

The Binding Dropbox is empty!

I would like to provide additional info about
ph get /sensors/9

but I have no clue what "ph" is! Please enlighten me!

Beam

[ebaauw]

here first is the screenshot of the new ikea motion sensor from the deCONZ gui:

Thanks. Some observations:

• This is yet another mac address prefix, which hasn't been whitelisted in the REST API code. Do you actually see the sensor in the API and/or Phoscon?
• It looks a lot like the on/off switch, including 0xFC7C IKEA cluster. I can only assume the Trådfri hub interacts with the cluster to configure the sensor;
• 0x0008 Level Control client cluster. This strengthens my suspicion that the sensor might issue Level Control commands when Dimmed is set.

The Binding Dropbox is empty!

Yes, you need to drag the 0x0008 cluster to the Source drop box and fill in the group ID manually.

I have no clue what "ph" is

Just a liitle tool I wrote to interact with the Hue/deCONZ API from the command line. It comes bundled with homebridge-hue. You can use curl instead, but then you have to specify the full URI (incl. host and username/apikey) and format the JSON yourself.

[triumvirrr]

Thanks, Eric.

Binding the sensor via GUI binding dropbox to an (in my case) empty group did the trick. No Ghost-Ons anymore. I also tested with a group with lights in it and they are switched as expected. And only the lights in the group are switched, es expected.

The problem is solved for me, thanks once again!

Note: Configuriong the sensor via we interface to work only for a group did NOT work.

Side effect: The group with the GUI-bound IKEA sensor is then not visible via Web Interface anymore.

The sensor itself is normally visible within all GUIs and the REST API.

Here is the sensor output via REST after binding it to group 6:

{
"config": {
"alert": "none",
"battery": null,
"delay": 180,
"duration": 60,
"group": "6",
"on": true,
"reachable": true
},
"ep": 1,
"etag": "26704aff65b268ca9d2b4aa67fc75963",
"manufacturername": "IKEA of Sweden",
"modelid": "TRADFRI motion sensor",
"name": "TRÅDFRI Bewegungsmelder",
"state": {
"dark": true,
"lastupdated": "2019-08-13T10:06:58",
"presence": true
},
"swversion": "2.0.022",
"type": "ZHAPresence",
"uniqueid": "00:0d:6f:ff:fe:45:ad:ba-01-0006"
}

[gloomytree]

Hi there,
i still have issues with the E1745 (2019, IP44). I can pair it without problems, after that it doesn't do anything. Phoscon says Status Not reachable.
I am running a Raspberry Pi 4 with RaspBee, HASS.io and the according deconz plugin. Version is 2.05.69, so i SHOULD be fine, according to this thread, Firmware is 26050500 (but i cannot update using the Phoscon GUI).

Can someone provide some insights? Need more info?

[wucherpfennig]

I am sorry to hijack this thread but as stated above hassio + deconz latest (2.05.69) works good BUT I noticed that there is a strange "cooldown" time of 60 seconds in which the sensor does not detect anything. Is this behaviour changeable?

[manup]

I am running a Raspberry Pi 4 with RaspBee, HASS.io and the according deconz plugin. Version is 2.05.69, so i SHOULD be fine, according to this thread, Firmware is 26050500 (but i cannot update using the Phoscon GUI).

That's a very old firmware which doesn't support devices like IKEA remote and sensor well.
I'd recommend to upgrade the firmware manually to the latest version 0x26330500 as described in https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually

[Korhm]

I am sorry to hijack this thread but as stated above hassio + deconz latest (2.05.69) works good BUT I noticed that there is a strange "cooldown" time of 60 seconds in which the sensor does not detect anything. Is this behaviour changeable?

I have the same behavior. Don’t know if it’s because of deCONZ or the motion sensor itself.
I’m also interrested of knowing how to avoid this « cooldown » time.

[manup]

Most likely the sensor prevents battery drain by not sending messages too often.

[gloomytree]

I am running a Raspberry Pi 4 with RaspBee, HASS.io and the according deconz plugin. Version is 2.05.69, so i SHOULD be fine, according to this thread, Firmware is 26050500 (but i cannot update using the Phoscon GUI).

That's a very old firmware which doesn't support devices like IKEA remote and sensor well.
I'd recommend to upgrade the firmware manually to the latest version 0x26330500 as described in https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually

Thanks, this saved me. Altough it was kind of difficult to upgrade the firmware via Hass.io / Hass.os, it now works like a charm.

[MacJawa]

Most likely the sensor prevents battery drain by not sending messages too often.

This kind of makes sense, but on the other hand, as per my experience, the sensor only waits 60 seconds after presence changed to true. Then it sends another update (after 60 seconds). Let's say the second update is presence = false. Then it does not send anything until another movement detected. I assume this behaviour based on "lastupdated" value. Therefore it probably does not send update every 60 seconds, but to be sure we need to monitor the network activity and this is above my actual skill :)
If I'm correct above, then if there is not so much movement, it will make sense to shorten the interval and still it will only send 2 updates. Or if battery drain is not a concern and one would like to have updates more often for the movement, it would be nice to have ability to set the interval to custom value.

So the question remains. Is it possible to set config.delay to custom value other then default 60?
Hopefully @ebaauw or @manup would clarify that.

[ebaauw]

The Trådfri motion sensor doesn’t send state updates (except for battery), and it doesn’t send anything when motion is no longer detected. It sends an On with Timed Off command to the bound group. This causes the lights in this group to turn on for the specified time. No need for a second message, and no need to report next/continued motion before that time has almost expired.

The deCONZ REST API plugin eavesdrops on the group command and sets state.presence, state.dark and config.delay accordingly. These REST attributes are read-only; the only way to “change” config.delay is to change the dial on the old model; on the new model it’s fixed to 180 seconds. The REST API plugin clears state.presence autonomously after config.duration (or, when that’s 0, config.delay) seconds, but this has nothing to do with the motion sensor. Note that the API was modelled after the Hue motion sensor, which works very differently. This sensor does send state updates, also when it no longer detects motion.

[MacJawa]

Thank you @ebaauw for further information. Unfortunately I still don't understand how motion sensor (new one) behaves when there is continous movement for let's say 5 minutes. Let me explain. I use OpenHab because I want to build more advanced rules, not only simple grouping. At first, I set simple rules:
When presence changes to True, turn on the lights. When presence changes to False, turn off the lights. I quickly found out this wouldn't work, because even I was moving in front of sensor, lights turned off after 60 seconds. They eventually turned on again, but only after I was jumping in front of sensor for a few moments. This is not good, right? So I changed my second rule like this: When presence changes to False, wait for 60 seconds, than check presence again and act. If presence is False, turn off the lights, otherwise let it be. But this is not good as well, because when I rush into kitchen for a cup of water and I leave in 10 seconds, my lights are turned on for 2 minutes, which is kind of wasted energy and not very smart. Of course I can lower the interval and check for presence again in 10 seconds after it changes to False, hoping the sensor will send the update meanwhile, but it's still one minute of wasted energy after I left the room.
But if that initial 60 seconds delay could be shortened to 20 seconds for example, this could solve the situation.

Back to beginning. You say that sensor only sends update when motion is detected. Does it then sleep for 60 seconds? Because according to log in openhab my presence state always changes to OFF exactly one minute after ON, regardless of the movement. Is this behaviour of the sensor or deconz API?
And finally, is it possible to turn off lights sooner after I leave the room (as I explained above) or is it impossible with this sensor?

Thank you for any ideas.

[ebaauw]

You say that sensor only sends update when motion is detected.

Strictly speaking, it sends a command to turn on lights, it doesn’t send a status update. But yes: only when it detects motion.

Does it then sleep for 60 seconds?

Sleep as in shuts down its ZigBee radio: yes. Sleep as in: won’t detect motion: I don’t know. Also I haven’t looked in detail, how far apart it sends commands under continuous motion, but for the new sensor, it seems closer to 180 seconds than 60 seconds.

Because according to log in openhab my presence state always changes to OFF exactly one minute after ON, regardless of the movement. Is this behaviour of the sensor or deconz API?

Again, state.presence is a REST API attribute that has no ZigBee equivalent for the Trådfri motion sensor. The REST API plugin resets it to false after config.duration seconds. If you set config.duration to 0, the REST API resets state.presence after config.delay seconds (the OnTime that the sensor specified with the On with Timed Off command). Personally, I would never have exposed config.duration for the Trådfri sensor, since it’s highly confusing and delay makes more sense if you use the sensor to control lights directly.

And finally, is it possible to turn off lights sooner after I leave the room (as I explained above) or is it impossible with this sensor?

A single motion sensor cannot detect when you leave a room. It detects motion, not presence. I actually use multiple motion sensor in adjacent rooms to detect leaving (motion in living room, motion in hallway, no more motion in living room => left the living room).

The granularity of the new Trådfri motion sensor is close to 3 minutes, i.e. you cannot infer no motion any sooner.

my lights are turned on for 2 minutes, which is kind of wasted energy and not very smart.

With LED based smart lights I wouldn’t worry about that. If you use a wired in-wall switch with tungsten or halogen lights, it’s maybe a different story - I’d replace them with (dumb) LED lights.

[oywino]

Excuse me for butting in. I tried to read this loooong thread, but somehow got lost in too many technical terms. I have two small questions:

1. Has the "problem" with ghost-on been solved by anyone?
2. I have the new model IKEA motion sensor paired with my ConBee II and integrated into HA 0.103.4
   When creating an automation, I get something called "duration" in the trigger section, with default value 00:00:00
   What is "duration", and how can I use it in an automation (what does it do and how does it work)?

[MacJawa]

Hi @oywino ,

let's think about IKEA motion sensor this way: When it detects movement, it sends to zigbee network command to turn on lights for a specific time. This specific time is the "duration" you mentioned. So if duration is set to 60 seconds (default if I'm not mistaken), then the motion sensor sends the command: hey lights, turn on for 60 seconds, then turn off.

That's it. There is no other message sent afterwards, just this one. No "turn off" message after 60 seconds or anything similar. Now deConz takes this message and set motion sensor "ON" for the duration time. Let's say it simulates the motion for a set duration. After that, when motion sensor detects movement, it sends another command to turn on lights. And this repeats.

What I did in OpenHab is this logic:

• when motion changes from False to True, I turn on lights.
• when motion changes from True to False (always after 60 seconds), I start the timer for another 30 seconds. After that time I check the motion status:
  • if status is True, I let the lights turned on and I wait for another OFF
  • if status is False, this means there was no movement for last 30 seconds and I turn off lights.

I recently build HomeAssistant besides my OpenHab instance and didn't try automation yet, but I will give it a try. I will eventually move all my autiomations to HA, so I will also check how it looks there. If you have more questions, don't hesitate to ask ;)

[ebaauw]

This specific time is the "duration" you mentioned.

No. The time is fixed to 3 minutes for the new model and set between 1 and 10 minutes using the dial on the old model. This value is reported by the REST API as config.delay.

What is "duration",

config.duration is used by the REST API plugin to reset state.presence to false automatically, after the given number of seconds. This is useful for motion sensors that don’t send a message when motion is no longer detected, but highly confusing for motion sensors that do (like the Hue motion sensor) or for motion sensors that send a On with Timed Off command on motion (like the Trådfri motion sensor). For the first type, you want to configure the PIR Occupied to Unoccupied Delay through config.delay (which is read/write for these). For the second type you want state.presence to become false automatically when the lights turn themselves off, i.e. after config.delay (which is read-only for these).

and how can I use it in an automation

You don’t. Since the REST API already resets state.presence automatically, you’d base your automation on that. If you want to set the duration yourself from your automation, best leave config.duration to 0.

When creating an automation, I get something called "duration" in the trigger section, with default value 00:00:00

That must be an HA thing; config.duration takes an integer value.

Note that motion sensors typically take some time to “recharge” after detecting motion. They won’t send another motion detected message during that period. If you set config.duration too short your automation might turn the lights off while there’s still (undetected) motion, and you’re left in the dark. This “recharge” period is hardwired in the sensor, but there is a mod for the Xiaomi motion sensor to shorten it. For the new model Trådfri motion sensor it’s close to the three-minute delay.

[oywino]

This is what it looks like in HA Automation UI. Whoever programmed this dialog must have had some purpose when he/she decided to include the duration timer?

[ebaauw]

Best ask the HA people.

[oywino]

Best ask the HA people.

I will. Thanks for taking the time to reply :)
Happy New Year

[vandalon]

I think HA triggers on motion detect and then applies own logic from that point on. So the duration is controller by HA and the stop motion trigger from the tradfri sensor is ignored.

[runevad]

This is what it looks like in HA Automation UI. Whoever programmed this dialog must have had some purpose when he/she decided to include the duration timer?

The duration is used as a criteria for removing false positives in the trigger. So the trigger only “goes through” if motion has been detected for example x minutes straight. Perhaps not as useful when using a sensor like this, but the duration criteria is there on several things in HA. More useful for other sensors to only trigger something. For example a door that has been opened or closed for x seconds or so.

[wes1993]

Hello!! Can someone know if there is a way to change the delay from 180 to 60 for example?
Thanks a lot
Stefano

[ebaauw]

The new model Trådfri motion sensor uses a fixed delay of 180 seconds. This is hard-coded in the sensor firmware. The old model has a user-configurable delay, between ~60 and ~600 seconds, using the dial on the sensor.

[gloomytree]

Hello!! Can someone know if there is a way to change the delay from 180 to 60 for example?
Thanks a lot
Stefano

You could try to reverse engineer the firmware.

[martinkrulltott]

Quick update for anyone experiencing the original issue.
I had the same issue as the OP, with the lights getting set to "ON" in Home Assistant when they're actually off. Using a Raspberry Pi and deconz, with IKEA bulbs and motion detector. These two solutions #1676 (comment) #1676 (comment) worked the first time it happened (6 months ago), but I recently changed the batteries in one of the motion sensors which seems to have triggered the issue to come back.

This time around I tried the same solution but without success, as the binding kept failing with failed: timeout. However, the trick seems to be to leave the motion sensor for a while (without triggering it) and only walk past it / trigger it when you've pushed the bind button. My best I guess there's a throttle on how often the motion sensor sends messages so if you walk past it too soon / too often, the bind command might miss the communication slot.
With the bind success the issue is now resolved again 🙂

[martinkrulltott]

My second sensor died a while back and I just changed the batteries. As soon as the pairing was done my lights started to turn on and off randomly and not responding to input properly. Once again I did the method outlined above and it worked ⬆️ 👍

[oywino]

I have read this tread and I am somewhat confused about all the issues reported - and the complexity of the advises given.
For me, using the "new" IKEA motion sensor with deConz was just as easy as using it with the IKEA HUB. And I never once had to visit deConz to get it working. I only used the Phoscon GUI.
Adding it to Phoscon was easy - just put it in pairing mode and search for it and Phoscon finds it right away.
Then I added the sensor to a room, and configured the trigger for on and off, and it immediately began to control all the lamps in the same room according to motion detection. And with Phoscon, it was easy to change the delay from 3 to 5 minutes.

Works for me!

[meros]

I just stumbled on this issue myself. I paired and configured the motion sensor without problems, but getting ghost 'ON' lights during usage. I tried binding the cluster to an empty group but when trying to do that I keep getting 'failed: table full'.

[meros]

I just stumbled on this issue myself. I paired and configured the motion sensor without problems, but getting ghost 'ON' lights during usage. I tried binding the cluster to an empty group but when trying to do that I keep getting 'failed: table full'.

I did a reset of the device, deleted in deconz and readded. After this, the binding command worked! :)

[thecobra666]

If I'm reading this right, the motion sensor can only trigger on day OR night, not both?