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

Anyway, some clever developers have already figued out how to comminicate with the gateway using encrypted CoAP (Constrained Application Protocol) with LwM2M IPSO provide common object model and have since developed this open source Python library to make implementations easier. Hopefully some interested Domoticz developers will be able to use this to create a Python plugin for Domoticz:

PS: By the way, "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).

Also interesting is thaty it just so happens that the current firmware of Ikea Trådfri Gateway is also compatible with Philips Hue lightbulbs (which are also ZigBee based), and while not confirmed the Ikea Trådfri Gateway might also be compatible with other ZigBee Alliance certified products (such as example Samsung SmartThings, OSRAM Lightify, and Iris by Lowe's, and perhaps even non-certified ZigBee devices as those from Xiaomi), so this Ikea Trådfri Gateway has the potential of becoming a cheap ZigBee gateway/hub for some very cheap sensors and devices.

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, and aim to be compatible with other ZigBee Alliance certified products, as well as in the future officially provide an open API and/or SDK for the Ikea Trådfri Gatewat network-attached home automation hub.

Reason why I think that this being interested to many people 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.

Much more detailed development information regarding is available here:

I own a Tradfri hub, a remote and three E27 WS opal 980lm bulbs, so I thought I'd give your plugin a try.
The Tradfri stuff is running fine on its own.
I am using an RPi B+ with Jessie and Domoticz 3.7431 beta.

I followed your instructions. After restarting Domoticz the IKEA Tradfri entry is showing up in de hardware section of Domoticz. IP and key can be inserted and saved. But the bulbs are not showing up in the devices section. The log is showing some errors:

The plugin will give an error when shutting down domoticz, due to unfinished threads. I've thought about a few possible ways to solve this, but haven't yet decided which way to go. I'm also thinking about implementing some kind of client (aka. domoticz-plugin)/server (=actually controlling the gateway) in order to support device-state-change notifications into domoticz, due to the no-asynchronous nature of the plugins-system.

Thanks for the reply. I guess I misread point 4 of your installation instruction. I did ../domoticz/plugins/pytradfri instead of ../domoticz/plugins/IKEA-tradfri/pytradfri. I moved pytradfri to the correct location and restarted Domoticz resulting in a new error message in the log.

Installed libcoap (to /opt/ikea/libcoap/ if it matters)
Added pytradfri and your scripts to /home/domoticz/plugins/IKEA-Tradfri/ (Running Debian Jessie on a non Pi box) /home/domoticz/ is the location of the domoticz install.
a Quick ls gives

Hi,
been playing with it and notice that the actual status is not reflected in Domoticz.
i.e. turn on via Domoticz but turn off via Tradfri control, Domoticz still thinks it is on.
Is this usual behaviour?

After a lot of delays, I have committed a new version of the IKEA-tradfri plugin to the git repository. This version support the latest changes to the plugin-system, and thus requires the latest beta-version of domoticz. The plugin uses a separate service to enable notification of state changes and to keep within the constrains of plugins not to use threads or async calls. This service is also written in python, using twisted and is intended to be run from systemd.

The plugin is still quite rough, and I'm not good at writing instructions, so a certain amount of trouble should be expected, any feedback, suggestions, code changes etc. are most welcome!

moroen wrote:After a lot of delays, I have committed a new version of the IKEA-tradfri plugin to the git repository. This version support the latest changes to the plugin-system, and thus requires the latest beta-version of domoticz. The plugin uses a separate service to enable notification of state changes and to keep within the constrains of plugins not to use threads or async calls. This service is also written in python, using twisted and is intended to be run from systemd.

The plugin is still quite rough, and I'm not good at writing instructions, so a certain amount of trouble should be expected, any feedback, suggestions, code changes etc. are most welcome!

Did you checkout the new aiocoap implementation option that they added to pytradfri?

Could you get around not using Twisted with that new aiocoap implementation option?

Cool regardless!

Yes, I've checked it out, and considered making the COAP-adaptor using the aiocoap, but decided to stick with the plain pytradfri-module for now, since there are quite a lot of hoops to jump through to get aiocoap working at the moment.

As to get rid of the need for the adaptor, Dnpwwo has clearly stated that plugins doesn't support spinning off threads or using asynchronous calls. The adaptor takes care of the asynchronous communication with the gateway, which is needed to support notifications of state-changes.

I think it's possible to create a module that controls lights without depending on a external service, but not one that allows for observing state changes (which I think will be even more important down the way, in order to support the motion sensor etc). Until (if ever) plugins support coap+dtls as a native protocol, I fail to see how to support the plugin-system's methods for communication (onConnect, onMessage etc) without some kind of external service that asynchronously observe states and then sends the message about changes to the plugin. I might be completely wrong on that account, naturally...