Central heating with underfloor heating and existing openhab integration advice required

Hi Everyone ,

I could do with some advice , I’m soon to install gas central heating (radiators and underfloor heating) in an up till now electric heated house.
I will be installing radiators upstairs and underfloor heating down stairs this will require me to have 2 room stats (or HestiaPi’s) for the 2 zones so to speak . I also have a current Openhabian installation that I use for presence detection and sensors monitoring and control.

My question is will I need to have a separate Openhab app on my phone to access the different hestiaPi’s or is there a way to access the HestiaPi’s from my existing openhabian setup ? now I know the easiest thing is to incorporate my openhabian setup into one of the HestiaPi’s but I have a NRF24L01+PA+LNA radio Antenna connected to the GPio’s so this option is out.

also has anyone integrated a HestiaPi with a Worcester - Bosch boiler I only ask as the boiler has a hot water preheat function but I cant Get my head around whether this is controllable from an external 3rd party programmer like the HestiaPi ( its not essential if its not , the hot water will still work on the boiler )

Finally the underfloor heating requires that the room stat for the radiators and the room stat for the underfloor heating, be connected to a wiring centre, this is then connected to the boiler to turn it on and off and to control the zones via zoning valves , here is a link to the pdf to see what I mean .

Prowarm Underfloor Heating

My question is if I have 2 HestiaPi’s will they update to show as ‘ON’ for the heating if the other room stat turned the system on for the underfloor heating say ?

any advice would be Brilliant

Thanks in advance

Sounds like a great setup you have there :wink:

As you can see in the items page (lines 4,5,6 and 17 as of commit c550516)

The relays status and temperature setpoints are accessible via MQTT (mosquito) for both read and write so simply adding these MQTT items in your existing installation will be the only thing needed to remotely control any HestiaPi installation in you network.

So an item like this would do.

Number TempSetpoint "Temperature Downstairs Setpoint[%.1f °C]" { mqtt="<[mosquitto:hestiadownstairs/local/settempsetpoint:state:default]"}

Notice the different mosquitto.clientId hestiadownstairs which you will need to modify in each

Sure they will. Leaving relays and actual controls aside, you can test this yourself by running a HestiaPi on any RasPi without our custom PCB (just flash our image on an SD and boot it) and publishing to the desired MQTT topic from your laptop while watching the web/app interface of that RasPi from your phone. It is also quite fast on RasPi Zero (<1sec).
As the MQTT topics are for both read and write you can even turn off the underfloor heating from upstairs if you forgot it on before going to bed :wink:

I cannot know for sure but if this wiring centre controls these valves with some logic, I don’t see why you cannot use the 3-relay Hestia’s relays to control each one separately

Let me know if you get stuck!

1 Like

Thank you for the reply @HestiaPi,

Of course Mqtt why didn’t I think of that, I currently use Mqtt for the presence detection so I already have Openhabian set up as a broker .

I will admit my knowledge of Mqtt isn’t amazing even though I understand how it works and can with a bit of trial and error get it to publish and subscribe to topics. I will probably be calling on your assistance quite a bit to get things functioning mainly with the syntax of the items. Out of interest have you seen MqttSpy for monitoring publishes and subscribes from your broker I think its brilliant.

I won’t be installing the heating for a few months yet but I’m trying to iron out any problems before the event also I have to get my plumber to agree that he’s happy to commission the system with a 3rd party programmer.

however I will be following this project with eager anticipation and fingers crossed I really hope I can incorporate it into my project .

Thanks for all you hard work on an amazing idea .

The link I posted before has some basic testing steps to get you going but surely we are here to help with syntax etc. Basic configuration for MQTT is not that hard so don’t get overwhelmed even if you are not that experienced with it.

Cool and easy UI. Added it to the instructions link :wink: Thanks!

Average planning is better than great troubleshooting :wink: Make sure you cover most if not all areas before you continue with purchases and installation.
Keep us updated!

1 Like

