Integrating with Home Assistant?

Customization
1

I’ve recently mostly finished my HestiaPi build. I’m working out one little hardware nuisance (the screen connector) finding the right solution that will still fit in the hestia case is tricky. But that’s not this thread.

I’m a home assistant user. And this thermostat has me SUPER STOKED. I love everything it stands for, and I am very excited to get working with it. I have my thermostat assembled, and powered via usb on my desk right now, and I’m trying to figure out how to make it work with my Home Assistant before I actually wire it up in place of one of my thermostats.

First, I have several heating zones in my house, and I intend to eventually run up to 4 hestiapis. So keep that in mind here.

Second, I really want to control them each from Home Assistant, as this is where I’m centralizing my home automations. I could… probably… start from scratch, and make my own interface for this thermostat, as it;s running OpenHAB, which from what I understand doesnt talk to HomeAssistant directly.

I’ve read a bit about bridging message brokers, and I;m tinkering with that now. But I have to ask… Has anyone already done this in a way that gives me complete control from the HA end? The broker bridge seems promising, but at the moment its just not working, so before I delve too deeply, i wanted to check in, see if there might be another way.

Thanks!

2

Have you monitored the MQTT messages exchanged? It is extensively supported by MQTT which is something HA and openHAB support for sure. Both monitoring and control messages are supported.
Please also keep in mind the HestiaPi Zero which will probably be available within 2021 and suits better your needs. We hope within the next month, once production for HestiaPi ONE with the new Chinese factory is starting to run smoothly, to focus on Zero and release some more solid info, specs and photos.

3

Thanks! I feel like I need to learn a bit about mqtt. I get the overall concept. There are topics, and things either publish or read these topics. So i can get the state of the hestiapi by reading the topics it publishes, and change the state of it by publishing to topics it reads.

My first question though its… How do i figure out what all those topics are? And if i’m managing more than one hestiapi, can I change each one to read its own set of topics? The example I found references topics like hestiapi/local/temperature. Which I’ve managed to get bridged over to my own mosquitto instance, and I can read the temperatute on HA! Cool! But what if I have a second hestiapi? Can I tell it to publish to a new name like… i dunno… hestiapi2/local/temperature? Otherwise theyll all just be trampling eachothers topics on the bridge.

Thanks for the heads up on Zero. That sounds cool. Can you say whether the software for Zero will be compatble with the hardware ive put together for the One? or is he hardware platform going to change as well?

Thanks!

4

I just went and read your linked post about zero. I see you’re considering moving from Pi zero to ESP. So that answers one question. NO the software will not be compatible. :wink:

Sounds like a good direction though, and thanks for the heads up! I don’t have hardware purchased for the other Hestia builds that I need, so maybe i’ll hold off on those until I see where Zero is going.

5

Easy answer. Full answer > Read the .things file (/etc/openhab2/things/default.things).

Yeap :slight_smile: To be more precise… The correct architecture would be to use your HA as the broker (MQTT lingo for the “server”) and change HestiaPi2 configuration to connect to that and subscribe to (aka post to and read from) a meaningful topic like hestiapi2/local/temperature or upstairs/local/temperature. The part “local” in the topic for example is there in case people get readings from other devices so you could leave hestiapi part intact and replace local with the distinguishing characteristic like upstairs or whatever.
Oh we forgot to mention that the values on the LCD are also MQTT topics so that it can display:

  • Values from its local installation (local temp - that is the default as you know it already) or
  • Values from another HestiaPi subscribed on the same MQTT broker or
  • Values that can be pushed from anyone else on the same MQTT broker
    How flexible is that?

If you configure HA to talk only MQTT with HestiaPi it won’t make much difference to HA if the other end is a Pi Zero, an ESP or your… laptop/server. As long as HA gets temp/humidity readings and sends commands to turn the relays on/off (all via MQTT) HA would be happy.

6

This is great information.

So are you saying that I’d treat the mosquitto i setup as my HA broker as the broker for my hestiapi (or hestiapis as i expand) instead of bridging the local broker on the Hestia to my own mosquitto? And in doing so, i’d get to define its topic? So making hestiapi/upstairs/ and hestiapi/downstairs for example.

Where does that configuration happen on the HestiaPi side?

7

Here bud, hope this helps

with 4 zones youve got a little bit more advanced setup than me but you can probably use different topics in the broker to control them.
Also, I used GitHub - thomasnordquist/MQTT-Explorer: An all-round MQTT client that provides a structured topic overview this to inspect the messages and what all was doing what.

8

Thanks! Your thread is what gave me the idea to use the MQTT broker bridge! I have read through it. And a friend pointed me at MQTT explorer just yesterday, so i’ve started looking at that.
It seems like when I try to update the set temperature via MQTT though, it does not update the hestiapi. Or at least it doesn’t show anything on the display that tells me its received my command. I can read the current temp/humidity and lots of other info, but it does not seem that I can send commands back.

9

I believe this is the topic used to set the temp
temperature_command_topic: “hestia/local/cmnd/setmintempsetpoint”
Maybe the bridge isnt passing back from HA to hestiapi, do you see the values change when pointing mqtt explorer at the mosquitto on hestiapi?
Do you have the mosquitto on hestiapi configured with the bridge for all topics both in and out?
topic # out 0
topic # in 0

10

ok, i’ve been doing quite a bit of tinkering here, and i’m getting a little discouraged. I am hoping that this is my own lack of understanding of the software stack. So I’m looking for a little guidance.

I am on the v1.1 release of the Hestia One software, because 1.2 was listed as dev, and I wasn’t sure if that was in fact OK for “production” use. Let me know if I should in fact be on 1.2.

