Integrate with Ikea Trådfri Gateway as bridge to communicate and control connected Ikea's ZigBee based smart lights, switches, and sensors

[Hedda]

Ikea have just released a new app-controlled network-attached home automation hub which will serve as a Gateway to control its new "Trådfri" series of affordable smart lights / lightbulbs, switches / remotes, and sensors, which in turn so far all uses ZigBee based protocols. These products are set to be released on the 31st of March 2017 in selected countries around the world.

https://www.cnet.com/news/ikeas-rolling-out-a-brand-new-smart-home-lineup/

http://www.ikea.com/ms/sv_SE/customer-service/about-our-products/smart-lighting/index.html

"Trådfri" means 'wireless' in Swedish, and Ikea have so far announced this very aggresivly low-priced network-attached (Ethernet) "Ikea Trådfri Gateway" home automation hub in their "Tradfri" series, as well as a wireless Motion Sensor Kit (that have integrated light sensor too), a wireless Dimmer Remote (which is accelerator-based), a wireless multi-switch remote, and several smart light bulbs of different formats and even a few unique panel lights. All these products will then be released in most other contries worldwide too as Ikea steps up manufacturing (and irons our the initial software bugs I guess).

Ikea had already leaked news about this upcoming gateway/hub more than 6-months ago, during the summer or 2016, and at that time they also revealved that they will use ZigBee and keep validated access to the gateway/hub as open as possible, including providing an open API for this network-attached home automation hub.

Ikea in Sweden are first to post this news about the network-connected Home Automation Gateway / Hub, but again these products will become available worldwide. Here is link to the Swedish links:

http://www.ikea.com/se/sv/catalog/categories/departments/living_room/36812/ http://www.ikea.com/se/sv/catalog/products/40337806/ http://www.ikea.com/se/sv/catalog/products/80338960/ http://www.ikea.com/se/sv/catalog/products/80338941/ http://www.ikea.com/se/sv/catalog/products/80349888/

Link are in Swedish for Ikea Sweden site, but the PDF manuals on each page are available in English and many more languages, however they don't say much other than mounting instructions.

http://www.ikea.com/ms/en_US/img/buying_guides/fy17/april/Home_Smart_lighting_Buying_guide_APRIL1.pdf

Reason why I think that this news being interested is Ikea's aggresive pricing might them the first to make two-way communication home automation really affordable for almost everyone while still following all the electrical safety and wireless communications regulations in all countries, as they are today well known to have very low prices yet good manufacturing quality items.

