Deconz-rest-plugin: IKEA Trådfri Remote (and motion sensor)

[jsve]

IKEA has launched some more products in their Trådfri line. I have gotten the lights to work, but not remotes. They also have motion sensors now, which I guess will not work either.

de_web_plugin.cpp has a comment about IKEA remote not being supported yet. Is this because of the web-plugin of the core of deCONZ? Is there some work being put in to make this compatible?

I have managed to get the remote to show up in the deCONZ GUI and it has that blue indicator-dot that blinks when I push buttons. So something seems to be working at least. The logs (using --dbg-aps=2) shows the proper cluster being activated when i push the respective button, but there is nothing indicating if it was (for instance) brightness up or down that was pushed.

[manup]

Hi, in a few days we will release a new beta update which adds basic support for the Trådfri Remote in the REST API and realtime event notification in a new WebSocket interface. The button events can be used in rules to control lights and groups. We've made some tests with the Remote (firmware from 2016) and so far we haven't managed to find a stable way to join it into the gateway network — by pressing the setup button 4 times, sometimes it works, sometimes not. Hopefully the firmware will improve with the wider release.

We haven't testet the motion sensor yet, due the lack of a device, but expect support in the next few releases.

[jsve]

Awesome! My experiences with the remote is similar. Somehow it just pairs after a lot of tries. Not sure, but it seems to help if i spam the buttons shortly after the pair (or at the same time). Might just be a coincidence though.

Guess thats fine if you know about the issue. I think it would be OK if it was available in the web-gui as an option, but with the disclaimer that it might take a few tries.

Is there any way for me to test the beta when it comes out?

[manup]

Sure, you can download beta versions from https://www.dresden-elektronik.de/rpi/deconz/
the source code will be updated here too. Right now only stable version is kept here but we will provide a new branch (beta?) with the next beta release wich is in sync with the binary version.

Be aware that the next beta will only advance the REST API, not the WebApp itself. So using the IKEA switch and others is possible but a bit hacky.

[manup]

The beta is released now, with basic support for IKEA Trådfri motion sensor and remote control

https://github.com/dresden-elektronik/deconz-rest-plugin/releases

[yene]

Is it technically possible to talk directly to a light, or is always a remote required?

[manup]

Yes every light can be controlled directly through /lights REST API.
The remotes are just a further way to control them.

[binomie]

Hi, I managed to join the remotes, but how do i join a light. After joining the remotes to raspbee they don't join the lights by long press any more. I have the Tradfri LED E27 1000 lm.

[manup]

The lights need to be brought into the network first. If they were paired to the remote before you need to reset them. In case of IKEA lights they can be resettet with 6x on/off powercycle the light.

Or you can reset lights under Menu > Settings and then Scan for Devices > Reset.

After that bring the lights into the network as usual with Open Network. Once they are in the network you can pair them with the remote or simply put them in the remotes group.

[binomie]

Many thanks, worked well. I always tried to pair with 10 seconds press like Ikea mentions in their description, now i understood to open Network and then reset the light (6x on off) or button (4x press on back button).

In sensor.cpp i saw only two ikea sensors.
I have the dimmer as well:

IKEA Dimmer
On Youtube

DeCONZ does show it on the map, but it does not get a name and is not shown in the webinterface.
Is it not yet supported?

[manup]

Yes the integration into API will take some time and testing, the dimmer is more complicated to handle than for example the remote.

However since it's already in the network you can pair lights, which are also in the network, to it with the physical pairing button of the dimmer.

[ebaauw]

I couldn't resist and got myself a Trådfri light and remote. Both connect to deCONZ without any issues. The buttons on the remote cause WebSocket events, very nice! As far as I can tell, the value of /sensors/<id>/state/buttonevent matches the WebSocket notifications. I like that it uses similar buttonevent values to the Hue dimmer switch.

I do see some inconsistencies on the use of buttonevent, though:

1. When pressing the _On/Off_ button, a 1002 buttonevent is emitted. In Hue speak this would mean a release (after press) of the _On_ button. A press would bebuttonevent 1000. When holding or releasing the _On_ button, no additional events are emitted;
2. Similarly, when pressing the _Dim Up_ or _Dim Down_ button, a 2002 or 2003 buttonevent is sent. I'm not sure if this is linked to the press or to the release (after press), though. When holding the _Dim Up_ or _Dim Down_ button, a single 2001 or 3001 buttonevent is emitted. In this case, the Hue dimmer switch would emit 2000 or 3000 (on press) followed by series of 2001 or 3001 while holding the button. When releasing (after hold) the _Dim Up_ or _Dim Down_ button, a 2003 or 3003 buttonevent is sent, just like the Hue dimmer switch.
3. When releasing (after press) the _Next_ (right) or _Previous_ (left) button, a 5002 or 4002 buttonevent is emitted. Again, no equivalent 5000 or 4000. No event is emitted at all when pressing, holding, and releasing (after hold) these buttons. On the Hue dimmer switch, the 400x range is used for the _Off_ button. The Hue dimmer switch has no equivalent for _Next_ or _Previous_ buttons.

While the current behaviour seems to match the Trådfri remote's functionality as a standalone dimmer, I would like to get the same series of buttonevents as for the Hue dimmer: x000 and x002 for press/release, and x000, x001, ..., x001, x003 for press, hold, ..., hold, release. I'm not sure if this is technical feasible, though: the remote doesn't seem to have an equivalent cluster to the Hue dimmer switch's FC00.

[ebaauw]

Somehow it just pairs after a lot of tries. Not sure, but it seems to help if i spam the buttons shortly after the pair (or at the same time).

@jsve I don't think this is a coincidence. I find reading attributes from the Trådfri remote as well as from the Hue dimmer switches in the deCONZ GUI usually fails. Based on a remark by @manup in another thread, on battery-powered devices being mostly asleep, I started hitting a button while reading the attributes... with increased success rate (but still not 100% by far).

Probably related to this: The config for the Trådfri remote doesn't show battery. Some of my dimmer switches don't show battery. I did a clean installs for all.

[Hypfer]

I have 6 Tradfri remotes. Adding the first one to the network did work well. However, all the other remotes just get hex values as their names and never show up as remotes.

Why is that?

Update:

It seems that the network wasn't completely open for adding new nodes. I have no idea why.

However pressing "Scan for devices" and then 5 seconds later "Open Network" followed by factory resetting the remote and mashing its buttons did work.

[ebaauw]

I put the Trådfri light in the Trådfri remote group and it reacts to On/Off, Dim Up, and Dim Down. It doesn't react to the Previous and Next buttons, thought. When paired directly, the light changes it's colour temperature on these buttons. I finally managed to create a binding of the Scenes cluster (from the remote to the light), but that doesn't seem to change anything.

[philipptrenz]

Short question.
I'm on v2.04.35, pairing a Trådfri lamp worked fine. But I'm struggling with adding a remote. Do I have to upgrade? To which version, or even HEAD?
Thanks!

[manup]

https://github.com/dresden-elektronik/deconz-rest-plugin/releases

The remote has early support in the latest beta release version 2.04.40, it creates a group to which you can add lights. Currently only on/off and dimming works.

[ebaauw]

One of my users has a 1000lm Trådfri bulb, which deCONZ (v2.04.35) reports as On/Off light, even though it's dimmable:

{
  "etag": "f8679f2533edfc067b383abbc7bf34bf",
  "hascolor": false,
  "manufacturer": "IKEA of Sweden",
  "modelid": "TRADFRI bulb E27 opal 1000lm",
  "name": "Decken-Lampe",
  "pointsymbol": {},
  "state": {
    "alert": "none",
    "bri": 0,
    "effect": "none",
    "on": false,
    "reachable": true
  },
  "swversion": "1.1.1.0-5.7.2.0",
  "type": "On/Off light",
  "uniqueid": "00:0b:57:ff:fe:xx:xx:xx-01",
  "manufacturername": "IKEA of Sweden"
}