Task 1. is to figure out how to rename the topics that Hestia uses in mqtt. What I want to do is simply take my hestia and make its topic tree look more like ‘hestia/testtherm/’ testtherm is just a stand in name im using to identify this thermostat for now, later that might look like ‘hestia/zone1/’ or ‘hestia/livingroom/’. I am trying to do this locally without the HA integration yet, I figure that’ll come once I get this part worked out.

As i understand it, the local mqtt broker is mosquitto, and the configuration of the mqtt service is prety simple, and its all in /etc/mosquitto. I havent really touched that much yet.

I have found two components that refer to the ‘hestia/local’ topics, those are /etc/openhab/things/default.things, where all of the topics for various reads/writes happen, and the UI that displays on the touch panel, in /home/pi/scripts/oneui/js. The files for the UI are really hard to sift through though, and it makes me wonder if they were not written by a human, and are instead auto-generated somehow?

Editing these topics in the default.things and then watching mqtt explorer after restarting the thermostat, i see that hestia/testtherm gets populated with topics! but making the same edits in the js files for the UI doesnt seem to work out quite as well. At this point my display shows 0 degrees, 0 humidity, the three icons for heating, cooling, and fan are not even present, and where you;d set the temperature just says OFF.

Task 2. of course, is going to be bridging mqtt, or re-pointing it to my HA mqtt broker. I did attempt the bridge once, and it didn’t go so well, but I intent to re-try that once I’ve got these topic names worked out. I also tried just pointing the ‘localhost’ entries in the two files mentioned above, for the broker host, to my mqtt broker, and that at least partially worked, the hestia started populating the remote mqtt broker instead of its local one, but I had the same local display problem mentioned in task1.

so, both tasks are currently related to MQTT, can someone let me know if editing default.things, and the js files in /home/pi/scripts/oneui is the right way to make the changes i;m looking to make to the topic names?

Thanks! I feel like i’m close to getting this working. I need to tackle wiring it to my heating system next. My Thermostats are 2-wire… Sigh… So that’ll be another challenge, but I want to get this piece worked out before I tackle that as its going to mean wiring changes it seems.

11

We haven’t seen any bugs for version 1.2 (yet) actually so I would suggest you try that as it is a major improvement in terms of speed, responsiveness and ease of use as you get to use GUI instead of text files.
Follow Rich’s post to get you started.

12

ok, so that’s good on 1.2. But what about the mqtt topic questions? Am i on the right track modifying just those two files? or is there more to this that I’m not aware of?

Thanks!

13

You wont see those files again. Follow Rich’s post to familiarise yourself with the GUI and you should find them under your “things” I believe.

14

The post you keep pointing me to is about creating rules. My question is about how to change the name of the mqtt topic so I can then control more than one hestia on a single mqtt broker. I dont understand how these are related? Or are you saying that rules should allow me to control the hestia in some other way and I shouldnt be looking at mqtt?

The mqtt topics still exist in the same files im talking about in my question, the things file seems to have been moved to /home/pi/scripts, but its still the same basic problem, if i change the topic names, everywhere I can manage to find them, including the JS files that DO still exist as well in the same place they did before, it beaks the UI on the touch display.

15

Sorry I don’t have a 1.2 instance to give better guidance at the moment. The Paper UI Rich is using (see this too) for the rules should give a “Things” menu under which you should be able to find “Channels” and the MQTT topics to modify and save. Then you would need to match these with the LCD UI topics defined here.

16

Thanks! I’ve had some success, at least in changing the topics without breaking the UI.

I pulled the git repo for the ui, and then followed these directions after I updated the topic names in that store.js file.

I updated the topics for each of the various things in the paper ui, configuration → things then under each “thing” labelled as a generic MQTT thing, you can edit it, and then edit each channel with your new topic name.
Then, of course, these need to be setup to match the topics in the store.js file.

After youve changed them, and rebuilt the oneui, and deployed it to the hestia (/home/pi/scripts/oneui) you either need to reboot, or reload the UI. I just rebooted the hestia.

The display is reading the new topics!

Now, I need to decide how to handle the integration to HA. I feel like I have two paths. One would be to update the UI and the back end to use my HA’s mqtt broker, this seems easy enough as both the paperui and the oneui had options to define the broker. My HA broker is password protected though, and I didn’t see an options for that in the one ui, is there a way to tell the oneui my broker’s user/pass?

If not, the bridge method might still be on the table. I’ll look that direction if the oneui cant use a user/pass.

Thanks!

17

It should be in the configuration options on the MQTT Binding Thing where you setup your HA MQTT IP but I guess this is the place you checked already.

18

Yes, the mqtt binding thing does offer the option, but the oneui, that displays on the screen. It doesn’t look like it has a variable in there for user/pass like it does for the broker address. updating that in the mqtt binding in the paper ui doesnt also update the touch screen ui does it?

19

@jay any hints?

20

If you are running a separate MQTT broker already, perhaps a better approach would be to bridge the two brokers instead of trying to get the HestiaPi to use your main broker. Because the communication between OH and OneUI is through MQTT, if you move to an external broker that will make the thermostat more brittle as if your network goes down or main broker goes down you will essentially sever the connection between the UI and OH and therefore lose local/manual control of your thermostat.

But if you bridge the two brokers then each client can send and receive messages to each other regardless of which broker they are subscribed to. And that means OH and OneUI can continue to talk to each other through local Mosquitto instance unchanged.

It’s possible that OneUI’s connection might support a basic auth type user:password@host:port connection string to define the username and password. But I am woefully ignorant on how all that UI stuff works. But it doesn’t take much to test that out.

1 Like