Integrate IOThermostat with home automation


Ok so this is my thread to discuss integrating IOThermostat with an existing home automation setup as mentioned here , in my case OpenHAB but considering IOThermostat uses Mqtt for its control I cant see why this cant be used in other home automation.
I have several Temp sensors that speak to OpenHAB and it would be great to have them update the temp average on IOThermostat ( mainly because I had to install a HestiaPI on a wall with heating pipes running behind, this provides an inaccurate temp reading ).

I would also like IOThermostat to communicate it humidity and pressure readings with OpenHAB as a minimum but Ideally being able to control IOThermostat from OpenHAB would be the real end goal.

@janbonne I’ve done a bit of research and I’ve found this regarding a Mqtt bridge, that allows brokers to talk to each other, I would like to make both HestiaPI thermostat brokers talk to the openHAB ‘main broker’. In my understanding it allows a broker to subscribe to itself and to another broker as if it were a client, my concern is might this break IOThermostat? as IOThermostats setup relies so heavily on its broker to function.

here is the mosquitto.conf, find the section for configuring a bridge .

any thoughts ?


Do I understand correctly that you want

a) to use some temperature value provided by OpenHAB instead of the reading of the HestiaPi sensor in IOThermostat?

b) show IOThermostat humidity and pressure in OpenHAB?

A bridge config indeed looks like a nice solution.

By design all MQTT data sent/received by IOThermostat is available for other applications (provided they are logged in; could be your own web interface). Having a bridge config output them to some other MQTT broker should give no problem.
For receiving temperature, bridge your OpenHAB temperature topic to a new one on IOThermostat.

Using sensor readings from MQTT in IOThermostat would require some python coding:

  1. add the bridged externalsensor topic to
  2. add this topic to SUBSCRIBELIST in
  3. call a function that receives mqttclient.getData() and returns the temperature into variable ‘t’, much like processMessages in near line 191, overriding the sensor value, before calculating averages and differentials.


This is correct

a) I’ve have the temp sensors in different rooms of the house so the readings are more accurate than the reading I have on the thermostat due to its location. I can set the topics for these sensors to what ever is needed for the IOThermostat . So the upstairs HestiaPi can subscribe to upstairs temp readings and the downstairs HestiaPi can subscribe to the downstairs readings
B) As I understand the bridge it would publish all messages that it receives to the main broker (OpenHAB) all I would have to do is subscribe to the topics that I want i.e humidity and pressures I would only change both of HestiaPI’s to be the bridge brokers.

I’m not really that advanced with python but I’m more than happy to give it a try using your other functions a template .
Ill report here with my examples before I implement them .



I’ve updated iothermostat-python, please pull in the update from Github. Then in set:


and publish/bridge your temperature readings to the iothermostat0/sensor/othertemperature topic.


sorry for the delayed reply this is brilliant I hopefully will get this up and running in the next few days when I get a chance . Although my wife came home to a black screen on one of the HestiaPi’s and and no flashing light so I really need to debug this , I think its hardware related, something to do with my wiring but I will start a thread to try and figure this out .

thanks again for sorting out the python coding .


I attempted to get this working today but something in the edits of the code in caused the code to exit and the iothermostat.service to fail I had to delete the edits to get everything working again .

I did however get the bridge to work and currently it is publishing humidity and pressure to openhab .

to make sure it wasnt the bridge causing problems I disabled the bridge and restarted the iothermostat.service this still produced an error with code exit .

edit: might it be something to do with this
not having the othertemperature topic ?


An assignment was missing, I updated the python code again. On my system it now picks up temperatures from the specific topic without errors. Please update again.

FYI the python code reads the temperature from the topic, calculates average and differential and republishes it to the default temperature topic to the web interface together with the differential value.


Ok so I need some help to debug whats not working , I’ve updated to the latest Github update , but after a few hours of trying to things working I’ve had to change back to

so to start with Ill show you my setup

OTHERTEMPERATURE = SYSTEMNAME+'/sensor/othertemperature/downstairs' # temperature reading from mqtt