I noticed the ZigBee device ID for a ZHA On/Off light is the same as that for a ZLL Dimmable light. I suspect our Swedish friends think they use the ZLL device ID, but that gets interpreted differently on the ZHA endpoint?

[ebaauw]

On google, I found the location of the Trådfri firmware: http://fw.ota.homesmart.ikea.net/feed/version_info.json. I downloaded the files for my bulb and remote and renamed them to end with .zigbee, but the deCONZ OTAU plugin doesn't seem to recognise them. Is it at all possible to use deCONZ to upgrade the firmware of non-dresden-elektronik devices?

[manup]

I noticed the ZigBee device ID for a ZHA On/Off light is the same as that for a ZLL Dimmable light. I suspect our Swedish friends think they use the ZLL device ID, but that gets interpreted differently on the ZHA endpoint?

This is a HA/ZLL glitch in the ZigBee spec, I think they clarified that in the ZigBee 3.0 spec.

The new commit https://github.com/dresden-elektronik/deconz-rest-plugin/commit/f0f3e95c4083d0408acdc2e4c0724421d8b2a35a fixes the issue, IKEA bulbs now have proper type 'Dimmable light'.

Is it at all possible to use deCONZ to upgrade the firmware of non-dresden-elektronik devices?

Yes, the plugin just uses standard ZigBee OTA, It was already testet with OSRAM, Busch-Jaeger and JUNG/GIRA devices. However the OTA firmware files of these are not publicly available (yet).

The firmware files of IKEA are raw data, not packet into an standard OTA file format. So in order to use them the .zigbee format binary header must be put before the data payload as described in the spec. Right now it's not worth the efford, because the version referenced in the JSON file is only the 'old' shipped version (1.1.1.0-5.7.2.0). I guess you're looking for the new ZLL certified version ;-) to my knowledge it's not online yet.

Once it's online (and downloadable like the current version) I'll give it a go for an update test.

[ebaauw]

The remote has early support in the latest beta release version 2.04.40, it creates a group to which you can add lights. Currently only on/off and dimming works.

Still some issues in v2.04.46:

• config.battery is missing for the Trådfri remote;
• When you use the Trådfri remote with a group from the Web GUI, the light reacts as expected, but this is not reflected in the API light nor group state. Only when the light/group is polled, the API state gets updated. With the Hue dimmer switch, the API states are updated immediately;
• When I set ct for the Trådfri bulb to an unsupported value (e.g. "ct": 500), the API light state shows the requested value (500) instead of the actual value (454). Again, the state is only updated to the actual value on the next poll cycle. Not sure if this is specific for the Trådfri bulb or generic for deCONZ, but the Hue bridge immediately reflects the actual ct value for Philips Hue and OSRAM lights. However, for the xy value it doesn't. I still haven't setup ZigBee sniffing so I'm not sure if the command to set colour temperature returns the actual value or if the Hue bridge queries the light after sending the command.

[perler]

Ok, I am still a bit unclear. I can bind the Tradfri remote to the deConz gateway in a way that it appears in the app but not in the webui. How can I control devices now?

[manup]

Normally it should create a new group to which you can add lights in the webapp.

[perler]

it didn't.. but I added the switch in 2.0.35 (when support was not really there for it), is there a way to force/delete it first?

[manup]

Please try the following with a recent deCONZ version:

• in webapp settings open the network (I recommend 10 minutes, 1 might be too short)
• while the network is open remove the switch battery
• press large button a few times
• insert battery again
• press large button a few times more

It's a bit hacky but now a new sensor should be created in the API and the group should also be created.

[perler]

that didn't work unfortunately. I really would like to remove the device from deconz first. is there a db where I can simply delete it?

[manup]

Yes it's a SQLite database

.local/share/data/dresden-elektronik/deCONZ/zll.db

It can be edited with tools like sqliteman, deleting the file is also possible but this would discard lights and groups settings as well. The switch if present is listed under sensors.

While modifying the database deCONZ shall not run.

[perler]

I did a complete factory reset and this looks more and more like a bug to me.

the tradfri remote is visible in the GUI (it blinks blue (in the GUI)) when a battery is inserted but it is nowhere to be seen in the web gui and so no group is created and controlling devices with the remote is not possible.

[manup]

Can you please try out the new version 2.04.52, it should improve the discovery of the remote.

• open network in webapp settings (even if the remote is already on the network!)
• press large button on the remote
• after a few seconds there should be a new group in the webapp

http://www.dresden-elektronik.de/rpi/deconz/beta/deconz-2.04.52-qt5.deb

Further if this worked so far, please press the large button again for more than 5 seconds to finish setup for the arrow buttons (control color temperature).

[ebaauw]

Deleted the Trådfri remote resource through the API, deleted the node it from the deCONZ GUI, deleted the record (with status deleted) from the database, installed 2.04.52.

Opened the network through the Webapp, pressed the _On/Off_ button. The Trådfri remote appears as a node in deCONZ GUI. Another press or two and sensor resource is created. Read the attributes of the Basic and Power Configuration clusters in the deCONZ GUI, just to be sure. A group was created, and linked to the remote (through the group's devicemembership attribute and through the sensor's config.group attribute). I got web socket notifications for the creation of the sensor and for the buttonevents (1002, 2002, 2001/2003, 3002, 3001/3002, 4002, 5002), as expected.

Added the Trådfri bulb to the group. The light now changes colour temperature on the _Previous_ and _Next_ buttons! When changing the colour temperature, I even get two web socket notifications (as expected): one for the sensor state.buttonevent and one for the light state.ct.

Still some issues, though:

• The Trådfri remote still doesn't show under Devices in the Webapp;
• The light (and group) state.on and state.bri aren't updated on the _On/Off_, _DimUp_, or _DimDown_ buttons;
• The light state.ct reflects the value sent to the light, not the actual value of the light (e.g. it reports ct in the range of 153..500, where the Trådfri only supports ct of 250..454). When the light is polled, I receive a new event for the correct state.ct value.
• config.battery is still missing from the sensor resource.
• Probably more a caveat than an issue: The _Previous_ / _Next_ buttons react differently from when the remote is linked directly to the light: in that case, Ikea only support three values for ct and the value rotates (e.g. pressing Next on the max value switches over to the min value).

[manup]

Wow that was fast, thanks for testing :)

• The Trådfri remote still doesn't show under Devices in the Webapp;

Not in the current public one, we are very busy working on a complete new app (in development for about a year now) which includes several switches and sensors, which are currently only visible in the API. There will be a private beta soon to test these things out.

• The light (and group) state.on and state.bri aren't updated on the On/Off, DimUp, or DimDown buttons;

This is a general problem related to specific ZigBee commands of various remotes/switches which I want to address in the next days. The events for groups should also be improved by this.

• The light state.ct reflects the value sent to the light, not the actual value of the light (e.g. it reports ct in the range of 153..500, where the Trådfri only supports ct of 250..454). When the light is polled, I receive a new event for the correct state.ct value.

Yep currently its the hard coded 153..500 range (originated by first E27 hue bulbs), this will be changed to reflect the actual physical min. max. values reported by the lights.

• config.battery is still missing from the sensor resource.

Currently disabled and needs more testing, not sure if the remote supports ZCL attribute reporting for power configuration cluster as the hue dimmer switch does.

It's a quite fuzzy problem since many battery powered devices provide very different ways to report battery state, or even only battery critical events.

• Probably more a caveat than an issue: The Previous / Next buttons react differently from when the remote is linked directly to the light: in that case, Ikea only support three values for ct and the value rotates (e.g. pressing Next on the max value switches over to the min value).

That was made on purpose and is considered a feature :) since the original IKEA way only provides the 3 temperature settings, we decided it would be nicer to have finer smooth control as for brightness. The step size and fading time needs some tweaking though.

Later on we will provide an alternative mode to cycle through all scenes of the underlying group.

[ebaauw]

