Ha-bridge: Integrate with Ikea Trådfri Gateway as bridge to communicate and control connected Ikea's ZigBee based smart lights, switches, and sensors
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.
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
Hedda
All 158 comments
@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.
bwssytems
on 27 Mar 2017
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
emiliosic
on 27 Mar 2017
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.
michaelhinchey
on 27 Mar 2017
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?
Hedda
on 28 Mar 2017
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
Matt8119
on 28 Mar 2017
@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.
Hedda
on 28 Mar 2017
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.
emiliosic
on 28 Mar 2017
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.
bwssytems
on 28 Mar 2017
@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
Hedda
on 29 Mar 2017
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
on 30 Mar 2017
Has any one tried to dump the network packets leaving the trådfri app? (i don't have access to a physical android phone)
AnderssonPeter
on 31 Mar 2017
@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.
peterhoffren
on 1 Apr 2017
@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
That would perhaps be simplest, but again don't know if WiFi works in emulator.
Hedda
on 3 Apr 2017
@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..
AnderssonPeter
on 3 Apr 2017
@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/
Hedda
on 3 Apr 2017
@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.
AnderssonPeter
on 3 Apr 2017
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.
nox-uk
on 3 Apr 2017
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.
stenehall
on 3 Apr 2017
@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
AnderssonPeter
on 3 Apr 2017
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.
Hedda
on 4 Apr 2017
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.
vidarlo
on 4 Apr 2017
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"
arturo182
on 4 Apr 2017
@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
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.
Hedda
on 5 Apr 2017
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
on 5 Apr 2017
@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.
Hedda
on 5 Apr 2017
@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.
arturo182
on 5 Apr 2017
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
on 6 Apr 2017
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.
r41d
on 6 Apr 2017
FYI; pautomate from the Home Assistant community put together a simple Python implementation for his Raspberry Pi.
"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
on 6 Apr 2017
@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
Hedda
on 6 Apr 2017
@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
on 6 Apr 2017
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.
r41d
on 6 Apr 2017
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
hvanderlaan
on 6 Apr 2017
I spent some time writing a small homebridge plugin for this. https://github.com/stenehall/homebridge-ikea it works with some kinks.
stenehall
on 7 Apr 2017
@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
Hedda
on 7 Apr 2017
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.
bwssytems
on 7 Apr 2017
@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 :)
stenehall
on 7 Apr 2017
Learn more about IPSO objects at:
https://github.com/IPSO-Alliance/pub/blob/master/reg/README.md
cabo
on 9 Apr 2017
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._
Hedda
on 9 Apr 2017
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.
jaimejim
on 10 Apr 2017
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.
sandyjmacdonald
on 10 Apr 2017
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.
matemaciek
on 10 Apr 2017
@sandyjmacdonald if you are using groups (multiple lights) you have to address the group. This is not coaps://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
hvanderlaan
on 10 Apr 2017
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}]}
md5-74f14993e8bb2a375834474c7cb9d174
$ ./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.
matemaciek
on 11 Apr 2017
@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.
r41d
on 11 Apr 2017
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
Hedda
on 11 Apr 2017
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.
hvanderlaan
on 11 Apr 2017
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?
sandyjmacdonald
on 11 Apr 2017
@sandyjmacdonald Yes, you could change the state, dim or change the color individual from a group by addressing the lightbulb directly (/15001/
hvanderlaan
on 11 Apr 2017
Another developer making progress is @hardillb :
https://www.hardill.me.uk/wordpress/2017/04/06/fist-pass-tradfri-mqtt-bridge/
Hedda
on 12 Apr 2017
The Ikea tradfri uses the iCoAP libs, this lib supports http/https proxy. Maybe in the future this will/could be enabled. When this is done the lib-coap / coap-client is not needed any more because you could talk to the http/https proxy.
https://github.com/stuffrabbit/iCoAP
If they enable this function the python module requests of urllib should be sufficent to talk with the hub.
Ik got also feedback from Ikea, they tolled me that from October the tradfri will have Apple's Home Kit support. So I thing they will open up the api :smile:
hvanderlaan
on 12 Apr 2017
https://www.hardill.me.uk/wordpress/2017/04/06/fist-pass-tradfri-mqtt-bridge/
A Java based mqtt bridge. Useful for a Openhab Add on writer?
Edit... Posted this in the wrong place - more than one window open
Justblair
on 12 Apr 2017
Did anyone actually try to reach out to IKEA and ask if they plan a public API documentation (similar to Philips hue)? It would make stuff much easier than having to guess how it works through reverse engineering...
kaikreuzer
on 12 Apr 2017
Yes: https://twitter.com/hardillb/status/848644863885271040
And half the fun is working it out for ourselves
hardillb
on 12 Apr 2017
I also had contact with Ikea, they say that in october they will add Apple's Home Kit Support. So there will be an api for this in the future. Also iCoAP can use a proxy but for now it is not enabled.
hvanderlaan
on 12 Apr 2017
I also used Ikea's contact-form a couple of days ago to ask if Ikea (Sweden) have any news to shere about their plans for an open/documentred API, but I have not recieved any reply to that as of yet.
Regardless I would advice everyone to write to Ikea and ask them to open up the Trådfri Gateway API.
http://www.ikea.com/ms/en_US/customer_service/contact_us/email_request.html
http://www.ikea.com/gb/en/customer-service/contact-us/email/
http://www.ikea.com/ms/sv_SE/kundservice/kontakta_oss/maila_oss.html
https://customersupport-ikea-nl-nl.custhelp.com/app/ask/
http://www.ikea.com/ms/en_HK/customer_service/contact_us/contact.html
Would be good if Ikea get more feedback so they understand that not everyone use Apple HomeKit.
Hedda
on 12 Apr 2017
Would be good if Ikea get more feedback so they understand that not everyone use Apple HomeKit.
I fully agree - I'll try to do my part to make IKEA aware of the importance of open APIs.
kaikreuzer
on 12 Apr 2017
I'm not sure it was in this thread, but I read that Ikea already confirmed
they are going to release an open API...
Sources:
https://www.dailybits.be/item/ikea-tradfri-smart-lighting-app-netwerkhub/ (in dutch)
"In vroegere interviews heeft IKEA beloofd om een open API interface te gaan aanbieden naar de Tradfri producten, zodat je deze kan connecteren met vele andere services. Momenteel is deze nog niet beschikbaar en werkt alles enkel lokaal. IKEA doet het stap voor stap met hun Tradfri ecosysteem."
http://www.domoticz.com/wiki/Ikea_Tradfri_Gateway
"Ikea Trådfri Gateway comes with support for its own official Android and iOS apps from Ikea, however Ikea have also said that they are working on an open API for the Ikea Trådfri Gateway."
https://github.com/bwssytems/ha-bridge/issues/570
"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."
vandenberghev
on 12 Apr 2017
@hvanderlaan
I'm having the same problems as @sandyjmacdonald, I can read values through coap-client, but I can't seem to control my lights; I only get 4.00 as a response and neither the 5850 nor the 5851 values change.
I've tried controlling both the individual lights and the group, but I can't seem to get it to work. I've also tried the Python class with no success.
The commands I've tried for controlling the lights are:
echo '{"3311":[{"5851":254}]}’ | coap-client -u "Client_identity" -k $KEY -m put "coaps://$IP:5684/15001/65537" -f -
and
echo '{"3311":[{"5850":1}]}’ | coap-client -u "Client_identity" -k $KEY -m put "coaps://$IP:5684/15001/65537" -f -
And for controlling the group:
echo '{"5851":254}’ | coap-client -u "Client_identity" -k $KEY -m put "coaps://$IP:5684/15004/166682" -f -
and
echo '{"5850":1}’ | coap-client -u "Client_identity" -k $KEY -m put "coaps://$IP:5684/15004/166682" -f -
4.00 as a response for all of the above. I'm starting to think I've got a typo somewhere in there... But then again, the Python class doesn't seem to work for me either.
andersmilton
on 12 Apr 2017
Try it the following way, @andersmilton:
coap-client -m put -u "Client_identity" -k "1a2b3c4d5e6f7g8h" -e '{ "3311": [{ "5850": 1 }] }' "coaps://192.168.0.10:5684/15001/65537"
OMG, works like a charm. Thanks @sandyjmacdonald!
andersmilton
on 12 Apr 2017
:-) Took me a while to suss that too. Not sure why the echo and pipe isn't working?
sandyjmacdonald
on 12 Apr 2017
Perhaps a character encoding problem or something? What platform are you on? I'm running it from a macOS terminal window through ssh to another Mac, so I guess there's plenty of room for translation errors...
andersmilton
on 12 Apr 2017
I'm SSHing into a Pi Zero W from a macOS terminal window.
sandyjmacdonald
on 12 Apr 2017
Looks like macOS could be the problem. Oh, well. As long as it works :)
andersmilton
on 12 Apr 2017
This is correct, it's an issues with macOS, on a ubuntu box i can use the echo way but the payload argument of coap-client is a very nice solution to use
hvanderlaan
on 12 Apr 2017
My default OS X terminal encoding seems to be UTF-8. You can find out your encoding with the command locale. And I found this quite interesting:
"Now that we have checked the local terminal settings, we should do the same for hosts where we ssh into. Luckily, ssh can forward our locales settings, just append “SendEnv LANG LC_ALL” to ~/.ssh/config and check that your locale is also available on the remote host. Voila, you have a properly working terminal with defined locales." (found at https://benjamin-schweizer.de/unix-terminals-surviving-the-encoding-hell.html)
vandenberghev
on 12 Apr 2017
On Apr 12, 2017, at 12:45, Sandy Macdonald notifications@github.com wrote:
coap-client -m put -u "Client_identity" -k "1a2b3c4d5e6f7g8h" -e '{ "3311": [{ "5850": 1 }] }' "coaps://192.168.0.10:5684/15001/65537”
Actually, you can leave off that :5684, that is implicit in the coaps:
Grüße, Carsten
cabo
on 12 Apr 2017
I've put together a tutorial about how to set all this up on a Pi, using @hvanderlaan's Python code, and showing how to use one of our (Pimoroni) Enviro pHAT boards as a light-responsive trigger, for those that might be interested.
https://learn.pimoroni.com/tutorial/sandyj/controlling-ikea-tradfri-lights-from-your-pi
sandyjmacdonald
on 12 Apr 2017
You can now also omit the -u for coap-client:
coap-client -m put -k "1a2b3c4d5e6f7g8h" -e '{ "3311": [{ "5850": 1 }] }' "coaps://192.168.0.10/15001/65537"
obgm
on 12 Apr 2017
It doesn't seem to let me omit the -u, but I found an easy way of changing the color of the light by using the RGB hex values (f5faf6, f1e0b5 or efd275) like so:
coap-client -m put -u "Client_identity" -k "$KEY" -e '{ "3311": [{ "5706": "f5faf6" }] }' "coaps://$IP/15001/65537"
I don't think I've seen that posted here before. I apologise if I'm mistaken :)
andersmilton
on 12 Apr 2017
I just implemented Color Changing (warm/normal/cold) for bulbs in the MQTT bridge from @hardillb:
https://github.com/r41d/TRADFRI2MQTT/tree/features
Awesome foundation by the way :+1:
If my pull requests get accepted, this should be the most complete open source Tradfri tool yet =)
r41d
on 13 Apr 2017
Some findings regarding /15011 a.k.a the gateway (mostly based on looking at the code of the Android app):
- a POST on /15011/9031 performs a soft reset
- a PUT on /15011/9034 is used for performing a firmware update, but it looks like this is not implemented yet (firmware payload is empty)
- a PUT on /15011/15012 can be used to perform many different operations (check OTA, commissioning, update time…) on the gateway, e.g update the current time by PUTting a timestamp with key 9060, etc.
- /15011/9033 is TBD
- /15011/9063 (POST) appears to be used for re-keying the gateway, as the code seems to involve the generation and transfer of a new PSK
kartben
on 13 Apr 2017
For those on linux based systems have a look at this...
https://www.hardill.me.uk/wordpress/2017/04/06/fist-pass-tradfri-mqtt-bridge/
It seems to rely on a coap library (hence the linux thing, unless I am mistaken) and creates a mqtt to tradfri bridge. Obviously it would be better if we had a binding that did it natively (and was cross platform)
Justblair
on 13 Apr 2017
@Justblair it's all pure java so should run (nearly) anywhere
hardillb
on 13 Apr 2017
Some inside news from IKEA, nothing official, it can be changed, don't get attached to them:
- they're working on open API,
- new products are to appear in October,
- even more products in April next year.
I can't say, what products they're going to introduce, but let's just say, that I think that RGB bulb and controllable plug sockets would be a nice addition to the system (-:
matemaciek
on 13 Apr 2017
Oh I see. I misunderstood the coap library thing.
And yet again posted in the wrong place ...
Justblair
on 13 Apr 2017
On Thu, 13 Apr 2017, Maciej Sokołowski wrote:
I can't say, what products they're going to introduce, but let's just say,
that I think that RGB bulb and controllable plug sockets would be a nice
addition to the system (-:
Do you have any information regarding the number of devices? I've seen a
maximum of ten devices connected - and this seems low in some cases.
vidarlo
on 13 Apr 2017
There is a limit of ten groups per gateway and ten devices per group, so limitation is not that painful.
matemaciek
on 13 Apr 2017
There is a limit of ten groups per gateway and ten devices per group, so
limitation is not that painful.
Ok, so we can connect 100 devices theoretically?
Do you happen to know if the gateway supports observation, as per RFC7641?
That would be a quite nice addition, as Ikea makes motion sensors and
dimmers for Trådfri.
vidarlo
on 13 Apr 2017
Observations work, but observing a dimmer does not give the level changes, I've not worked out what it is yet, but I suspect it might be the battery level
hardillb
on 13 Apr 2017
RGB bulbs from IKEA would be awesome, there is also already a hint in the code: the COLOR_X and COLOR_Y constants in the Tradfri Android App.
It's possible to express color with X and Y coordinates with the CIE 1931 color space: https://en.wikipedia.org/wiki/CIE_1931_color_space#CIE_xy_chromaticity_diagram_and_the_CIE_xyY_color_space
The following values from the CoAP traffic were extracted:
public static final String COLOR_COLD = "f5faf6";
public static final String COLOR_COLD_X = "24930";
public static final String COLOR_COLD_Y = "24694";
public static final String COLOR_NORMAL = "f1e0b5";
public static final String COLOR_NORMAL_X = "30140";
public static final String COLOR_NORMAL_Y = "26909";
public static final String COLOR_WARM = "efd275";
public static final String COLOR_WARM_X = "33135";
public static final String COLOR_WARM_Y = "27211";
Changing color temperatures doesn't need any of the X or Y values, but if we look at this picture https://upload.wikimedia.org/wikipedia/commons/3/3b/CIE1931xy_blank.svg
Not entirely sure how the scaling works, we have 0-1 in the linked picture but 5 digit integers in the CoAP traffic, 65535 is probably the maximum there.
Cold = 24930,24694 -> 0.38,0.38. Both values are almost similar. This is near to white in the wikipedia picture.
Normal = 30140,26909 -> 0.46,0.41. Greater values in both X and Y (though much more increase in X), it's probably somewhere in that yellow range.
Warm = 33135,27211 -> 0.51,0.42. Again, much more increase in X than in Y, it's probably in the orange area.
Does that sound reasonable?
r41d
on 13 Apr 2017
Yeah @r41d , that seems like a good approximation.
I must find some time to try some colors in the middle of Tradfri bulbs range. Maybe we can set more than three colors via CoAP? I dissected one of my bulbs, it has two colors of emitters, warm and cold, and, of course, that makes three available color temperatures. But I'm wondering whether we can set them to different brightness to achieve the whole spectrum between cold and warm white.
matemaciek
on 13 Apr 2017
You do indeed have full control over the colour temperature of the bulbs, and not just the three temps! Here's an example that ramps back and forth through the range:
import os
import time
import math
coap = '/usr/local/bin/coap-client'
securityid = 'xxxxxxxxxxxxxxxx'
hubip = '192.168.x.x'
lightbulbid = '65538'
tradfriHub = 'coaps://{}:5684/15001/{}'.format(hubip, lightbulbid)
while True:
scale_factor = (1 + math.sin(time.time() * 2)) / 2
payload = '{ "3311" : [{ "5709" : %s, "5710": %s }] }' % (25000 + int((8000 * scale_factor)), 25000 + int((2000 * (1 - scale_factor))))
api = '{} -m put -u "Client_identity" -k "{}" -e \'{}\' "{}"' .format(coap, securityid, payload, tradfriHub)
result = os.popen(api)
time.sleep(0.01)
For the integration with Home Assistant we made the following Python lib: https://github.com/ggravlingen/pytradfri/ . The Python abstraction maps the API 1:1
These are the constants that we have been able to figure out thus far
balloob
on 13 Apr 2017
@balloob You can also have a look at http://sprunge.us/CCQF
(Also finally put them on gist: https://gist.github.com/r41d/5d62033f88b3046bccf406c9158d4e59)
These are constants that I extracted from the Android Tradfri App, class com/ikea/tradfri/lighting/ipso/IPSOObjects.java
@matemaciek also used them in his tradslator I think.
r41d
on 14 Apr 2017
Hmm... everything seems to be broken for me. I wonder if IKEA pushed an update that somehow broke things. Not even querying the API with a get request from coap-client is working. :-(
sandyjmacdonald
on 15 Apr 2017
Hmm... everything seems to be broken for me. I wonder if IKEA pushed an
update that somehow broke things. Not even querying the API with a get
request from coap-client is working. :-(
Which firmware version do you have? My GW has 1.1.0015 and works perfectly
fine.
vidarlo
on 15 Apr 2017
FYI, Pimporoni posted step-by-step instructions for how pne could implement @hvanderlaan & @sandyjmacdonald Phyton code here:
https://learn.pimoroni.com/tutorial/sandyj/controlling-ikea-tradfri-lights-from-your-pi
They make it very easy to follow if someone who is not developer just want to try it out to test the functions.
Hedda
on 15 Apr 2017
Ops, didn not mean to close this, reopening.
Hedda
on 15 Apr 2017
Have fixed my problems, @vidarlo. It seems to be that one of the bulbs got stuck while updating and that was causing no requests to get through. Had to reset everything, pair everything again, and it all works as expected now.
sandyjmacdonald
on 15 Apr 2017
All these things works great if you have lights and groups set up, i'm trying to read the value directly off a remote/dimmer, but i'm suspecting that it doesn't work like that...
Does the hub know if a remote is clicked on or does that communication happen directly to the lightsource then the lightsource broadcasts it's state to the hub so that the app can read it?
Or is the only way to do that to build a zigbee device?
possan
on 16 Apr 2017
@r41d I figured out that the colorX and colorY (5709 and 5710) range up to 10000, because in the CIE color space the values range between 0-1, and here they're probably just scaled up.
With this in mind, I created a homebridge plugin that has full support for the Ikea gateway and light bulbs, including dimming and accurate color changing, natively from the Home app: szokeptr/homebridge-tradfri-plugin
szokeptr
on 16 Apr 2017
@szokeptr Hmm, did you look at my computations in my previous post and the correlation with the wikipedia picture? From that it looks much more likely that the maximum is 2^16-1=65535.
But I can't say anything definitive about this as I didn't do any testing like you or @sandyjmacdonald did, should make up leeway.
I think the most interesting part now, is which ranges are actually compatible to control the temperature.
r41d
on 17 Apr 2017
@r41d yes, it looks like you're right, however this way my method is not that accurate. I am actually converting the hue and saturation values from the Home app to RGB then to CIE XY values. The function I am using is outputting values in the range of 0-1, and when I scaled that up to 0-100000 the lights are following the color changes almost dead accurate. I changed the scaling factor to 65535 and this way the colors are all in a much colder zone. I'll do some more testing on this.
szokeptr
on 17 Apr 2017
@possan As described here: https://github.com/ggravlingen/pytradfri/issues/2:
You can indeed listen (subscribe) to changes on a bulb with -s
coap-client -u "Client_identity" -k {KEY} -s "60" "coaps://{IP}:5684/15001/65537"
This will leave the coap-client running and pop out new messages if there are changes, e.g. by clicking on any button on the connected remote or control the bulb within the app.
mariusobiegala
on 17 Apr 2017
Jaime Jiménez ( @jaimejim from the company Ericsson) who is apparently an active member of the IPSO Alliance’s working group, and especially worked in the team that published the IPSO Smart Object Guidelines, posted this great teardown of the Ikea Trådfri implementation:
http://jaimejim.github.io/tradfri/
He also shared a couple of links to related articles he posted earlier:
http://jaimejim.github.io/lwm2m-yang/
http://jaimejim.github.io/coap-functionality-lwm2m/
Also cheackout the IoTSI Workshop as a reference:
https://www.iab.org/activities/workshops/iotsi/
Interestingly enough Michael Koster ( @mjkoster who is the main author of these IPSO Objects) posted a comment to Jaime's post staying: "Great move on IKEA's part here. Too bad we hadn't published the IPSO lighting objects yet. Maybe we can talk them into registering the new identifiers with OMNA.".
Hedda
on 18 Apr 2017
@mjkoster is by the way the original author of iottoolkit - an IoT Toolkit with SmartObject API reference implementation and framework written in Python here which code could maybe be reused for this:
Hedda
on 18 Apr 2017
Hedda notifications@github.com writes:
FYI, Pimporoni posted step-by-step instructions for how pne could
implement @hvanderlaan & @sandyjmacdonald Phyton code here:https://learn.pimoroni.com/tutorial/sandyj/controlling-ikea-tradfri-lights-from-your-pi
Cool! One question: You are always using the -u "Client_identity". Is
this required for Trådfri (since commit dc91eb9 from Apr 12, you can
invoke coap-client without -u but I have no hardware to test against...)
obgm
on 18 Apr 2017
Hi all,
I hope it is ok that I ask the following question here.
It is a little bit off topic since it has nothing to do with the ha-bridge but I think this is a great thread for questions regarding IKEA's Trådfri API.
I have made a small shell script but it does not work.
The echo output looks good and if I copy and paste the echo output manually in a terminal window it will work.
I suspect that the error is caused by some wrongly escaped quote that is not shown with echo but I am new to shell scripts so I need some advice.
Thanks in advance!
tradfri.sh
#!/bin/bash
set -x #echo on
exec coap-client -m put -u "\"Client_identity"\" -k "\"$1"\" -e ''\'{ "\"3311"\": [{ "\"5850"\": $2 }] }''\' "\"coaps://$3:5684/15001/$4"\"
exit
echo output & response from the coap-client after running the shell script:
$ sh tradfri.sh KEY 1 192.168.0.1 65537
+ exec coap-client -m put -u "Client_identity" -k "KEY" -e '{ "3311": [{ "5850": 1 }] }' "coaps://192.168.0.1:5684/15001/65537"
v:1 t:CON c:PUT i:dfb1 {} [ ]
gobo-ws
on 19 Apr 2017
@gobo-ws I don't see why you would need exec. Also this looks like too many quotes. For example "\"Client_identity"\" translates to the string "Client_identity" being send, while it should just be Client_identity (which you can write as "Client_identity" for the -u parameter. Same for other parameters.
r41d
on 19 Apr 2017
@r41d thanks!
Do not know why I made it harder than it was...
The following line works fine:
coap-client -m put -u "Client_identity" -k "$1" -e '{ "3311": [{ "5850": '$2' }] }' "coaps://$3:5684/15001/$4"
gobo-ws
on 24 Apr 2017
Hi, My colleagues and I have tried all of the above methods, involving several builds of libcoap with dtls, as well as using golang implementations of DTLS over COAP (https://github.com/zubairhamed/canopus) but have had no luck. Have IKEA changed something, we simply cannot get a key/certificate exchange to occur, as shown by the following wireshark dump,
coap-client -m put -u "Client_identity" -k "bloop" -e '{ "3311": [{ "5850": 0 }] }' "coaps://10.0.2.117:5684/15001/65537"
v:1 t:CON c:PUT i:78d5 {} [ ]
^ No further output is produced
and
csjames
on 27 May 2017
@csjames have you tried installing pytradfri by ggravlingen and test as a proof-of-concept?
https://github.com/ggravlingen/pytradfri
Follow the instructions in its README.md you install libcoap fork from home-assistant repo.
Hedda
on 29 May 2017
Ikea has already said they are adding support for the echo, Google home, and homekit in a month...
Matt8119
on 29 May 2017
Homebridge
Matt8119
on 29 May 2017
Ikea has already said they are adding support for the echo, Google home, and homekit in a month.
@Matt8119 that does not help Ikea Trådfri Gateway emulate Philips Hue API which ha-bridge does for us.
The way ha-bridge works is it emulates Philips Hue API because which brings compatibility to many more home automations systems since most of them are already compatible with the Philips Hue API.
Samsung SmartThings => ha-bridge => Ikea Trådfri Gateway => Ikea Trådfri Lightbulbs/Lightpanels.
Vera => ha-bridge => Ikea Trådfri Gateway => Ikea Trådfri Lightbulbs/Lightpanels.
Harmony Hub => ha-bridge => Ikea Trådfri Gateway => Ikea Trådfri Lightbulbs/Lightpanels.
Once ha-bridge gets native support for Ikea Trådfri Gateway then you can use ha-bridge as bridge to other systems that does not yet have native support for Ikea Trådfri Gateway, such as Samsung SmartThings, Vera, Harmony Hub, and many more that already supports Ikea Trådfri Gateway.
Hedda
on 29 May 2017
Yeah so I have tried the pytradfri aswell, and just get a request timeout unfortunately
python3 -i -m pytradfri 10.0.1.5 bloop
DEBUG:pytradfri.coap_cli:Executing 10.0.1.5 get ['status']
Traceback (most recent call last):
File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/home/james/libcoap/pytradfri/pytradfri/__main__.py", line 18, in
api = api_factory(sys.argv[1], sys.argv[2])
File "/home/james/libcoap/pytradfri/pytradfri/coap_cli.py", line 104, in api_factory
request('get', ['status'])
File "/home/james/libcoap/pytradfri/pytradfri/coap_cli.py", line 58, in request
raise RequestTimeout() from None
pytradfri.error.RequestTimeout
csjames
on 29 May 2017
@csjames Me and a collegue had a similar problem. Turned out that the key printed in text was wrong, turned out that the QR code had an "o" instead of a "c", might have been scraped off but it was not easy to detect. Scan the QR code with a cell phone just to be sure.
gabrielsson
on 31 May 2017
Last night we reset our Tradfri hardware by holding the reset button down and then resetting all settings within the application.
This lead to the coap working fine, then, after about 10 minutes the base station proceeded to update and the coap interface became unresponse (5 second delays) for both the apps and coap-client. Following the update, performance returned to normal and everything is working smoothly.
Thanks for all your help! :)
csjames
on 31 May 2017
Just added support for Moods in the MQTT bridge https://github.com/r41d/TRADFRI2MQTT/commit/eb90ef40f6a69b09ab05e080e6462d5435462686
Does anyone know if there is a DTLS-capable Python Library/binding yet?
All I've seen yet is this ugly calling of coap-client via subprocesses, this kinda keeps me from using anything else than Java atm :/
r41d
on 29 Jun 2017
I need a libcoap implementation with DTLS support for iOS. It seems nothing is available... any idea ?
ticatagdev
on 8 Jul 2017
Anyone aware of a polling command to update the reachable property? I want to know if a bulb is reachable. The problem is that it seems like this property is not updated until something is commanded without success. If I disconnect a bulb, the property is not updated in the gateway (according to pytradfri), also not when I check the status from the app. But if I try to command something it is updated after some time. For the cheaper lamp with fixed colour temperature I can send a command to change colour temperature as a "NOP" command, reachable is then updated. Don't know what to send to the other bulbs though, unless I save the commanded values and send them a again. Is there no "poll" command? Why doesn't the gateway poll the bulbs at a regular interval?
hanpal
on 12 Jul 2017
@hanpal Maybe you could try sending a command with invalid payload (out of range color XY values for example). In theory that would work the same like the color setting request on bulbs that don’t support it.
On 12 Jul 2017, at 10:27, hanpal notifications@github.com wrote:
Anyone aware of a polling command to update the reachable property? I want to know if a bulb is reachable. The problem is that it seems like this property is not updated until something is commanded without success. If I disconnect a bulb, the property is not updated in the gateway (according to pytradfri), also not when I check the status from the app. But if I try to command something it is updated after some time. For the cheaper lamp with fixed colour temperature I can send a command to change colour temperature as a "NOP" command, reachable is then updated. Don't know what to send to the other bulbs though, unless I save the commanded values and send them a again. Is there no "poll" command? Why doesn't the gateway poll the bulbs at a regular interval?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
szokeptr
on 12 Jul 2017
Nice idea but didn't work. Invalid values stopped by gateway or pytradfri. Had no effect.
hanpal
on 12 Jul 2017
After reading this thread it seems like we now know which commands we need to send but there is still no ha-bridge support. Is this correct?
If so is anybody working on the tradfri integration with ha-bridge or ha-bridge to homebridge automation?
Last question. With ha-bridge is it possible to use the philips hue app and control your light from abroad?
Thanks!
kloknibor
on 26 Jul 2017
I think this project needs more active developers other than bwssystems. One man can't do anything alone.
To your last Question regarding "control from abroad": No, because that would require to link ha-bridge with a hue account which i believe is not possible. You can use the hue app with ha-bridge, but only locally.
FloFoer
on 26 Jul 2017
To your last Question regarding "control from abroad": No, because that would require to link ha-bridge with a hue account which i believe is not possible. You can use the hue app with ha-bridge, but only locally.
To be fair, any person with enough knowhow to get ha-bridge running and working correctly is likely also able to configure a VPN server on their home router, in which case yes, yes you can control your lights remotely. (Though, I personally dont see the point in doing so, as we are all trying to build smart homes, the home should control the lights itself based on a variety of factors - having to remember to turn the lights on, off or dim to a specific setting while you're sitting on the playa with an umbrella drink isn't really a viable solution to this)
Oh, and IKEA has recently said (few days ago) their bulbs will be fully ZLL compatible as of the next firmware update so then you can mix and match Hue and Tradfri bulbs, hubs and actuators as needed.
emigrating
on 16 Aug 2017
I've added support for changing colour temperature in whole spectrum between 2200K and 4000K: https://github.com/ggravlingen/pytradfri/pull/48/files
Next step: add it in home assistant.
matemaciek
on 17 Aug 2017
@kloknibor Can't you just use the pytradfri solution?
emigrating
on 18 Aug 2017
Apparently E27 RGB bulbs are now available, today I bought one in an IKEA in Germany.
I didn't find anything online, so these gotta be released brand-new.
Here are some photos and screenshots: http://imgur.com/a/yC5VW
The Android App is able to display the colors that the bulb shows, but it's not able to set them. Setting RGB color only work ATM by repeatedly pressing the < and > buttons on the Tradfri remote.
Will try to do further investigation soon.
r41d
on 21 Aug 2017
As soon as I get RGB bulb I'll be able to add support to pytradfri. @r41d , do you have IKEA product number (8 digits)? I'll check when they'll be available in Poland.
matemaciek
on 21 Aug 2017
@r41d, what was the price of the RGB bulb compared to the 980lm white ones?
emigrating
on 21 Aug 2017
I've been having issues with my gateway and now cannot connect to it using coap-client. It was running firmware 1.1.0012 (i think) when i could connect but this lost connection to all the bulbs, which made it useless. I reset it and now it is running fireware version 1.0.008 according to the app. Bulbs are all connected however coap-client won't. Clicking check for updates says there are no updates. Any one had similar issues and know how to force it to update to 1.1.0015 from http://fw.ota.homesmart.ikea.net/feed/version_info.json?
davetaz
on 22 Aug 2017
@matemaciek: on the back of the box it says 703.389.51
@emigrating: It cost 35€ for an RGB bulb with a remote (10€ more than a regular white spectrum bulb with remote) Sadly it wasn't possible to buy one without a remote... but I just had to get one ^^
@davetaz: also recently got problems with the coap-client connection to my gateway, damn, maybe they changed something.
r41d
on 22 Aug 2017
@r41d I'm fairly confident my gateway has an issue at the moment as it won't upgrade. Will keep you posted.
davetaz
on 22 Aug 2017
If anyone wants to try most recent pytradfri with home-assistant, here it is https://github.com/home-assistant/home-assistant/compare/dev...matemaciek:dev
It includes full white spectrum support, so you can use flux now (-:
matemaciek
on 23 Aug 2017
I made an attempt to document the Lwm2m+IKEA JSON format that TRÅDFRI communicates with. It is derived from these sources:
- http://sprunge.us/CCQF
- https://github.com/ggravlingen/pytradfri/blob/master/pytradfri/const.py
- https://github.com/hardillb/TRADFRI2MQTT/blob/master/src/main/java/uk/me/hardill/TRADFRI2MQTT/TradfriConstants.java
And by querying my own Trådfri system with my own python script.
The format of the JSON structure below is my own invention so hopefully you can make sense of it...
```{
"15001": {
"name": "DEVICES",
"description": "Device ids for lights and remotes.",
"example": [
65536,
65537,
65538
],
"15001/reset": {
},
"15001/{DeviceId}": [
{
"9019": {
"name": "REACHABILITY_STATE",
"example": 1
},
"3": {
"name": "DEVICE_INFO",
"example": {
"1": "TRADFRI bulb E27 CWS opal 600lm",
"0": "IKEA of Sweden",
"3": "1.3.002",
"2": "",
"6": 1
}
},
"5750": {
"name": "APPLICATION_TYPE",
"example": 2
},
"9003": {
"name": "INSTANCE_ID",
"example": 65538
},
"9002": {
"name": "CREATED_AT",
"example": 1504616889
},
"9001": {
"name": "NAME",
"example": "Badass bulb"
},
"3311": {
"name": "LIGHT_CONTROL",
"example": [
{
"5708": 0,
"5709": {
"name": "LIGHT_COLOR_X",
"example": 30140
},
"5710": {
"name": "LIGHT_COLOR_Y",
"example": 26909
},
"5706": {
"name": "LIGHT_COLOR",
"example": "f1e0b5"
},
"5707": 0,
"5711": 0,
"5712": {
"name": "TRANSITION_TIME",
"description": "Specified in seconds/10.",
"example": 100
},
"5850": {
"name": "ON/OFF",
"example": 1
},
"5851": {
"name": "LIGHT_DIMMER",
"example": 160
},
"9003": {
"name": "INSTANCE_ID",
"example": 0
}
}
]
},
"9054": {
"name": "OTA_UPDATE_STATE",
"example": 0
},
"9020": {
"name": "LAST_SEEN",
"example": 1504769379
}
},
{
"9019": {
"name": "REACHABILITY_STATE",
"example": 1
},
"3": {
"name": "DEVICE_INFO",
"example": {
"1": "TRADFRI remote control",
"0": "IKEA of Sweden",
"3": "1.2.214",
"2": "",
"6": 3,
"9": 87
}
},
"5750": {
"name": "APPLICATION_TYPE",
"example": 0
},
"9003": {
"name": "INSTANCE_ID",
"example": 65536
},
"9002": {
"name": "CREATED_AT",
"example": 1504610844
},
"9001": {
"name": "NAME",
"example": "TRADFRI remote control"
},
"9054": {
"name": "OTA_UPDATE_STATE",
"example": 0
},
"9020": {
"name": "LAST_SEEN",
"example": 1504706016
},
"15009": {
"name": "SWITCH",
"description": "No references to this anywhere",
"example": [{
"9003": {
"name": "INSTANCE_ID",
"example": 0
}
}]
}
}
]
},
"15004": {
"name": "GROUPS",
"description": "Groups of devices.",
"example": [
154580
],
"15004/add": {
},
"15004/remove": {
},
"15004/{GroupId}": {
"5850": {
"name": "ON/OFF",
"example": 1
},
"9002": {
"name": "CREATED_AT",
"example": 1504610855
},
"9001": {
"name": "NAME",
"example": "My phat group name"
},
"9003": {
"name": "INSTANCE_ID",
"example": 154580
},
"9039": {
"name": "SCENE_ID",
"example": 205512
},
"9018": {
"name": "HS_ACCESSORY_LINK",
"example": {
"15002": {
"name": "HS_LINK",
"example": {
"9003": {
"name": "INSTANCE_ID",
"description": "DeviceIds reached by: 15001/DeviceId",
"example": [
65536,
65537,
65538
]
}
}
}
}
},
"5851": {
"name": "LIGHT_DIMMER",
"example": 0
}
}
},
"15005": {
"name": "SCENES_TOP",
"description": "Some kind of top scene structure",
"example": [
154580
],
"15005/{SceneTopId}": {
"name": "SCENES",
"description": "List of all scenes",
"example": [
217404,
228154,
203200,
205512
],
"15005/{SceneTopId}/{SceneId}": {
"9068": {
"name": "IKEA_MOODS",
"example": 1
},
"15013": {
"name": "LIGHT_SETTING",
"description": "Interesting that two LIGHT_CONTROL's are specified here.",
"example": [
{
"5708": 0,
"5709": {
"name": "LIGHT_COLOR_X",
"example": 30140
},
"5710": {
"name": "LIGHT_COLOR_Y",
"example": 26909
},
"5706": {
"name": "LIGHT_COLOR",
"example": "f1e0b5"
},
"5707": 0,
"5711": 0,
"5850": {
"name": "ON/OFF",
"example": 1
},
"5851": {
"name": "LIGHT_DIMMER",
"example": 203
},
"9003": {
"name": "INSTANCE_ID",
"example": 65537
}
},
{
"5708": 0,
"5709": {
"name": "LIGHT_COLOR_X",
"example": 30140
},
"5710": {
"name": "LIGHT_COLOR_Y",
"example": 26909
},
"5706": {
"name": "LIGHT_COLOR",
"example": "f1e0b5"
},
"5707": 0,
"5711": 0,
"5850": {
"name": "ON/OFF",
"example": 1
},
"5851": {
"name": "LIGHT_DIMMER",
"example": 203
},
"9003": {
"name": "INSTANCE_ID",
"example": 65538
}
}
]
},
"9003": {
"name": "INSTANCE_ID",
"example": 217404
},
"9002": {
"name": "CREATED_AT",
"example": 1504610855
},
"9001": {
"name": "NAME",
"example": "EVERYDAY"
},
"9057": {
"name": "SCENE_INDEX",
"example": 0
}
}
}
},
"15006": {
"name": "",
"example": [{
"9014": {
"name": "NOTIFICATION_STATE",
"example": 0
},
"9015": {
"name": "NOTIFICATION_EVENT",
"example": 5001
},
"9002": {
"name": "CREATED_AT",
"example": 1504794867
}
}]
},
"15010": {
"name": "SMART_TASKS",
"example": []
},
"15011": {
"name": "GATEWAY",
"description": "Operations on the gateway",
"15011/15012": {
"name": "GATEWAY_DETAILS"
},
"15011/9034": {
"name": "UPDATE_FIRMWARE"
},
"15011/9030": {
"name": "REBOOT"
},
"15011/9031": {
"name": "RESET"
},
"15011/9063": {
"name": "AUTH_PATH"
},
"15011/9033": {
"name": "SESSION_ID"
}
},
"status": {
"name": "",
"example": {}
}
}
```
pere5
on 7 Sep 2017
@r41d managed to get my gateway working. It would seem that the gateway might hold two firmware images and each time you reset the gateway it boots either the factory default or the latest one it has. So I had my gateway running 1.1.0015 but it was corrupt, so I reset and the gateway booted 1.0.008 and it remembered the devices. Although the gateway was running 1.0.0008 the updates screen said the gateway was up to date. This is because it was, I just wasn't running that image. I then reset it again and the gateway booted a working 1.1.0015 and forgot all my devices. After re-adding them everything is now fine and homebridge and coap is all happy.
davetaz
on 10 Sep 2017
Seemingly, IKEA released the first update to the Tradfri Android App.
One can now choose some colors when tapping on a bulb and then on the three dots: https://imgur.com/a/0A7iq
These are many more than those colors which one can cycle through by using the physical remote
r41d
on 22 Sep 2017
I'm gonna get my RGB bulb finally today, I know that they're in my IKEA (-:
matemaciek
on 22 Sep 2017
Someone know how to change color for an entire group ? I tried to change the mood but I didn't want to change my dimmer level.
Hydro8
on 27 Sep 2017
@Hydro8 I'm also interested in how to change for an entire group
pere5
on 29 Sep 2017
Hello guys, just wanna post my experience with development version of libcoap and some issues I have with it.
If you git clone libcoap and then checkout devel branch, you get v4.2.0alpha which is way forward of the latest stable in master (4.1.2) with a bunch of bug fixes etc.
Since I'm developing my own Tradfri coap-mqtt bridge in python2, I use coap-client extensively (no support for python yet and py3 version is incomplete) in polling mode, and I've noticed that it has more extensive output on stdout than before.
One line more, to be precise, where it writes additional info about data type it handles, so take care of that in your parsing programs.
But, one more thing that still fails, like in old version, is subscription, or observe.
It appears that you get Observe:0 option when using -s switch to coap-client which should emulate the usual mqtt subscribe method. Now, in coap-client it works for some time, but after some undetermined time it breaks and the client unsubscribes itself - or the server (Tradfri hub, in my case) kicks it out.
Playing with -s timeout doesn't really change anything, and I don't even understand what is exactly that timeout for.
So, my question - did somebody manage to effectively subscribe to an endpoint (topic) on coap server without this disconnecting behaviour?
If the problem is in coap-client, does anybody have and other cli coap client that actually works with tradfri?
I can't compile LibNyoci on multiple platforms, and FreeCOAP has no usable client and no DTLS, so...bummer.
UserXYZ
on 29 Sep 2017
@UserXYZ I believe it's an issue with libcoap, as we don't experience the issue with aiocoap over at ggravlingen/pytradfri
lwis
on 30 Sep 2017
Well, I guess then that the developer of libcoap made a bug that needs to be fixed, or he chose such behavior of coap-client deliberately, since that is supposed to be a test tool...
What surprises me is that no other contributor decided to fix it, or at least make subscribe parameter with value of zero work as normal Observe:0 option, which would actually be a regular no-timeout subscription.
Since I can't use Python 3 (still being under much of development etc), aiocoap is not a solution atm...
So, anybody knows of another software that can be used instead of libcoap? Should be written in C/C++ (simplest to build), have dtls using tinydtls (gnutls is pain to include and I'm not sure if it works with keys besides certs) and pretty much everything else that libcoap has...?
Like a better version of libcoap...
UserXYZ
on 30 Sep 2017
@UserXYZ You are always welcome to open issues on the libcoap bugtracker or discuss these on the libcoap mailing list. It is difficult to fix your issues if nobody knows about them.
You can adapt the amount of output produced by coap-client on stdout with the option '-v'.
Regarding the timeout: '-B' controls the time until coap-client terminates. By default, this is 90 seconds as documented in the manual page. The option -s controls the timeout until coap-client cancels the established observe relationship.
Regarding your question about alternatives to libcoap: There is Californium which has DTLS support, and AFAIK, there is a version of node-coap with DTLS support.
obgm
on 30 Sep 2017
I came a cross a similar problem : Getting something not supported by ha-bridge working with ha-bridge. (Denon Amplifier, Samsung TV, 433Mhz based HA kit and more.
Rather than delving into ha-bridge's code, I ended up writing my own php broker and ha-bridge just flings the http command at it and the broker sorts out the rest.
Alexa / Google => ha-bridge => My Broker => Insert Weird Gateway => Weird Kit here.
It appears from the above a similar approach is being attempted by some of you. The work carried out by Adreas Spiess may help : https://www.youtube.com/watch?v=wS8Vj0ba4ic.
rodders99
on 1 Oct 2017
@davetaz I have exactly the same problem, my gateway is stuck on 1.0.0008 and says there are no updates. I tried reseting with the hole button but it stays in the same version. How did you make it to boot to the other image?
skatsikeas
on 1 Nov 2017
Here are some of the things I did.
1) Keep trying the reset
2) Each time you do, also reinstall the app on your phone
3) Take the gateway back to IKEA (which is what I did in the end)
davetaz
on 1 Nov 2017
@lwis can you tell me how do you use aiocoap with ggravlingen/pytradfri code? In asynchronous mode, I suppose, because in synchronous mode it is just calling coap-client in the background (saw that in my process list) which kinda defeats the purpose of aiocoap...
UserXYZ
on 1 Nov 2017
@UserXYZ guts are all here buddy.
lwis
on 1 Nov 2017
@lwis Well, that didn't quite answer my question, but based on your link, I'd say async mode...
So, no problems with observation of resource, you can track it's state for as long as you like?
No need to poll, or at least disconnect and reconnect at some time to give the hub a chance to clean connections or something?
UserXYZ
on 1 Nov 2017
@UserXYZ Oh, you mean observation? Yes, coap-client has issues with observation, but aiocoap does not. You can observe until the connection is stopped at either end.
lwis
on 1 Nov 2017
@lwis Sweet, that's what I need...now just to figure out aiocoap's API to reimplement my code or switch totally to pytradfri as a base...oh, and learn Python3 alongside Python2...such fun...
UserXYZ
on 1 Nov 2017
@UserXYZ obviously I'd recommend using pytradfri 😉
lwis
on 1 Nov 2017
@lwis Weeell, that would be easier way to do it, for sure, but again it's also adding another layer.
my code->pytradfri->aiocoap and I could do my code->aiocoap but with more effort on my part...
Meh, I'll try with pytradfri first and then see if I get the hang of aiocoap's API, make another branch/version then.
UserXYZ
on 1 Nov 2017
I found my GW, but it is not open on port 5684
The gateway is running version 1.2.42, claiming to be hue-compatible.
I'm currently scanning all ports; none seem to be open.
leifnel
on 11 Nov 2017
With 1.2.42 IKEA changed the authentication. See the following link: https://community.openhab.org/t/ikea-tradfri-gateway/26135/148?u=kai
greluc
on 11 Nov 2017
Where do you find the coap-client?
I got the one from libcoap-1-0-bin in debian.
It does not have the -u option.
`
root@mini:# coap-client -m post -u "Client_identity" -k "qwertyuiopå" -e '{"9090":"nodered"}' \
"coaps://192.168.1.86:5684/15011/9063"
coap-client: invalid option -- 'u'
coap-client v4.1.2 -- a small CoAP implementation
(c) 2010-2015 Olaf Bergmann <[email protected]>
usage: coap-client [-A type...] [-t type] [-b [num,]size] [-B seconds] [-e text]
[-m method] [-N] [-o file] [-P addr[:port]] [-p port]
[-s duration] [-O num,text] [-T string] [-v num] [-a addr] [-U] URI
`
I'm trying to access the hub from node-red, and it will not authenticate.
node-red-contrib-tradfri 1.1.0
Registration did not work. Verify your settings and possibly try another identity. Note that an identity can only be used once and the response preshared key must be stored for usage with the identity
leifnel
on 11 Nov 2017
For testing of the gateway purpose i'm using the californium.tools (https://github.com/eclipse/californium.tools) and in my program i use the coap client implementation of the californium library.
greluc
on 11 Nov 2017
Hi, I've been following this (nice) discussion from the very beginning. The thing is that I would be interested in running some (source) code directly (bypassing the gateway) on the bulbs. Do you think it would be possible? (a piece of software running continuously in the bulb... if the temperature of the bulb falls down, then change the color to blue)
Pica4x6
on 20 Nov 2017
Hello! Tons of useful info and links in the thread, thanks! I have been playing with the new Trådfri Color bulb trying to figure out why it would not show the whole spectrum and found the answer by cracking one open. It does not have green LEDs. I have put some code, info and pictures here: https://github.com/ffleurey/ThingML-Tradfri so that you do not have to vut your own bulb :-) Cheers!
ffleurey
on 1 Jan 2018
@ffleurey Really nice library. Great that you have put the effort in to make the UI, really fun and works great.
gabrielsson
on 1 Jan 2018
Very informative thread. I'm trying to generalize some of the findings above into a handy CoAP Shell (https://github.com/tzolov/coap-shell) with some initial Ikea gateway support as well.
https://www.youtube.com/watch?v=zhEGFfCJwTg&feature=youtu.be
tzolov
on 8 Jun 2018
With the implementation of OpenHAB, Which has Tradfri connectivity, I will suggest that is the path to implement this.
bwssytems
on 5 Jun 2019
^ Please report @SamSpringPackaging for spam (go to the profile and click 'Block or report user')
vandenberghev
on 5 Aug 2019
@vandenberghev Thanks! He is reported and banned from BWS Systems
bwssytems
on 5 Aug 2019
Related issues
smanig
·
7Comments
JsChiSurf
·
6Comments
MallocArray
·
3Comments
sieropoli
·
4Comments
scottdalton
·
5Comments
Most helpful comment
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:
You can set the dimmer to something between 0-255.
You can also query all the available endpoints: