I have an Atag One central heating system and the corresponding themostat and want to control and monitor it through openHAB. There is no binding for this device, so in the past, I used a set of rules to connect to this device via this java application. This worked okay but was not a very elegant solution (at least to my opinion).
Now, recently, I have been experimenting with my own ESP8266 devices. In the process, I came along MQTT and the Homie convention, which work very nicely together with openHAB. So I thought, why not make my Atag One available as a Homie device? So that is what I implemented the past week. I created a Python script to read and write from the Atag One and bridge that to MQTT via the Homie convention. Luckily, I could use some building blocks available from Github so I did not have to invent the wheel again. The end result can be found in the atagone-mqtt-bridge project on Github.
I run openHAB via Docker, so for me it as natural to host this bridge also via a Docker container. The Dockerfile to build it can be found in the project. (I still have to find out how to publish these containers). But it should also be possible to run this bridge as a Python service (e.g. in openHABian).
I hope this solution is useful and please comment if you have any question or remarks.
This is amazing and exactly what I was looking for. I haven’t done anything with MQTT yet and was wondering if you maybe have a step by step tutorial how to set everything up?
I am running openhab on a PI, so not quite sure how this works with Docker. Any help would be much appreciated.
@Ltty There is a lot of information in the docs and on this forum on how to setup MQTT and OpenHAB. I recommend using the v2 MQTT binding and Mosquitto as the MQTT broker. I am not running my OpenHAB system on a Pi but on an Synology NAS (X64), so I cannot help you with that.
With regard to Docker: it is not strictly necessary to use Docker to use the bridge. I just made it for convenience. And I fear that you will not be able to use the Docker image as it was build for X64 not ARM so it is not compatible with the Raspberry Pi.
But you really don’t need Docker. can just run the script using a Python environment. It should just work on a raspberry Pi that way. Just take a look at the instructions at Github.
Which python version do you run the app with? I am getting some weird “invalid syntax” errors when I try yo launch the python script on my Pie with python 3.5.3. Requirements are installed…
I use Python 3.8.so that should work for you. I guess the invalid syntax is due to the fact that interpolated strings are used in the code. These are supported since Python 3.6.
sorry for asking stupid questions. I managed to fix the python issue by updating to 3.8. The script now detects the ATAG one on my Pie, authorization seems to work as well, but when the script tries to create the Homie device, I get an exception
The assertion error is from the homie library. It looks like the settings['MQTT_BROKER'] variable is empty. If you set the MQTT_HOST environment variable, it will be used to set the settings['MQTT_BROKER'] for the library. This works well for Docker images.
If you do not want to work with environment variables, you can also generate a .env file (copy if from .env.sample) and set the MQTT_HOST there.
Thank you @ArdKuijpers. Managed to set it up and it seems to work. Had some issues with deploying at as a daemon because you have to add the EinvironmentFile directly to the demon, but everything’s fine now.
A last question: Does the binding offer a control to change the modes? I am in particular asking for the Fireblace Mode that you can activate for a specific time, or the vacation mode…
Great to hear you got it working. The binding does not offer switching the modes, but I just found that the underlying pyatag library does offer that. So I will try to add that feature to the bridge as well when I find some time to do that.
Version 0.3.0 is out with the new feature to get/set the central heating mode via the topic homie/atagone/controls/ch-mode. The mode for central heating and domestic hot water are also published in home/atagone/centralheating/mode and homie/atagone/domestichotwater/mode respectively, but they cannot be controlled from those topics.
Under the hood, the pyatag is used. This library uses different names for the central heating modes (e.g. away for vacation mode and boost for fireplace mode.) I made a pull request to change these. The docker image uses my fork of the pyatag library with the modes’manual,automatic,vacation,extend,fireplace’. Please inspect the homie/atagone/controls/ch-mode/$format topic to see what modes are supported.
got everything to work, great job. One last question: Away and Boost are usually connected to a timespan. I saw centralheating has a mode duration value which can’t be set. Is there something similar for controls so you can add a value for how long the away mode or vacation mode shall be active?
My code was based on version pyatag 0.3.4.4 and in version 0.3.5 the force parameter was removed. To be honest, I do not remember why I needed it, but the atagone-mqtt-bridge works fine without it. So you can remove force=True from atag_interaction.py line 40, or just checkout the latest version from Github.
I managed to fix the python issue by updating to 3.8. The script now detects the ATAG one on my Pie, authorization seems to work as well, but when the script tries to create the Homie device, I get an exception