• Probably more a caveat than an issue: The Previous / Next buttons react differently from when the remote is linked directly to the light: in that case, Ikea only support three values for ct and the value rotates (e.g. pressing Next on the max value switches over to the min value).

That was made on purpose and is considered a feature :) since the original IKEA way only provides the 3 temperature settings, we decided it would be nicer to have finer smooth control as for brightness. The step size and fading time needs some tweaking though.

I see you created rules for the _Previous_ and _Next_ buttons, instead of using a direct binding between the Trådfri Remote and the group. I understand that this is needed for non-Trådfri bulbs. However, now when deCONZ is not running, the _On/Off_, _DimUp_, and _DimDown_ buttons continue to work, but the _Previous_ and _Next_ buttons don't.

I'm currently migrating my entire setup, Hue lights, Hue motion sensors, Hue dimmer switches, CLIP sensors and rules from the Hue bridge to the deCONZ gateway. Looking good so far: deCONZ seems to like my custom-made rules, and the CLIP sensors seem to work just fine now.
Unlike the Hue bridge where you either bind the switch to the bridge or to a group, deCONZ seems to support both bindings simultaneously. I really like that with deCONZ, the dimmer switches continue to work when the gateway is down, still allowing for more advanced use in rules when the gateway is running.
Could you elaborate how that's done? Is the gateway a "member" of the switch group (listening in on the commands send to the group)? Or are there multiple bindings, from the 0xFC00 cluster to the gateway and from the 0x0006/0x0008 clusters to the group? How is that done for the Trådfri Remote, which doesn't have a 0xFC00 cluster?
What is the mode attribute of the sensor? It's 3 for the Trådfri remote and 1 for the Hue dimmer switches. It's not reported for other sensor resources, but in the database they have value 1 as well. I've also seen value 2 in the database (I think after creating a CLIP sensor, but before setting its state?).

I tried changing group IDs in the database (both in the nodes, sensors, and groups tables), but deCONZ insisted on using its own group IDs with the Hue dimmer switches and Trådfri remote. Changing sensor IDs and node IDs worked out just as I expected. (I'm using a numbering scheme for the IDs, so I can more easily maintain my rules manually).

It would be cool to have a way to create, view, and maintain the bindings from the REST API (also for other sensors like the Hue motion sensor). I've seen the documentation for the BIND rules, but no such rules are created automatically. Also their syntax is awful. Would it be possible to create a /bindings resource instead, or alternatively, create a config.bindings array for the sensor, which would contain and object with the (sensor) cluster and (group/gateway) endpoint for each binding?

[perler]

I still can't get the remote visible in the web app. I tried everything as described in this thread. I can see it in deConz, but not on the web app. commit 545f771f7b3654ecefa2a14e71430c7c2f6d6c8c

[ebaauw]

The trådfri remote doesn't show in the webapp, but you should see the group that was created for it. It does show in the API under /sensors.

[manup]

I still can't get the remote visible in the web app. I tried everything as described in this thread. I can see it in deConz, but not on the web app. commit 545f771

Did you try it with version deCONZ 2.04.53? There were some fixes after 2.04.52 to improve the setup. We've seen different behaviors from IKEA remotes related to the large button.

Can you also check which firmware version is running on the RaspBee/ConBee: In deCONZ > Help > About the firmware version should be 0x26110500.

[perler]

the commit mentioned is 2.04.53..

but the firmware update did the trick. I have seen the "update available" information in the web app but thought it was a bug (as I was on the latest commit). I was not aware that this is about the firmware.

[manup]

I see you created rules for the Previous and Next buttons, instead of using a direct binding between the Trådfri Remote and the group. I understand that this is needed for non-Trådfri bulbs. However, now when deCONZ is not running, the On/Off, DimUp, and DimDown buttons continue to work, but the Previous and Next buttons don't.

Currently that's the only way to use the buttons with deCONZ, since the remote only sends a fixed set of commands on button press to the related group, which can't be changed. Maybe the IKEA gateway is able to configure the buttons but I haven't looked deeper into this yet, would be interesting though :)

I really like that with deCONZ, the dimmer switches continue to work when the gateway is down, still allowing for more advanced use in rules when the gateway is running.
Could you elaborate how that's done? Is the gateway a "member" of the switch group (listening in on the commands send to the group)? Or are there multiple bindings, from the 0xFC00 cluster to the gateway and from the 0x0006/0x0008 clusters to the group? How is that done for the Trådfri Remote, which doesn't have a 0xFC00 cluster?

It's a mix: the hue dimmer switch is quite unique since binding could be created to customize it to some extend, Busch-Jaeger switches also support this freedom - but it's more tricks to setup. Most other switches like IKEA, JUNG, GIRA and ours create their own random 16-bit group to which lights can be added. They just send commands (on/off, dimm, call scene x, ...) to the related group and don't (need to) care what happens then. Setup for these is quite simple.

The gateway receives all group commands in the network too (in newer firmware versions). And is able to extract the related group-id and specific command which was send.

Adding lights to the switch group and edit scenes for certain buttons is quite easy via the API and our new App is using this quite heavily and if possible always takes advantage of the switch group so features will work even when the gateway is off.

[manup]

but the firmware update did the trick. I have seen the "update available" information in the web app but thought it was a bug (as I was on the latest commit). I was not aware that this is about the firmware.

Not a bug but poorly implemented user experience :)

The two updates will be combined in near future, we've seen confusion about it quite often.

[ebaauw]

but the firmware update did the trick

Do you see the Trådfri Remote under _Devices_ in the web app? I'm on deCONZ v2.04.53, firmware 0x26110500 (according to deCONZ gui's _About_). I deleted the remote and corresponding group, restarted deCONZ, opened the gateway and reset the remote (4x press the reset/link button). deCONZ found the remote, created the sensor resource and the group, but it's not visible in the web app.

[perler]

yes, right now I see it but didn't find the time to use it for anything.

[manup]

deCONZ found the remote, created the sensor resource and the group, but it's not visible in the web app.

As mentioned before in the current web app it won't show up as a device only the group and in the REST API. Switches and Sensors like the IKEA ones are only implemented in the new app which is not yet public. By interest I can provide early access to it next week.

[perler]

you are right, I see only the group. I would be interested in the beta..

[ebaauw]

By interest I can provide early access to it next week.

Yes, please.

I did notice a new _Daylight Control_ option under _Settings_, which found the light level resources for my Hue motion sensors. Nice! However, it does show the gateway time in PM, even tough I set the time format to 24h.

Most other switches like IKEA, JUNG, GIRA and ours create their own random 16-bit group to which lights can be added

Dare I ask: Ubisys?

Where is this group stored (which cluster/attribute on the switch)? I cannot seem to find it in the deCONZ GUI.

Currently that's the only way to use the buttons with deCONZ, since the remote only sends a fixed set of commands on button press to the related group, which can't be changed.

I appreciate that, but why doesn't this command reach the Trådfri bulb in the remote's group?

[donnib]

Can one use the 5 buttons on the IKEA remote to control anything you like ? I mean if i just get a IKEa remote can i use it for something else than together with the bulbs ? I pressume the answer is yes since the remote is paired with the RaspBee gateway ?

[ebaauw]

Can one use the 5 buttons on the IKEA remote to control anything you like ?

Yes, they're available as buttonevent values to the sensor resource, so you can use them in gateway rules, controlling anything connected to the deCONZ gateway. The functionality is different compared to the Hue dimmer switch, see above.

Using my homebridge-hue plugin, you can use them in HomeKit automations as well, controlling anything connected to HomeKit.

[donnib]

@ebaauw nice, i am just about to get my hand on a bunch of bulbs and ikea remotes brand new at 50% discount so nice to know i can use them as i want. It seems like the motion sensor is the same case right ? I am hoping to use this with Home Assistant which i like a lot and got the hang of it but i have no idea if the websockets events work with that....hmm. Have you tried these switches http://www.ikea.com/dk/da/catalog/products/00356910/ ? I also have a Hue motion sensor which i hate how i have to poll to the gateway. I have ordreded an RaspBee and hope i can use that for Philips, Ikea and my Osram lights.

