Hometechnica Community

Cover image for HomeSmartHome - Implementing The Basic Actions
Lars Richter
Lars Richter

Posted on

HomeSmartHome - Implementing The Basic Actions

Welcome back to my little post series on building my own home automation suite. Today I will share my steps and experiences while implementing the basic actions.

The "Constrained Application Protocol" (CoAP)

As mentioned in the earlier posts, the IKEA Tradfri Gateway provides an API based on "Constrained Application Protocol" (or short "CoAP"). It's very similar to HTTP. You've methods like "GET", "POST", "PUT" or "DELETE" and endpoints with a fairly standard URI. But I don't want to dive too deep into this topic, because this could be a whole blog post itself.

To keep my sanity, I decided not to implement the protocol layer myself and use an existing library instead. 😄 Also, I already used a library when I explored the API initially. So I went with it. It's CoAPnet, a CoAP client for .NET applications. The only problem was, that for some reason, the application would not stop when it reaches the end. Luckily, the creator is active on GitHub and responded very quickly to my issue and the corresponding comments. Together we found a way for me to still use the lib.

Building a Small "Tradfri Library"

As mentioned in my last post, I plan to use the IKEA Gateway as well as my homee and build some kind of unified UI for them. The logical conclusion is, to create some kind of abstraction layer and split the two implementations (Tradfri and homee) into separate projects.

Maybe I will share the two implementations later on NuGet and/or GitHub for everyone to use. The prerequisite, of course, is that the project/library ever finished.

What is What? The Tradfri Property Codes

As the name suggests, CoAP is built for constrained environments. That's the reason, why the payload of the single messages looks pretty cryptic. To save important bytes, the property names are replaced by IDs. Here is an example response:

{
    "9001": "TV Ambient Light",
    "9003": 65537,
    "3311": [
        {
            "5850": 0,
            "5849": 2,
            "5851": 254,
            "9003": 0
        }
    ],
    "9002": 1607088608,
    "9020": 1617119091,
    "9054": 0,
    "9019": 1,
    "3": {
        "0": "IKEA of Sweden",
        "1": "TRADFRI bulb E27 opal 1000lm",
        "2": "",
        "3": "2.3.068",
        "6": 1,
        "7": 8449
    },
    "5750": 2
}
Enter fullscreen mode Exit fullscreen mode

Looks nice, doesn't it? 😄 Even if you use a formatter to print it in a pretty way, the individual property names are not very helpful. Some of them are easy to translate. "9001" seems to be the name of the device. "1" looks like it should be called "Manufacturer". But others won't tell you anything without documentation.

Now it gets interesting. Because there is no official documentation. But the internet can be a good place (like this community). I found "translations" for the most important pieces. But there are still codes that I cannot identify/associate with a property.

Implementation is easy, once you know the codes

Once you know the important codes, the implementation is straightforward. I already implemented functions for the following actions:

  • Show all connected devices
  • Show a specific device
  • Show all lights (all remotes, blinds, and plugs can also be controlled)
  • Switch a light bulb on and off
  • Set brightness
  • Set the color (for RGB bulbs)

A simple CLI

To make the tests with the real Gateway as simple as possible, I created a small CLI project, that uses my Tradfri integration project. It's also helpful to get a feeling for the interface I'm creating.

So, it's just a rudimentary integration, but playing with the lights using my own CLI and library sparks a lot of joy. 😄

Discussion (0)