Brilliant I will be continuing my research and planning over the next few months and I’ll report back here if I need advice or to report any updates .

I discovered MqttSpy when trying to find a UI for Mqtt instead of using the terminal mosquitto-client.

I’ve had a quick thought, I’ve been browsing through your github repo at the items,rules and sitemap files. With my setup I don’t believe I would require a boost feature on the hotwater or the heating as I would either manually turn the heating On or Off
Or I would have a daily timer .
Which means I’ll have to edit the files a bit for my usage but I don’t suppose you would be able to include instruction on the guide page on creating a daily timer feature for the 7 days of the week? Also I don’t know how possible it would be to create a Holiday mode which would turn Off the timer function( Holiday Mode active ) while you were away for several days.
I’m more than happy to try and create this all, be it very slowly myself , I thought though that other users might benefit from this as well should they have a similar setup .

Timers and scheduling in general has been a very popular request. Direct support from OpenHAB has been delayed for a few months now (only complicated support via Google Calendar has been published so far) so an indirect workaround by us would have been developed for nothing once the official one is released. Having said that I need to chase this up with OH and see where this stands right now as it has been quite a few months since it was promised “to come soon” but I know for a fact their pipeline is looong with the latest releases :wink:
The boost functionality is something many commercial thermostats offer and it was easy enough to make to help people make “some” scheduling without having to break anything in GCal or so…
If you manage to make something, please share and we may include it as an optional feature for people to pull.

My 2 HestiaPi touch kits turned up today, so I’ll be looking forward to assembling them this weekend, Thanks for sending them out .

I have a few questions, has there been any updates regarding the possibilities with scheduling and timers? or is it still coding the scheduling in as shown in other threads on the forum with rules still the way to go ? also I will be printing my case soon is it worth waiting for the updated case ?if so is there an update on when the files will be ready ?.
I’ve also been looking through the github repo at all the files and as I’m not going to be using my thermostats for anything other than the heating (i.e no Aircon or hot water) I can delete most things such as items , rules etc …related to Hot water, humidity set points etc… my question is I take I should still keep the main switch item as its connected to the boost functionality not just the heating, hot water and humidity functions/rules.

and finally you mention in the guide that its best not to customise to much as the UI and such are to be updated does this still stand true or has this been and gone ?

thanks again for your help and the kits

Hey Tim,
Glad you got them ok.
I’m on a short weekend break.
Hold the 3D prints as the new design has been tested thoroughly and passed. Will publish everything Monday-Tuesday and will respond to all your other questions too.

1 Like

Thanks ,
Enjoy your well earned break .

Here are the promised 3D files (click the “3D files” tab):

Now to your questions…
Scheduling is not done yet. Sorry.
If you only want to clear the UI, I would suggest to only remove stuff from the sitemap and not to touch items and rules. It is much safer this way. You wont get any performance improvement by removing items (if that’s what you are thinking :wink: )
Customising the UI, means you will need to manually patch text files when an update comes. So more customisation will lead to harder patching. Up to you…

1 Like

Brilliant, I can’t wait to get started with the printing I’ve been looking forward to it since I saw the project, but now with the updated mk3 .stl files I’m really excited. Now I know what I will be doing tomorrow :wink:.
Well I’m very glad I asked the question now and saved myself a lot of agro. I will only comment out the sitemap entries I won’t need, save myself the pain of any update problems.
That’s a shame about the scheduling but I know these things can take a lot of time to get right . I’ll just have to do some more research about adding some rules and cronjobs of which I’m not overly experienced with but I have managed to achieve a few things with both.

Thanks again for all your help

Please read the notes and release notes under each file

Everything printed perfectly :sunglasses:

Now to reflash the SD card with the new image release.

Design globally, produce locally :wink:

