[RELEASE] *any* hub (C5/C7/C8) Ecobee No Cloud HAP Thermostat (Local) — direct control of an Ecobee thermostat, no Apple hardware

[ramset]

TL;DR

A native Hubitat driver that controls an ecobee thermostat 100% locally over the HomeKit Accessory Protocol (HAP) — the hub itself acts as the HomeKit controller. No ecobee cloud account, no api.ecobee.com, no Apple TV / HomePod / Home Hub, no Pi or bridge. You pair the hub directly to the thermostat with its 8-digit HomeKit setup code; after that it's all LAN.

As far as I've found, this is the first direct, cloud-free ecobee integration on Hubitat — and it runs on a plain C5 / C7 / C8, not just newer hardware.

---

What it does (all local, no cloud)

Thermostat control

• Mode: off / heat / cool / auto (including dual-setpoint auto)
• Heating & cooling setpoints, "Set Desired Temperature," raise/lower setpoint
• Fan mode (auto / on) and actual fan-running state (fanState: inactive / idle / blowing)
• Comfort profiles: Set Comfort Profile (Home / Away / Sleep), with a comfortProfile attribute showing the active one (or Hold)
• Resume Program, plus a holdEndsAt attribute (when the current hold/event ends)
• Humidifier target (Set Humidity Setpoint)
• Per-profile setpoints exposed as attributes (home/away/sleep heat & cool)
• Alerts/reminders text (thermostatAlert)
• Live temperature, humidity, and operating state
• "Macgyvered" extras built on the driver's own timers: Hold Until (set a profile/temp for N minutes then auto-resume), Boost (nudge the setpoint +/- for N minutes then resume), Fan Run Time (timed blower run to emulate the per-hour fan minimum HomeKit doesn't expose), and derived booleans onHold / alertActive for easy rule-gating.

Real-time: a persistent encrypted session with HomeKit event push — changes show up instantly, no polling — and it self-heals (tolerant keepalive watchdog + auto-reconnect).

Sensors: the thermostat's built-in motion/occupancy and any remote room sensors appear as their own child devices (motion, presence, temperature, battery). This keeps the thermostat itself a clean Thermostat (so it still exports to Apple HomeKit) while each sensor exports as its own accessory.

Multiple thermostats: fully supported — run one instance per ecobee.

---

