Hey all,
Utilizing my olde skoole coding knowledge and modern AI to (ahem..."vibe" I guess) code my way to the integrations I want... Thusly, was born this...
Sharing a free, open-source Hubitat integration I've been building that's a companion to @ljbotero's excellent Flair Vents integration — they're designed to coexist.
GitHub: https://github.com/holocronology/hubitat-flair-2
What it covers
- Flair Structure — system mode (auto/manual), heat/cool mode, structure setpoint, away policy, home/away presence, and the "set by" controller (Manual / Thermostat / Geolocation). Full read + write.
- Flair Room — per-room temperature, humidity, setpoint, and active state. Each room is a first-class Hubitat device implementing
TemperatureMeasurement+RelativeHumidityMeasurement, so you can wire them into anything that takes those capabilities. - Flair Puck (V1) and Flair Puck V2 — separate device classes, because they're different hardware. V1 has light + pressure sensors; V2 doesn't but adds display-color, temperature-scale, setpoint-bound, calibration, and lock metadata. Each Puck implements the sensor capabilities its hardware actually supports.
- Flair HVAC Unit — the controllable mini-split entity. Mode, fan, swing, setpoint, power — full read + write, with the cross-entity "displayed mode" decision tree applied (so the tile correctly shows Off when the structure is off, even if the unit's own cached mode is still Heat).
What it does NOT cover
Vents. @ljbotero's Flair Vents integration already covers those thoroughly. If you have all Flair hardware, install both apps — they're designed to coexist.
Coexistence note: if you install both this app and ljbotero's Flair Vents, pick only one set of Puck drivers (mine has separate V1 / V2 drivers; ljbotero's has one fused-with-room Pucks driver) — otherwise you'll get duplicate puck devices for the same physical hardware. Either approach works; pick whichever data model fits your automation style.
Architecture notes
- One parent app ("Flair Climate Connect") handles OAuth 2.0, token lifecycle, polling, and all HTTP. Each child driver delegates writes back to the parent — no driver makes its own HTTP request.
- Polling is async (
asynchttp*) with a configurable cadence (15–600s, default 30s) and a retain-on-failure invariant: transient errors keep the previously pushed state rather than blanking devices to unavailable. - Writes parse the PATCH response and push the result back to the device, so commands feel responsive (~1s) rather than waiting for the next poll.
- Token TTL is currently 10 days on Flair's side; proactive refresh ~60s before expiry.
Tested against
A real Flair account with 1 structure, 7 rooms, 3 V1 pucks, 4 V2 pucks, and 7 Mitsubishi Electric mini-splits. Every read + write surface verified end-to-end.
Status
Beta. Manual install only — paste each .groovy file into Apps Code / Drivers Code per the README. HPM packaging is on the to-do list but not yet there.
Credits
- @ljbotero for the working OAuth + async pattern I cribbed when Hubitat's sandbox kept rejecting my first attempts (turns out the OAuth body has to be a hand-built string, not a Map, and
asynchttp*returns PATCH bodies base64-encoded — Hubitat's quirks are well-documented in his code if you look) RobertD502/flairaioandRobertD502/home-assistant-flair— most of the Flair API behavior in this driver set was learned there first (I maintain a fork:home-assistant-flair-2) and translated to Groovy- The Flair team for the JSON:API endpoints and the responsive OAuth credentials process
Looking for
- Testers — especially folks with V1 pucks (I only had 3 to test against), button-only IR HVAC units (the
constraintsshape differs from mini-splits), or non-Mitsubishi units where the capability matrix may have edge cases I didn't see - Bug reports, feature suggestions, GitHub stars all welcome
- PRs if you have something useful to add
Free, open source, MIT licensed. Have fun.