Saving money with Fibaro thermostats, OpenHAB and Grafana

Tamas Føldesi
10 min readFeb 24, 2021

In some countries, including where I live, district heating is quite common. Apartment buildings in a given area get heating from a common, central place — called the heating central —in the form of hot water, transported via insulated pipes (well, that’s at least one solution).
Apartments then have radiators that the hot water warms up.
There is, of course, quite a difference in energy consumption (i.e how much heat is used) for the different apartments, depending on where they are located (top/ground floor/corner) and who’s living in them.

The Trigger

Shortly after I started with home monitoring, the housing association kicked off a project for installing energy meters on the radiators.
They were supposed to measure the amount of heat exchanged on each radiator, so that the consumption of each apartment could be calculated, relative to each other. The main heating bill would then be split up respectively.

Needless to say —before that, properly regulated heating throughout the whole apartment would have been just for our comfort (and our conscience), but suddenly it was all about money!

So I began researching the options for controlling the radiators with thermostats — if possible, in a centralized manner, so that I can adjust them remotely when needed.

Restricted by what I actually could buy in my country, finally I ended up with five pieces of Fibaro Heat Controllers. Now, those were meant to be operated via their own Fibaro Home Center — but that sounded like a pretty closed system, giving me no direct access whatsoever (or very little).
Part of the reason I chose Fibaro was that the Heat Controllers supported Z-Wave — and at that time it seemed like a good idea to exploit it, so I also got hold of an Aeotec Z-Stick, and a new Raspberry PI 3B — all this to build my own Z-Wave controller.

The Choice

I wish I could say that I found the right way to control my new toys immediately — but I did not.

I attempted to set up Home Assistant, Homeseer and OpenHAB (and a few more — but some of the alternatives I could find weren’t free, so those I didn’t try).
Luckily I forgot most of the failed attempts I had. Long story short, one of those just wasn’t willing to read from these devices, the other one didn’t want to configure them. Those issues were kind of deal breakers.

The least bad option seemed to be OpenHAB — it looked unnecessarily complex to set up, but at least it appeared to have full support for Fibaro devices, and it could run on Linux.

I suspect there is a term/theory I could not find that describes this phenomenon.
In order for OpenHAB to support the wide range of devices it supports, it had to have quite generic concepts that can cover all the different terms, naming conventions, configurations those devices might have.
At the end, this made it overly complex…
… and almost unusable.

But I already paid the money for the Heat Controllers, so I wasn’t allowed to give up, just like that.

Just to be precise — the Heat Controllers would function fine without a Z-Wave controller, as they had their thermometer attached, and there was a knob on them to adjust the desired temperature.
But I wanted remote control & monitoring…

OpenHAB setup

So first, the Z-Stick and OpenHAB had to be made friends. OpenHAB supports Z-Wave via a binding, which I installed and configured.
This was relatively easy, as the Z-Stick acts like a serial device, so I just had to find the right device ID, and enter it in OpenHAB:

Once OpenHAB began surfing the Z-Waves, I could start adding the Heat Controllers, one by one. To add one, I had to trigger inclusion mode on the device (three clicks on the hidden button), then find & accept it using OpenHAB’s Inbox:

Another side story — in theory, Z-Wave is using a mesh, so devices should be able to communicate with the controller via other devices, even if they themselves are too far for direct access.
But this didn’t seem to be the case for the Fibaro gadgets I had. I tried so many times, but finally I had to move the Raspberry PI to a place which was close enough to all the thermostats, while hidden enough to satisfy everyone’s aesthetic requirements.

So far so good. But how do I get to see the data, and control the thermostats?

For this, I had to create & assign Items to the Things’ Channels (have I mentioned that OpenHAB is really generic?).
So, a Thing is a device, in my case a Heat Controller. A Channel is something you can read from, or set on the d̶e̶v̶i̶c̶e̶ Thing, like, read the current temperature, or set the target temperature.
Note that this is different from the Thing’s configuration (LED on/off, open window detection, etc) — which can be set on a different page.
Finally, an Item is a logical representation of a physical parameter in your environment, like the current temperature in the living room.

Aren’t Item and Channel the same, you ask?
Well, once you connect them in OpenHAB, they indeed have the same value. But if I decided to throw out my Fibaro Heat Controllers, their Channels would cease to exist, while my living room would still have a current temperature.
The good thing is that once you have set up your Items, everything else is based on them, so you don’t have to redo the dashboards/etc if you decide to replace a Thing.

I haven’t read the whole history of the software, but it pretty much seemed like they themselves understood that file-based configuration is not every people’s dream.
This led to that one could create Items dynamically, from the UI (new method), or via a file that should sit in a given directory (old method).
Since further configuration (publishing data externally, groupings, etc) was dependent on statically (file-)configured Items, I invested some time to learn how to write proper configuration.
Finally I ended up with this as home.items :

Then I assigned these Items to the various Channels:

Control

That was all nice — first I added the Z-Wave Stick, then the Things, then the Items, mapped to Channels… but where is the data?!