[ebaauw]

I have no experience with the Ikea motion sensors, but they should work. I use (many) Hue motion sensors. I also have a bunch of Hue dimmer switches, two Hue taps, and one Ikea Trådfri remote. All these fire websocket events in the latest beta (I'm on v2.04.54) as one would expect. I have yet to make use of use these events in my homebridge plugin, though.

I don't have any Trådfri dimmers, afaik they don't work with deCONZ.

I have Philips, OSRAM, innr, and Ikea lights connected to deCONZ. Also an OSRAM plug and a ubisys dimmer.

[donnib]

Sound very good, now i need to find out if Home Assistant can support Websockets in it's Hue components (seems this works with the RaspBee gateway).

@manup do you know anybody using Home Assistant with RaspBee ?

[neonal]

@donnib I am, with a bit of a problem: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/66

[ebaauw]

If I read the ZigBee sniffing data correctly, the Trådfri remote does send different commands when pressing (0x07), holding (0x08) and releasing (0x09) the _Previous_ and _Next_ buttons, with different data to indicate which of the buttons was pressed. This means that, technically, we could support button events 4001, 4003, 5001, and 5003 in addition to 4002 and 5002 for the Remote.

[donnib]

👍 for battery support on the IKEA Remote, that would be great so i can monitor those.

@manup If i use deConz together with my IKEA devices, how can i update the firmware ? Can i download it and push it thru deConz ?

[donnib]

@ebaauw or @manup have you seen problems with the IKEA remote ? I have one paired and i am looking at the websocket for event and most events come in but once in a while when i click the main button no event comes in (located same place). I get RSSI -70 and LQI 145. The gateway sits 1meter from an WiFi AP, could that be a problem ?

UPDATE: I moved the gateway another location, signal is the same. I still see same problems even worse with the other buttons. They are unpredictable really. I try hard everytime i click to try again if maybe i did not push enough on the buttons. I don't know if this is a problem with the remote (it's brand new and used only very little time just for development), the websockets events or the gateway.

[ebaauw]

To me, the Trådfri remote seems somewhat less reliable than the Hue dimmer switch, but I wouldn't go so far as to call it unpredictable. Sometimes a button press simply doesn't seem to be registered, neither by deCONZ, nor by the lights added to the group that the deCONZ REST API has created for the remote. As far as I undestand, the remote interacts directly with these lights, bypassing the deCONZ gateway altogether, so I suspect it's the remote, or at least the Ikea's interpretation of the ZigBee standard. I haven't done any serious ZigBee sniffing, though, to confirm this.

As I mentioned above, I think deCONZ' support for the _Previous_ and _Next_ buttons is incomplete - when you press them too long, deCONZ doesn't register anything (not even a short press). I haven't been able to get the remote to change directly the colour temperature my Trådfri light, once it's been paired to the gateway. I find as soon as I start messing with the bindings for the scenes cluster in the deCONZ GUI, I screw up the whole remote configuration and I need to remove it re-pair it to make it work again. Still, as long as I don't mess with its configuration, the remote works (except the occational missed button press).

I like the fact that deCONZ configures the switches so that they can continue to control the lights when the gateway is down, but I don't think I'll be using the Trådfri remote for controlling any lights. I think I'll use it to control my Sonos instead, once I'll have added support for next/previous song to homebridge-zp. That'll be a while, as I'll be focusing on homebridge-hue for deCONZ for quite some time.

I understand that ZigBee and WiFi share the 2.4 GHz frequency range, except for ZigBee channel 25, so I use that channel. I also have the impression that deCONZ runs somewhat better (or at least finds the lights faster after restart) when I connect the Raspberry over ethernet and disable its WiFi (and Bluetooth). I've also seen suggestions on the Hue developers forum that ZigBee signals might be hindered when placing bulbs in lamps with metal enclosures.

