Regarding pairing with the remote; does it also apply to the IKEA 5 button remote?
I’ve found the remote as THING, but in the ST app it states “Please Wait”. According to your guideline (step 5) I should keep the remote close to ST Hub and hold reset button for 15 seconds, but noting happens.
The thread’s getting long so I understand how it’s tempting not to look through for answers. THING is correct since there isn’t a Device Handler for the remote. “Please Wait” is normal since there isn’t a Device Handler present.
The “Steering Device” will still able to control everything except the color temp when there isn’t a Device Handler present.
I don’t believe the original IKEA Devices were certified for either profile: I think that technically they’re “manufacturer proprietary.” No guaranteed interoperability. The inexpensive orvibo zigbee devices are the same way. They mostly work but there are some idiosyncrasies, including the fact that the Orvibo devices will work with the SmartThings 2 hub but not the first generation hub.
It would be nice if Ikea eventually got them fully certified, but I wouldn’t count on it.
One of the people on the hue developers board has done some deep dive work on just what commands are being sent and has the following information:
The bad news: both the light and the remote seem to use the usual ZLL clusters, but on a ZHA endpoint instead of a ZLL endpoint. I’m no ZigBee expert, but it would seem like the Trådfri is not ZLL compliant.
Updated: In April Ikea did get one version of one light ZLL certified, but it only appears to apply to that specific firmware/hardware model. They didn’t go back and upgrade other existing devices. So it may also be that people have different experiences because they have devices with different firmware and technical specifications. That’s likely to be a problem for a while because of the retail distribution. There won’t be any way to tell in the store which devices are from the older stock.
For those interested in more technical details on why not all zigbee devices work together, see the Community FAQ:
Yeah, I just updated my post at the same time that you were writing.
In April Ikea did get one version of one light ZLL certified, but it only appears to apply to that specific firmware/hardware model. They didn’t go back and upgrade other existing devices. So it may also be that people have different experiences because they have devices with different firmware and technical specifications. That’s likely to be a problem for a while because of the retail distribution. There won’t be any way to tell in the store which devices are from the older stock.
Long answer, maybe, if you have the Dresden device and Deconz, but the firmware update files have not been released so essentially you’d be jailbreaking the IKEA device and have to write your own files for it. Which is why the short answer is no.
I’m heading over to IKEA later today to pick up some GU10’s and a 5 button remote. I was going to then have a look at creating the ST device type for the remote, but now I’m thinking about it, I’m not really sure what it would tell ST to do. I guess you’d need to be able to assign what each of the button presses did? I’ve never paired a switch/remote with ST before so I’m not sure what is expected of one.
A switch is completely different from a remote because the switch has “state.” That is, a switch by itself can be either “on” or “off.” So if you press a switch, it turns on, and it tells the hub that it turned on. Or, the hub can just send a message to the switch to turn on.
A remote, which SmartThings Will usually call a “button controller,” has no state of its own. It’s neither on nor off. When you press a button, nothing happens on the remote itself – – it just sends out a message to another device that its button was pressed. Ideally, we want the hub to receive that message. If the hub can receive a message from the remote, and the message is specific to which button was pressed, then we have a device that can integrate fully with SmartThings.
What will happen is that there will be an automation/smart app set up so that when the hub receives the button press notification, The automation can treat that as a trigger and have something else happen.
Remotes that don’t notify the hub of a button press
Some remotes, however, never send a notification to the hub when the button is pressed. They just think they are supposed to talk to some other device directly.
Some people still use these as a parallel means of control. You press a button, and a lamp comes on, and eventually SmartThings knows that the lamp came on. But SmartThings never knows the button was pressed.
As long as the remote doesn’t steal the lamp away from SmartThings, so the Lamp ( not the remote, just the lamp itself) can still be controlled by either the remote or the hub, the remote can still be useful. It’s just not as useful as a full “button controller” that sends notification of button presses to the hub.
The worst case
The worst case is if the remote only works with the lamp by stealing the lamp away from SmartThings so that the hub can no longer send commands to the lamp directly. So we hope that won’t happen.
An example of a remote that can be used as either a button controller or a parallel means of control – – you decide
The Osram/Sylvania Lightify Smart Dimmer is an interesting example, because it is a zigbee device that can be used as either a button controller (sending a notification of each button press to the hub) or as a parallel means of control (sending instructions directly to some specific bulbs, but not stealing those bulbs from the hub). It just depends on which device type handler you use.
Many people like it as a button controller, because then they can have it trigger anything that SmartThings controls, including Z wave devices, because the dimmer sends the button press notification to the hub, and then the hub sends the commands to the other devices.
But some people set it up as a parallel means of control because then it is very very fast. But it will only be able to control a few nearby Zigbee bulbs.
Here for reference are the two alternative device type handler’s for the Lightify device. You have to use one or the other, and they work very differently.
As a button controller ( notifies the hub of each button press)
As A parallel means of control (does not notify the hub of the button presses, but instead speaks to the bulbs directly)
But again, this particular lightify dimmer is unusual in that it is up to the user which DTH to use and how to set it up to communicate with a Bulb – – either through the hub or directly.
Most remotes will need to be set up as one or the other, because they just won’t work in both ways. But I wanted to put both DTH links here since first of all, we don’t really yet know which of the two ways the IKEA remote would be able to use. (Or of course if it’s going to end up being one of the worst case devices, meaning it can be paired to SmartThings but it can’t be used because it always steals the lamps away from the hub. ). And it’s important to understand the differences when you get ready to start writing a device type handler.
Writing the DTH
The following thread is my favorite example for how someone who had never done much coding set out to write a DTH for a new zigbee remote, in that case A three button Key fob. It was a device that was eventually able to be set up as a full button controller, sending a notification of each button to the SmartThings hub. In the thread, you can see exactly the steps the person went through to get the information needed to write the DTH.
Because the IKEA Remote is intended to control zigbee lights, I think you may be able, as has already been suggested in this thread, to start with the appropriate lightify DTH and then modify that. Who knows, the IKEA remotely may even end up being able to use either control method, like the lightify, and you will end up with two different DTH is that users can choose between. But regardless, you need to get some information from the IKEA device itself, and the thread I just posted will show you how that process works.
how to organize the code discussions
I suggest that, just as was done with the lightify device, you start a new topic for each DTH project under, well, “projects.” In that thread you can discuss what you’re trying to do, get help from other people, brainstorm any problem if you run into. This will be your development thread.
Then when you have a completed DTH ready for beta testing, start a brand-new thread under community – created device types and put the link to the github where the code is in the very first post of that thread. But wait to post in this section until you have a working device type handler at least ready for beta testing.
That way in the future when people are just looking for the DTH, they will be to find it quickly. But during the development process you will be able to get help and feedback from other community members in the development thread. And you will keep this thread, which really should be for discussion of the devices themselves, from getting flooded with code discussions.
In the end, I’ve used @SmartHomePrimer’s instructions coupled with the information in your post to conclude that while I can get the 5 button remote to work to turn off/on the lights, I’m unlikely to get it to operate with the hub directly.
I’ve now got my bathroom set up with 6 tradfri GU10s controlled by an ST motion sensor, and the remote paired as a secondary. It means that the button can be used if you’re in the bath or such, as the motion sensor is on a 5 mins and turn it off set up.