@HestiaPi Ok so good news I have both thermostats up and running and I’ve made a few edits to the items and sitemaps but let me give you some feedback on what I’ve done and what I’ve noticed.

  1. So when I started the Pi’s for the first time at the same time I had a conflict with both Pi’s presenting the same ip address of HESTIAPI (new V10 Image with turnkey script ) which meant one I couldn’t work out immediately which Pi I was providing WIFI credentials too, but ultimately the other Pi rebooted till I managed to find its HESTIAPI network and add WIFI credentials to it . This is no major problem only what I found and obviously its only an issue should you have more than one HestiaPI.

2)I had a slight problem that I managed to mis-align an LCD display due to how it was positioned in the case and because I didn’t notice for about 10 minutes this somehow was short circuiting and cause the transformer to heat up to the point where you couldn’t touch it. Once I realised what I had done, rectified and restarted the Pi it cooled down. I thought I would mention this to help out anyone that might make this mistake, make sure that the connection block on the back of the LCD is perfectly in line with the PI GPios and make sure the LCD illuminates before moving on .

3)Ok so I have a few errors in the openhab log, I was wondering if you could shed some light on .

these are the errors I see often,

Validation issues found in configuration model 'default.rules', using it anyway:
The operator '!=' should be replaced by '!==' when null is one of the arguments.
2018-08-04 11:56:55.665 [WARN ] [.core.transform.TransformationHelper] - Cannot get service reference for transformation service of type MAP
2018-08-04 11:56:55.739 [WARN ] [b.core.events.EventPublisherDelegate] - given new state is NULL, couldn't post update for 'HeatingPin23'
2018-08-04 14:46:15.275 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Heating Mode': An error occurred during the script execution: Could not invoke method: org.eclipse.smarthome.model.script.actions.BusEvent.sendCommand(org.eclipse.smarthome.core.items.Item,java.lang.String) on instance: null
2018-08-04 12:18:11.546 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'convertproxy': The name 'MyTempProxy' cannot be resolved to an item or type; line 48, column 3, length 11

now I did notice that the transform for the binary.map for the heating switch item was not present in the transform directory of the new image . I don’t know if there is a reason for this but I added the transform from the github pages .

  1. why do I receive this image when I boot the Pi ? is it something to do with the other HestiaPi or is it because the initial hostname on my router for that IP was Raspberry pi and now its HestiaPiUp /Down this wont change until the address lease runs out on the router if that makes any sense, any ideas ?

and finally I could do with some advice. I’m working with the Mqtt and as we discussed I changed the client name for each HestiaPi in the mqtt.cfg file but I couldn’t subscribe to a client id so I had to modify the items themselves to


for example .

and now I have the items showing on my existing sytem .:grinning:

my question is if I want to control the set point I will need to raise or lower the temp with switches like in the main menu (basic Ui) of the hestiaPi’s

as I understand it the switches change the target temp with rules, will I need to add these rules to my existing openhab to raise and lower the target temp ?
I have been successful in using Mqttspy to publish a temp to the HestiaPi on the topic I know its listening to but to increase and decrease incrementally using switches requires rules, right?

I also have a question regarding the Habpanel. How do I remove certain elements that are displayed ? I mean I don’t need the hot water boost or control to be displayed just Heating and the settings menu.

Thanks for all your efforts I cant believe I’ve made it this far and now can control my heating upstairs and downstairs using the Pi’s or my laptop


Hey Tim,
let me dig into your post and reply one item at a time.

To be honest we haven’t thought about multiple HestiaPis boot at the same time for the first time. What happened is that you got 2 networks with the same SSID (HESTIAPI) and you couldn’t tell which was which. Of course one solution would be to power up one at a time. The other solution, and probably what you did, was to setup blindly whichever you connected to and see which restarts. Once they are connected to your actual home network they will get unique IPs which will also be displayed on the loading screen to help you identify.

We are changing the case design to minimise these situations. It needs indeed some extra care to align everything.

You are absolutely right. Well spotted. Replacing the download with a new image. Thank you!

Hmmm… never seen this. There may be a bug on Chromium. Try this suggested solution

rm -rf ~/.config/chromium/Singleton*

