Trying to set Climate in HA to Function like an EcoBee (or Other Smart Thermostat), Need Some General Guidance

I am used to having an EcoBee thermostat, and my new house has ductless mini splits in each room instead of central air. I am new to home assistant and trying to basically implement the features that the EcoBee had. I’m finding that the learning curve for HA is massive, even coming from an IT background. Basically, the features I would like to implement are:

  1. Climate profiles such as Home, Away, and Sleep which adjust the temperature in each room based on a preset.
  2. Switching between profiles for home/away triggered by geofencing, and home/sleep by hitting a button on my phone.
  3. EVENTUALLY, I would like to add motion sensors which would set back the temperature in rooms that are unoccupied. It would need to have a buffer and use the history, so simply walking through a room to pick something up wouldn’t trigger it. For example: “If motion detected at least 5 minutes of past 30 minutes, then room is occupied… else: room is unoccupied”
    a. Can I have some guidance on how the best way to achieve this would be?

One of the things that overwhelms me with home assistant is all of the terms! We have devices, integrations, services, entities, objects, helpers, templates, integrations, automations, scenes, scripts, blueprints, addons, areas, dashboards, YAML… and the list goes on. It’s really hard to see how these all fit together without any working examples to go off of.
Do I want to trigger the climate adjustments in an automation, or create a scene for them (home, away, sleep) and use the automation to call that? The integration for the minisplits uses a climate object for each unit. The problems I have encountered with the scenes are:

  1. Every time I try to open and adjust the scenes, the units start adjusting. Apparently, you can’t view or edit them “offline” without putting every device into that state which seems kind of dumb. People said to get around this by using YAML. This brings us up to the second problem I encountered with scenes:
  2. Adding the climate entity for all 8 units adds a tons of YAML. My scenes in the YAML file is literally 1600+ lines long with just the three scenes I mentioned (home, away, sleep) controlling the units). Creating the scenes in the user interface seems to have added a ton of internal “fluff” values used by the integration that are not necessary and will not change. I manually removed these from the YAML and applied changes. But now any time I run the scene in LoveLace (not sure why the GUI seems to have that name), the settings are applied to the units and immediately reverted back one or two seconds later.
  3. Lastly, my third issue with using scenes is the clunkiness of making adjustments. If we’re going through a period of cold weather and I want to adjust all the setback temperatures by a few degrees I have to open each device inside the scene settings and adjust it manually. I would rather have a variable for “set back temperature” and be able to adjust that either manually or automatically and have it applied to all of the units. So something kind of like:
    a. Sleep:
    i. Bedroom: set to “warm” variable
    ii. Kitchen: set to “cold” variable
    b. Away:
    i. Bedroom: set to “cold” variable
    ii. Kitchen: set to “cold” variable
    c. Home:
    i. Bedroom: set to “warm” variable
    ii. Kitchen: set to “warm” variable

Based on what I’ve read, it seems that HA calls variables “helpers” for some reason? Since scenes are not proving to be flexible and support variables, do I need to do some kind of scripting?

I feel so lost, like I need to be a master software developer to get any of this working. Is there someone I can pay to help get everything working for me?

1 Like

I have an ecobee system and this drives me crazy, because it does exactly this, and am working on replacing all of its “smarts” with “just do what home assistant tells you”. Probably going to eventually replace the ecobee devices themselves, once I can find something zigbee that isn’t hideously ugly.

Yeah, I hear that. It takes a little to get it all straight. Personally, I just ignore scenes — I use them with one or two existing blueprints that triggers them, but mostly I put all of my stuff in automations. You’ve listed a bunch of drawbacks, so I won’t duplicate — just affirm that that’s probably not the way to go.

Of all of the complicated terms, the most basic thing in HA is an “entity”. And an entity is a thing with a state (and optionally some extra values, called attributes). Pretty much al of the other things are represented by underlying entities — sensors, controls and things, but also even automations and scenes.

Some of these entities don’t correspond directly to any real device or other thing in HA. These are “helpers”, and there are a lot of possible types:

You can use these as global variables — and you can also use them as adjustable controls. For example, I made a panel for my daughter with a toggle helper and a date-time helper. Then, an automation triggers at the set time, exiting immediately if the toggle is off. If it’s on, it slowly turns on the light and plays morning music on her speaker – it’s an alarm clock.

For your use, you may want to use the min/max/average helper to aggregate some of your sensors.

Home Assistant also has a bunch of built-in services — built in, or added by integrations, to be more accurate. Things like light.turn_on or climate.set_temperature. Automations can act on entities or devices (“devices” are basically “collections of entities” — unfortunately, defined by integrations rather than things you can just make up.) So you could have an action which refers to your climate device and then sets the temperature — or you can call the climate.set_temperature service. The advantage of that is that most services let you provide a list of entities, devices, or areas to change all at once. And, they can usually change multiple things — hvac mode and target temperature at once.

And finally (this post at least), “scripts” are collections of actions that you can call as services just like you might an in-built service. This is useful basically wherever you find yourself duplicating a lot in an automation — you can move that to a script to avoid spaghetti-code.

The mix of yaml and jinja templates makes for a kind of messy scripting language, but once you’re used to it, it serves well enough.