How it compares (and where it doesn't fit)

A few people have asked how this stacks up against the other ways to run an ecobee on Hubitat (thanks @mavrrick58 for the nudge). My honest read — corrections welcome:

Method	Local / no cloud	Needs ecobee cloud account	Extra hardware/software	Remote room sensors	Best for
This driver (HAP, local)	Yes	No	None	Yes — each as its own child device	Cloud-free, instant, simple control on any hub
Ecobee Suite (SANdood)	No (ecobee cloud)	Yes	None	Yes (rich)	Maximum features — schedules, vacations, history, weather
Built-in Ecobee integration	No (ecobee cloud)	Yes	None	Yes	Official-style cloud integration
Built-in HomeKit Controller	Yes	No	None	Reportedly struggles once a secondary sensor is added (per forum reports)	Native local control, simpler setups
Ecobee via Home Assistant (HomeKit)	Local to ecobee, but…	No	A running Home Assistant + the HA↔Hubitat bridge	Yes	People already invested in Home Assistant
Built-in "HomeKit" bridge	—	—	—	—	This is the export direction (Hubitat → Apple Home), not a way to control an ecobee

Short version: if you want every cloud feature (full schedule editor, runtime history, weather, editable vacations), Ecobee Suite is still the most complete and these two pair well. If you want direct, cloud-free control with no extra software and remote sensors that actually behave, that's what this driver is for.

---

Supported models

• Works on the HomeKit-era ecobees: ecobee3, ecobee3 lite, ecobee4, ecobee SmartThermostat (with Voice Control).
• The ecobee3 lite has no built-in occupancy/motion sensor — so with no remote sensors it creates no sensor child device. That's expected, not a bug; all thermostat control still works.
• The 2022 Smart Thermostat Premium / Enhanced (Matter-era) are unconfirmed. If you have one and something's missing, run Dump Accessories (below) and post the output so it can be mapped.

---

Install

Via Hubitat Package Manager (recommended): search for "Ecobee HAP Thermostat (Local)".

Manual import (Drivers Code / Libraries Code → Import) — all three:

• Library: https://raw.githubusercontent.com/RamSet/hubitat/main/libraries/hap-core/hap-core.groovy
• Thermostat driver: https://raw.githubusercontent.com/RamSet/hubitat/main/drivers/ecobee-hap-thermostat/ecobee-hap-thermostat.groovy
• Sensor driver: https://raw.githubusercontent.com/RamSet/hubitat/main/drivers/ecobee-hap-sensor/ecobee-hap-sensor.groovy

v0.15.0 note (shared engine): the HAP engine (pairing, encrypted session, port discovery, reconnect) now lives in a shared hapCore library. I pulled it into a library because it's now shared with my new HomeKit Import (Local) package (imports any LAN HomeKit accessory into Hubitat) — same protocol engine under both, so fixes happen once and benefit this thermostat and every imported device. No setup change and no re-pairing — existing pairings are preserved.

Existing users updating via HPM: HPM does not auto-pull the new library (neither Update nor Repair brings it in), so you'll see "library not found: #include RamSet.hapCore" until you add it once, manually: Libraries Code → Import → the hap-core URL above → Save. One-time; the driver compiles immediately after. Fresh installs pull the library automatically.

(If you installed a very early build from the old flat path, the files moved into drivers/. Re-import from the URLs above so updates track the new location.)

---

Pairing

1. On the thermostat, reset/remove its HomeKit pairing if it's already in an Apple Home (this frees a slot and gives a fresh setup code). HomeKit is single-admin — it can't be in Apple Home and here at the same time.
2. Create a Virtual Device using the Ecobee HAP Thermostat driver.
3. In its preferences, enter the thermostat's IP and the 8-digit setup code, then Save.
4. The setup code rotates quickly — generate it right before pairing and Save promptly (pairing at the thermostat is easiest). Watch hapStatus go connecting → live. Sensors appear as child devices automatically. After pairing, the code is stored as long-term keys and is never needed again.

---

Exposing it back to Apple HomeKit / Google / Alexa

The thermostat is a standard Hubitat Thermostat, so it exports cleanly through Hubitat's built-in HomeKit Integration (and Google/Alexa). Motion/presence reach HomeKit via the child sensor devices — a Hubitat device can't be both a Thermostat and a motion/occupancy sensor in the HomeKit export, so the sensors are deliberately separate children.

---

Companion apps (optional)

There's a separate package, "Local Ecobee Helpers" (also in HPM), with offline helper apps built on this driver: per-room vent control, open-contact HVAC pause, and humidifier control. All local.

---

What HAP does NOT expose

These stay cloud-only or aren't on the HomeKit interface at all, so pair this with Ecobee Suite (cloud) if you need them:

• Weather / forecast, the full multi-period schedule editor, runtime / equipment history, vacations as editable objects
• A few device settings the ecobee keeps off HomeKit entirely: screen brightness, speaker volume, and fan minimum-runtime-per-hour

(You can detect that the thermostat is on a hold/override and when it ends via comfortProfile = Hold + holdEndsAt, and emulate a per-hour fan minimum with Fan Run Time.)

---

Troubleshooting

• "library not found: #include RamSet.hapCore" after a v0.15.0 update? Import the hap-core library once (see the v0.15.0 note under Install) — HPM doesn't auto-pull it into an existing install.
• No sensor child appears? If your model has no built-in occupancy sensor (e.g. ecobee3 lite) and no remote sensors, that's expected — there's nothing to expose.
• Unknown model / something missing? Click Dump Accessories on the device and post the ===== HAP /accessories dump ===== block from Logs.
• Logging: preferences include Enable info logging and Enable debug logging toggles (debug auto-disables after 30 minutes).

---

For the curious (how it works)

The complete HAP handshake runs in Groovy on the hub: SRP-6a pair-setup (3072-bit, SHA-512), X25519 ECDH + Ed25519 pair-verify, and a ChaCha20-Poly1305 encrypted session. Because the Groovy sandbox blocks KeyAgreement / Signature / SecureRandom, X25519 and Ed25519 are hand-rolled in BigInteger. (Hubitat staff are adding those crypto classes to the sandbox in an upcoming build; since the engine now lives in one shared library, slimming it down to native crypto later will be a single change that benefits every driver that uses it.)

---

Related

• HomeKit Import (Local) — same HAP engine, pointed the other way: import any LAN HomeKit accessory (switches, lights, locks, garage doors, shades, sensors, more) into Hubitat. Release thread → (drop the link here)

---

Source & license

• Repo (public): GitHub - RamSet/hubitat · GitHub
• License: Apache 2.0. Provided as-is, without warranty — it controls real HVAC hardware, so test it on your own setup.

Feedback, model reports, and corrections welcome — thanks to everyone who's been testing on the forum.

[ramset]

[RELEASE] HomeKit Import (Local) — bring any LAN HomeKit accessory into Hubitat (no cloud, no Apple hardware, no Homebridge)

HomeKit Import pairs Hubitat directly to a Wi-Fi/LAN HomeKit (HAP) accessory, reads what it exposes, and auto-creates the matching Hubitat devices — with live updates and control. Think of it as Homebridge in reverse: instead of exporting Hubitat devices to HomeKit, it imports HomeKit accessories into Hubitat. 100% local — no cloud account, no Apple hub, no bridge, no extra hardware. It speaks HAP natively on the hub (SRP pairing, encrypted session, the lot), so the accessory talks to Hubitat ex…

[RELEASE] Local Ecobee Helpers — offline companion apps for the HAP Thermostat (vents, contact-pause, humidity)

A small companion package to the Ecobee HAP Thermostat (Local) driver. Same philosophy — 100% local, no cloud — these are the everyday automations people used to lean on Ecobee Suite for, rebuilt from scratch to run entirely off the local driver. Inspired by SANdood's Ecobee Suite helpers; none of this touches the internet. It's a parent app that holds your local thermostat reference, under which you add as many child helpers as you need. Three helper types in this release: Room Vent Per-room…

[mluck]

@ramset, I’m afraid you got one thing very very wrong: specifically when you said “this is a bigger deal than it sounds”. Umm, not my reaction at all. To my thinking, local control of Ecobees sounds huge, nay, transformational!

Excited to dig into this! Well done, sir.

[tray_e]

Is there a difference between this driver and the native Homekit already available on hubitat?

[ramset]

This driver is not part of the Homekit integration.

It uses the same protocol (HAP) to communicate with the Ecobee thermostat (just like the AppleTV/Homepod would).

It basically enables the Hub to connect directly to the thermostat and control it locally, without the need of Ecobee's cloud services. The only thing it has in common with the Native Homekit integration, is the Homekit name

Think of this as a pipe from the hub to the thermostat, on your LAN, without the need of an internet connection (or an AppleTV/Homepod for that matter).

IF you so desire, once connected to the thermostat, with this driver, you can expose the newly available device to your Home app, via the native Hubitat Homekit integration

[MikeSas]

Very impressive sounding and thanks for sharing!

I am assuming that it does not have the extensive support for all the custom attributes that are available on the Ecobee Suite integration app? Do you foresee any issues with running both at the same time for local access for the core capabilities you have made available and still have access to the additional controls in the Ecobee Suite?

[ramset]

Yeah, you nailed it — this thing doesn't have anywhere near the attribute list Ecobee Suite does, and honestly it never will. Suite pulls all that rich stuff (programs, climates, equipment status, weather, hold status, humidifier/dehumidifier, smart recovery, the heat/cool ranges, etc.) straight out of the ecobee cloud JSON. None of that lives in HomeKit — HAP only hands you the core thermostat characteristics. So I get temp, humidity, mode, operating state, the setpoints, fan, and the remote sensors, and that's basically the ceiling over local. No amount of cleverness conjures equipmentStatus out of a protocol that doesn't have it lol.

Running both at the same time? Totally fine, and honestly that's the way I'd do it. They're two completely separate pipes — Suite goes out to api.ecobee.com, my driver stays on the LAN over HAP. The thermostat already juggles cloud + HomeKit every single day (that's literally how the ecobee app and Apple Home coexist), so there's no fighting at the protocol level. The one thing to keep in your head is plain old last-write-wins: if both of them throw a setpoint or mode change, the device just takes whoever spoke last. No harm done — each side re-syncs to the real state right after (mine basically instantly thanks to event push, Suite on its next poll cycle).