Might also be related to how the remote connects to the ZigBee network (see also https://github.com/dresden-elektronik/deconz-rest-plugin/issues/69#issuecomment-318907621): directly to the gateway, or to some light bulb as router in between. I have mainly Hue lights, which seem better at maintaining the mesh network than the Trådfri lights. If the remote connects to a light that has turned zombie (see issue #33), I would expect to miss some buttons while the remote tries to connect to another router.

[donnib]

@ebaauw once again thx for your thorough explanation and thoughts,

In my test i only use the remote together with RaspBee (i don't think i have ever paired it with the IKEA hub), i'd like to keep things simple so i would not want to pair the remote both with lights and the RaspBee gateway.

I am indded running it on Ethernet however have not shutdown the WiFi, i might want to try that as well since i don't need it. I have changed to channel 25. I'll report changes if there are any. UPDATE: i changed to 25 but then my IKEA bulb lost connection to the gateway (i am not home so i can't turn it off/on from power to see if i can get it back or if i have to pair it again ? i tried rebooting my gateway but didn't make a change)

I don't know the details of ZigBee but as far as i understand it should mesh. At the moment i only have 3 devices on the network while i am developing. An IKEA bulb, IKEA remote and Hue Motion sensor. The RaspBee is placed in a third place. In deConz i see all of the devices are connected to the gateway, none connect to another ZigBee device, should i not see that? Maybe i have to move around the house to see if there is a difference, does deConz show this live i mean when devices mesh and go thru another ?

Basically my problem is that i'd like to use the remotes in all rooms and if they are not reliable e.g have to click maybe two or three times before lights turn on then the whole WAF will fall apart.

Another issue is that either the range of the remote itself or the RaspBee is not sufficient for my case. I have 15m where the gateway sits to one remote and i get no events from the remote. I don't know if it helps that i can add an antenna on the RaspBee, most likely not if the sender in the remote is too weak. I have not tried same case with the IKEA hub to see if there is a an improvement or the same problem is there.

[ebaauw]

i changed to 25 but then my IKEA bulb lost connection to the gateway

I don't know if the channel is also stored in the devices and whether they need to be "online" when changing the channel on the gateway.

In deConz i see all of the devices are connected to the gateway, none connect to another ZigBee device, should i not see that?

Only ZigBee router devices build up the mesh network. End-devices just connect to a single router. Typically, only mains powered devices (read: lights) are routers, while battery-powered devices (read: switches, sensors) are end-devices. The gateway is a router as well.

Another issue is that either the range of the remote itself or the RaspBee is not sufficient for my case.

That should be addressed by the mesh network: the remote connects to the light(s) in the same room, which, in turn, connect to the lights in the next room, which, in turn, connect to the RaspBee.

[ebaauw]

i changed to 25 but then my IKEA bulb lost connection to the gateway

I don't know if the channel is also stored in the devices and whether they need to be "online" when changing the channel on the gateway.

In deConz i see all of the devices are connected to the gateway, none connect to another ZigBee device, should i not see that?

Only ZigBee router devices build up the mesh network. End-devices just connect to a single router. Typically, only mains powered devices (read: lights) are routers, while battery-powered devices (read: switches, sensors) are end-devices. The gateway is a router as well.

Another issue is that either the range of the remote itself or the RaspBee is not sufficient for my case.

That should be addressed by the mesh network: the remote connects to the light(s) in the same room, which, in turn, connect to the lights in the next room, which, in turn, connect to the RaspBee.

[donnib]

Gotcha, thanks for the explanation.

I have installed 5 GU10 bulbs in my office, i control each of them from the REST API to on then off then i see after maybe 30s events in websocket like this :

{"e":"changed","id":"2","r":"lights","state":{"ct":250},"t":"event"}
{"e":"changed","id":"3","r":"lights","state":{"ct":250},"t":"event"}

I find this behavior weird, have you experienced that ?

[ebaauw]

I have installed 5 GU10 bulbs

Philips?

I find this behavior weird, have you experienced that ?

Yes, especially shortly after restarting deCONZ. It's weird, but to be expected.

The gateway keeps a cache copy of the actual state of the light. In theory, all changes to the light state pass through the gateway, so it keeps its cache up to date when sending ZigBee commands to the light. In addition, the gateway polls the light state over ZigBee, updating its cache when it finds a changed value. The gateway issues web socket events when it updates its cache. The more lights you have connected to the gateway, the longer the time between two polls of the same light, so the longer the delay.

You'll see this behaviour anytime a light acts differently than the gateway expects. The most notorious case is when your wife uses a 20th century wall switch to power-off or power-on a light. The gateway only notices this the next time it polls the light, only updating state.reachable after a delay. Other interesting cases are: setting the light to a colour or colour temperature value it doesn't support (try "xy": [0.0, 0.0]), using ZigBee switches and/or sensors interacting directly with the light (bypassing the gateway), using group commands, or ZigBee commands not reaching the light due to a network hiccup.

When the light supports ZigBee attribute reporting (and when this has been configured properly), the light actually sends a push notification over ZigBee whenever it's state changes. In that case, you wouldn't see this behaviour anymore. Unfortunately, only a few lights support this (Philips don't). Only the latest versions of deCONZ configure this (see https://github.com/dresden-elektronik/deconz-rest-plugin/commit/887e6b121640109c1e1f7ef6f7f4743e69648b24, https://github.com/dresden-elektronik/deconz-rest-plugin/commit/a0748da0e1a413167d65a502f41a1a97d5f2c550, and https://github.com/dresden-elektronik/deconz-rest-plugin/commit/8cfb4e4846a51a43594e9c74bd3c0f7673480fde).

[donnib]

No it's IKEA GU10, i got them dirt cheap 7,5€.

Ok, i should get the latest version i guess and see if that solves some problems like these.

[ebaauw]

Tunable white? They cost double that there in the Netherlands :-(

I don't think v2.04.60 yet sets up attribute reporting for ct (see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/33#issuecomment-319182344), but you can configure it manually in the deCONZ GUI.

[donnib]

Yes they cost double here too but somebody had a bunch of IKEA devices from his new house (he had somebody in the family with IKEA) so i got 32 x GU10, 6 x E27 (fixed color), 7 x remotes, 6 x (remotes and e27 tuneable white), 4 x e14 tuneable white, and 5 x (motion + e27 fixed color) all of it brand new unopened 55% of original price therefore i am working to get this to work acceptable in deConz ;)

@ebaauw do you have an idea on my question further up ? https://github.com/dresden-elektronik/deconz-rest-plugin/issues/23#issuecomment-319361914 answered here : https://github.com/dresden-elektronik/deconz-rest-plugin/issues/23#issuecomment-303826855

[donnib]

Using the remote last couple of days i have a feeling the remote goes into some standby so after using the remote after a night of no usage you have to tap it couple of times before it reacts. @ebaauw @manup have you experienced this ?

[markbeee]

The Tradfri remote goes into sleep mode rather quickly after using it, because it only has two coin cells as energy source and should last for some time. But pressing a button does a hardware interrupt on the microcontroller in the remote and sends out the command. So it should not be necessary (and would not be helpful also) if you have to press several times. Maybe check the signals with a ZigBee-sniffer or have a look at the deCONZ GUI and the node view. The remote should show a connection to your RaspBee/ ConBee modue after pressing a button once on the Tradfri remote.

[donnib]

Yes you are right that's how it should work and how i expect it, i need to try a Zigbee sniffer. The remote just feels weird also in daily ussage as it's misses button press many times like i explained earlier. I wish it worked well, maybe a firmware upgrade will help on this case.

[manup]

I've one in my home/testing setup, I don't use it that often so usually it sleeps quite long (24h and more). It's directly connected to the RaspBee and always works on first button press. There were some end-device issues before RaspBee firmware version 0x26110500 though.

The IKEA remote has firmware version 1.1.1.1-5.7.2.0

[ebaauw]

I don't seem to have problems with the Trådfri remote waking up. deCONZ does seem to miss the second button press, when I press too quickly after the first. Also, on occasion, a single press seems to be missed, especially on the _Previous_ and _Next_ buttons. I don't experience any of this with the Hue dimmer, so I tend to think it's related to the remote, rather than to deCONZ.

Indeed, some serious ZigBee sniffing will be needed to figure out what's happening. Alternatively, if you run deCONZ --dbg-aps=2 you should see messages when deCONZ receives commends from the remote (filter on the remote's mac address). Here's what I see pressing _On/Off_, _DimUp_, _DimDown_, _Previous_, and _Next_:

09:36:50:444 APS-DATA.indication srcAddr: 0x000b57fffexxxxxx, dstAddrMode: 1, profile: 0x0104, cluster: 0x0006, lqi: 255, rssi: -42
09:36:54:943 APS-DATA.indication srcAddr: 0x000b57fffexxxxxx, dstAddrMode: 1, profile: 0x0104, cluster: 0x0008, lqi: 255, rssi: -44
09:37:02:115 APS-DATA.indication srcAddr: 0x000b57fffexxxxxx, dstAddrMode: 1, profile: 0x0104, cluster: 0x0008, lqi: 255, rssi: -44
09:37:05:686 APS-DATA.indication srcAddr: 0x000b57fffexxxxxx, dstAddrMode: 1, profile: 0x0104, cluster: 0x0005, lqi: 255, rssi: -43
09:37:08:278 APS-DATA.indication srcAddr: 0x000b57fffexxxxxx, dstAddrMode: 1, profile: 0x0104, cluster: 0x0005, lqi: 255, rssi: -43

[donnib]

@ebaauw how is it possible to sniff traffic ? I mean with the RaspBee ? I am using my own rPi with the official image from Dresden Elektronik and deconz starts automatically on boot, where can i add the deCONZ --dbg-aps=2 ? Where is the log file located ?

[ebaauw]

how is it possible to sniff traffic ? I mean with the RaspBee ?

Not. You need a ConBee USB stick and an x86 Linux or Windows 7 machine. See #69.

where can i add the deCONZ --dbg-aps=2 ? Where is the log file located ?

I'm not sure. I think there's a deCONZ-autostart.sh script, but I think it's overwritten when you install a new version. In the standard install, deCONZ doesn't save a logfile. If you exit deCONZ from the GUI, you can start it again manually from the command line, redirecting output and specifying the command line options.

[donnib]

ahh i see, thx. I guess i need to invest in a conbee as well at some point.

[ebaauw]

Yeah, they reel you in... ;-)

The ConBee works with deCONZ as well as BitCatcher for sniffing, you just need to flash the correct firmware for each. I use it on my "test" Raspberry, so my "production" environment doesn't get polluted.

[donnib]

yeah that's what i would also need to understand better what happens or rather why things are not happening :D

[donnib]

@ebaauw if you have time it would be really cool if you could try with your IKEA remote and a sniffer. I see more than occasionally misses the button presses

[ebaauw]

• config.battery is still missing from the sensor resource.

Currently disabled and needs more testing, not sure if the remote supports ZCL attribute reporting for power configuration cluster as the hue dimmer switch does.

I setup attribute reporting on my Trådfri remote (with new firmware) for the battery percentage (cluster 0x0001, attribute 0x21), and a binding of the Power Configuration cluster to the RaspBee. I'm seeing ZCL Report Attribute commands every five minutes from the remote to the gateway in BitCatcher.

BTW, it reports 0x2F after the firmware update. Is that 47% or do I need to scale the value from 0..254 to 0..100%? Although, all my Hue motion sensors and dimmer switches show value 200, so maybe I should scale 0..200 to 0..100%?

[manup]

Yes the scaling is 0.5 see related code here:

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/de_web_plugin.cpp#L2990

Curious if it works, I'm adding battery support for motion sensor and remote control right now :) The bindings will be created, if missing, on incoming commands.

[manup]

Battery updates should now work with latest commit: https://github.com/dresden-elektronik/deconz-rest-plugin/commit/cdb460434b908fba266637601e4d9e75997f65e8

Note The reporting configuration will be done automatically by the plugin, but it may take some time after button event or presence is received.

[ebaauw]

There is no cluster in the uniqueid for the IKEA motion sensor. I would expect 0006, but that's a client cluster on the motion sensor. As far as I can tell, a server cluster is used in the uniqueid. The IKEA remote uses cluster 1000 (which is both server and client on the remote). I assume as sort of a catch-all, since the ZHASwitch resource uses 0006, 0008, and 0005?

[ebaauw]

There is no cluster in the uniqueid for the IKEA motion sensor.

Found a bug in setting uniqueid after loading the sensor from the database. I fixed it in 878f8fd (set the endpoint to 1000, just as for the remote).

[ebaauw]

I think the remote is fully supported now. The only issue still outstanding is how, on occasion, the _Previous_ and _Next_ buttons are able to change the ct of IKEA lights in the group, but mostly not (see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/96#issuecomment-321981553).

For the motion sensor, I think there's still a couple of issues (see also https://github.com/dresden-elektronik/deconz-rest-plugin/issues/96#issuecomment-323518995):

1. config.duration should be read-only and updated from _onTime_ attribute from the _On with timed off_ command sent by the motion sensor. Currently state.presence turns false after the time specified in config.duration, but the lights turn off after the time specified by the motion sensor's dial, which is passed in _onTime_;
2. When the timer expires, deCONZ should also set state.on of the lights in the motion sensor group to false, unless another command overruling _Remaining Time_ was sent to the light in the meantime. Maybe it's safer to force-poll the light when the timer expires? For lights supporting attribute reporting (IKEA, OSRAM, ubisys) this would not be needed, but for other lights state.on will only reflect the actual light state when the light is polled next;
3. When the Day/Night dial is set to Night, the motion sensor sends the _On with timed off_ command with _Accept Only When On_ set in the _On/Off Control_ parameter unless it's dark. When it's dark, or when the dial is set to Day, this flag is cleared. When set, this flag causes the light to turn on only when it's already on.
   So effectively, on the Night setting, the lights only turn on when it's dark. deCONZ should take this into account when setting state.on to true for the lights in the motion sensor group. Maybe alternatively, deCONZ could force-poll the light here as well? Currently, deCONZ sets state.on to true while the light remains off. Note that the timer would still be required to set state.presence to false and to force-poll the lights in the group (in case the light was already on, the _onTime_ parameter will be applied to turn the light off). Also note that attribute reporting doesn't help here, as the light doesn't change, so it has nothing to report.
4. We could add state.dark to the motion sensor resource based on _On/Off Control_.

[manup]

1. config.duration should be read-only and updated from onTime attribute from the On with timed off command sent by the motion sensor. Currently state.presence turns false after the time specified in config.duration, but the lights turn off after the time specified by the motion sensor's dial, which is passed in onTime;

Yes the time should be extracted from the commands (for this specific sensor), it needs more tests if the time is always the max time or can also be the remaining time.

For example we have build sensor lights which also send this command but with dynamic time, which not always is the max time but could be less aka remaining (the command is send more often than the actual ontime to reach more lights in specific use cases).

When set, this flag causes the light to turn on only when it's already on.

The reason behind the flag is the timeout carried in the command wich will taken and run locally on each light. If the flag is set the lights will only process the command if their state is on. You can read the on/off cluster attributes and see how the OnTime attribute will count down until it's refresh by the sensor.

1. When the timer expires, deCONZ should also set state.on of the lights in the motion sensor group to false, unless another command overruling Remaining Time was sent to the light in the meantime. Maybe it's safer to force-poll the light when the timer expires? For lights supporting attribute reporting (IKEA, OSRAM, ubisys) this would not be needed, but for other lights state.on will only reflect the actual light state when the light is polled next;

In our new app we create various rules for this purpose in a rule set which is organized with the /resourcelinks API, we call this set — motion sensor control:

• there is one virtual CLIPPresence sensor which will be armed if any assigned physical sensor triggers
• multiple motion sensors can be assigned to the rule set (from various vendors), important for example in long floors and large rooms
• there is another CLIPStatus which acts as state machine there each state describes what should happen then motion is detected (in the virtual presence sensor), or xx seconds after no motion is detected, or switch command comes in between
  
  
  
  • on/off, set dimm, call scene, dimm only if lights are on, etc.
  
  
• localtime and daylight will also be part of these rules (the above already works, this is in development)

Therefore it's the rules which controls the lights, the sensors are only providers of the presence impulse.

Due to the virtual sensors it's also very easy to replace and extend the physical sensors, which is very important feature in commercial and industrial applications.

1. We could add state.dark to the motion sensor resource based on On/Off Control.

If this works reliable it would be nice to extract this information.

[ebaauw]

Yes the time should be extracted from the commands (for this specific sensor), it needs more tests if the time is always the max time or can also be the remaining time.

The TRADFRI motion sensor has no idea of remaining time - it just sends the _onTime_ corresponding to its dial setting. I think the ZLL standard specifies the light should take the max of the remaining _onTime_ and the _onTime_ specified with the _On with timed off_ command:

In all other cases, the device shall set the OnTime attribute to the maximum of the OnTime attribute and the value specified in the on time field

Therefore it's the rules which controls the lights, the sensors are only providers of the presence impulse.

Are you saying: don't link a group to a motion sensor for standalone operation (when the gateway is unavailable); use rules instead? This would make sense to me and is consistent with Philips' approach for the Hue motion sensor. It might be prudent to remove config.group from the ZHAPresence sensor altogether, in this case, to avoid any confusion.

there is another CLIPStatus which acts as state machine there each state describes what should happen then motion is detected (in the virtual presence sensor), or xx seconds after no motion is detected, or switch command comes in between

I've actually created a similar ruleset at home, except using a CLIPGenericFlag as master switch instead of a CLIPPresence. For the CLIPGenericStatus state machine, I also use the motion sensors in the adjacent rooms in conjunction with the motion sensors in the room itself, to detect that I've left a room. I only turn off the lights when I leave, so my lights don't turn off suddenly while I'm watching _Game of Thrones_, motionless from suspense. Also, I set a special state in the bedroom when sleeping, so the lights won't turn on when I turn in my sleep (but my logs still register the motion).

localtime and daylight will also be part of these rules (the above already works, this is in development)

I actually use a second set of rules, that use the CLIPGenericFlag as input, in combination with the ZHALightLevel sensor and some flag for night setting (which is normally set and cleared at a fixed time, but allows me to override). By exposing the CLIPGenericFlag to HomeKit, I also control other devices (like my Sonos speakers or a fan connected to an Eve Energy plug) based on room presence (and, in case of the fan, based on the ZHATemperature sensor).

[manup]

The TRADFRI motion sensor has no idea of remaining time - it just sends the onTime corresponding to its dial setting. I think the ZLL standard specifies the light should take the max of the remaining onTime and the onTime specified with the On with timed off command:

Cool, that makes extracting easy. Yes for lights that makes sense, it's better to have light than sit in the dark.

Are you saying: don't link a group to a motion sensor for standalone operation (when the gateway is unavailable); use rules instead? This would make sense to me and is consistent with Philips' approach for the Hue motion sensor. It might be prudent to remove config.group from the ZHAPresence sensor altogether, in this case, to avoid any confusion.

That's only the way our new app sets up the rules, to be generic and require only the minimum of the motion sensors.

However putting lights into the sensor group still is very useful in some cases and should be kept. I think it should be documented clearly with examples for use cases what way is useful for which use case.

I actually use a second set of rules, that use the CLIPGenericFlag as input, in combination with the ZHALightLevel sensor and some flag for night setting (which is normally set and cleared at a fixed time, but allows me to override). By exposing the CLIPGenericFlag to HomeKit, I also control other devices (like my Sonos speakers or a fan connected to an Eve Energy plug) based on room presence (and, in case of the fan, based on the ZHATemperature sensor).

These CLIP sensor are really cool, I totally underestimated them for quite a time, thanks to you we will use them more to provide an easy ui for various features.

[ebaauw]

I think the remote is fully supported now. The only issue still outstanding is how, on occasion, the Previous and Next buttons are able to change the ct of IKEA lights in the group, but mostly not.

I forced the remote to connect to the TRADFRI white spectrum light by powering off all Hue lights in the vicinity. Confirmed this by sniffing: at MAC level the remote sends a unicast group command to the TRADFRI light, which re-broadcasts the command to 0xffff. Double-checked that the light is member of the group. Still no reaction to the _Previous_ and _Next_ buttons.
BTW The non-standard scene commands 0x07, 0x08, and 0x09 are rebroadcasted by other routers in the network alright.

[ebaauw]

For the motion sensor, I think there's still a couple of issues:

1. config.duration should be read-only and updated from _onTime_ attribute from the _On with timed off command_ sent by the motion sensor.

Done.

1. When the timer expires, deCONZ should also set state.on of the lights in the motion sensor group to false

This would be very complex. I think we'd better spend our efforts in improving the polling of lights.

1. So effectively, on the Night setting, the lights only turn on when it's dark. deCONZ should take this into account when setting state.on to true for the lights in the motion sensor group.

Done.

1. We could add state.dark to the motion sensor resource based on _On/Off Control_.

Done.

[ebaauw]

The only open end in this issue is that we still don't understand how the remote in standalone mode changes the colour temperature (or colour) of the Trådfri lights.

[manup]

I think these are factory presets for scenes, I saw something like that polled by the IKEA gateway.

[ebaauw]

Does the IKEA gateway set these scenes, or does the light contain them on factory reset. The latter makes sense, as it worked right after updating the white spectrum light's firmware (but not after updating the colour light's firmware).
What causes these scenes to be deleted? Could deCONZ (re-)create them?

[mploetne]

Hi,
Think it could be a bit different.
The next few lines are just observations and my own conclusions on that.

I could imagine that the pairing of a light to the orig. Tradfri Gateway differs "completely“ from that of other Gateways.

I don’t have to start a discovery mode on the Gateway to bind a light to it. I just have to use the already gateway-bound remote and pair it with the bulb.

First possible way how the light comes to the gateway is that the pairing process initiate the discovery on the gateway to.

But I think its another way the light is bound to the gateway.
I think the remote pairs similar to the standalone mode to the bulb (creates the default scenes and binding) but if its already paired to gateway it announce the needed infos (addresses, keys and so on…) of the bulb to the gateway, where the light is added manually. That way the standalone pairing and the gateway pairing would result in the exact same standalone (if the gateway is down) behaviour.

One more time: all of that are just possibilities and nothing of that is observed or sniffed cause i don't know how. But if i’m right, it would be possible to get the lights manually to the network and extract the default scenes and bindings for each bulb type? With that information the default device creation on discovery for the tradfri’s could be streamlined by write those infos back to the reseted lights.

But maybe I’m completely wrong.

Marko

[snillevilla]

@ebaauw Do I understand correctly that the decision to remove the 'duration' parameter from the json the sensor returns via REST API was implemented by you and not IKEA?
Asking because I wrote this guide (English version is machine-translated, so sorry about the language) about using the sensor with Conbee + Node RED + Home assistant, and the duration parameter did play a role there.

Namely, it was possible to extract the sensor presence state (true/false) from the API and forward it to Home Assistant via Node RED, and that state did change according to the duration parameter that could be set manually. I did test that myself extensively, and it worked as expected. This was practical, because the default minimal 1m setting is too long in some situations.

So if it was you who took away the setting, could you please put it back?

[manup]

Recent versions of deCONZ do extract the duration parameter from the received IKEA sensor commands (I figure the minimum is 1 minute). The duration send by the sensor is configured on the back. However the API can be extended in order that manual via API configured duration parameters, which are not send by the sensor itself, will not be overwritten — therefore allowing custom durations under 1 and above 10 minutes.

[snillevilla]

@manup That would be most appreciated.

[ebaauw]

You could already use a CLIPPresence sensor for that.

[snillevilla]

@ebaauw How what where? Please explain in more detail! :)

