@quinnjudge you probably can see in thread above where I reported this same issue. I learned there’s an easy work around — just assign every vent/room to a thermostat, need it or not. Since I presume all your automations live inside HE and therefore you have the Flair app set to manual mode, assigning the thermostat has effect other than it circumvents the bug you reported. Easy fix, at least for now. Worked for me.
Hey Jaime @ljbotero you still around? Wonder if you saw the last couple questions? Thanks.
Hi @quinnjudge,
Thank you for reporting this issue. I was unable to replicate the problem on my end, and I do see the post messages being sent to Flair endpoint successfully. It’s possible that Flair prevents vents without an associated thermostat from being controlled, which could make sense given that the thermostat is key for determining the room’s temperature and adjusting the vent accordingly. I’ll keep an eye on this, but it appears the issue might be on Flair's side.
Thanks again for bringing this up!
Hi @mluck,
Yes, those 404 responses are coming from the Flair API. I encounter them fairly often too—they seem to occur when Flair’s cloud service isn't responding, which is a known drawback of cloud-based solutions. I’ve also suspected it might be due to request throttling on Flair's end, a common practice to prevent downtime. I’ll work on adding more details to the logs for these 404 errors, so we can better understand the issue.
As for your question on battery/voltage readings, I'll take a look and get back to you soon. Thanks for your patience!
ah, I didn't realize this. Now that I understand, I'm not that concerned. It doesn't appear to create any undesired behavior.
Thank you! I'm interested in doing basic battery monitoring. Having said that, I'm also thinking about wiring the vents to mains power instead of battery since most of them are accessible from my attic -- have you done this? Anybody?
Not at all! I appreciate your work on this. I'm the leech here 
1 Like
I've just pushed an update. I discovered a critical bug that was causing the problem described @quinnjudge above. I also updated some attribute names that were renamed by flair team, including voltage readings. Thanks everyone for reporting these problems!
2 Likes
@ljbotero, does the driver need to use the official Hubitat voltage capability in order to be recognized as a voltage meter? I’m asking because I was using other tools to monitor battery level (e.g., Tile Builder), and it wouldn’t recognize any of my vents as having a voltage meter. Not a big deal, but maybe this is an easy fix?
Battery and voltageMeasurement are two very different capabilities. The former should be on any battery device, the latter typically only found on power management devices.
Yes I’m totally clear about the distinction between battery and voltage. But the voltage attribute in the vent driver isn’t getting recognized as a voltage capability. So I’m wondering if that’s defined at the driver code level or perhaps the root issue is elsewhere?
Is that in the state variables or attributes data?
Interesting it uses system-voltage as the name instead of the expected variable voltage.
Bottom line is it would be possible to modify the driver to expose that system-voltage as voltage. Whether it truly represents the battery voltage is a separate question.
That list is from “Current States” at the top of the device details page. So I think that makes it an attribute. And I am confident it represents the battery voltage of the device (though tracking voltage reliably is tricky business for sure).
So yeah it would seem we need the voltage exposed as a voltage attribute. But I’ll defer to the dev here, @ljbotero. Appreciate you weighing in…
Thanks @garyjmilne for pointing out the right way of defining voltage as a capability, rather than as an attribute. I just pushed a small fix (v0.16) to address that. Voltage should show up now as Voltage instead of system-voltage, which is how the API was defining it.
2 Likes
Yet another example of why this community is so great. None of us had all the knowledge individually, but collectively we nailed it. Thanks @ljbotero and @garyjmilne!
Wondering if I could get some input on this from people that are already doing it? So basically if I go all in on Flair, I'm in a relatively small house (1200 sq feet) with an open first floor first floor and 2 bedrooms on the second floor. It's a central air unit with a heat pump and ecobee smart thermostat. Are pucks recommended in at least the bedrooms (I have ecobee sensors in them already) due to being able to control the temp in a room like it has it's own thermostat? Does anyone know if flair stuff occasionally goes on sale? If you were to redo your flair setup what would you do differently? Any regrets? Have you seen any recovery on heating/cooling costs? Thanks for any input you guys can give me!
With 1200 sq feet, I think you can get away with a single puck--and certainly you can start with one and then see how it goes. However, you will be relying on wifi for communications AFAICT. You may view that as a feature, or as a drawback. YMMV. For me, I wanted the reliability of wired connectivity and I have 20-25 vents, so I went with the Flair Bridge which supports both. Details here.
Note, whether you use a puck or not, you still need a temperature reading in each room/area you want to control. That could come from a puck, an ecobee, or just a thermostat sensor in HE.
I've noticed Flair regularly offers sales, but only 10%. Beats a blank, I guess.
We're thrilled with Flair. We used Keen previously--what a disaster. Flair just works. And since we have adult children that come and go to/from college, we can close off their bedrooms and have the vents automatically close, which has saved a bunch of money. No sense air conditioning unoccupied sections of the house.
Hope this helps. G'luck.
1 Like
Thanks so much for taking the time to reply! The input means a lot and I'm just going to jump in. Putting in windows sensors now. Flairs next.
Hey @ljbotero I was just messaging with Flair support because I was trying to figure out how best to use the API with two homes. I have two Flair bridges, one in each home, each with their own vents. And I have HE in both places. The trick is that I don’t want my vents commingled. I want the vents in house A in show up in that HE instance. And vents in house B to show up in that HE instance.
In the flair app, my vents are already organized by home. So I was asking Flair whether it made more sense to have different OAUTH2 credentials (one for each house) or separate some other way.
The response from Flair was to ask which endpoints we were hitting. “If you hit the api/vents endpoint you will likely get all vents across multiple homes but if you hit the api/structures/<SID>/vents endpoint that should return only the vents in the home specified by the 5-character SID.”
I tried looking through the app code but was unable to decipher. I’m guessing your automation doesn’t distinguish by SID. Is that correct? Would it be difficult to make this change?
Thanks for considering.
EDIT: other thought— if easier, I’m happy to hardcode the 2 SID values in each HE instance since my wife tells me we won’t be buying more houses 
. Just would need you to point me to the spot in the code. Thx
Mi @mluck , you are right the current implementation does not distinguish between different homes. I actually thought about supporting that at the beginning, but I considered as an edge case as it would have added additional scope to the initial work. I think there could be a workaround in your case. Given you have HE in both homes, and I'm assuming they are two separate HE Hubs, then what you can do is change the 'Flair Vents' app code and hardcode your SID into the API calls. The current implementation actually uses the SID into the API calls, but assumes only one SID exists. If you go to the Flair app settings (clicking the little gear on the top right) you can see there a variable named 'structureId', which is essentially the SID. So, to accomplish your objective, you need to find out the two SIDs for the two houses. You already have one from the app settings, then you need to discover the other one, which you can easily find from the Flair mobile app under Home settings. Then, what you need to do is hardcode these values into the code base; to do that, search and replace the following string by your corresponding SID: '${state.structureId}'. For example, assuming your SID for house1 is 123, you'll change the following code:
def patchStructureData(attributes) {
if (!state.structureId) { return }
def body = [data: [type: 'structures', attributes: attributes]]
def uri = BASE_URL + "/api/structures/${state.structureId}"
patchDataAsync(uri, null, body)
}
To:
def patchStructureData(attributes) {
if (!state.structureId) { return }
def body = [data: [type: 'structures', attributes: attributes]]
def uri = BASE_URL + "/api/structures/123"
patchDataAsync(uri, null, body)
}
At least, in theory, that should work. I think it shouldn't be very hard to add SID as a custom setting into the Flair App, I might do that when I get some time. Let me know how it goes.
1 Like
]NP, hope it works, make sure you replace all occurrences of ${state.structureId} to your SID. The above was just an example.
