New Bridge Device
I noticed an iOS update mentioned adding support for the Flair Bridge and I found this product page that appears to be a new bridge device: https://flair.co/products/bridge but there's not many details on that page.
I've got one vent in my home that often reports that it can't contact my puck so I'm looking for a device to amplify/augment those connections. Would this new bridge do the trick? I'd love to see some details about it.
-
Looks like the product page ( https://flair.co/products/bridge ) has been updated with a lot of product details. 👍
In particular, this is news to me an probably lots of you who already run central HVAC systems:
For central HVAC systems with ductwork: A Bridge is required.
(I do have a puck obviously, so maybe the language here is just saying you need a bridge instead of a puck)
-
It seems to be just the language and could use some rewording/elaboration using some common scenarios to clear up confusion.
Potential examples of when you need a bridge.
Central HVAC systems:
- With Flair Puck/Pucks: If you are currently using a Puck/Pucks to control Flair vents and are seeking to improve connectivity to the vents.
- Only using supported 3rd party temperature sensors: To automate control of Flair vents when only using supported 3rd party temperature sensors.
- Not using Flair Puck(s) or supported 3rd party temperature sensors: To control Flair vents manually.
The wording used at the moment makes it seem like past customers are not going to be able to continue using their Flair setups unless they get a bridge, which clearly isn't the case.
Edit:
I just spoke to someone from the pre-sales support staff. According to them, you will still be able to use a puck as a gateway. Listing the bridge as "required" is an attempt to improve the user experience (for both initial setup and connection reliability) for new user - for existing users, if they are facing the problem of pucks and vents being too far away from each other to maintain a reliable connection, a bridge would also improve their experience. A new user planning their purchase won't know for sure if a puck placed on one side of the house will be able to maintain a consistent connection to vents placed on the other side of the house. If that user were to run into connectivity issues, it would sour their Flair ecosystem experience from the start. Using a bridge would decrease/eliminate the likelihood of this happening.
Although the bridge is a step in the right direction for improving the user experience, the wording should be revisited to eliminate confusion for existing customers.
-
"...the wording should be revisited to eliminate confusion for existing customers." They are shooting themselves in the foot here, selling the new bridge as "better coverage" than the older puck when in fact then the new bridge doesn't have any temperature sensor built in - so tell the client they are getting more while taking something away... So a new client is encouraged to buy the new bridge but then they need to buy additional hardware... lol. Wow.
-
I think it really depends on the customer here. As customers, we don't have insight into what percentage of current users are buying pucks for the sole purpose of acting as a temperature sensor for Flair rooms. I'm willing to bet that this is only a single factor, within a myriad of other factors, that they took into account when developing their marketing strategy. In the event that their insight is "a brand-new customer more than likely already owns 3rd party sensors that are supported by us", the new customer would be more receptive to the idea of spending $99 on a bridge (while also being reassured that the bridge will cover distant vents in their house) vs $119 on a puck - If they have coverage issues, the single $119 puck wouldn't be enough and, in the end, they have to buy a bridge to get the coverage they would have gotten if they started with the bridge. In terms of bridge vs puck, if Flair's goal was making as much money as possible, they would have stuck to selling multiple pucks to users at $119 a pop even if the IR and temp functions are of no use to said users.
The only time that it would make sense to recommend the puck instead of the bridge would be for a Nest thermostat user (the fault here rests on Google since their API still doesn't support remote Nest temp sensors) or if the user has a dumb thermostat. However, as I've said before, I'm sure their analysis has shown that a new user is more than likely going to be one that would benefit, in both overall cost to the user and user experience, from using the bridge. It all boils down to the common user profile.As an example, when taking coverage issues into account,
** The fixed cost, regardless of which scenario below is encountered, will be the cost of the vents themselves
A user with a thermostat using supported remote sensors in a 3-room setup:
- Cost = Vents cost + Flair bridge ($99)
Same user that instead starts with a Puck as a gateway:
- If a single puck can provide coverage for all 3 rooms - Cost = Vents cost + Flair Puck ($119)
- If they have coverage issues when using a single puck: Cost = Vents cost + (# of pucks needed to get coverage x $119) OR Cost = Vents cost + Flair Puck ($119) + Flair Bridge ($99).
For the user in the example above, getting a bridge from the beginning will always be cheaper and a better experience when compared to starting off with a Puck. For a Nest thermostat or dumb thermostat user, they should utilize the pre-sales support that Flair offers or inquire here as to what the most cost-effective setup would be for them. In some instances (i.e., depending on the number of rooms you will be using vents in), it would actually be cheaper for a Nest and dumb thermostat user to switch to a thermostat that has supported remote sensors. If the thermostat is the premium version of the Ecobee, this would be around the point where you are going for 3-4 Flair Rooms (if not using the thermostat as a sensor for a Flair room). For 4 Flair rooms: Premium model Ecobee pack, that comes with 2 remote sensors, can be had for $219 + pack of 2 additional remote sensors ($80) + Flair Bridge ($99) = $398. To get the same setup, a Nest or dumb thermostat user would need to buy 4 Pucks ($119 each) for a total cost of $476. The difference in cost continues to get bigger if you plan on expanding beyond this. With the Ecobee, supporting additional rooms would cost you $40 per room vs $119 per room when using the puck. I don't know the cost of supported Honeywell thermostats and their remote sensors, but it's probably even cheaper than going down the Ecobee route.
Even for the more "advanced" users that utilize the Home Assistant integration to automate their vents based on temp sensors that aren't supported, starting with the bridge will be cheaper and result in better connectivity than using a puck + potentially having to buy a bridge if they run into connectivity issues.
TLDR:
My opinion is still that the wording should be revisited. However, I don't think what Flair is doing is connected to a malicious intention of "tell the client they are getting more while taking something away".
-
I picked up the bridge and it's filling a gap in my network well enough (no surprise as it's several rooms over from a puck). Glad I don't have to buy a puck for this since I didn't need its features, just more range on the wireless network.
I would like a PoE option also, but this version would require an external adapter for that. Probably not too difficult to do as it doesn't require much power: the brick it comes with outputs 5V at 1Amp to a USB-C input connector on the bridge.
-
I received my new bridge today and am very pleased with the results so far. I had two smart vents that would intermittently disconnect and one other vent that would regular disconnect. Setup of the bridge was easy and RSSI levels for all smart vents improved. So far, all are connected with no issues.
Given the cost of the puck, I just didn't want to invest in another puck and had mostly given up on the one vent that was the most finicky. There was just no point having another puck just to extend the network. When I saw the bridge become available it made a lot more sense. Now I may actually look at building out on more smart vents for other areas.
With regards to PoE, there are several PoE splitters available online that could get the job done. I may look into that as well.
-
JacobG FWIW, this thread is probably not the best place to get support since we're just discussing the device and its capabilities. I suggest opening a new support ticket etc https://flair.co/pages/contact-us
-
I just grabbed this one. they make really good stuff for raspberry Pis and it supports up to 2a draw so it should be plenty.
-
Steve Rossi Even if it does not, should be possible with something like this: https://amzn.to/4bGuakz
-
I have the same issue Aleks. Im running unifi as well. Any chance you run pihole? Mine has lost connection a few times, reboot and im good. last night it went offline and woke this morning to everything working. Also had the ecobee integration break a few times. Been working with tech support but still only preliminary testing. i wish the bride had a web interface with some diagnostics and testing
-
I have a bridge arriving today and also use UniFi APs. Although I was planning on hardwiring the bridge, I can set it up to use WiFi to test if I experience the same in my setup.
Regarding traffic stats: I’d take the UniFi traffic stats with a grain of salt as they have been known to be wildly inaccurate. I use OPNsense - I’ll be able to report back if the traffic stats are completely wrong.
Regarding bridge disconnecting: I’d start by narrowing down what, within your own setup, could be contributing to this happening.
1. Is the bridge placed in a location where it has poor connectivity to your APs?
2. Are you using multiple APs? If so, do you have roaming enabled? It could be that the bridge has a poor connection to one or more of your APs and keeps trying to jump around (unsuccessfully). If you know that a device should only try to connect to a certain AP and not the others, I found that blocking the device on the APs it should NOT connect to is superior to using UniFi’s “lock device to AP” setting on the AP you want a device to connect to. -
If you'll look at screenshot, it's hardwired, part of the reason I got the bridge.
The pucks also had the same behavior, but I had multiple so the vents would just bounce to another gateway, it was less noticeable.I feel like it might have something to do with DNS and pihole then, as JacobG has same setup and same issue.
-
Aleks screenshot shows wired. Mine is also wired. We can basically eliminate everything you mentioned. I am using the flair supplied ethernet cable as well for now. However when i get my poe splitter ill be using a good quality cat6 for that run.
Edit: it doesnt seem like the device is disconnecting from the network as its still pingable, its like it crashed or stopped getting out to the cloud software.
-
"it doesnt seem like the device is disconnecting from the network as its still pingable, its like it crashed or stopped getting out to the cloud software. "
exactly the same, I have the ping running for a day, not a drop, yes it dropped on the app.
I originally thought it was the POE splitter, but last 2 days running it on the included power brick and same.
EDIT: for whitelist, yea I did the same, we'll see! -
My apologies - my eyes were drawn to the circled traffic stats so I didn't even look at the type of connectivity. However, the traffic stats could still be wrong as this has been reported by users for both wired and wireless devices....just a quirk of the controller software.
Since you are dealing with a wired device, like you all have said, I'd start with identifying if there are any DNS issues and potentially ethernet cable issues.
I haven't used pihole since switching to Adguard Home several years ago. However, the pucks, and presumably the bridge as well, only make requests to "my.flair.co", which isn't on any block list. Are either of you using unbound behind your pihole?
-
No unbound. I have my stat, pihole, and flair actually sitting on my primary lan and not my IOT network for troubleshooting purposes. If all it talks out to is flair.co we should be good as log into that alot vs my phone app and i see the traffic allowed in pihole just fine. If it has hard coded DNS it could be an issue though as i block any dns queries that dont come from my piholes. Hard coded dns is naughty though and i hope flair isnt using it.
-
I havent received my splitter yet so ive been running it on flair provided wires since install. I think you can eliminate that from troubleshooting.
Although Flair's wires are unlikely the culprit, you can't 100% rule them out without testing using a known good ethernet cable and USB-C cable.
-
If it was a cat cable his ping -t would have netted some interesting results. As for the power cable we have two devices doing similar/same thing with two separate power sources. Ill have my uctronics poe splitter here in the next day or so, so ill be able to do that as well. Without shh or web interface with diagnostics on the bridge we are pretty limited.
Please sign in to leave a comment.
Comments
52 comments