[ebaauw]

Create a CLIPPresence sensor and set the duration you want on that sensor. Then create a (series of) rule(s) that sets the CLIPPresence sensor when the ZHAPresence sensor becomes true. Base your rules to update the lights or other devices on the CLIPPresence sensor. We also used this workaround to trigger a HomeKit camera from a switch, see https://github.com/ebaauw/homebridge-hue/issues/179

[snillevilla]

@ebaauw Looks good as an interim measure, but the duration parameter was SO much more convenient. :)

[jonatanolofsson]

I have been trying today to make the remote work with V2_04_91, and the remote shows up alright in the network, but the only response from the buttons I get is from the big button, which yields an "ikea remote toggle button" in the log, but nothing else - nothing in the gui and nothing on the websocket. I just spent the night updating the firmware of the remote OTA, but it made no difference.

Any ideas on how to continue debugging? Or on what I'm doing wrong?

[jonatanolofsson]

Nevermind, after a few reparings in the webapp it started working.

[manup]

Normally the events are just forwarded based on the group commands the remote sends. The webapp doesn't show the button events currently, but at least the websocket messages should be visible.

@ebaauw tool dc_eventlog can also be used to get some more debug output for the events.

https://github.com/ebaauw/dc_eventlog

Also I recommend to update to 2.04.92, sadly 2.04.91 had some serious issues.