connection bridge-down
remote_username iothermostat
remote_password iothermostat

topic iothermostat0/sensor/humidity out 0
topic iothermostat0/sensor/pressure out 0
topic iothermostat0/sensor/othertemperature/downstairs in 0

I created a mosquitto log file and added debug to the iothermostat.conf file ,so Icould check if messages were being received

1542971644: Received PUBLISH from local.iothermostat.bridge-down (d0, q0, r0, m0, 'iothermostat0/sensor/othertemperature/downstairs', ... (4 bytes))
1542971649: Received PINGREQ from js-paho-mqttws-client-976392
1542971649: Sending PINGRESP to js-paho-mqttws-client-976392
1542971649: Received PINGREQ from js-paho-mqttws-client-976392
1542971649: Sending PINGRESP to js-paho-mqttws-client-976392
1542971677: Received PINGREQ from iothermostat-backend
1542971677: Sending PINGRESP to iothermostat-backend

and as you can see it receives the topic for othertemperature/downstairs but the temperature remains at 0°C as set in the file

here is a pic also of mqtt-spy receiving the topic

any ideas?



Try setting readwrite for the sensor topic for the appropriate user (pyiothermostat) in /etc/mosquitto/aclfile.


acl_file file path
Set the path to an access control list file. If defined, the contents of the file are used to control client access to topics on the broker.
If this parameter is defined then only the topics listed will have access.


You sir are a genius !!!

everything is working .

Thank you for all your help and coding. I have a couple of questions

  1. My temp sensors report the temp every 5 minutes and if it hasn’t changed they report nothing, obviously with the heating on this would change every 5 minutes and so it will send the temp. Do you think this is too long a time interval ? I can always program the sensor to report a lot sooner.

2)I currently have humidity and pressure being reported by only one of the thermostats to the standard topic but if wanted to change it so that both thermostats reported their pressure/humidity I would need to seperate the topics could I change the topic names for humidity and pressure in and mqttconf.js or would this break IOThermostat ? I notice you have topics d_humidity to change the arrow direction on the GUI this wouldn’t need changing too ?

We are well on the way now to controlling IOThermostat from OpenHAB, you said before that if openhab could post commands on the right topics in theory it could control IOThermostat remotely How simple would this be ? I’m hoping that by having an mqtt message sent to change the mode and increase/decrease the temp would be all I would need to do on the OpenHAB side.

anyway Thanks again for all your help .:smiley:


Thank you for your ideas on and testing of integration with OpenHAB! :slight_smile: :+1:

  1. Depends on your building + heating system. Currently IOThermostat doesn’t run a PID controller, it’s not anticipating, just switching off when the temperature is almost right. Like classical thermostats. From control engineering point of view, for example a hot water circulating system is responding slowly, hence to not have way too much overshoot in temperature the system should stop heating early before set temperature is reached. Personally, for temperature sensor update rate with non-PID control like current implementation, I’d go to the order of seconds rather than minutes.

  2. You could change system names to iothermostatN (N = integer) and use a single MQTT broker for all HestiaPi’s. See iothermostat-http/scripts/mqttconf.js and iothermostat-python/, note they should have matching configuration. All topics you find in iothermostat-http/scripts/mqttconf.js can safely be read from into your own application (OpenHAB). The settings topics you can write to, but make sure you use the right format (e.g. MODE = ‘Auto’ / ‘Boost’ / ‘On’ / ‘Off’ / ‘Sleep’ , targettemperature = float, schedule = comma separated numbers [day,starthour,startminute,endhour,endminute,targettemperature,day,starthour,…)


No! thank you for all your commits to get this working .
I’ve set the reports to every minute and I’ll see how well this works out and adjust as needed .
I like your idea about changing the system name I think I’ll trial this soon when I have day spare .
So if I have an mqtt message publish with a payload Command of Boost or Auto for example this should work ? I think I’ll look at how @hestiapi uses boost /on/off in HestiaPi sitemap and items and have it publish to the required topic .


Gladly done.