UPDATE 1: Sound as Ikea Trådfri Gateway software uses the Cypress WICED IoT platform SDK (formerly Broadcom WICED IoT platform before acquired by Cypress http://www.cypress.com/internet-things-iot ) and have choosen to base their implementation on OMA (Open Mobile Alliance) and Eclipse recommended IoT protocol standards of those three logical components; CoAP (coaps) and DTLS layers of the LwM2M (Lightweight machine-to-machine) security model for IoT device management and protocol stack, using IPSO (IP for Smart Objects) Smart Object Guidelines provide a common design pattern. That is, looks as if the communication between Android/iOS app and the Gateway takes place via OMA Lightweight M2M (LwM2M) wrapped in CoAP with DTLS.

http://openmobilealliance.org/data-models-for-the-internet-of-things/

Update 2: Jaime Jiménez (from the company Ericsson) who is an active member of the IPSO Alliance’s working group and part of the team that published the IPSO Smart Object Guidelines, posted this great teardown of the Ikea Trådfri implementation:

http://jaimejim.github.io/tradfri/

For those who don’t know, LWM2M is a protocol built around CoAP and use for managing devices. So things like firmware upgrades, error reports, etc. Apart form the management interfaces, LWM2M also adds a very simple Object Model for managing those devices. IPSO expands that set of Objects so that you can have application information too (e.g. sensor readings, commands, etc). IPSO defines objects and resources that map to device properties.

Particular pay attention to the IPSO Light Control objects:

https://github.com/IPSO-Alliance/pub/blob/master/reg/xml/3311.xml

If you want to know more about the wealth of data models out there you can check the IoTSI Workshop as a reference.

https://www.iab.org/activities/workshops/iotsi/

LwM2M (Lightweight machine-to-machine) meanwhile is a system standard in the Open Mobile Alliance. It includes DTLS, CoAP, Block, Observe, SenML and Resource Directory and weaves them into a device-server interface along with an Objects structure based on IPSO Smart Object Guidelines.

https://connect2.io/open-mobile-alliance-lightweightm2m-oma-lwm2m/ https://www.eclipsecon.org/na2014/sites/default/files/slides/Eclipsecon%20NA14%20-%20One%20protocol%20to%20rule%20them%20all-%20(1).pdf http://openmobilealliance.org/constrained-application-protocol-coap-is-iots-modern-protocol/

IPSO provide common object model for interoperability of IoT Devices and Applications.

https://github.com/IPSO-Alliance/pub/blob/master/reg/README.md https://github.com/IPSO-Alliance/pub/tree/master/reg/xml https://github.com/IPSO-Alliance/pub/blob/master/reg/xml/3311.xml https://github.com/IPSO-Alliance/pub

[bwssytems]

@Hedda Those are really affordable! Pretty much $17 USD for each item.

So, Ikea would need to publish an API that can be called for the ha-bridge to connect. We will need to keep looking into that.

[emiliosic]

From this link: http://www.ikea.com/ms/sv_SE/customer-service/about-our-products/smart-lighting/index.html

Zigbee lights should also work with other bridges like Philips Hue, Osram Lightify or Vera Plus

[michaelhinchey]

Cool. The more companies building smart home items the more it should drive down competition. I do wish these were zwa e but I have a very plus so zigbee will be just fine for now.

[Hedda]

While it is cool that Ikea have released a gateway/hub on their own I would personally much rather skip buying the Ikea Trådfri Gateway and instead buy and install an ZigBee USB-adapter in my mini-PC that I currently use for as my DIY home automation hub with Linux to control each Ikea Tråd Lightbulb and Lightpanel directly.

Problem with that simplter concept is that right now I don't know of which if any ZigBee USB-adapters and software libraries available that will work the ZLL (ZigBee Light Link) protocol which the Ikea Trådfri Lightbulbs and Lightpanels. Anyone here got some advice there?

[Matt8119]

There's a user on the hue developers forum that said it works with the old hub 1.0. https://developers.meethue.com/content/philips-hue-and-ikea-trådfri

[Hedda]

@emiliosic, Ikea Trådfri sensors and devices uses ZLL (ZigBee Light Link) protocol so will probably be made to work sooner or alter with hubs such as Samsung SmartThings Hub and Vera Plus. That is because those hubs are made by companies who made it the main concept for those hubs as commercial products to work with as many third-party devices as possible. That is, their goal is to make the hubs compatible with third-party sensors and devices. Samsung and Vera does officially support third-party devices.

But that is not the goal of the Philips Hue and Osram Lightify hubs. Thier goal is only for those hubs to work with their own devices, which means that they do not do compatibility testing with third-party ZigBee devices connected to their hubs. So while some third-party sensors and devices might work because they too use the ZLL (ZigBee Light Link) protocol, is not the goal of Philips or Osram to make third-party devices work stable with their hubs, as that is not in their interest. Philips and Osram want people to buy their own devices, so officially they only support their own devices connected to their hubs.

[emiliosic]

If the lights follow the standard there shouldn't be any development needed. Same goes for many Z-Wave devices which just work as generic. http://www.zigbee.org/zigbee-for-developers/applicationstandards/zigbee-light-link/ I mentioned the lightify bridge because I noticed that HomeSeer seems to have decided to use a lightly bridge instead of developing their own: http://www.homeseer.com/zigbee.html But agree, if you have a Vera, SmartThings or Wink, it would probably work either at launch or soon enough.

[bwssytems]

I believe what the OP intended is, will the ha-bridge support the Tradfri Gateway. This is a specific hub and will need an API to talk to. This Gateway would be on the level of the vera, wink hub or smartthings hub.

[Hedda]

@bwssytems That is exactly what I mean. Idea is that ha-bridge should be bridge to Ikea Trådfri Gateway. I did not mean that ha-bridge should communicate using ZigBee directly to the devices.

Amazon Echo => ha-bridge => Ikea Trådfri Gateway => Ikea Trådfri Lightbulbs/Lightpanels.

Google Home => ha-bridge => Ikea Trådfri Gateway => Ikea Trådfri Lightbulbs/Lightpanels.

Harmony Hub => ha-bridge => Ikea Trådfri Gateway => Ikea Trådfri Lightbulbs/Lightpanels.

Main problem with this is that we don't know if the Ikea Trådfri Gateway will offer a (documented) open API on the day-one of release. However I an interview with Ikea smart home development team from 6-months ago where they first leaked the news of plans to release Ikea Trådfri Gateway and in that article the Ikea developers specifically said that they do plan for the Ikea Trådfri Gateway to have an open API.

So if it an open API not available in the initial firmware pre-installed day-one of release, they might release an over-the-air update for the firmware sooner or later which will offer an open API. And even if they might not officially offer support to third-parties that uses that API once available, the Ikea developers of this product have at least stated they do want interoperability with third-party smart home solutions.

One possible option if the Ikea Trådfri Gateway does not offer an open API in the initial firmware pre-installed day-one of release is to hack the network communication between Ikea Trådfri Android/iOS application and the Ikea Trådfri Gateway, and then make library for ha-bridge software that can emulate an Ikea Trådfri Android/iOS app, similar to how ha-bridge software today emulate a Philips Hue Hub. That would of course be much more difficult and might not something that the developers of ha-bridge have any personal interest to dvelve into, but with the Ikea Trådfri series gateway and devices being so cheap and sold worldwide it will surley not be long before some other hacker hacks the communication between the Ikea Trådfri Android/iOS apps and the Ikea Trådfri Gateway and then publish that information or even code/library publicly for how to achieve exactly this. At it is several hackers usually have more insentive to hack stuff like this when a company does not offer an open API. Again, just look at the ha-bridge software and the Philips Hue Hub API.

Here are some more decriptive diagrams with paths to put these concepts in perspective of ha-bridge:

Amazon Echo => Hue API in ha-bridge => API by Ikea Trådfri Gateway => Ikea Trådfri device to control

Google Home => Hue API in ha-bridge => API by Ikea Trådfri Gateway => Ikea Trådfri device to control

Harmony Hub => Hue API in ha-bridge => API by Ikea Trådfri Gateway => Ikea Trådfri device to control

[AnderssonPeter]

The app is now downloadable on the google play store and apple app store , in case anyone wants to analyse it. https://play.google.com/store/apps/details?id=com.ikea.tradfri.lighting https://appsto.re/gb/NkWrhb.i

I have tried to start it in a virtual machine but it just complains that im not connected to wifi, then i tried to start it in arc welder, i came a little bit farther but then it just crashed.

[AnderssonPeter]

Has any one tried to dump the network packets leaving the trådfri app? (i don't have access to a physical android phone)

[peterhoffren]

@AnderssonPeter Tried to capture the packages from the app on my Android but tPacketCapture did not allow the Trrådfri app to work so I need another way to capture packages.. Also neither the iOS or Android app use any connection over HTTP what I could see when trying to capture req/resp.

[Hedda]

@AnderssonPeter maybe try loading Ikea Trådfri app in the Android Emulator?

https://developer.android.com/studio/run/emulator.html

You of course need to have to have a physical Ikea Trådfri Gateway pre-installed.

But not sure if can enable WiFi in Android Emulator to local network though?

https://www.techwalla.com/articles/how-to-enable-wifi-on-an-android-emulator

If that works then should be able to use Wireshark to capture all IP packages

https://www.wireshark.org

That would perhaps be simplest, but again don't know if WiFi works in emulator.

[AnderssonPeter]

@Hedda i don't have the official android emulator installed as that requires java and i don't want all those nagging java update popups.

I have tried with the visual studio android emulator, but none of the package capturing apps seem to work there sadly. And running wireshark on the host did nothing..

I have also tried android x86, but there i ran into the wifi problem and when i tried a solution to add wifi or fake wifi the emulator got stuck in a reboot loop..

[Hedda]

@AnderssonPeter You can install Android x86 in a virtual machine on VirtualBox or KVM

https://www.howtogeek.com/164570/how-to-install-android-in-virtualbox/

http://www.osboxes.org/android-x86/

http://www.android-x86.org/

[AnderssonPeter]

@Hedda i had it up and running on hyper-v and it worked until i managed to brick it when trying to fake the WIFI. But ill try with VirtualBox as i have that installed on one of my PC's.

[nox-uk]

Think you'll find Tradfri uses ZHA not ZLL. when IKEA stated they were Zigbee compliant they were, just using 'the other' protocol. Most of the other hubs (like the hue hub 2.0) use ZLL though i think home hub 1 can use ZHA with an old firmware. All it really means is don't rush out and buy some bulbs and expect them to work with your hue hub 2.0. (yet)

there is a big post on the hue developers forum about it here:

https://developers.meethue.com/content/philips-hue-and-ikea-tr%C3%A5dfri

On the plus side, it sounds like IKEA are aware of this (post #45) and will remedy at some future point.

[stenehall]

From what I could see (proxy:ing the app traffic) it's using DTLS v1.2. I can see a "Hello" from the client and then an encryption request. After that all data is encrypted. If I understand it all correctly it's using a PSK. I.e. we'd need to extract that to be able to talk to the gateway. I'm in no way good at network communication so I might be completely wrong on this.

[AnderssonPeter]

@stenehall you are correct it is using DTLS, some analysis has started here: https://community.home-assistant.io/t/ikea-tradfri-gateway-zigbee/14788/8

[Hedda]

Someone now looks to have figured out how exactly Android/iOS communicates with the Ikea Trådfri Gateway - Turns out it communicates using OMA LwM2M (Lightweight machine-to-machine) security model for IoT device management based on CoAP (Constrained Application Protocol) encrypted with DTLS (Datagram Transport Layer Security) using the PSK (Pre-Shared Key) written on under the physicial Ikea Trådfri Gateway box.

https://bitsex.net/software/2017/coap-endpoints-on-ikea-tradfri/

https://bitsex.net/software/2017/ikea-tradfri-zigbee-lights/

This Norwegian guy as linked in two blog posts above have already figured out how monitor and send control commands to the Ikea Trådfri Gateway using standard CoAP to send and recieve commands to its end devices (using DTLS based encrypted communication to the Ikea Trådfri Gateway over network).

https://tools.ietf.org/html/rfc7252

Ikea Trådfri Android application appears to be using multicast (224.0.0.1) to find the Ikea Trådfri Gateway, and then communicates using encrypted CoAP (coaps). Also, it does not look like the Trådfri Gateway attempts to talk to the Internet (as the device looks to have has no outgoing connections). The default Ikea Trådfri Android app is fairly basic, where it currently only let you create schedules for turning on and off, and you can control lights and create zones, and control zones.

Looks like Ikea might have conformed with OMA LightweightM2M (LwM2M) Object IDs and Resource Registry ID as unique identifier http://www.openmobilealliance.org/wp/OMNA/LwM2M/LwM2MRegistry.html Examples: 5750 Application Type 5850 On/Off 5851 Dimmer 5706 Colour

For those who don’t know, LWM2M is a protocol built around CoAP and use for managing devices. So things like firmware upgrades, error reports, etc. Apart form the management interfaces, LWM2M also adds a very simple Object Model for managing those devices. IPSO expands that set of Objects so that you can have application information too (e.g. sensor readings, commands, etc). IPSO defines objects and resources that map to device properties.

Particular pay attenton to the IPSO Light Control objects:

https://github.com/IPSO-Alliance/pub/blob/master/reg/xml/3311.xml

IPSO (IP for Smart Objects) Smart Object Guidelines provide a common design pattern: https://github.com/IPSO-Alliance/pub/blob/master/reg/README.md https://github.com/IPSO-Alliance/pub/tree/master/reg/xml https://github.com/IPSO-Alliance/pub IPSO provide common object model for interoperability of IoT Devices and Applications.

If you want to know more about the wealth of data models out there you can check the IoTSI Workshop as a reference.

https://www.iab.org/activities/workshops/iotsi/

OMA LightweightM2M (LWM2M) standard: http://openmobilealliance.org/iot/ http://openmobilealliance.org/iot/lightweight-m2m-lwm2m/ http://www.openmobilealliance.org/wp/Overviews/lightweightm2m_overview.html http://www.openmobilealliance.org/wp/OMNA/LwM2M/LwM2MRegistry.html http://www.openmobilealliance.org/tech/profiles/ https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/wiki http://devtoolkit.openmobilealliance.org/OEditor/Legal?back=Default http://www.openmobilealliance.org/wp/comments.html https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues http://openmobilealliance.hs-sites.com/keep_updated

Interestingly is that CoAP (Constrained Application Protocol) is the protocol which the OCF (Open Connectivity Foundation) backed by most industry gians is promoting to become the standard for IoT. As reference in IoTivity and AllJoyn projects which guidelines one can suspect that Ikea have followed when they choose to go with standard CoAP in the Ikea Trådfri Gateway and its apps.

[vidarlo]

I'm that norwegian guy. I was not aware of the standard, and I'm happy that you brought it to my attention.

I was not aware of ha-bridge either, but it seems interesting. So far I've been a bit stumped by that zero of the COAP libraries for python supports dTLS, and I don't want to go the java route... I got a couple more bulbs today, and confirm that they add the same place as the previous.

If I can be of any assistance, I'm happy to. If wanted I can provide a linux box with access to the gateway for anyone wanting to play.

The key that is used for communication is printed beneath the gateway, so there's no need for any cracking; it's perfectly open, albeit using a not-yet-so-common protocol.

[arturo182]

Hi guys,

You can easily talk to the gateway if you build the "dtls" branch of https://github.com/obgm/libcoap

And then enter examples and do stuff like:

echo '{ "3311" : [{ "5851" : 255 }] }' | ./coap-client -u "Client_identity" -k "YOUR_KEY" -v 10 -m put "coaps://192.169..0.3:5684/15001/65538" -f -

You can set the dimmer to something between 0-255.

You can also query all the available endpoints:

./coap-client -u "Client_identity" -k "YOUR_KEY" -v 10 -m get "coaps://192.168.0.3:5684/.well-known/core"

[Hedda]

@vidarlo Sound as Ikea have choosen to base their implementation on OMA (Open Mobile Alliance) and Eclipse recommended IoT protocol standards of those three logical components; CoAP, and DTLS layers of the LwM2M (Lightweight M2M) protocol stack. That is, looks as if the communication between Android/iOS app and the Gateway takes place via OMA Lightweight M2M (LwM2M) wrapped in CoAP with DTLS.

"Lightweight M2M (LWM2M) is a system standard in the Open Mobile Alliance. It includes DTLS, CoAP, Block, Observe, SenML and Resource Directory and weaves them into a device-server interface along with an Object structure."

http://openmobilealliance.org/data-models-for-the-internet-of-things/

https://connect2.io/open-mobile-alliance-lightweightm2m-oma-lwm2m/

http://openmobilealliance.org/constrained-application-protocol-coap-is-iots-modern-protocol/

http://openmobilealliance.org/data-models-for-the-internet-of-things/

https://connect2.io/open-mobile-alliance-lightweightm2m-oma-lwm2m/

https://iot.eclipse.org/standards/

https://eclipse.org/community/eclipse_newsletter/2014/february/article2.php

https://www.eclipsecon.org/na2014/sites/default/files/slides/Eclipsecon%20NA14%20-%20One%20protocol%20to%20rule%20them%20all-%20(1).pdf

The Wakaama project covers the LWM2M Protocol, CoAP, and DTLS layers of the LwM2M protocol stack for all three logical components. Wakaama is not a library but files to be built with an application. The Eclipse Wakaama project provides a C portable framework for building LWM2M clients and/or servers. The source code of Wakaama is available from the project webpage. It is written in C and designed to be portable on POSIX compliant systems.

http://www.eclipse.org/wakaama/

You can also build the "dtls" branch of libcoap from:

https://github.com/obgm/libcoap/tree/dtls

Anjay - C implementation of the client-side OMA LwM2M protocol have very good documentation:

https://avsystem.github.io/Anjay-doc/ https://github.com/AVSystem/Anjay https://avsystem.github.io/Anjay-doc/

Californium is another CoAP client from Eclipse (programmed in Java) which also supports DTLS

https://eclipse.org/californium/ https://github.com/cetic/6lbr/wiki/Example-:-Dtls-Coap-Server https://people.inf.ethz.ch/mkovatsc/resources/californium/cf-dtls-thesis.pdf

And the Eclipse Leshan project provides a Java implementation of LwM2M, allowing to build LwM2M servers and clients. The source code of Leshan is available from the project webpage.

http://www.eclipse.org/leshan/

[Hedda]

OMA LightweightM2M (LWM2M) standard: http://openmobilealliance.org/iot/ http://openmobilealliance.org/iot/lightweight-m2m-lwm2m/ http://www.openmobilealliance.org/wp/Overviews/lightweightm2m_overview.html http://www.openmobilealliance.org/wp/OMNA/LwM2M/LwM2MRegistry.html http://www.openmobilealliance.org/tech/profiles/ https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/wiki http://devtoolkit.openmobilealliance.org/OEditor/Legal?back=Default http://www.openmobilealliance.org/wp/comments.html https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues http://openmobilealliance.hs-sites.com/keep_updated

[Hedda]

@arturo182 tinydtls-coap is another attempt to integrate the libcoap and tinydtls client-server

https://github.com/thecodemaiden/tinydtls-coap

You are then missing implementation of the LWM2M standard an top of CoAP.

[arturo182]

@Hedda, yes I have tried that one, it has the psk hardcoded and even when I changed that I still couldn't get a DTLS handshake, the dtls branch of libcoap works very well.

[r41d]

Bought my Trådfri starter kit today (in Germany where it was launched shortly ago) and have been following this thread attentively, nice insights so far :) The advice from @arturo182 was worth gold, but building libcoap was a little troublesome, so I summarized the installation in the following, might save others some time when experimenting:

#!/bin/bash
git clone https://github.com/obgm/libcoap.git
cd libcoap
git checkout origin/dtls
git checkout -b dtls
git submodule update --init ext/tinydtls
cd ext/tinydtls
autoreconf
./configure
cd ../../
./autogen.sh
./configure --disable-shared
make

I would recommend doing:

export GATEWAY_IP="192.168.XXX.YYY"
export GATEWAY_KEY="<gateway key from underside label>"

Then you can get available endpoints (from @arturo182):

./coap-client -u "Client_identity" -k "${GATEWAY_KEY}" "coaps://${GATEWAY_IP}:5684/.well-known/core"

or use dimming:

echo '{ "3311" : [{ "5851" : 255 }] }' | ./coap-client -m put -u "Client_identity" -k "${GATEWAY_KEY}" "coaps://${GATEWAY_IP}:5684/15001/65537" -f -

this dims one of my two bulbs (they are in different groups). 3311 is an ext-label for dimming, 5851 stands for a dimmer (0-100%), but the value after that seems to be 0-255. UDP 5684 is the port used by CoAP. 15001 seems to be the number of the endpoint used by the bridge and 65538 is the identifier for an actual bulb. My bulbs had the numbers 65537 and 65538 and there's something with the number 65536, this may be the remote that was used to pair the bulbs. Device number seem to start at 65536. Client_identity seems to be the default username for DTLS communication.

Procotol

I think the communication takes place via OMA Lightweight M2M wrapped in CoAP with DTLS. Most valuable resources so far:

• https://tools.ietf.org/html/rfc7252
• http://www.openmobilealliance.org/wp/OMNA/LwM2M/LwM2MRegistry.html

A library listed under https://en.wikipedia.org/wiki/OMA_LWM2M#Implementations may be a better approach than writing LwM2M by hand, I'm currently looking into that...

[r41d]

OK, I now played a bit around with the Anjay LwM2M library and I would recommend it to anyone doing LwM2M, the documentation is just awesome. Link: https://github.com/AVSystem/Anjay Compilation is easy and is explained in the README.

Here's what I tried so far:

As a preparation I would suggest again:

export GATEWAY_IP="192.168.XXX.YYY"
export GATEWAY_KEY="<gateway key from underside label>"

Then, use the demo binary that was created during compilation. Connecting to a coaps-DTLS server requires quite some parameters, Identity and Key need to be supplied "hexlified", which xxd -p poes.

./output/bin/demo \
    --server-uri "coaps://${GATEWAY_IP}:5684" \
    --security-mode psk \
    --identity `echo -n "Client_identity" | xxd -p` \
    --key `echo -n $GATEWAY_KEY | xxd -p`

This prints a lot of successfully registered object and then manufacturer: 0023C7; serial number: 000001, that doesn't look bad, but I haven't gotten any further yet, but the above command should serve as a good starting point.

[Hedda]

FYI; pautomate from the Home Assistant community put together a simple Python implementation for his Raspberry Pi.

https://community.home-assistant.io/t/ikea-tradfri-gateway-zigbee-very-basic-working-implementation/14788/19

"Taking no credit of all the hard work others have put in and just put my code here if you want to play around":

First installed the libcoap-library as such:

apt-get install libtool

git clone --recursive https://github.com/obgm/libcoap.git cd libcoap git checkout dtls git submodule update --init --recursive ./autogen.sh ./configure --disable-documentation --disable-shared make sudo make install

pautomate put together a very simple Python-script that execute by running shell_commands:

https://github.com/ggravlingen/home-assistant/blob/master/extraconfig/python_code/ikea.py

You then run the code by invoking:

python ikea.py "65537" "100" "Yellow"

Or, from within Home assistant as a shell command:

ikealight_off: '/usr/bin/python3 /home/homeassistant/.homeassistant/extraconfig/python_code/ikea.py "65537" "0" "Yellow"'

[Hedda]

@r41d FYI, Ikea is a customer of AVSystem who developed the LwM2M library Anjay (which is dual-licensed, bot as free and open source software and under a commercial license).

https://www.avsystem.com/news/avsystem-anjay-supports-lwm2m1/

https://www.avsystem.com/products/anjay/

While they don't say so outright one could suspect that Ikea uses commercially licensed Anjay and/or AVSystem Coiote for the Ikea Trådfri Gateway and its apps.

AVSystem Coiote it is a complete end-to-end solution for empowering IoT applications, which I understand relies on Anjay too.

https://www.avsystem.com/products/coiote/

https://avsystem.github.io/Anjay-doc/Commercial_support.html

[r41d]

@Hedda Hm, wasn't aware of that, but if they use it and if it's also open source then it should be a good choice. Have been digging a bit more into the Anjay and it contains nothing from the LwM2M Registry (http://www.openmobilealliance.org/wp/OMNA/LwM2M/LwM2MRegistry.html), this stuff needs to be coded by hand. But I found an intersting class in the Android App, after decompliling with apktool, it is located in com/ikea/tradfri/lighting/ipso/IPSOObjects.java. Here's an upload: http://sprunge.us/CCQF This lists a lot of constants that one can see when talking to the bridge (with this (https://bitsex.net/software/2017/coap-endpoints-on-ikea-tradfri/) in mind).

[r41d]

I just wrote a minimal web interface for controlling the brightness of Trådfri bulbs. It's absolutely dirty code, but I just wanted an working example to start with for now. You need to install libcoap with dtls like I described here: https://github.com/bwssytems/ha-bridge/issues/570#issuecomment-292036357 You also need to have Flask installed. Then you can download the server https://gist.github.com/r41d/65be2c7a111ac6c32f24d762ba38612c Place it one the same level in the file system as the libcoap folder and heed the instructions in the file. The interface is ugly as hell, but it's a first step. Have fun.

I also posted the instructions here: https://community.home-assistant.io/t/ikea-tradfri-gateway-zigbee-very-basic-working-implementation/14788/20 which seems to be a discussion with similar goals as here.

[hvanderlaan]

If also create a simple python script for reading the status of the lightbulbs that are paired with the hub. Still working on a framework that can get the status and put new state(s) to the lightbulbs.

Code is not up to my spec, but will post it soon.

script for reading lightbulb state: https://gist.github.com/hvanderlaan/3d8e11869f86ba94d9d6df1c815af3aa

small update: https://github.com/hvanderlaan/ikea-smartlight

light and group functions now working

[stenehall]

I spent some time writing a small homebridge plugin for this. https://github.com/stenehall/homebridge-ikea it works with some kinks.

[Hedda]

@stenehall nice but unfortutante that ha-bridge can not yet connect to Homebridge as a HomeKit bridge.

That is however a frequently asked feature request for ha-bridge:

https://github.com/bwssytems/ha-bridge/wiki/HA-Bridge-FAQs#Hb_Hk

For that related feature request can checkout discussions in https://github.com/bwssytems/ha-bridge/issues/366 and https://github.com/bwssytems/ha-bridge/issues/159

If it could then ha-bridge could indirectly take advantage of all the plugins that Homebridge supports:

https://www.npmjs.com/browse/keyword/homebridge-plugin

Amazon Echo => ha-bridge => Homebridge => Homebridge plugins for Ikea Trådfri Gateway & others

Google Home => ha-bridge => Homebridge => Homebridge plugins for Ikea Trådfri Gateway & others

Harmony Hub => ha-bridge => Homebridge => Homebridge plugins for Ikea Trådfri Gateway & others

[bwssytems]

I have been working on reverse engineering the HAP so that the ha-bridge can talk to homebridge or any other HAP device. The only thing is being the client side, there are no libraries and I am working with the server side. Currently, I am not getting consistent handshake results with the encryption.

[stenehall]

@Hedda I'm actually not using ha-bridge, only using homebridge atm. But since I'd followed this issue and commented in it I figured I'd provide what I had in terms of code :)

[cabo]

Learn more about IPSO objects at:

https://github.com/IPSO-Alliance/pub/blob/master/reg/README.md

[Hedda]

Matthew Garrett (Google security dev) have posted an analysis of the security of the gateway here:

https://mjg59.dreamwidth.org/47803.html

He seems sure the Ikea Trådfri Gateway software is based on the Cypress WICED IoT platform (SDK):

http://www.cypress.com/internet-things-iot

_A quick look at the Ikea Trådfri lighting platform

Ikea recently launched their Trådfri smart lighting platform in the US. The idea of Ikea plus internet security together at last seems like a pretty terrible one, but having taken a look it's surprisingly competent. Hardware-wise, the device is pretty minimal - it seems to be based on the Cypress[1] WICED IoT platform, with 100MBit ethernet and a Silicon Labs Zigbee chipset. It's running the Express Logic ThreadX RTOS, has no running services on any TCP ports and appears to listen on two single UDP ports. As IoT devices go, it's pleasingly minimal.

That single port seems to be a COAP server running with DTLS and a pre-shared key that's printed on the bottom of the device. When you start the app for the first time it prompts you to scan a QR code that's just a machine-readable version of that key. The Android app has code for using the insecure COAP port rather than the encrypted one, but the device doesn't respond to queries there so it's presumably disabled in release builds. It's also local only, with no cloud support. You can program timers, but they run on the device. The only other service it seems to run is an mdns responder, which responds to the _coap._udp.local query to allow for discovery.

From a security perspective, this is pretty close to ideal. Having no remote APIs means that security is limited to what's exposed locally. The local traffic is all encrypted. You can only authenticate with the device if you have physical access to read the (decently long) key off the bottom. I haven't checked whether the DTLS server is actually well-implemented, but it doesn't seem to respond unless you authenticate first which probably covers off a lot of potential risks. The SoC has wireless support, but it seems to be disabled - there's no antenna on board and no mechanism for configuring it.

However, there's one minor issue. On boot the device grabs the current time from pool.ntp.org (fine) but also hits http://fw.ota.homesmart.ikea.net/feed/version_info.json . That file contains a bunch of links to firmware updates, all of which are also downloaded over http (and not https). The firmware images themselves appear to be signed, but downloading untrusted objects and then parsing them isn't ideal. Realistically, this is only a problem if someone already has enough control over your network to mess with your DNS, and being wired-only makes this pretty unlikely. I'd be surprised if it's ever used as a real avenue of attack.

Overall: as far as design goes, this is one of the most secure IoT-style devices I've looked at. I haven't examined the COAP stack in detail to figure out whether it has any exploitable bugs, but the attack surface is pretty much as minimal as it could be while still retaining any functionality at all. I'm impressed._

[jaimejim]

I don't know if this has been mentioned in the long thread. The numbers you see are LWM2M/IPSO objects.

http://ipso-alliance.github.io/pub/

I wrote a blog post on that here, I am still working with the GW itself.

http://jaimejim.github.io/tradfri/

[sandyjmacdonald]

Was playing with the Tradfri lights today. Had some weird behaviour though. I was able to query the lights' state no problem, and got the expected response back but when trying to send a put request to control the lights I just got back a 4.00 response. I had two bulbs and a remote connected to the hub.

[matemaciek]

Thanks for all the effort! I've played with IKEA app and some of the devices, I can help reverse engineer some of the values in API.

[hvanderlaan]

@sandyjmacdonald if you are using groups (multiple lights) you have to address the group. This is not coaps://:5684/15001 but coaps://:5684/15004. Also sometimes I encountered the same issue when I use echo '{ .... } | soap-client .... you could send a payload with coap-client with the argument -e '{ json format }'.

example: coap-client -m put -u "Client_identity" -k "${TOKEN}" -e '{ "5850": 1 }' "coaps://${GATEWAY}:5684/15004/140387" Note: 140387 is a group id this could change per traderhub

you could take a look at my python code, this will show information of the lightbulbs and groups. It also can control lightbulbs and groups. You can power on and power off lights and groups, dim lights and groups and change color temperature of the lights only. Color temperature of groups are done by presets. I've not yet incorporate these. This will follow later this week when I have some more time.

Feel free to clone or fork my repo: https://github.com/hvanderlaan/ikea-smartlight

[matemaciek]

I've created simple (and kind of dumb) tool for Tradfri output to be more readable:

https://github.com/matemaciek/tradslator/blob/master/tradslator.py

I've used names from http://sprunge.us/CCQF and added some new ones basing on experiments with my setup.

Examples of its results:

$ ./libcoap/examples/coap-client -u "Client_identity" -k "${GATEWAY_KEY}" "coaps://${GATEWAY_IP}:5684/.well-known/core" | tr "," "\n" | python ./tradslator/tradslator.py
v:1 t:CON c:GET i:ec26 {} [ ]
decrypt_verify(): found 24 bytes cleartext
decrypt_verify(): found 935 bytes cleartext
<//{DEVICES}/65541>;ct=0;obs
<//{DEVICES}/65543>;ct=0;obs
<//{DEVICES}/65536>;ct=0;obs
<//{DEVICES}/65537>;ct=0;obs
<//{DEVICES}/65540>;ct=0;obs
<//{DEVICES}/65542>;ct=0;obs
<//{DEVICES}/65539>;ct=0;obs
<//{DEVICES}/65538>;ct=0;obs
<//{GROUPS}/131602>;ct=0;obs
<//{GROUPS}/153539>;ct=0;obs
<//{SCENE}/153539/203088>;ct=0;obs
<//{SCENE}/153539/203292>;ct=0;obs
<//{SCENE}/153539/209306>;ct=0;obs
<//{SCENE}/131602>;ct=0;obs
<//{SCENE}/153539>;ct=0;obs
<//{SCENE}/131602/205574>;ct=0;obs
<//{SCENE}/131602/209107>;ct=0;obs
<//{SCENE}/131602/217767>;ct=0;obs
<//{SCENE}/153539/228632>;ct=0;obs
<//{SCENE}/153539/199834>;ct=0;obs
<//{SCENE}/153539/217483>;ct=0;obs
<//{DEVICES}>;ct=0;obs
<//{DEVICES}/reset>;ct=0
<//status>;ct=0;obs
<//{SCENE}>;ct=0;obs
<//{GROUPS}>;ct=0;obs
<//{GROUPS}/add>;ct=0
<//{GROUPS}/remove>;ct=0
<//{NOTIFICATIONS}>;ct=0;obs
<//{GATEWAY}/{GATEWAY_DETAILS}>;ct=0;obs
<//{GATEWAY}/{UPDATE_FIRMWARE}>;ct=0
<//{GATEWAY}/{REBOOT}>;ct=0
<//{GATEWAY}/{RESET}>;ct=0
<//{GATEWAY}/{AUTH_PATH}>;ct=0
<//{GATEWAY}/{SESSION_ID}>;ct=0
<//{SCHEDULES}>;ct=0;obs
<//{SCHEDULES}/270213>;ct=0;obs

$ ./libcoap/examples/coap-client -u "Client_identity" -k "${GATEWAY_KEY}" "coaps://${GATEWAY_IP}:5684/15010/270213" | tr "," "\n" | python ./tradslator/tradslator.py
v:1 t:CON c:GET i:9d64 {} [ ]
decrypt_verify(): found 24 bytes cleartext
decrypt_verify(): found 169 bytes cleartext
{"{REPEAT_DAYS}":31
"{CREATED_AT}":1491151882
"{INSTANCE_ID}":270213
"{ONOFF}":1
"{SMART_TASK_TYPE}":4
"{START_ACTION}":{"{ONOFF}":1
"{LIGHT_SETTING}":[{"{INSTANCE_ID}":65538
"{DIMMER}":254
"{TRANSITION_TIME}":18000}]}
"{TRIGGER_TIME_INTERVAL}":[{"{START_TIME_HR}":3
"{START_TIME_MN}":30}]}

$ ./libcoap/examples/coap-client -u "Client_identity" -k "${GATEWAY_KEY}" "coaps://${GATEWAY_IP}:5684/15001/65540" | tr "," "\n" | python ./tradslator/tradslator.py
v:1 t:CON c:GET i:b7f7 {} [ ]
decrypt_verify(): found 24 bytes cleartext
decrypt_verify(): found 313 bytes cleartext
{"{NAME}":"Kuchnia"
"{CREATED_AT}":1491151779
"{LAST_SEEN}":1491860913
"{INSTANCE_ID}":65540
"{OTA_UPDATE_STATE}":0
"3":{"0":"IKEA of Sweden"
"1":"TRADFRI bulb E27 WS opal 980lm"
"2":""
"3":"1.1.1.1-5.7.2.0"
"6":1}
"{TYPE}":2
"{REACHABILITY_STATE}":1
"{LIGHT}":[{"{ONOFF}":1
"{DIMMER}":187
"5707":0
"5708":0
"{COLOR_X}":24930
"{COLOR_Y}":24694
"5711":0
"{COLOR}":"f5faf6"
"{INSTANCE_ID}":0}]}

It seems like encoder would be a nice addition, maybe next time.

[r41d]

@hvanderlaan @matemaciek nice, great stuff. I have been experimenting with libcoap and decided to fork it for better Tradfri support: https://github.com/r41d/libcoap-tradfri The repo contais a build script build_libcoap_with_tinydtls.sh which does all the work.

The new coap-tradfri example is just a variant of coap-client, but makes the invocation much easier. It currently defaults to 15001 as a path prefix, but that be changed very easy in the source.

coap-tradfri 192.168.X.Y -b 65537 -k abcdefghij
coap-tradfri 192.168.X.Y -b 65537 -k abcdefghij -m put -e '{"3311":[{"5851":0}]}'

This may be seen as a step forward, I mostly did it to learn something about libcoap and have an easier interface.

I also looked at other CoAP libraries that support DTLS (both also written in C):

• LibNyoci claims to have experimental DTLS support, but the linked issue doesn't exists. Not sure if I want to grapple with it.
• FreeCoAP looks like it has good source code quality and is also very small and lucid. But the DTLS examples there onyl use certificates, I wasn't able to figure out how to do PSK DTLS with it.

We definitely need to get rid of this ugly calling of external binaries... Either by using C (sigh...) or by wrapping libcoap/FreeCoAP, which looks like a tiresome task.

The last DTLS CoAP lib is the Eclipse Californium framework, which is also used by the official Android App. Even though it's Java, it may be the best shot at the time.

[Hedda]

Home Assistant developers ( ggravlingen / pautomate, balloob & turbokongen ) looks to be making great progress with their collaberation on a Python class to communicate with the Ikea Trådfri Gateway, and

https://github.com/ggravlingen/python-openikeatradfri

balloob also extracted that code from the platform into a standalone Python library

https://gist.github.com/balloob/e34241dafb28a855d4ba99b8bc2480c6

More discussion on that in the Home Assistant Community forum

https://community.home-assistant.io/t/ikea-tradfri-gateway-zigbee-very-basic-working-implementation/14788/

[hvanderlaan]

I found some small quarckiness, in the gateway,

1) you do not need / in the coaps url coaps://<gateway>:5684/1500165537 wil also work perfect. This is non-compliant with RFC7252 and RFC3986 2) when you power off a group with the mobile app, the group power state will retain the last status. { "5850": 1 } but the lightbulbs in the group are off { "5850": 0 }.

The first could be a security issue, or possibly a way to get more information from the gateway because /15002, /15009, /15011, /15012, /15013 will give a 4.04 not found. I will investigate.

The seconde is a bug, because the group can't be on while the individual lightbulbs are all off. Now is the only thing where do we need to address this bug.

[sandyjmacdonald]

Thanks so much @hvanderlaan!! That sorted the issue. You'll have seen our tweet using your code! :-) Do you know if there's a way to address bulbs individually when they're within a group?

[hvanderlaan]

@sandyjmacdonald Yes, you could change the state, dim or change the color individual from a group by addressing the lightbulb directly (/15001/)

[Hedda]

Another developer making progress is @hardillb :

https://www.hardill.me.uk/wordpress/2017/04/06/fist-pass-tradfri-mqtt-bridge/

https://github.com/hardillb/TRADFRI2MQTT