IKEA has increased the availability of their new "Smart Blinds" and they are pretty cool! But depending on your network they may not be that easy to set up... This article covers the process to work around an issue with gateway setup and review some of the problems with the system.
This post gets a little techy - but I swear most of it actually is in English. It's intended to be readable / accessible to anyone with a basic understanding of networks. If there are any particularly tricky bits, please let us know?
This article was written after I started a post on the IKEA sub-reddit - I kept searching for answers, but mostly saw questions. https://www.reddit.com/r/tradfri/comments/f1hni3/trouble_with_tradfri_connecting_gateway_only_one/
In Canada, the smart blinds (FYRTUR) product page is here:
https://www.ikea.com/ca/en/cat/smart-blinds-44531/
The gateway (TRÅDFRI) can be seen here:
https://www.ikea.com/ca/en/p/tradfri-gateway-white-00337813/
Out of the box, each blind includes a signal repeater (why?), battery, charger, and a remote. Some of these things are not or should not be necessary in many installs, so this does seem a bit wasteful. From what we can tell, you only need one signal repeater for an area, not one per blind (although we didn't test that) and each battery doesn't need it's own charger? So in the end you might have a bunch of spare accessories (wasted money and so on) at the end of a multi-blind install.
When you want to connect multiple blinds to each other, you do need to work through a repairing process - from what we've read you can control up to 4 blinds from one remote - I'm not sure why 4 - it seems limiting if you actually wanted to group all the blinds in a room together, but we didn't investigate that limitation seriously, as we were more interested in the Google Assistant integration. So, after getting the blind mounted, we turned to the second product. For all the things they do put in the box, you need to go to a different department to find the gateway device which is used to connect the Zigbee network for IKEA equipment to the rest of your network so you can control things from your phone, set timers, etc.
This is where the challenges really begin. Zigbee in general is a mess of walled gardens (isolated implementations of the same thing) so although I have access to a Philips Hue bridge, connecting an IKEA window blind to it is not an option. Admittedly, people are reporting connecting their IKEA light bulbs to Philips Hue, although many who tried are reporting it's "FaF" (Flaky as f*$%). Hue chose to support only their lights on their bridge. Much as IKEA will likely support only their products on theirs - which can leave you with multiple gateways for no reason other than manufactures not playing well with each other.
So with the need for another gateway clearly established, I plugged in the IKEA product and launched the app.
Following along, I got to a point where I saw this:
The trouble of course, was that the IKEA app could not find my gateway - troubleshooting to the rescue! I started the process, and saw this:
And that's where the help ended... Because my scenario (only the power light on) was not listed! What to do?
So I used a function on the router to capture the network traffic from the TRADFRI and here's what I saw:
I understand this might seem really complicated, but essentially what started at packet #14, just continued forever... because I happen to know what MDNS is (it's a multicast implementation of a DNS like protocol for turning names to IP addresses intended to enable devices on complex networks to find each other. My network supports MDNS - the router has an MDNS repeater which facilitates things like people on the trusted Wi-Fi casting things to speakers located on the IoT Wi-Fi - they find each other using MDNS.
So I did a little Googling on MDNS and IKEA - many people suggested turning it off - but that would break everything else that needs it!
So what I did do, was filter access to the MDNS service (on port 5353) so that the IKEA device could no longer find the MDNS service. Then I rebooted, and all the lights lit up - pressing back on the IKEA app, and pressing "try again" and bingo! We were connected!
Afterward I looked around and found there were a lot of posts online about this issue - some were on reddit, twitter, people were frustrated...
Of course getting connected was just the first step. After that, I had to pair the remote with the gateway, then pair the remote with the signal repeater, and the remote with the blind. I've heard people have trouble with some of those steps, but for me it worked rather well the first time.
Upon completing the pairing, I was able to start to program the blind. Each blind has a max length. Unfortunately, each blind does not have a minimum length. To work around that, when I created the automated schedule, I set it to only roll up the blind to 5% of the end. That seemed to solve the issue of the blind getting caught on itself / wedged against the wall - the wedging issue isn't really IKEA's fault - the blind wouldn't wedge except for a piece of trim around the window. But the lack of a minimum length setting is the reason there is a problem.
As one final test, I repeated my packet capture now that things were working, and got one little bit of disappointment... This is an example of a tiny thing you can't see - and how it can become a problem (there could be more - this is just the one that jumped out at me!). When devices on the IoT communicate with the world, they need to be very careful who they "talk" to. You do not want your cameras viewed by strangers! One of the ways this is supposed to be done, is by ensuring the device to service or app communication is encrypted.
The good news is that most of the communication between the gateway and the cloud is encrypted. The bad news is that some of it is not, and that the device listens on port 80 with a standard web service which just seems to return errors, but it's still a weakness / attack vector.
Here is a capture of what happens during boot up which is potentially more concerning though - the device goes to the internet to check a version number - sounds trivial I know - but because it's unencrypted, and does not verify the server it's connecting to, it's a big risk. It's very easy for an attacker to put their information / server in the middle in what's known as a man-in-the-middle attack when there is no encryption in place. What encryption WAS done, was using a slightly out of date version of TLS (1.2) and is hosted by - you guessed it! Amazon!
Here's a capture of the troubling data:
As you can see the information exchanged is plainly readable. The reason this is particularly significant is that this query happens each time the device is rebooted. If someone discovers a way to cause the gateway to restart they could in theory trick it into downloading a bad webpage which could be used to break the gateway. On the other hand, if the gateway was designed to confirm the identity of the server it was connected to, it wouldn't be as easy to potentially attack it.
In conclusion / summary, here's what's wrong:
- The productization / packaging is wasteful. The unit comes in heavy plastic, and includes parts which are not necessary for many multi-unit installs. That leads to waste.
- An issue with MDNS / possible error in implementation (or incompatibility with my setup)
- An issue with the app, where this situation SHOULD be included on the list of possible outcomes
- An issue with the gateway leaving port 80 (http) open, without apparent reason
- Using http during the boot up process, potentially compromising the device's security
- IKEA has many twitter handles - we messaged 3 of them (@IKEA @IKEACanada @IKEAUSAHelp) with no response
I hope that helps someone who gets stuck / and maybe the people at IKEA with their updates / fixes. We're happy to help if you reach out to us.
Thanks - feedback appreciated,
BitBlock Systems