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.

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

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;

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.

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

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

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

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