The MQTT App, a Home Assistant, and an Ecobee walk into a bar

Based on reading through various threads in the community, I learned that my Ecobee will communicate locally with Home Assistant. YAY! So I pulled out my Raspberry Pi and put Home Assistant on it. With almost no effort and just a bit of help from a post in this community I was able to establish local control with my thermostat. Then I moved on to getting HE to speak with HA.

I found a couple posts on the MQTT App [beta] thread that seemed to indicate some degree of communication between HE and HA was possible using MQTT. So, I installed the app and driver and...that's where it got complicated. The MQTT App installation instructions started talking about brokers, homies, and other things I know nothing about. And I see a yaml file in the GitHub repo that makes me believe there may be some work that needs to happen within HA.

I'm not usually one to beg, but I would really appreciate some help with this one. I've been unable to find anything online that is written with a user like me in mind (literally zero experience with HA or MQTT).

My primary goal at this point is to simply monitor the status of the Ecobee, with possibly being able to change the comfort setting (Ecobee's term for "Home," "Away," "Sleep," etc.).

Any help at all is greatly appreciated.

As a way to help others who may find this thread while attempting to accomplish the same thing I am trying to do, I will attempt to summarize the outcome of this thread in the notes below. These are a follow up to the original questions and will hopefully be a basic step-by-step guide for others to follow.

  1. Set up a Home Assistant (HA) hub using the image from homeassistant.io. Did NOT add my ecobee device immediately. Instead I first installed the HomeKit Controller integration and then added my ecobee through that.

  2. Installed Mosquitto and Visual Studio Code Add-ons in HA using the Supervisor - Add-Ons menu. Visual Studio Code was mentioned somewhere as one option to edit the HA configuration.yaml file. I'm sure there are other options for this. Added a user to HA based on directions in the Mosquitto documentation and also enabled/configured the Mosquitto integration via the HA Configuration - Integrations menu

  3. Installed MQTT app on Hubitat. The app is still in beta, but version 3e will support climate entities when it is released. Using a pre-release sneak-peak I was able to get the four main attributes (mode, setpoint temperature, actual temperature, and operating state) directly from the thermostat/HA without going through Ecobee's cloud service. Status changes show up in HE almost immediately. I haven't gotten other items like remote sensor values and motion detection working just yet.

Which bit are you stuck in, in particular?

Have you got a MQTT broker (Mosquito, for example) installed? The broker is the thing that passes the messages between Hubitat and Home Assistant and is a requirement for getting them communicating. If you've installed Home Assistant using the HASS.io image, you should find that you have an add-on option to install Mosquito, I believe.

You then configure your broker address, username, password, etc. under the MQTT Broker section of the MQTT App settings. You don't need to touch the Configuration section, then under MQTT Publish Formats make sure all four options are turned on (homie is just a protocol for sending information) and set a 'discovery topic' if you're going to publish any devices from Home Assistant into Hubitat. You'll need to set the MQTT topic as the same under the MQTT options in Home Assistant.

You'll then need to have a block of code in your configuration.yaml file that is a little like this:

mqtt:
broker: 192.168.##.##
port: 1883
client_id: hass
username: super-secret-username
password: super-secret-password
discovery: true

mqtt_statestream:
base_topic: home-assistant
publish_attributes: true
publish_timestamps: true

1 Like

Dylan, I’m always happy to help too... I haven’t received any questions from you - just shout. Ignore ‘homie’ references it’s just a means to an end. The HA automation files are only for controlling HA devices that are imported into HE so in your case you can ignore those too.

Did you read the MQTT read me file ? I know it needs updating a bit

Also look at the Hubitat integration in HA which will import HE devices into HA via Maker API (who also drinks in that bar). It won’t link HA devices to HE though.

@kevin Thanks for offering to help. I'm always surprised by how willing the members of the community are in lending a hand. Although I'm also aware that I am starting out at square #1 and want to be respectful of your time and effort, and that you probably have enough on your plate without walking me through setting up MQTT on a completely separate platform (Home Assistant). That said, I'll keep your offer in mind when I get a bit further down the line. I'm sure this won't be my last call for help.

@jhcooke Your post was very helpful so far. With your help and the Mosquitto docs I've got Mosquito installed on HA. Part of the Mosquitto setup was to add a user to Home Assistant, which I did. Let's call that user user-mqtt and pass-mqtt for the password. Also, within the Mosquitto setting in Configuration - Integrations - Mosquitto - MQTT Settings there is a prepopulated user (homeassistant) and a really long, randomly generated password.

You then configure your broker address, username, password, etc. under the MQTT Broker section of the MQTT App settings. You don't need to touch the Configuration section, then under MQTT Publish Formats make sure all four options are turned on (homie is just a protocol for sending information) and set a 'discovery topic' if you're going to publish any devices from Home Assistant into Hubitat. You'll need to set the MQTT topic as the same under the MQTT options in Home Assistant.

It took me a fair bit of time to realize I needed to switch to Hubitat for this...I was still trying to find these options in HA. As I mentioned, this is all very new to me. Anyway, now I'm questioning which user to enter into HE...the one I created or the one Mosquitto has autopopulated? Also, is the topic just a simple text string that I choose, or is there something I need to select from a predefined list?

I'm pretty sure I have more questions within the HE setup, but I'm guessing I'll need to get the user credentials sorted out first.

Once back in Home Assistant, will the broker address be the same as the IP of the RPi running HA? or will it be the IP of the HE? And I'm guessing the that username and password I enter into configuration.yaml will be the same as the ones I used when I configured the HE app?

And lastly (for now), are there any noticeable syntax errors in the yaml code above? I got ahead of myself and when I tried to paste it into my editor it complained about "Incorrect Type. Expected 'object' or something similar.

I'm afraid I'm not sure, I run HA on a server and Mosquito on a Pi, so they're separate instances and the user is just the one I set up for Mosquito in my case. I'd assume that the homeassistant account was the correct account to enter for the broker, but that's just a guess. You'll know if it's wrong through, so just try both.

Yes, the topic is a simple string - it has to be unique, but it's just used by the broker to put in front of all the topics. In my case, I gave it the topic hubitat-elevation and you can see that it appears like this:

image

Incidentally, I'd recommend MQTT Explorer - it's a freeware app that allows you to view the state of your MQTT Broker, so if I look my office light, for example, I can see that it has the following subtopics:

image

Yes, I'd expect that to be the case.

Likewise, though I'm surprised that it doesn't auto populate that stuff since it's an add-on, but I run Home Assistant in a docker container, so I've never tried it myself, sorry.

Yes, I forgot to paste as a code block and so it's lost indentation. It should have been:

mqtt:
  broker: 192.168.1.80
  port: 1883
  client_id: hass
  username: your-username
  password: your-password
  discovery: true

mqtt_statestream:
  base_topic: your-topic-name
  publish_attributes: true
  publish_timestamps: true

I can connect to the HA using either set of credentials in the MQTT Explorer app that you recommended. There doesn't appear to be any difference between the two accounts. However, I didn't see anything in the explorer that looked useful until I remembered that I hadn't edited the configuration.yaml file yet. Once I did, I started seeing the ecobee data (and the rest of the HA information) in the tree.

So far, so good. Now I can try getting the data into HE. Stay tuned...

Just so I’m following .. EcoBee is on HA and your trying to get that into HE. You might need some help from me shortly. Thermostats are a little complicated to add.

You have chosen a hard starting device, do try with just a lamp or basic sensor first,

That sounds like good advice. Perhaps the motion and temperature states from my ecobee sensor would be step one, but I'm having some difficulty with the MQTT app in HE. I posted in your main beta 3 thread regarding that issue.

The only other "smart" stuff that HA sees are my roku devices... not sure what I'd do if I connected those to HA/HE.

With plenty of help from Kevin (and others here), I've gotten the MQTT link between HA and HE working fairly well. The ecobee temperature sensors were automatically detected in the Hubitat MQTT App but were not updating their temperature readings. I had to change the device type from the default "virtual temperature sensor" to "RM Connector Variable." Once i did that they seem to be working fine.

Today I also received and installed my zone dampers. My two Zooz ZEN16 units that will eventually control them are still in transit, so I'm temporarily using a spare iris plug and a simple rule to drive the dampers to a "balanced" setting anytime the heat turns on. Testing has shown the ecobee-HA-HE link to be quite fast.

I spent some time earlier this week and wrote two different rules to control the HVAC system, as well as define some comfort settings within the Ecobee. Things looked pretty good until one morning I saw my furnace was running with all of the dampers closed. It turns out the the Ecobee was still reporting that it was in "Sleep" mode with a setpoint of 64 degrees, but it was actively heating and trying to get to the "Home" setpoint of 70 degrees by the time it was supposed to change in the programmed schedule. Since all of my zones were over setpoint, the dampers closed.

I'm still trying to figure out how to use RM or another HVAC app to control things as intended...it just gets hard when the thermostat doesn't want to communicate what it is doing.

In any automation the fewer steps involved makes for a tighter integration. Since the ecoBee is on HomeAssistant you should ideally write the rules there.

Where was the 'sleep' mode originating from in your chain i.e. where was the correct mode first not updating properly, was that ecoBee > HA ?

Just a "short" note on a few things I've learned over the past couple of weeks and a progress update.

First, the local ecobee integration via Home Assistant is pretty limited in its functionality. It really only exposes the mode (Heat, Cool, Auto, and Off), the operating state (Heating, Cooling, or Idle), the setpoints for each mode, and the "average" temperature of the thermostat and any active remote sensors. Two things noticeably missing are the ability to monitor/control the fan status and the "comfort setting/program/schedule." The current states of "motion" and "presence" are also available for the thermostat as well as the individual states (temperature, motion, battery level) of any remote ecobee sensors. That said, even with it's limitations, it has proven to be a reliable and robust way to monitor the operating state and use that information to trigger rules within Hubitat.

On the flip side, the Universal Ecobee Suite (Community App) exposes an incredible amount of information, albeit via ecobee's cloud service. I can use UES to do things that even the native ecobee app can't do. However, because I want to avoid reliance on the cloud service, I've limited my use of the UES to only a those functions that can be operated in a "failsafe" mode if the cloud service is unavailable.

Current Equipment: Ecobee thermostat with 3 remote sensors, Raspberry Pi running Home Assistant (HA), HomeKit Controller, and Mosquitto MQTT Broker, and Hubitat Hub running xAPPO/MQTT client, 3 powered dampers (normally open) connected to a Zooz ZEN16 controlling airflow to the trunk zones.

The basic theory of operation is as follows:
The ecobee is located on the main floor and programmed with a standard shedule using the standard Programs of Home, Away, Sleep. Two additional programs (HomeB, SleepB) are also programmed but not used in the schedule (more on these later). One remote sensor is located in each main "truck" zone (basement, main floor, upstairs). The programs are set up to ignore one or more remote sensors based on expected occupancy. For example, all of the bedrooms are on the second floor, so the Sleep program is set to ignore all of the temperatures except the remote sensor on the second floor. Any manual change to the thermostat settings (setpoints, mode, etc.) results in a "Hold" that lasts until cancelled by the user.

UES reads the current program from the cloud service on a set polling interval of 1 minute. A RM rule is triggered to run if this value changes. The rule has conditional statements for each program name and sets three virtual "occupancy" switches based on the program. These occupancies must match the sensors included in the ecobee's internal program/schedule as noted above. Following the previous example, if the program name is Sleep, the occupancy switches for the basement and main floor are turned off, while the second floor switch is on.

MQTT reads the operating state locally via HA using the MQTT service. This is broadcast from the ecobee/HA and updates in real time. On a change, a RM rule is triggered that checks the state (heating, cooling, idle, etc.) and calls a separate rule to control the individual dampers.

The damper control rule first checks if the state is idle. If true, all dampers are turned off (opened) and the rule exits. It then checks to see if a manual override switch is on or off. If on, the dampers are set to a fail safe position and the rule exits. If neither of these is true, the rule sets the damper positions based on the virtual occupancy switches. Dampers in occupied zones are left open, dampers in unoccupied zones are closed. Thus, conditioned air is sent only to those zones that the ecobee is programmed to monitor. When the call for heating or cooling is satisfied, the state is changed to idle, the rule is triggered again, and all dampers are opened until the next cycle.

Now, back to the "special" programs HomeB and SleepB. Our basement is not someplace we spend a lot of time, so is programmed to be "unoccupied" for the standard programs. But sometimes we will watch movies down there or have guests in the guest bedroom and will want the basement to be conditioned with the rest of the house. So, I created the programs HomeB and SleepB in the ecobee and included the appropriate remote sensor to be included in the program. There is no way to manually select a program from the ecobee interface or from the app, but the UES can be used to force the ecobee into any stored program. So, I created a dashboard button and a rule that toggle an HE global string variable through the various programs that I've created in the ecobee. That way I can use the dashboard button to choose the HomeB or SleepB program as appropriate. The ecobee thermostat "holds" that program indefinitely. In order to resume the normal schedule, I can use the dashboard button to cancel the hold.

So far this setup has been working great. Now that the basics are covered, there are a few things I am still planning to implement...
-Verify everything will function as intended for cooling mode. Until now we've been using heating mode exclusively.
-Implement a looping rule to close the dampers to any zones that have been conditioned beyond their setpoint. For example, if two zones are "occupied" but only one has been satisfied, it's damper can be closed to force additional air to the remaining zone(s). Rule must loop and also also ensure that at least one zone is always open to maintain minimum airflow.
-Automatically change to override/failsafe mode if connectivity to the cloud is lost. Right now this is a manual intervention.

Can this be accomplished with HE, mosquitto & echobee? I would like to control these ecobee thermostats without internet access. seems the only way i can control them now is if they are able to reach the ecobee cloud or i walk up to the thermostat and touch it. and who wants to walk 3 feet and touch the thermostat.

I've been running the ecobee thermostats for about 5 years now. I've found that the satellite sensors are a crock. All they do is sense the temp and keep the heat on longer to average out the temp. IMO this is a waist of time and money. Set the temp to the comfortable level you like and be done with it. Also their sensors only work with their thermostats so what good are they after you realize that. When i was a homekit/homebrige environment i used automations to accomplish way more than ecobee offered and all without sending that extra data off to their cloud. Now that i no longer use homebridge and all automation is done inside HE, ecobee is the last item i need to cut off from the cloud. Everything else in my envornment has no ability to call out to their cloud.

Local integration of the ecobee is basically the equivalent of a $30 "dumb" zigbee thermostat. I've since dropped using the MQTT approach and rely on the user HE app "HomeAssistant Device Bridge" to share what few local attributes are available. The ecobee is integrated into HomeAssistant using the HomeKit capability. HomeKit is the real limiting factor here... it doesn't appear that the HomeKit standard includes support for modes, etc. Hopefully ecobee rolls out an update to add Matter support that includes more local features.

However, if you really want a cloud-less thermostat, you should probably just replace your ecobee with something else. I'm pretty sure that their business model is heavily dependent on their cloud platform.

My experience has been significantly different. The remote sensors allow my ecobee to to be an integral part of my HVAC zoning system. The main benefit is being able to sense (and control) the temperature of our bedrooms separately from the main areas of the house. The "occupancy" feature has been less useful, but still a benefit.

1 Like

I do that same function with any non ecobee sensor and automation rules. in fact you can replicated every bell and whistle that ecobee has with the rules engine and you get to use the sensors for other functions outside of ecobee. i have been muling over replacing the ecobee's with plane mqtt thermostats and handle the controls with rules.

Anyone interested in a pare of ecobee 4 thermostats?

Dont get me wrong the ecobee thermostats are nice thermostats. i just dont want to share my data with them.