Hi there,
Thanks to you all for this amazing software. I have been using Openhab for a very long time (years…) but never had something to share.
Today I think I have something to share that may help others (it is possible this has been already done by any of the experts of the community, but I could not find something like this, so let me post and let’s see…)
I have just created a software that monitors Uponor underfloor heating thermostats and control thermostats setpoint individually when there is no BMS support in the controller.
Let me go in detail:
First of all, this is not only my contribution but also others:
The development of this software has been possible with the help of the EEVblog Electronics Community Forum. There is a post (Figuring out an RS485 protocol? - Page 1) started by alanambrose in which the reverse engineering process is almost done due to the help of alanambrose, jsouto, mitokondoria, dimmu311 and TBuyukkilic among others.
You have all the details (including disclaimers) in the github repo: GitHub - ddsuc3m/uponor-floorheating
I’m conscious that despite it works, there are many aspects of this software that have not been thoroughly tested.
Also, there should be a more elegant way to do this in general (sure) and to better integrate this in OpenHab (more than sure), but this way was comfortable to me…
Do not hesitate to enlighten me about how this software can be improved.
Application:
Monitor Uponor thermostats and control thermostats setpoint individually when there is no BMS support in the controller.
Uponor FloorHeating (and cooling) systems require a controller that uses a Modbus like (not real Modbus AFAIK) to communicate with thermostats spread over the house.
I guess the protocol would be the same (or quite similar) even for wireless thermostats (probably with less updates to save battery), but I could only test this with wired ones.
It has been tested using the smatrix base unit (X.145) and T-146 thermostats.
According to the document entitled “Uponor Smatrix Base PRO Controller X-147 Modbus RTU interface” (that can be easily found on the internet), PRO models (as X-147) can be connected to a BMS (as Openhab using modbus binding) and controlled according to the information on the document (very easy, and the way to go if you are lucky and have a PRO model).
For those who have a controller with no external BMS connection, as my case, we must tap the bus, as in a MITM attack, and do some reverse engineering.
Usage
Hardware:
You will need any kind of serial port (RS485/RS232) server (i.e. HF5122) to interface with the controller connected this way:
I used 19200,8,1,NONE (speed, data bits, stop bits, parity) for the RS485 port configuration (this servers have the option to process Modbus directly, but it does not work for me, so let the server send you all the bytes without processing).
Other people have reported not “magic” frequencies (as 19680bps) but those than cannot be selected in commercial serial server ports (in those cases and additional element as esp32 with RS485 hardware can be used but this guide is not covering it).
Software components
The software comprises the following components:
- TCP Client: that gets the information from the serial port server
- Bus: that estimates the bus idle time (to inject frames to change the setpoint temperature)
- Frame processor: with the help of a Frame Parser, it extracts data form the bus, discovers thermostats and provides the information to a MQTT client
- MQTT client: posts the values to a MQTT topic and subscribes to a child topic (per thermostat) to receive setpoint values.
How to use it
Full details on github
Result
Once the service is running, you can connect to your MQTT broker and see what is going on:
(Here there is a picture, but I’m not allowed to post more than one)
You can also play with the system and change the setpoint:
(Here there is a picture, but I’m not allowed to post more than one)
OpenHAB
Still have pending to integrate in OpenHABm but vía MQTT is quite simple.
I will let you know later how it goes.
Regards!