The switches change the item “TempSetpoint”. Then rules are used to control when to turn the heating on and off to reach these setpoints. So if you renamed the setpoints for each HestiaPi you will need to apply the same change in the rules file.

The setpoint entry in the sitemap file (/etc/openhab2/sitemaps/default.sitemap) is this:

Setpoint item=TempSetpoint minValue=0 maxValue=40 step=0.5 icon="temperature"

The “step” parameter shows the increment step. You then need to keep the bidirectional MQTT (read and write) for the item and it should work.

See the HABPanel section of my answer below and follow steps 1-8.

Then click the edit icon at the top, next to the title and you are in edit mode where you can move, remove and resize everything. I think HestiaPi’s screen only changes on reboot so once your screen looks ok on your laptop, reboot HestiaPi for the changes to take effect. Please keep in mind that you laptop’s resolution and aspect ratio may be different from the LCD so make sure you compensate accordingly.

Well done!!!

1 Like

@HestiaPi ahhhh! nightmare i came home from work to find one of my HestiaPi’s showing just a white screen. After some diagnosing I discovered my raspberry pi has died for some reason so I am hoping to get a replacement from where I bought it from, I de-soldered it and tried powering it from an official pi charger and nothing !!!. Anyway whilst trying to desolder I managed to strip one of the tracks on the PCB . Would it be possible to order a few PCB’s from you just so I have a few backups should this happen again ?

Anyway back on track , Thankyou for helping me to understand how the switches work I finally get it.

To be honest we haven’t thought about multiple HestiaPis boot at the same time for the first time. What happened is that you got 2 networks with the same SSID (HESTIAPI) and you couldn’t tell which was which. Of course one solution would be to power up one at a time. The other solution, and probably what you did, was to setup blindly whichever you connected to and see which restarts. Once they are connected to your actual home network they will get unique IPs which will also be displayed on the loading screen to help you identify.

That’s how I worked out which PI i had connected with via the IP assigned from the router but as you say starting one at a time would be better.

I think the chromium issue was due to a IP lease being initially set for the Hostname Raspberry PI but when I changed it to HestiPIDown this caused the issue since the lease has run out now and I have since restarted the HestiaPi and the issue didn’t show.

I will get to work now on the HABpanel following your steps I cant wait till I have it all set up how I want it.

have you had any thoughts on Number 3) above? the errors in the log I take it Null showing isn’t a problem as eventually it will be either assigned a state or just simply ignored ?

Thanks again

Sorry forgot to comment on it as I think it is the same error. It looks like it is caused by the missing transformation file leaving some variables as NULL. If its gone after adding the .map file, ignore them.

About your PCB issue… I think it will be much cheaper to order them from a local shop or even a chinese low volume shop (dirtypcbs are good) and you will get like 10 for the price I can ship you 1-2 (~15-20EUR with the SMD presoldered). Let me know your decision. Here are the latest PCB files:

About the problem you faced, I would advise to check with a multimeter the output of the provided power supply if it is ~5V DC in case it is damaged from that other issue you got from misaligning the LCD and post back here the results.

I thought that might be the case but I thought i would check with someone with much more experience.
I appreciate the honesty regarding the Price of the PCB’s but although I know I could get it cheaper locally i would much rather support a project than a manufacturer so If it helps you I would prefer to buy your pre- soldered PCB’s, 2 would be perfect.
I tested the output and it is exactly 5.11 volts DC, I’m hoping I bought a dud Pi and that was all it was. Nothing appears to have burnt out it just wont power up, the other HestiPi is going strong so fingers crossed.

Thanks for everything .

Have you swapped the SD from the working one as it is confirmed to be working? It doesn’t need to be soldered back on the PCB to test it. It just won’t have the temp readings. Basically once you see the LED blinking at least 5 seconds after you powered it, it means it boots ok (it should keep blinking for a few minutes actually).
We have had 0 failures on RasPis in the last years, so I am a bit suspicious something else is wrong.
PMing you about the PCBs. Appreciate your support.