[aradmidias]

I also ran into trouble, trying to connect my IKEA TRADFRI Remotes, TRADFRI Motion Sensors and FLOALT Panels. The Web-IU reports software version 2.04.99 (which appears to be a beta?).
(Note: When I talk about the "Web-UI" I refer to the one, that is provided besides the REST-API, regarding Phoscon app, see notes below)

Anyway: After several days of trial and error I figured the following procedures to connect the devices:

For the Remote:

1. Open the Back of the Remote
2. Reset it (by pressing the pairing-button at least four time in a row)
   You can see if it succeeded, when the red light at the front flashes
3. Wait for the flashing to stop
4. Remove the battery
   Apparently the Remote can hang after being reset, causing successive connection attempts to fail
5. Wait 5 seconds
6. Open the Zigbee-Network (if it is not already open) to allow new devices to join
7. Re-Insert the batteries
8. Hold the Remote close to the RaspBee and press some buttons
   You can see the green LED on the RaspBee flashing and blinking
9. After some seconds the Remote appears in the "Control" section of the Web-UI
10. Assign a light to the Remote to test the on/off, increase brightness and decrease brightness buttons work in that group.

For the Motion Sensor:

1. The sequence is the same as with the Remote, just that it'll need some motion for the Motion Sensor to sense some motion (duh)
   I waved my hand in front of the Sensor.

For the Panels:

1. Reset the light (turn it on and off, six times in a row; when turning it on again, wait for a moment to see that it is reset)
2. Turn the light off
3. Open the Zigbee-Network (if it is not already open) to allow new devices to join
4. Turn the light on
5. It will be added automatically

Notes:

1. Regarding the Remote and the Motion Sensor: I did not test, whether the short distance is a necessity.
2. The Remote is not listed in the "Devices" section of the Web-UI, therefore it can not be configured (though both, the Remote and the Motion Sensor are included in the returned JSON)
3. The _previous_ / _next_ Buttons on the Remote do not work out-of-the-box, even if a Panel is in the Remote's group, though the events, that are triggered by pressing the buttons, are registered and visible in the JSON that is returned when opening the "Devices" section in the Web-UI.
4. I did not do these tests with the _Phoscon App_, though it visualizes the Remotes _and_ Motion Sensors. It also provides a way to assign scenes to the _next_ and _previous_ Buttons, but right now, I could not get them to change the scene.

