@HomeAlone Copy-paste unfortunately isn't enough for 0.236 and later. It ships as a Bundle because there's now a fourth piece, a shared library the app needs to compile, and pasting just the app and driver code misses it. Install through HPM (beta channel, Update or Repair), or download flair-vents.v0.237.zip from the repo's bundles folder and import it on your hub's Bundles page. Puck v2 support was added in 0.236, but that build's discovery bug aborted after the first device, which is why yours never appeared. On 0.237 it should come in. If it still doesn't, please open a GitHub issue with debug logs and I'll dig in.
@pomonabill220 Sorry for the slow reply, and fair questions. Quick rundown:
Spread guardrail (C): if the predicted temperature spread across your active rooms is already at or below this, the app skips the adjustment entirely. Bigger value means fewer vent moves, looser balance.
Spread improvement deadband (C): new vent targets are only applied if they're predicted to shrink the spread by at least this much. It filters out moves that barely help.
Enable duct cross-coupling: when a room can't keep up even with its vent nearly fully open, rooms that already hit their target close their vents to redirect air to the struggling room. Duct pressure/temperature readings veto it when it wouldn't help.
Pre-adjust minimum idle dwell (min): the HVAC must have been idle at least this long before the app will pre-position vents for the next cycle.
Pre-adjust trigger threshold (C): pre-positioning only happens once at least one room has drifted back within this many degrees of the setpoint, meaning a new cycle looks imminent. The two gates together keep vents from moving on short idle blips.
Create diagnostic devices: opt-in. Creates one child device per room plus a zone summary device exposing what the algorithm is thinking (targets, learned rates, predicted spread) so you can watch or chart it. Purely informational, no effect on control.
You're right that there's no settings reference yet, that's on me. I'll add one to the README.
On your circulate conflict: that's the pre-adjust path above. Once the idle dwell and trigger gates are met, the app pre-positions vents for the next cycle, which is what's undoing your force-open rule. The supported way to do what you want is the "Open vents during fan-only circulation" toggle: enable it, set the circulation percentage to 100, and the app opens the vents itself instead of fighting you. It keys off the selected thermostat's operating state reporting "fan only", and since your Daikin's internal circulate schedule is invisible to Hubitat, your idea of a rule that turns the fan on and off around that schedule is exactly right.
On the temperature worry: the app only reads the selected thermostat for operating state and setpoint. Room temperatures come from each room's own Flair sensor, or from the per-vent "Choose Thermostat" override if you map one, so the controlling vs controlled temperature difference doesn't feed vent control.
And 0.235 is still available: it's the current stable channel in HPM (turn off beta and Repair), and the zip lives in the repo under bundles/flair-vents.v0.235.zip. That said, 0.237 fixed real 0.236 bugs, so if flakiness is what pushed you back, give 0.237 a try first.
@HomeAlone Your logs were exactly what I needed, thank you. v0.238 (beta) is up with the fix.
What your error revealed: that strange blob in the log starting with capabilities and attributes isn't Flair data at all, it's the app's own device handle after being mangled. When the app hits its API request limit, it defers the request and reschedules it for a few seconds later. Passing the device through Hubitat's scheduler flattened it into plain data, so when the retry fired, the app tried to send sensor updates to "a map" instead of your puck. That's the error repeating every few minutes.
The same investigation uncovered why the v2 puck never showed up: those deferred retries were also overwriting each other, so when several requests got deferred in the same burst, only the last one survived and the rest were silently dropped. Your existing vents and v1 puck didn't care because they were already created; the brand-new v2 puck needed its discovery request to actually complete, and it kept being one of the dropped ones. I also found and repaired a third discovery path (pucks referenced through rooms) that had been silently broken since 0.236.
All three are fixed in 0.238: retries now carry the device ID instead of the device itself, every deferred request keeps its own retry, and the rooms path works again. Update via HPM (beta channel, Update or Repair) or grab flair-vents.v0.238.zip from the repo's bundles folder, then hit Discover again. Heads up: you may see one last copy of the old error right after updating (a leftover retry scheduled by the old code), then it should stop for good.
One ask: I don't own a Puck 2, so I'm flying blind and your logs are my only eyes. If the v2 puck still doesn't appear on 0.238, please turn on debug logging in the app, click Discover, let it run a few minutes, and share the logs in the GitHub issue. Same if the sendEvent error somehow comes back. That level of detail is what made this fix possible.
I updated to 0.238 through HPM. It’s still not finding the puck v2. I’m not getting any error logs now. I turned on debug as you had requested. Here is a blurb from the debug log which is related to puck 2, which has e7c0 in its name in the flair app.
self:/api/rooms/208822/relationships/puck-apps]], puck2s:[data:[[id:e7c0a9ae-0ddf-5526-d727-da00e3b32a31, type:puck2s]], links:[related:/api/rooms/208822/puck2s, self:/api/rooms/208822/relationships/puck2s]], pucks:[data:[], links:[related:/api/rooms/208822/pucks, self:/api/rooms/208822/relationships/pucks]]
@ljbotero THANK YOU!!!!!
TONS of very useful info in my situation.
I do use the thermostat controller app (HE) to "tell" my flair vent controller (your app) how to position my vents, and a couple of rules to force them open during fan only, which my Daikin stat does not state.... so your app and my rules fight eachother, and that is what was happening.
I use temp sensors for room sensors and no Flair pucks... only have a Flair bridge (I really wish we could get local control though!), but your app (version .234 which I will upgrade to .235 which was working great before), is working great!
Thank you again for the detailed explanation of the different features of .236/7.
I will give it another go and see if there is some way I can "tell" or indicate that the fan only is running.
Right now, I just enable the Daikin's circulate schedule and let the stat itself control the fan during the circulate schedule, but that is where there is no indication the fan is running.
I could create a rule in HE that commands a "fan on" in the thermostat controller so that your Flair app "sees" that the fan is running, and also create a virtual switch to command a "fan on" if I wanted to run the fan.
I have no problem using a rule to schedule circulate rather than the Daikin stat. Now that I know how your Flair app handles fan running and where it "looks" for the status.
I do not use the Daikin to control my HVAC as I use the HE thermostat SCHEDULER to select different combinations of temp sensors to average, during the day, so the Daikin stat will not sense those rooms, and will "signal" the incorrect temperature and setpoints.
I will work on this in my situation and give your Flair app another try as the features it has are very useful!
Thank you so much again for your help and detailed explanations!
@HomeAlone That log solved it (I think). Your room payload lists the v2 puck under puck2s while the pucks list next to it is empty. I checked the official Flair API docs and Puck 2 is a separate resource type with its own /api/puck2s endpoints, never returned by /api/pucks. The app wasn't asking for puck2s at all, so no transport fix in 0.238 could have found it.
v0.239 (beta) adds Puck 2 support. Discovery now queries both generations, the v2 puck lands on the same driver as your v1, and readings map to the same attributes. USB powered units won't show a bogus 0% battery. Your v1 puck and vents keep the exact same paths as before.
Update through HPM on the beta channel or grab flair-vents.v0.239.zip from the repo's bundles folder, then hit Discover. The e7c0 puck should finally appear.
I still don't own a Puck 2, so if it doesn't show up or any reading looks off, please send debug logs of a Discover plus a few minutes of polling to the GitHub issue. Your last log cracked this in one shot.
@pomonabill220 Glad it helped, and your plan is exactly right. Schedule circulate from HE and have the rule set the fan to on (not circulate) on the thermostat the Flair app watches. The app treats fan on while idle as circulation and opens the vents to your configured percentage. When the rule sets the fan back to auto, normal idle behavior resumes.
One version note. The circulation toggle shipped in 0.236, so 0.235 doesn't have it. If you want it, go straight to the 0.239 beta, which also carries the fix that makes fan on while idle actually register. And seconding local control, there's a Flair feature request for offline operation on their support site worth upvoting.
I will work on that and try .239.
Another question.... if there is a call for fan AND cool or a call for fan AND heat, is the fan call ignored? IE cool or heat calls override a fan call?
I will also visit Flair's site and upvote for offline operation! THAT would make this a dream come true!
I created a rule that turns the fan on for 10 minutes every hour between 9 am and midnight.
The rule controls the thermostat controller and not the Daikin stat directly as I am also using the setpoint and averaged temperature for your Flair app, and so far... SUCCESS!!!
I did enable "create diagnostic devices" but I cannot find the devices.
Do I need to create them first or does the app create them, and how often do the devices update?
Thanks again!!!!
@pomonabill220 Great to hear the fan rule works. On your question, heat and cool always win. A fan call only counts as circulation while the system is otherwise idle, so during a heating or cooling cycle the app balances normally and ignores the fan.
On the diagnostic devices, you found another bug. The toggle shipped without the piece that actually creates the devices, and the two small drivers they need were missing from the bundle. Both are fixed in 0.240, which is up now. After updating, the devices appear on their own after the first evaluation, one per room plus a DAB Zone Summary, and they refresh every evaluation, roughly every 3 minutes while heating or cooling and every 10 while idle.
One requirement to know. Diagnostics only publish under the balance control strategy (DAB v2). Upgrading keeps you on legacy DAB by default, so to get them, switch Control Strategy to balance in the app. That also changes how vents are balanced, which you may want anyway since it is where the new tuning options live. Thanks for stress testing all of this, you keep finding real bugs.
I had a suspicion that this was the case, but wanted to verify. Thanks!
My fan rule works great and is MUCH easier to modify if I want to change the recirc time and/or when it runs, so overall a win win!
My ONLY nag is that both Flair vents and Daikin stat are cloud based so there can be up to a 2 minute delay before either respond, but the your app and my rules respond immediately so there are times when vents are positioned and nothing is happening..... just have to live with it I guess.... BUT your Flair app is working VERY nice!!!
Glad I was able to help! I was going nuts trying to find the diag device, but came to the conclusion that something wasn't right, or had been left out.
I will update and give it a try!
I am using DABv2 and with your detailed explanation of the features, I really like the better control of this new version of your app!
I am happy to help where I can.
But thank YOU for your work on this!
I am happy to report that Puck 2 is now discovered. Thanks!
I have been getting this error:
java.lang.IllegalArgumentException: No json exists for response on line 5878 (method handleVentPatch)
What does this mean? Is Flair down?
@ljbotero What influence does the outdoor temp sensor have on control?
Is it used to calculate heat load?
@pomonabill220 That error means Flair's cloud answered a vent command with a success status but an empty reply, so they were likely having a brief hiccup rather than being down. The app choked on the empty reply and skipped updating the vent's state in HE, which could leave the device looking stale until the next poll. Fixed in 0.241 (beta), just posted. The app now shrugs it off, records the commanded position locally, and reconciles on the next poll.
On the outdoor temp sensor, honest answer, it does nothing yet. It is not used for heat load. It feeds groundwork for regime aware learning, where the app would learn separate room efficiency rates for hot, mild, and cold conditions instead of one blended rate. The banding code exists but the balancing loop does not consume it yet, so you can leave it unset for now. I updated the README to say so, and it will start mattering in a future release.
@HomeAlone Great news, thanks for confirming and for the logs that got us there. If any Puck 2 reading ever looks off, temperature, humidity, battery, signal, you know where the GitHub issues live.
Thank you for the quick reply!
I noticed that after a while, the error did not show up, so I gathered that Flair was having problems.
I did ignore it and my vents finally started to respond, so I concluded that they were the problem.
Thanks for clarifying about the outdoor sensor.
I do have it unset.
This app is wonderful and has come a LONG way and is VERY "customizable", and with the explanation about the different features, I have been trying different values for them.
Thanks for your time and work!
Can anybody successfully fire a set room active command to false? When I try it from the device command tab, the value never changes to FALSE. Keep thinking I'm missing something obvious.
I don't think this feature is working: open vents during fan-only circulation. I have a Honeywell T6 Z-wave thermostat so Hubitat does know whether it is heating/cooling but I don't think it reports actual circulation. Is it possible when value of thermostatOperatingState is 'idle' that the vents could open?
Also how do I manually set a temperature for a room? I think it’s try to keep the room the same temperature as the hvac thermostat which is too warm for that room.