So the sweet spot is exactly what you're describing: lean on the local driver for fast, no-internet-required core control and anything you need to keep working when the cloud face-plants, and keep Suite around for the deep features. Best of both, no real downside.

FWIW there are a couple more HAP characteristics I could surface if there's interest — display units, the ecobee "resume/hold" bits, maybe a couple others the accessory exposes. Not cloud-tier stuff, but if people want 'em, easy enough to add.

[ramset]

Quick correction to my own post — turns out I was selling it short lol. I went and dumped the full HomeKit accessory database off the thermostat, and there's way more reachable over local HAP than I first said. Home/Away/Sleep is right there — the ecobee exposes the comfort-profile selector and the heat/cool setpoints for each profile as custom HomeKit characteristics. Same deal with the humidifier setpoint, fan min-on-time, hold-until time, and even the alerts/reminders text. So all of that can come over local, no cloud. I'm wiring it into the driver now (read-confirming the profile enum on real hardware first, because I'd rather not YOLO a write that flips your HVAC mode).

What genuinely can't come over HAP, and where Ecobee Suite stays the boss: weather/forecast, the full multi-period schedule editor, runtime/equipment history, and vacations as editable objects. None of that crosses the HomeKit boundary — it only lives in the cloud API. So the hybrid story still holds, I just had the line in the wrong place: local gets you a lot more of the day-to-day than "core thermostat only."

[MikeSas]

Thanks that sounds great! Many of those extra bits will be helpful too. The Hold / Resume bits would be especially great. You may actually cover most of what I need. The only thing I use with Vacation is restricting or triggering rules based on the Ecobee entering Vacation state.

[MikeSas]

Oh and FYI, I am heading out of town tomorrow AM so will not have a chance to really test this out until I return next week. I will let you know my experience after I have a chance to play with some.

[danabw]

@tray_e

Is there a difference between this driver and the native Homekit already available on hubitat?

@ramset

from any hub (C5/C7/C8)

I think this is a key headline for anyone who doesn't have a C8-Pro, which is required for the Hubitat HomeKit connection to Ecobee thermostats (which is also local, and doesn't require any Apple hardware).