So from what I can tell, the Remote(s) and the Motion Sensor(s) can be paired and do work with 3 out of 5 buttons.

Since I wanted to control one light with multiple Remotes and Motion Sensors, which is possible, by adding the light to the respective groups, I achieved what I wanted to achieve. :smile:

[ebaauw]

The Web-IU reports software version 2.04.99 (which appears to be a beta?).

Could be - haven't seen that version yet.

Regarding the Remote and the Motion Sensor: I did not test, whether the short distance is a necessity.

Probably not, but it seems prudent while pairing to have end devices connected directly to the gateways instead of through the ZigBee mesh network.

The _previous_ / _next_ Buttons on the Remote do not work out-of-the-box, even if a Panel is in the Remote's group, though the events, that are triggered by pressing the buttons, are registered and visible in the JSON that is returned when opening the "Devices" section in the Web-UI.

Yes, still don't know why. See my comments above and https://github.com/dresden-elektronik/deconz-rest-plugin/issues/96#issuecomment-321981553.

So from what I can tell, the Remote(s) and the Motion Sensor(s) can be paired and do work with 3 out of 5 buttons.

Actually all five buttons work when using gateway rules. If you hold the _On/Off_ button for 10 seconds, deCONZ will create some default gateway rules to change the colour temperature of lights in the corresponding group (also non-IKEA lights). The remote sends the commands when pressing the _Previous_ or _Next_ buttons, but the IKEA lights simply doesn't seem to react to these when connected to the deCONZ gateway.

[xibriz]

I'm having a really hard time with my Trådfri Motion Sensor (TYPE: E1525).

Can't get it to report motion. Any way to get some logs/debug info?

I'm running deCONZ 2.04.99 / 12/15/2017 on Raspbian Stretch 4.9 / 2017-11-29 (Headless installation)

Sensor info:

{
  "config": {
    "alert": "none",
    "battery": 87,
    "duration": 60,
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "b002180869295a690b6df4a7abc6fda4",
  "manufacturername": "IKEA of Sweden",
  "modelid": "TRADFRI motion sensor",
  "name": "TRÅDFRI Motion sensor",
  "state": {
    "lastupdated": "1970-01-01T00:00:00",
    "presence": false
  },
  "swversion": "1.2.214",
  "type": "ZHAPresence",
  "uniqueid": "00:0b:57:ff:fe:46:9f:68-01-1000"
}

[ebaauw]

Indeed, looks like state has never been updated. Also config.group is missing. When detecting motion, the sensor sends a _On_ command to its associated group. deCONZ listens in on this command and sets state.presence when it occurs. deCONZ resets state.presence after config.duration seconds, without any further interaction with the motion sensor.

My best guess is that the sensor somehow dropped from the network. I'd try reading the attributes of its _Basic_ cluster from the deCONZ GUI, but that's kinda hard in a headless installation. Best delete it from the REST API, reset it, and pair it again with deCONZ, while continuously waving in front of the sensor to keep it awake during the pairing.

[xibriz]

Thanks for the info @ebaauw .

I have paired it many times with no luck. Some thing that I noticed is that the config.battery is updated, but not the config.duration. Assuming config.duration reflects the physical setting on the motion sensor.

If I restart deCONZ the config.reachable is set to false. I then have to take out the battery from the sensor to get the status to true again.

[ebaauw]

Assuming config.duration reflects the physical setting on the motion sensor.

Yes, but it only gets updated through the command the sensor sends when it detects motion.

If I restart deCONZ the config.reachable is set to false. I then have to take out the battery from the sensor to get the status to true again.

So deCONZ does receive the device announcement when the sensor is powered on. No clue why the command isn't received. You could try and power off all your lights, and move the sensor close to the RaspBee, so it connects directly instead of through the mesh network.

[xibriz]

Now I can't get the motion sensor paired with deCONZ at all. Have tried far to many hours now. It gets paired with the IKEA gateway right away with now problems.

[mattiasflodin]

@xibriz I managed to pair my motion sensor by removing the battery, opening the gateway, then reinserting the battery.

[xibriz]

@mattiasflodin Witch version does your motion sensor report?

I tried opening the gateway and reinserting the battery. The sensor was included right away :) But still does not seem to detect motion :( I have the latest deCONZ installed.

Vendor: IKEA of Sweden
Product: TRÅDFRI Motion sensor
Version: 1.2.214
Battery: 87 %
Motion: none
Refreshed: Invalid Date

[dxxxm]

By chance I had to re-pair the motion sensor today. No trickeries required. Didn't remove battery.
Sequence as by the book: Phoscon, 'add new sensor', 'IKEA', quickly press 4-times the rear link button, wait a bit until phoscon app replies with a 'ready' and a green 'tick' symbol.
"config": { "alert": "none", "battery": 47, "duration": 600, "group": "25463", "on": true, "reachable": true }, "ep": 1, "etag": "cdfzzza7xxxxxc0f2529yyy0050dd", "manufacturername": "IKEA of Sweden", "modelid": "TRADFRI motion sensor", "name": "TRÅDFRI Motion sensor", "state": { "dark": false, "lastupdated": "2018-03-13T20:45:15", "presence": true }, "swversion": "1.2.214", "type": "ZHAPresence", "uniqueid": "00:0b:57:ff:ss:xx:yy:zz-01-1000" }

[FezVrasta]

Is it just me or the remotes go into some kind of standby mode after a while?

I notice that I have to press the button twice to make it trigger the event, but after that, everything works just fine.

Is this a known limitation?

[mattiasflodin]

@FezVrasta I used to have this issue before when I only had a couple of remotes in the network and no light bulbs. After adding all the light bulbs as well, it doesn't happen anymore. Perhaps it has to do with not finding neighbor devices in a close enough range, or perhaps a non battery-powered device is needed to keep the mesh active.

[FezVrasta]

Thanks for the reply @mattiasflodin, I have recently added a Osram Smart Power Plug for this very reason, the situation got better but still sometimes I have to press twice.

Anyway I'm going to move most of my lights to DeCONZ this weekend so I'll see if anything gets better!

[ebaauw]

or perhaps a non battery-powered device is needed to keep the mesh active.

The mesh is maintained by ZigBee routers (yellow nodes in the deCONZ GUI), which typically are mains powered. ZigBee end devices (most battery powered devices, grey nodes in the deCONZ GUI) connect to only one (typically the nearest) router in the mesh. When that connection is lost, the end device needs to find another router, which might lose the notification of the first press.

[FezVrasta]

@ebaauw the fact is that one of my remotes is exactly between my Osram plug and the DeCONZ, approx 3 meters from each side... I doubt there's lack of coverage in that particular position.

[ebaauw]

I’m lost in the technical details, but there’s more to it than radio signal coverage. IKEA, OSRAM, Philips all use a slightly different way to build up the mesh, sometimes causing devices from one vendor not to play well with routers from another vendor. Also, a router only supports a limited number of concurrently connected end devices. And if you power-cycle a router, the connected end devices are orphaned.

My network consist of 42 lights (routers), which are powered on always, and still my Hue motion sensors sometimes blink red, (presumably) indicating they’re re-connecting to the mesh network.

[FezVrasta]

I see, thanks for the info. On my DeCONZ I just have 3 remotes and the Osram plug so I thought that would be enough to have a stable network.

I hope that adding more bulbs things will get better.

[olemr]

Just updated to 2.05.32 (beta) and added an Ikea 5 button remote.
Added 2 ct bulbs to the group and on/off and dimming works well, even with deconz gateway offline.
I have read above about problems with the < > buttons controlling the color temperature and that is still not working out of the box.
What is the latest take on this?

I can see in the REST API that the buttons produces both press, hold & release events so rules are an option, but it would be nice if it worked with the gateway offline as well.
Before resetting the remote, I tested that ct change worked even when the Ikea Gateway was offline, so this direct control is possible, somehow.

[manup]

Should work with recent versions of deCONZ, closing the issue for now.