As described in the previous incarnations of this series (part I: introduction, part II: heating manifolds), the heating in our new house wasn't working very well, and I was working on finding out the root cause, as someone without too much proficiency in mechanical engineering, but with a software engineer background.
This installment is about our smart thermostats connected to a KNX (aka EIB) based backbone, that control the valves (turn on/off) on our heating manifolds for per-room temperature control.
I described in the previous post, I was suspicious of the thermostats, as some of our rooms were set to the same temperature, and one was warm while the other was cold.
These thermostats have a couple of parameters that can be adjusted that would significantly change their behavior. The most important ones from my perspective are
KNX access
KNX is a ~30 years old standard for building automation, spearheaded by the likes of Siemens and actually standardised as ISO 14543.
KNX uses a twisted pair cable, organized in a bus topology, to which all smart devices are connected to. Typical KNX devices are bus powered, e.g. they only need the bus cable to operate.
The bus offers an 9600 bit per seconds connection (e.g. 1200 bytes per sec), and can support roughly 50 datagrams per second. This is not very fast, but the delivery of these messages is very reliable over long distances. And usually everything you need is a couple of bytes per message.
The bus itself is organized into lines, which are grouped into areas which are grouped into domains, supporting a total of 57600 devices (256 * 15 * 15 per line, area and domain respectively), which can be extended further by using ethernet gateways (and filtering of datagrams so we stay below the bus limits).
Each device connected to the bus is "smart", in the sense they usually have some kind of program they execute, which involves communication with other devices on the bus. For instance, the thermostats are such smart devices, which perform temperature measurements and send valve open/shut signals to the valve motors. A light switch would similarly send a datagram when it is pressed. Producers and consumers of these messages are addressed using logical addresses (e.g. group addresses in KNX speak). In KNX, there's no central role, like an automation server. If something fails, only the respective functions of the house will be affected.
There are multiple connection options if you wanted to connect a computer to KNX. There are
I have to tell, that I was initially sceptical about KNX (the house was built ~20 years ago, so it seemed a bit old-school), but eventually I started to like it. The implementation of functions is pretty straightforward, ETS (the tool to configure it is Windows based, but works), and most importantly: Homeassistant worked out-of-the-box: the gateway was automatically discovered and after configuring a KNX based actor, I could flip it on and off easily from the Homeassistant interface.
Thermostats
I mentioned that the thermostats I had have a view parameters that affect how they operate, here's a screenshot to demonstrate, but there are a lot more, believe me (sorry, for this being German):
The boring part was to make sure the important settings are set to the same value: I made sure the base setpoint was set to 21 degrees everywhere. I also used a temperature sensor from Xiaomi to calibrate each of the thermostats and set their temperature adjustment properly. Some of the rooms had as much as 1.5C deviation in measurement, which can be a lot if you are around the comfort zone (20.5C feels cold, while 22C is comfy). Another potential issue solved. Unfortunately this was not the root cause.
I also set up Homeassistant to monitor the thermostats and display a card like below for each of the thermostats. The turquoise line is the "set" temperature, the red line is the measured one. The green/red bar on top shows when the valve to the specific room was open or shut.
You can immediately notice that our heating system is not "fast", it takes hours for heat to increase or decrease, which is because the relatively low water temperature used in under-floor-heating.
But what was more interesting is that the opening of the valves follows a rhythm: they are opened even though the temperature is above setpoint and closed shut even if the temperature is below setpoint. Why? It's as if someone applied PWM (aka pulse width modulation) to heating. PWM is used for "dimming" a led, turn on-off a led 50 times a second, with half the time on and half the time off, and you'll perceive a continuous light but with half the power. Increase "on" time vs "off" time within the same timespan, and you have precise control on the amount of light emitted.
This is exactly what my thermostats are doing with the valves, although at a much lower pace. Let me explain this a bit more in the upcoming episode, together with PI and PID regulation and how to tune the related parameters.
This installment is about our smart thermostats connected to a KNX (aka EIB) based backbone, that control the valves (turn on/off) on our heating manifolds for per-room temperature control.
I described in the previous post, I was suspicious of the thermostats, as some of our rooms were set to the same temperature, and one was warm while the other was cold.
These thermostats have a couple of parameters that can be adjusted that would significantly change their behavior. The most important ones from my perspective are
- the temperature adjustment: to offset to be added/substracted to the measured temperature to counter potential sensor errors
- the base setpoint: to set the mid-value on the thermostat, that can be increased/decreased locally with +/- 3 degrees.
KNX access
KNX is a ~30 years old standard for building automation, spearheaded by the likes of Siemens and actually standardised as ISO 14543.
KNX uses a twisted pair cable, organized in a bus topology, to which all smart devices are connected to. Typical KNX devices are bus powered, e.g. they only need the bus cable to operate.
The bus offers an 9600 bit per seconds connection (e.g. 1200 bytes per sec), and can support roughly 50 datagrams per second. This is not very fast, but the delivery of these messages is very reliable over long distances. And usually everything you need is a couple of bytes per message.
The bus itself is organized into lines, which are grouped into areas which are grouped into domains, supporting a total of 57600 devices (256 * 15 * 15 per line, area and domain respectively), which can be extended further by using ethernet gateways (and filtering of datagrams so we stay below the bus limits).
Each device connected to the bus is "smart", in the sense they usually have some kind of program they execute, which involves communication with other devices on the bus. For instance, the thermostats are such smart devices, which perform temperature measurements and send valve open/shut signals to the valve motors. A light switch would similarly send a datagram when it is pressed. Producers and consumers of these messages are addressed using logical addresses (e.g. group addresses in KNX speak). In KNX, there's no central role, like an automation server. If something fails, only the respective functions of the house will be affected.
There are multiple connection options if you wanted to connect a computer to KNX. There are
- serial (RS232),
- USB and
- ethernet based gateways.
I have to tell, that I was initially sceptical about KNX (the house was built ~20 years ago, so it seemed a bit old-school), but eventually I started to like it. The implementation of functions is pretty straightforward, ETS (the tool to configure it is Windows based, but works), and most importantly: Homeassistant worked out-of-the-box: the gateway was automatically discovered and after configuring a KNX based actor, I could flip it on and off easily from the Homeassistant interface.
Thermostats
I mentioned that the thermostats I had have a view parameters that affect how they operate, here's a screenshot to demonstrate, but there are a lot more, believe me (sorry, for this being German):
The boring part was to make sure the important settings are set to the same value: I made sure the base setpoint was set to 21 degrees everywhere. I also used a temperature sensor from Xiaomi to calibrate each of the thermostats and set their temperature adjustment properly. Some of the rooms had as much as 1.5C deviation in measurement, which can be a lot if you are around the comfort zone (20.5C feels cold, while 22C is comfy). Another potential issue solved. Unfortunately this was not the root cause.
I also set up Homeassistant to monitor the thermostats and display a card like below for each of the thermostats. The turquoise line is the "set" temperature, the red line is the measured one. The green/red bar on top shows when the valve to the specific room was open or shut.
You can immediately notice that our heating system is not "fast", it takes hours for heat to increase or decrease, which is because the relatively low water temperature used in under-floor-heating.
But what was more interesting is that the opening of the valves follows a rhythm: they are opened even though the temperature is above setpoint and closed shut even if the temperature is below setpoint. Why? It's as if someone applied PWM (aka pulse width modulation) to heating. PWM is used for "dimming" a led, turn on-off a led 50 times a second, with half the time on and half the time off, and you'll perceive a continuous light but with half the power. Increase "on" time vs "off" time within the same timespan, and you have precise control on the amount of light emitted.
This is exactly what my thermostats are doing with the valves, although at a much lower pace. Let me explain this a bit more in the upcoming episode, together with PI and PID regulation and how to tune the related parameters.
Comments