So C8, C7, and C5 users should be happy about this if they want a local control (and who doesn't) Ecobee option.

[ramset]

I looked into it. As far as local HAP exposes it, "Vacation" surfaces identically to a manual hold with a dated end time — there's no distinct vacation flag over HomeKit. I updated the driver so it exposes comfortProfile = Hold and a holdEndsAt attribute while one's running. (Holding to a named comfort setting still reports Home/Away/Sleep, so only a manual temperature hold looks like a vacation.)

So you can reliably gate rules on "thermostat is on a hold/override (and when it ends)" — which == vacation if you don't otherwise use manual temp holds. A soft heuristic also works: an override ending days out is almost always a vacation, vs. a manual hold that's usually hours/next-transition. Creating/editing vacations still stays cloud-side (Ecobee Suite).

[tray_e]

@danabw

I think this is a key headline for anyone who doesn't have a C8-Pro,

Or an instance of Home Assistant and HADB (cause this was the initial reason I started up my Home Assistant instance in the first place).

Now, the main reason I don't bring it back into HE directly is that I have automations based on multiple locations (My and My Wife's work locations) in Home Assistant. HE doesn't have multiple presence locations, so it is easier for me to keep it in HA.

However, if it can get other comfort settings besides the default home, away, and night locally, then that might be an interesting development.

