What happens if there is no internet?
So I am looking to invest in smart vents but I have seen many tech companies come and go in the past 10 years. Is there any ability with Flair to operate in an "off grid" mode if internet were lost?
And if, God forbid, Flair went out of business what would happen to the functionality of the smart vents and the required Pucks I invested in?
I have a large house and I would likely be looking at several thousand dollars to make the full conversion, the fact that everything is cloud based makes me quite nervous to make such an investment in a relatively new company.
Is there any consideration to having at least a base "offline" mode of operation that would allow the system to still be functional?
-
Official comment
Hi Patrick,
Be assured we are financial solvent and rapidly growing our business!
As with most iOT solutions, the data and processing exist in the cloud layer. This makes the Puck lightweight and allows Sensor Pucks to be battery operated. It also allows for Flair to integrate with other third party products that have cloud-based APIs, like smart thermostats, Alexa and Google Assistant.
To have a fully offline solution, we'd need to create a bulky base unit that could store all the data and handle the processing. We kinda have to weigh that against the frequency of a system going offline and the convenience of lightweight controls.
This isn't to say that it's out of the question, we just don't have the demand for it right now.
All the best,
Finn
Comment actions -
What about a way to run the "cloud" based stuff locally on a local pc on the home network. The cloud aspect is a big problem for me. Are the vents, themselves, zigbee or such and can the vents be paired to something else that isn't cloud based like a mixtile hub? For what it's worth, Keen doesn't even have an API but their vents are zigbee and possibly would connect to such a hub.
For me, the only functionality I need is a way to open and close the vent via an automated PC based software (that I write). I am currently using the flair API for this but and looking for a method without cloud or internet reliance. I shouldn't need to go out to the internet to control devices locally in house.
-
Finn, I appreciate that you say your company is financially stable, I am sure Ecovent and others said the same thing.
In terms of Non internet functionality I do not see why any major hub would be required. There should simply be a basic online mode that exists that isn't as fully functionally enabled but that still allows the system/thermostats and vents to operate like a normal thermostat/vent system automatically. Basically like an offline version that is the equivalent of the programmable thermostats everyone has. But even then, in the longer term, it would be good to have the ability for end users to have an option to have a "stand" alone system backup.
I can think of many scenarios where this would be important to prevent damage and catastrophe in the even of the internet going down (which for many is just a matter of time)
I have a house that is 4000+ sq feet, with two furnaces and a lot of vents. My cost to fully setup my house with Flair would likely be in the $2-$3,000 range. As a customer I would GLADLY pay another $500 so that my system had the capability operate (even if not quite as efficiently) offline if the internet went down. Or if god forbid, your company went out of business.
Keen and other systems have the ability to use some other options that allow them to be not only dependent on Keen's servers. I think Flair is missing the boat on making sure their systems are flexible enough to not become paperweights if the internet goes down. I like Flairs features better but I will have to think long and hard before making an investment with the risk that's attached. -
H Patrick,
Keen requires a hub. They call it the "Smart Bridge". It's considerably larger and heavier than the Puck, must remain plugged into power and can't be mounted on a wall or used wirelessly like Flair Puck can.
Most Smart home systems that operate a locally require a hub. This centralized piece of equipment houses the physical components necessary for communication, processing and storage.
The only real advantage of a system that can run locally is if the internet goes down frequently and for long periods of time. If the internet goes down, Flair Smart Vents will open. This is a fail-safe mechanism. And when the internet comes back up, Flair resumes where it left off.
Just curious, how often does your internet go down - and is it for long periods of time?
All the best,
Finn
-
Hey Finn,
Yes, Keen requires a hub. However, that hub can be an open source hub anything that supports ZigBee. While connecting to one of these hubs doesn't provide all the automatic open and closing logic, you could open and close your vents via automation without internet in these cases.
Another concern with something that's dependent on the cloud is that the internal SSH certs that allow them to connect to https sites eventually expire. If the company isn't around and able to renew these via firmware upgrades, then all these cloud devices stop working and cannot be fixed.
-
Hey,
I'm looking into purchasing smart vents and I gotta agree with the folks here -- one of the primary things I'm concerned about is that all the vents don't turn into bricks if Flair goes out of business. Right now, I'm strongly considering Keen instead since their devices will work with any Zigbee hub.
I don't think it's been said explicitly here: are Flair vents functional in any way, shape, or form if flair goes out of business, or chooses to shut down the cloud service? I appreciate all the marketing about having open APIs, but I care a lot about making sure investments I make in technology for a house I'll own for likely the rest of my life will continue to work even when Flair may have chosen to move on.
Thanks, Jay
-
I am tending to agree with the folks above. I really like the Flair product but with no way to open and close the product through some local only app it could become bricked. I would also like to point out to Finn that yes those local options require a hub that is plugged in all the time so does the Flair as the first Puck must be plugged in so it can communicate with the rest of the system.
Lastly I do not like the idea that I can only control a vent by the temperature in a room versus just saying I want it opened or closed.
please let me know if I have come to the wrong conclusion as I do so want to go with the Falir vents.
-
Hi Kevin,
You can control Smart Vents manually in Manual mode by setting System to “Manual”, or if you just want to control individual Vents manually, remove the Puck from the “room” in the Flair app:
1. Tap the room
2. Tap the 3-dot menus at the top right
3. Select Settings->Devices
4. Expand the Puck section
5. Uncheck the Puck(You can put it back in the room the same way.)
Once the Puck is removed, you’ll see the Vent widget with the manual controls.
All the best,
Finn -
I have to agree with everyone else. In fact, I just recently had an experience with some hardware that apparently a year ago would have worked fine, but since Google decided to kill off the Works With Nest API without having a replacement ready in Works With Google, functionality was broken.
They didn't have to go out of business to make the product useless, they chose a direction and flipped a switch that left countless customers stuck.
I'm not saying Flair would do that, but I bet if the right offer came along and Flair was purchased by another company that then decided to go a different direction with any of a number of aspects of the business, suddenly we're left with disconnected temperature sensors and some expensive vent covers that we can't even close manually.
There really does need to be a "backup plan" to keep that from happening. Plus, I suspect many companies are going to start getting more and more pushback from customers about all the "Cloud" integration. How many of these cloud servers have been hacked and given hackers access to a customer's devices? A persistent hacker could find a way into any connected system. Once they are in, they can crank up your heat, unlock your doors, disable your security system, use the occupancy sensors or the thermostat status to tell if anyone is home or not, etc..
To be honest, 99.9% of these systems don't need to be (and most shouldn't be) online in the cloud anyway, it's just not necessary.
Advantages of a hub:
- Local control of your devices without requiring internet access
- Can still provide "Cloud" access to customers by having the hub poll the portal website
- Keeps customer data on the customer's premises, limiting liabilityThe other option is to update the firmware in the Pucks and Vents to use a standard protocol. I think I read somewhere that Flair uses Zigbee but it's a proprietary protocol layer on top of it, or something of that nature. Change that so the Vents and Pucks use the standard protocol and you won't need to make a hub, you can just partner with companies that already have hubs for Zigbee. People can then choose to use something like a SmartThings Hub, or a Hubitat Evolution, neither of which requires the internet to remain functional.
At that point you could also drop the headaches of the API, since those hubs would be able to talk directly to the devices it would no longer be needed.
-
Excuse me, while I fire a parting shot:
Another, apparently as-of-yet-unmentioned elephant in the room here is the lack of privacy and security with the IoT, cloud approach. You are logging people's GPS positions and intimate information about their homes--when they're there, when they're not, etc.
I work in Internet security, and I guarantee you that some of your employees already have unfettered access to this information. It's only a matter of time before hackers do too--if they don't already. It's also only a matter of time before employees abuse their access to this information--again, if they haven't already.
The canned responses to such concerns are always the same and have been made, ad nauseum, by innumerable companies, both before and after embarrassing privacy incidents occurred. Some people never learn.
My 3.5-story home has major problems with temperature differentials from floor to floor, and your tech would've been a perfect solution for that, but your refusal to support independent and private operation forces me to give all of that money to someone else. Your loss, and I'm sure that plenty of other, privacy-minded individuals are taking their money elsewhere. Adieu.
P.S. I can't wait to see how long it takes for this message to be deleted.
-
Adding to the chorus; I'm building a house and am looking at Flair. Not falling back to a even a basic degree of automation without Internet connectivity is a deal breaker for me. It's not a question of casting aspersions about your corporate solvency or good graces; Internet access is not reliable and at times, especially during inclement weather, and that's a germane issue. There are other scenarios, some alluded to here, that will end up with the devices being effectively bricked. Corporate acquisition, mundane things like SSL certs not renewed, trade wars, you get acquired and asset stripped -- or you could just decide you want $5 a month per vent for the privilege, or else. This latter seem far fetched? That happened only this week with Nucleus (see this thread https://twitter.com/rklau/status/1330544963562602497 ).
As a small company tech CEO myself, I can only urge you to listen to what your leading edge customers and prospects are telling you. I'd be willing to pay extra per vent, or for a "puck plus" for the "works-adequately-offline-as-long-as-your-wifi-is-up-and-you're-home" mode. Personally, I thought the dedicated puck was a hub, just with a different name. Surprised that it isn't, TBH.The market - your community - is telling you something important here on this thread. I'll be buying in a few months when my home is delivered. I'd love to buy from you, but I won't if there isn't a fallback when WiFi is up, but the Internet is unavailable.
Edit: typos
-
Right. It doesn't need any form of offline automation, IMO. Just simply open up the ability to tell the vents to open or close by talking to the vent or puck directly without internet.
Currently, you can do this with Keen vents. If you get an open source zigbee hub, you can marry the keen vents to the hub and use the hub API to control the vents with no internet.
-
I returned my Flair vents and picks and bought Keen vents without their hub. I connected them to a Hubitat hub and have full offline local control, just like it should be. I couldn't be happier with this new setup.
The simple fact is, there's zero reason for vents to be controlled in the cloud. Zero.
I have nothing against Flair, and I wish them well. Being cloud based and using a proprietary protocol was a deal breaker for me.
-
Kevin Summers Thank you for mentioning Hubitat; I'm giving them a good look this morning. The problems they're solving are exactly what we're talking about here.
-
Glad I found this thread as it reaches exactly my concerns. I'm also looking at smart vents solution and also weighting Flair vs Keen.
Question for Flair : If Keen is already using an open protocol (Zigbee) why are we taking the time to post on this thread? Why don't we simply pass our way and go straight with Keen? In my case it is because I feel that Flair has something more to offer. What you did with the Puck is much better then a Keen room sensor. With the Puck, my user can see the room temperature, and change it without pulling out his phone from where it might be, open the app, change the setpoint etc...even worst if I have a guest that does not have the app installed or because it's my 86 years old Dad. I'm also on the impression that Flair, without being perfect about the fan mode, has a better hand on it's control logic. I might be wrong. I also feel that the Flair Ecobee integration is tighter. Here you might say Ah! ah! you have a web base Ecobee! Yes but it can work on it's own to a large degree and if Ecobee goes out of business, gets bought or decide to charge me $5/mth, it will be easy to replace and with a much lower cost then replacing all vents, sensors etc... By that time, I'll also probably be thrilled to look at the newer offering.
What Phil wrote translate exactly and precisely the situation. Listen to you customer and potential customers. The one that takes the time to post here, without even being customers yet are most likely just the tip of the iceberg. I keep going to the online store and dropping my basket because I'm to hesitant in going web base only. As I was ready to write this, I lost internet for 5 minutes, for no reason, in a large Canadian city, as I was in morning heat increase mode. Of course you have the fail-safe open integrated but there is much more to it and it's all listed here. Autonomy, security, reliability etc.... (Question : After how long of no internet does the fail-safe kicks-in?)
Finn, I was designing the BacNet automation systems for the large heating products our firm was selling and there was always someone coming-up with a "Your product should to this and that..." and most of the time these comments were either a) Already taken into consideration and left off for good reasons or b) Very specific requests base on this customer specific situation. But here...you have a pack of peoples asking the same thing. If I was in your shoes, I would grab this opportunity to expend to the next level and switch in solution mode. With local control option, Keen will no longer be a option. My opinion.
Right now, the fact that both Flair and Keen are back-order on the vent size I need is probably a blessing and I always prefer taking no decision then taking the wrong one.
Hoping to read you soon about all this.
Michel
-
Flair Customer Support Nudge.
-
Hi All,
Flair is on backorder with an actual delivery timeline:
https://support.flair.co/hc/en-us/sections/360003983672-Backordered-Items
Flair checks for internet connectivity every 30 seconds and will open all vents within 3 minutes of a continued loss of connectivity.
All the best,
Finn
-
Hi All,
I’m compiling this thread a bit. As Michael V states, reasons for local control are: autonomy, security, and reliability.
In terms of solutions, I’m seeing the following:
1. Operate vents manually - open, close - without automation
2. Add automation logic to phone app - what communication protocol this would use - and what happens if you take your phone out of range?
3. Add a hub -what kind of functionality would this provide - full automation, or control the current api functionality via standard communication protocol (zig by, z-wave, etc)
4. What else?All the best,
Finn -
The best case would be a hub that handles the automation locally. This does several things.
1. Simplifies the Puck to be a temp and humidity sensor, and a thermostat.
2. Continues to operate without internet
3. Gives you the ability to give the customer a choice of whether or not they need access to their vent system from outside their home, which if they choose not to closes a potential security hole.Adding a simple override lever on the vents would be a plus, or even just a push button to open/close the vent.
Change to standard Zigbee protocol on the Pucks and Vents so a hub isn't required.
I'm sure there are other ideas/suggestions, but these are the key elements of why I returned all of my Flair equipment and went with Keen. The Keen vents connect directly to my Hubitat hub with no extra hub required, reducing the number of potential points of failure or security breach.
-
Hi Flair Customer Support - Firstly, let me acknowledge this step you're taking. Thank you, Finn.
The architecture I leave to your designers. What I'd like is something like my Kasa smart plugs. They are Wi-fi and cloud connected for Alexa and outside the home integration, but they also have local control, which is why I chose them. No Kasa cloud, no worries: I can still manage them at home from the app, run scenes etc., once we're on the same network. They cost $18, a few $$ more than the ones that require cloud to function, and those extra $4 per plug are completely worth it for my peace of mind.
There are lots of good reasons for security concerns with IoT and I would expect a "we're better and we're more secure" would be a positive and compelling solution differentiator.
And I think that what I'd encourage Flair to do is to understand that what the markets buys from you is not vents. It buys solutions. For me, I want to make my new home not only more comfortable, but also save $$ on bills (and make it more environmentally friendly) by using less energy. I want a solution that helps me do this even if cloud access is unavailable, whether that by a contractor cutting the cable, ISP failure, business failure, business plan, DDOS / security issue, or some other cluster.
The thing we all know is that tech fails at some point; the question is how well do we plan for that to ensure that the solution still works (at a good enough level) when the SNAFU hits.
So I don't care if the brains of the beast are in the app, on the hub, or something else TBD. Just needs to be inside my firewall.
You've got most of the moving parts. Make a Zigbee or Wi-fi flavor instead of your custom radio. If a smart plug vendor can do this at a single digit $ marginal cost, so can you.
-
PS The fact that Kevin Summers is still contributing to this thread, Finn, even though he bought from a competitor, should tell you guys something about (a) how strongly he feels about this, and (b) who he would much rather have bought from.
-
Great news Finn.
I'll mull it over but here's a first reaction. I think that using the phone app for logic would not be a reliable solution for the reason you listed and probably a few more like BT reliability, battery drainage etc...
In order to keep order coming in the meantime, I feel it would need to be an approach where it's all field up-gradable. So having the proper hardware in place, at least for the Pucks and Vents is key.
Best regards.
Michel.
-
Finn,
As mentioned, I have not yet had the pleasure of using your product nor Keen's. I can only rely on what I happen to read so far, therefore please forgive me if I'm wrong in any of my statements. I'm simply hoping it can feed your reflexion. So here are my taught on the whole vent zoning approach :
I'm now breaking this down into (4) aspects : Safety, security, reliability and autonomy.
Safety : Assuming that you already covered the mandatory basics like fire hazards, RF interference, that leaves the back pressure potential. Both Keen and flair states that they handle this well, at least when the whole system is online. Based on a previous post, Flair has a FSO feature, should the internet go down for more then (3) minutes.
Question : Is that logic sitting in the Vent, controlling Puck or the Gateway Puck? If it is in the Vent itself, meaning that if the Vent losses communication with its Puck, thus is offline regardless of the state of the remaining components, I feel it is a pretty solid and defendable approach. The need for further local manual operation would not be needed in my opinion. On the other end, if the logic is "running" elsewhere in the network, you would gain more by moving at the Vent level rather then adding a button relying on the end-user being aware and available to manually correct the situation.Security : Risk zero does not exist. Between having a hacker change my thermostat set point or accessing my bank account, I'm more worried about the second. However, having the ability to isolate the numerous world wide Flair devices from the Flair servers would add a layer of protection against a massive breach. A hacker will be much prouder if changing 5,000 set points in one click then changing Michel's set point!!!
Reliability : From what I read, this is one of the point where Flair can really shine. As it is always the case with battery powered device, steady communication can be challenging. Kenn's solution is to add repeaters, meaning extra cost, footprint, maintenance etc... With Flair you only need to make a Puck "plugged" instead of battery operated and make it a gateway. So local network wise, I like what I read and as mentioned previously, the Puck is your "Niche". But Flair "reliability weakness" happens if the internet goes down. Agreed that in most cases it does not go down often or for long and that if you are in any the few areas where it happens often and for long, maybe having this type of system should not be your priority right now.
Autonomy : I think that this is the major concern because the tech world is in constant evolution with players that have billions of dollars that can make any owner think twice about its dedication to his initial product goal. My (and others) concerns are ;
- Flair gets taken over by another player who changes the rules : We've all seen that. The API becomes unavailable and the "perfect" system the user putted together now relies only on what the new player wants it to be. Nest/Google being an obvious example.
- The server side service becomes a monthly fee service or the service gets splits into different plans where the free version of course does not include the most useful features: We've all seen that as well.
- For any reasons, monetary, health, divorce etc... Flair simply put the key under the carpet.
Kenn's solution was to use the now commonly used Zigbee protocol. So it gives the users (2) options. Let Keen manage everything by buying the SmartBridge or adding each components to your existing Zibee network. I'm also using a product called Sinopé for my baseboards and they are using this approach. The nice think about it is that if I'm tech savvy I can leave the gateway in its box and communicate directly with the devices but if I need to sell my house, I can re-integrate the gateway and let the less tech savvy owner work with the manufacturer's UI. It's nice but not perfect as I need to make a choice of either controlling everything or nothing with my Home Automation system.
Based on all the above, without having to modify each products, my impression is that adding an optional "SmartController" would solve the (3) last topics. On top of adding new revenues, this bridge/controller would run the same logic as your servers while reducing the payload (cost) on these servers. It would be flash/software up-gradable. Give the user the option of exposing this bridge to the internet or not for remote control. This bridge would also be either Z-Wave Plus or Zigbee compatible, thus exposing as many values as possible to the user's HA system. So Flair would offer (4) modes :
1 - As is : The user does not want to invest into a bridge and his fine with having all the logic web based. If he changes his mind, he can do it later.
2 - Bridge in Auto mode : The user buys a bridge, still using Flair's logic but locally run. The user has the option of isolating from the internet (But not from his router of course) aka some security risk remains.
3 - Bridge in Auto mode, open for HA : The user buys a bridge, still using Flair's logic but in local. Let the user read all values as variable for his HA system and can read/write room set points or other general parameters that I'm not yet fully aware of yet.
4- Bridge in Manual mode : The user buys a bridge. Let the user read/write all allowable values, therefore implementing his own logic. The FSO cannot be override.
As a bonus, the HA user does not have to learn a new syntax to use a new API. If he learned his HA programming syntax, he's good to go.
Best regards.
Michel
-
I work for an industrial OEM and deal with automation and controls (as well as dabble in home automation), and I strongly concur with all of the points brought up by Michel, Phil, and Kevin. I understand cloud integration lessens the "load/hardware requirements" on local devices and allows the cost to shift elsewhere (advantageous for a start-up company), but the lack of full local control in event of internet loss is only one of a few deal-breakers for me. No physical adjustment capability hurts as well
I love the physical design and hardware, and from what I've learned it seems to be the best of any of the smart vent offerings. If a solution is developed to allow for local hub control (no cloud necessary {or make it optional}), I wouldn't think twice to invest in this system as my older 2 story home is served by a single 5 ton unit and central heating.
I appreciate you taking these suggestions, Finn. I truly hope that some changes are implemented so that I can invest in the Flair company
-
I recently reached out to Flair asking similar questions. So I figured I'd comment on this thread.
If you're looking for more suggestions:
1. Consider adding MQTT support. Here's an example of a company that offers MQTT in their smart switches, but also has other ways to control their devices. https://shelly-api-docs.shelly.cloud/#mqtt-support
2. Allow users to run Flair's cloud service on a machine on their network. Most web based technologies utilize containerization (like docker). If Flair's cloud service was packaged as a docker image (it's possible that it already is) and published to hub.docker.com, it would be possible for users to pull this image and run the service as a docker container. With this service running on their local network, we would then need the ability to point Flair devices at the service. So instead of Flair's devices calling the web service at https://api.flair.co it would call to some IP on the local network (like http://192.168.x.x). Here's an example of a company that publishes their service as a docker image, which can be run locally or in the cloud. https://hub.docker.com/r/deepquestai/deepstack Here's a very common way for home automation enthusiasts to use this particular docker image: https://www.youtube.com/watch?v=fwoonl5JKgo&ab_channel=TheHookUp
If it were possible to use Flair's products locally without the need for an internet connection, I would plan to buy 11 vents and 7 pucks, which totals to $1,700+.
If there's anything else I can help with, please let me know; my background is in software development. https://github.com/tonybrobston
Thanks,
Tony
-
Thanks Tony for sharing your recent exchange.
Personally, if I was Flair, since that "Bridge" does not exist yet, I would certainly put all the effort to make it more accessible from the start with something much easier. That's why exposing R/W variables using one of the (2) popular protocol like Z-Wave or Zigbee would seems the way to go.
When you are an home automation enthusiastic you are more likely to be attracted by all the technical approach you described but let's be honest, many, many, will not either have the knowledge, time or resources to put it all together. I would be one of them for sure. And because of this, I can only imagine the added workload that would create for tech support, answering how to questions from one that does not master this deeper levels of cross-integration.
So in short here's "my vision" of it :
- Create a bridge that runs the logic locally keeping the manual capability.
- Increase sales by attracting all the peoples hesitating right now.
- Increase sales by having one more hardware to sell.
- Reduce operating cost by having a smaller AWS servers footprint.
- Keeping my customer happy by listening and giving them what they need. Happy customers that feels listen to becomes your best sales persons without having to give them a salary.All the best.
-
Could you share what underlying technology is used to wirelessly transfer data? Is this: WiFi, Z-Wave, Zigbee, or something similar to one of these?
On a side note. I moved away from Z-Wave. This might be specific to Home Assistant, but when things went wrong with Z-Wave I found it really hard to troubleshoot. That's what caused me to move to WiFi based devices and troubleshooting things has been a breeze.
If Flair used Z-Wave or Zigbee and/or required any type of additional hub (other than a self hosted computer or server), I personally wouldn't be interested in those products.
Since the service is cloud based, running the cloud based service locally seems like the least intrusive change to the feature set on Flair's end. Very little development needs done. The service can likely be containerized (if it isn't already) and it's likely their devices allow you to point to a different IP address, if they do local development. The only 2 downsides I can see: 1. Running the service locally may be difficult for some, 2. Allowing customers to run the service locally potentially indirectly exposes the code base.
I think it's unlikely they'll do anything at all. I imagine the response will be: "Use our cloud service." I won't hold my breath.
Please sign in to leave a comment.
Comments
99 comments