Another confusing aspect of OpenHAB is the different kind of UIs one can use. After some trial and error, I stuck to PaperUI — that gave me the options I needed for the initial setup, and the rest (monitoring) I was planning to solve outside of OpenHAB anyway.

On PaperUI, after having mapped some of the Items to Channels, their values can be seen, grouped by Thing, on the Control tab. It is also possible to adjust some of the settings here:

So finally, I could control the thermostats, and also check what temperature their thermometer friends had measured.
Next step — charts!

Collect

Since I already had the infrastructure to collect & view time series data, I wanted to send temperature (and maybe other) metrics from the Fibaro Heat Controllers to the same place.

Luckily, OpenHAB supports InfluxDB persistence, so I just had to install the add-on & configure it to connect to a new database I created:

services/influxdb.conf
persistence/influxdb.persist

This went unexpectedly smooth —it worked immediately after I turned it on.

View

Back to Grafana —I added a chart which shows the temperatures in all the rooms that have heating:

The lines show the current, measured temperature, the legend shows the targets (so Heating Current is the temperature that the thermostats try to keep).

This graph looked promising — whenever the current temperature was over the target, the radiators were off, in other words, I was saving energy!

You could ask — how come there is such a huge difference between the target & current temperatures? Shouldn’t the thermostat be able to follow the target more accurately?
It would be nice, yes — but there are some other factors. First (and probably most unexpected by the poor thermostat) is that the temperature of the heating water varies, due to the heating central trying to save some energy itself, by sending higher temperature water only if it’s really cold outside. The thermostat most likely has something that’s called a PI(D) controller, which doesn’t tolerate this well.
Then there’s the thermal inertia of the room, there are windows & doors being opened/closed, the baking oven being fired up (hence the jump in the orange chart) — and so on.
Bottom line — I am pretty satisfied with the thermostats if they manage to keep the temperature within a 1°C error margin.

Some of those rooms also had a Wireless Tag, and I was curious to compare the two measurements, so I added the current temperature from the Fibaro devices to the respective charts I had from before:

The sensors of the two systems were mounted next to each other, and their readings correlate indeed, as expected.

What about the money?

The article’s title said something about saving money. So did I?

I think so.

It’s hard to say how much, due to a bunch of reasons.
First of all, we don’t pay according to the measurements each and every month. Instead, we pay the same monthly amount throughout the year, then at the end, we settle the difference between the sum of those, and the actual heating cost (which is the collective heating bill split up, based on the relative consumption of each apartment).

Second, that the whole energy-metering project is new, so actually I have no data to compare with, thus no idea how much I would have paid at year-end had I not installed the thermostats.

Third, that I had a little adventure with ventilation & icing, which in my opinion, negatively contributed to the case (wasting a considerable amount of heat).

Still, at year-end, I didn’t have to pay extra — I even got back a whole $60!
According to the statistics we received, there were many others who had to pay, the largest debt being around $2200. 😱

In retrospect

I had so many headaches with the setup. However, I am not so sure about what I would do differently.

Z-Wave seemed attractive at first, but the number of available devices, and their support in the open source space is limited, to say the least.
The implementation of the standard also seems to vary across manufacturers — my first attempt was a Danfoss Z-Wave Thermostat, which I couldn’t even get included in the Z-Wave network. It kept going to sleep after 5 seconds, even if it was in the middle of the pairing sequence.
Regardless — there are little to no alternatives, when you need open(ish) access, open source support and market availability.

As for the controller software, OpenHAB — each time I upgrade it, something stops working.
Once I had to re-add all the devices. Another time it began dumping exceptions like crazy, until I disabled something that was new, was turned on by default, and apparently was not working. Then the third time, I lost InfluxDB integration without an error message of any sort, but it began working again after three restarts.
Despite all these, OpenHAB still seems the least bad alternative — at least for the devices I have.

Fibaro, as a manufacturer, was perhaps the best of all the new things I encountered during this project.
They seem to produce quality devices, both in terms of design and technology. That’s true at least for the Heat Controller (the only product I tried) — but the rest of the product lineup also looks quite decent.
The only drawback I have with these thermostats is that their firmware can be updated only via Fibaro’s own controller, called Home Center. My thermostats are on version 4.4, while the latest one is 4.7 — so at least they have not abandoned them, it seems.

Next steps

As usual, I neglected error handling at the beginning. Suddenly I noticed that the kitchen thermostat keeps opening & closing the radiator valve every fifth minute or so.
A bit of reading, adding more Items, mapping some Channels, and it turns out that the radiator valve was stuck! Whenever it was pushed in (closed), it wouldn’t come out by itself. The fascinating thing was that the thermostat noticed this, based on that it didn’t have to apply much force when trying to close the valve — and was returning the respective error code. Nice!
After curing the valve with pliers and a hammer, I swore to myself that I’ll add error state monitoring and alerting.
At some point in the future …

You might also have noticed that on the screenshot above, the two battery levels (one for the thermostat, one for the connected thermometer) had the exact same value. They are mapped to the two respective Channels on the Thing, but the same number is coming via both Channels (i.e no thermometer battery level). Perhaps a firmware update would solve this.

This was the second upgrade to my home monitoring system — read on for the rest:

--

--