[Rxich]

@ramset This is fantastic, thank you very much. I wonder if this could be leveraged to incorporate other komekit devices, for those of use who despise apple(or samsung, google, alexa) anyway..

TIP- for others doing this I was trying to setup by getting the code off my ecobee, walking back to my office and typing it in on my desktop. Failed about 3 times. I had to perform the pair on my phone, right in front of the thermostat( it knows when you're there) immediately after generating the code.
Walking back to my office only takes about a minute, and I made sure to exit the pairing code screen before walking back to my office- so I don't think the code cycled?
Or maybe this is the way it's supposed to be done, directly in front of the thermostat?

Here were the errors: (sorry can’t find the hide text option)

dev:8802026-06-24 5:11:09.307 pm

error

connect: java.net.ConnectException: Connection refused (Connection refused)

dev:8802026-06-24 5:11:09.240 pm

warn

HAP: mDNS port detect timed out; using last-known port

dev:8802026-06-24 5:11:02.181 pm

info

HAP: setup code entered — pairing

dev:8802026-06-24 4:59:29.413 pm

warn

HAP: not paired

dev:8802026-06-24 4:55:06.274 pm

error

connect: java.net.ConnectException: Connection refused (Connection refused)

dev:8802026-06-24 4:54:56.921 pm

warn

HAP: not paired

dev:8802026-06-24 4:52:37.348 pm

error

connect: java.net.ConnectException: Connection refused (Connection refused)

dev:8802026-06-24 4:52:37.275 pm

warn

HAP: mDNS port detect timed out; using last-known port

dev:8802026-06-24 4:52:30.212 pm

info

HAP: setup code entered — pairing

dev:8802026-06-24 4:50:34.954 pm

error

pair M4 02 (wrong/rotated code?)

dev:8802026-06-24 4:50:32.485 pm

info

HAP: detected port 54575

[Prometheus_Xex]

Trying this out and I see something odd…
when thermostat is set to AUTO, the fan comes on and when set to ON the fan turns off.
It’s reversed somehow.

[ramset]

Ha! I’m melting here. Didn’t set it to auto but that was indeed a bug you just exposed. Update the driver ( via import).
Fixed it.

[Prometheus_Xex]

Thanks for the quick fix!

[jkudave]

So I currently have my 2 Ecobees configured in Hubitat using the native HomeKit Controller integration on my C8 Pro hub. I then bring them back into Apple Home using Homebridge via the Homebridge v2 app. If everything is currently working, what benefits would I see\gain using your drivers @ramset over my current setup?

[ramset]

There should not be any difference nor added benefit.

This driver brings the same support for the ecobee thermostats to non C8 Pro hubs.

I use the exact same process to bring my ecobee thermostat (via homebridge although one could use the Hub’s Native Homekit integration to do the same) into the Home app.
The only difference is that (while I have 2 x C8 - classic -), this resides on a C7, a hub that now connects to the Thermostat, the same way the C8 Pro does.

[Prometheus_Xex]

I think I might have noticed something else about Thermostat Fan Mode. When the fan was manually running, then turned off manually (from within WebCoRE), even though I waited a long time, this driver still thinks it’s running and shows “thermostatFanMode” is ON**,** when it’s actually off. ONLY when I hit REFRESH from within the device in Hubitat does it then show it’s off. In other words the driver doesn't refresh the fans current state.