Private, personal, home automation


Hemtjänst does not require an internet connection to function, or a subscription to a cloud service. It's a local-first system that doesn't track you. You own your data and you can do with it whatever you want.

Vendor neutral

A single protocol lets you control all devices in your home. Bridges take care of translating between Hemtjänst and vendor-specific protocols and can also be used to extend Hemtjänst with new capabilities.

Real time

By leveraging MQTT all interactions feel immediate and real-time. Just like if you were interacting with a physical device in the real world. Anyone connected to the broker is immediately notified of any changes.


All components can use TLS to encrypt their communication. Additionally TLS client certificates or username and password combinations can be used to gate access as well as apply ACLs.


Apple HomeKit

Hemtjänst, the bridge, exposes as many devices as possible as HomeKit accessories and is a fully functioning HomeKit bridge. You can pair the iOS Home app with Hemtjänst and control your whole house from there.

kea Trådfri

Sladdlos and its sister component tradfri-mqtt expose devices connected to the TRÅDFRI gateway. This lets you control any light connected to the Ikea gateway through Hemtjänst.


Rödljus lets you control IR-based devices. It leverages lircd and an IR-blaster to send comands. It's like pressing actual buttons on a remote control.


zVåg makes devices connected through Z-Wave available to Hemtjänst. This can be devices like contact sensors, outlets etc.


Färgton emulates a Philips Hue v2 bridge and API. This lets you use the Hue app to control compatible Hemtjänst devices, like lightbulbs. It also means anything in the "Friends of Hue" ecosystem automatically works with Hemtjänst.


Sensorer is a Prometheus exporter. It exposes the data of sensor-like devices, for example temperature, in the Prometheus exposition format. You can use Prometheus to scrape this data and Grafana to graph it and get all kinds of insights into your home environment.


HallonLarm exposes the GPIO pins of a Raspberry Pi as topics onto the MQTT broker. You can listen for events or send commands letting you hack together anything your heart desires.


Currently a work in progress, Bidans is a ZigBee bridge. Similar to Zvag, it exposes any ZigBee connected device to Hemtjänst. This should obviate the need to support different vendor gateways, like Trådfri, and vastly expand the amount of supported devices.


Dammsugare lets you control a Eufy RoboVac. It leverages Rödljus under the hood to send the IR commands to turn the robot on and off.


Similar in spirit to dammsugare, flakt leverages Rödljus in order to be able to control a tower fan.



Bibliotek is a Go package that implements the Hemtjänst protocol as well as its discovery and announce mechanisms. You can use it to create your own vendor bridges or extend Hemtjänst with new capabilities.


A TypeScript library implementing the Hemtjänst protocol. From Node you can connect directly to the broker using TLS, plain TCP or through websockets. In the browser you can use websockets to connect to the broker.

Message broker

The message broker is the central nervous system of Hemtjänst. Any MQTT v3.1+ broker will do but we happen to be using Eclipse Mosquitto.


Node-RED is an open source programming environment for the Internet of Things. It supports MQTT out of the box letting you interact with all Hemtjänst devices. Use it to create any kind of automation you want.


This is a demonstration of how to turn on a lightbulb with just an MQTT CLI. It requires minimal understanding of the Hemtjänst protocol and no knowledge of what IoT protocol the device itself is using. Libraries like bibliotek take care of the discover/announce flow and keep monitoring for device updates in the background. The whole flow is shown here for completeness. If you already know the device topics there is no need for the discover/announce flow.

1. Start by subscribing to the announce topic

mqttcli sub -t 'announce/#'


Once you publish to the discover topic all devices will announce themselves to a announce/<id> topic. By subscribing to announce/# we'll receive all mesages published to topics underneath announce/. The # is the MQTT equivalent of a wildcard.

2. Discover all devices

mqttcli pub -t 'discover' -r -m ''

3. Receive all the device announcements

    "topic": "light/grp-193347",
    "name": "Kitchen",
    "manufacturer": "IKEA",
    "model": "Trådfri Group",
    "serialNumber": "193347",
    "type": "lightbulb",
    "lastWillID": "sladdlos-c7274f9f-471d-4674-8075-81ad4c2d31f0",
    "feature": {
        "brightness": {
            "getTopic": "light/grp-193347/brightness/get",
            "setTopic": "light/grp-193347/brightness/set"
        "colorTemperature": {
            "getTopic": "light/grp-193347/colorTemperature/get",
            "setTopic": "light/grp-193347/colorTemperature/set"
        "on": {
            "getTopic": "light/grp-193347/on/get",
            "setTopic": "light/grp-193347/on/set"
    "name": "Kitchen small_window",
    "type": "contactSensor",
    "manufacturer": "Telldus",
    "model": "Device 23",
    "feature": {
        "contactSensorState": {}

4. Subscribe to the kitchen light on/off state

mqttcli sub -t "light/grp-193347/on/get"

Possible device states

0: the device is off
1: the device is on

5. Turn on the kitchen light

mqttcli pub -t "light/grp-193347/on/set" -m '1'

6. Receive notification that the light has been turned on


One important thing to realise is that the value you receive on the get topic is the actual state of the device. When you publish to set, a bridge will then send the actual command to the bulb to turn on. Only once the light is on does a bridge publish the new state onto the get topic which you then receive. As such publishing onto get does not imply an update to set. Only if the device manages to achieve the new state will you get an update. get and set are a bit of a misnomer and are likely to get renamed to something like current and desired.