Flying below the clouds

I’d like to build my HA infrastructure with the goal of minimizing or eliminating reliance on cloud services. I’m not a cloudophobe trying to go “off the grid” (part of my job involves cloud architecture), but there are boundaries around what I think is the right way to be “cloud connected”.

On the “OK” side:

  1. I want my HA control hardware and software on prem, governed by my firewall and VLAN security.

  2. I want to be able to connect to my home to monitor status and take actions. It would be OK (even preferable) to establish a VPN connection to interact with a local server. I have perimeter hardware to support this.

  3. I want my on-prem control software to be able to reach out to the cloud to leverage services there, e.g. using Twilio to send SMS, or to upload backups to blob storage, or to query weather information.

  4. I want cloud services to be able to securely reach in to my on-prem controller. For example, I have a personal API running in Azure, and I’d like to use it to trigger events and as a proxy for other services.

But there are things I don’t want to do with the cloud:

  1. I do not want a cloud service acting as a proxy between my devices and my controller.

  2. I do not want my devices communicating with cloud services unless I explicitly grant it, and I do not want my devices’ utility to be degraded for lack of cloud access.

  3. I do not want devices that require me to use a bespoke app to use them properly. I don’t mind an app for setup, but after that, all of my devices should be managed directly by my controller.

I’m finding it increasingly difficult to stick to these rules in an age where manufacturers are playing to the desire for plug-and-play. “Works with Alexa” isn’t a selling point with me. Unfortunately, the trend is the other way around. It amazes me that people who are oh-so-concerned about their online privacy will allow a server in who-knows-where managed by who-knows-who to listen to their conversations and control their lights and door locks.

Some of the first things I tried to do have already frustrated me.

  1. I wanted to automate things in my garage. I wanted to know if the door was open, and how much (I have good reason to leave it partly open at times). I wanted to have OH open and close the door, and control the lights. Since I don’t want to proliferate battery-operated devices, I looked for simple powered devices that could sense and trigger “dry contact”. Things like the Fortrezz MIMO seem a bit pricey. I found a plethora of cheap devices from Sonos and WHCozy, but they all wanted a cloud server to sit between my garage door and my OH server. Call me paranoid, but I wonder why manufacturers are so willing to sell me cheap devices that connect their servers to devices inside my network. Yes I can “flash” some of this stuff to be less cloud dependent, but I’m not much of a hardware tinkerer.

  2. I want a really smart, attractive thermostat to control my central AC and gas heat. I want it to be “smart” enough to do its job if my HA controller decides to crash and burn. I want it to push data to OH (or be polled by OH), and I want OH to be able to control it. I don’t care if that’s by WiFi or Z-Wave. Still hunting for that.

  3. Let’s not even talk about how hard it can be to get a flipping doorbell camera to work without the cloud. Really? A cloud server between the button and the chime? Nuts.

Am I alone in all this? I’ve seen some disconnected chatter about some of this, usually about specific devices, and most if it old. Are there like-minded people who are up to date on the market who could help point me in the right direction?

Thanks for reading this far!

1 Like

Zigbee and Z-Wave are both protocols designed to be local RF mesh networks, unconnected by the cloud. Our Zigbee ans Z-Wave bindings are both very current. @chris our esteemed developer can elaborate.

1 Like

Thanks for the quick reply, @Bruce_Osborne.

I have a pretty good understanding of the local communication protocols (my HA tinkering goes all the way back to X10). I’m a fan of Z-Wave, and I have nothing against Zigbee. It seems to me that wifi has gotten cheap enough that we should be seeing more wifi devices. There’s no reason why “wifi” has to mean “internet dependent”, and on a physically large premises, wifi should be more reliable than Z-Wave.

I’m not talking about local protocols here. There’s plenty of Z-Wave switches and receptacles out there, so I have good local control over standard electrical devices. But as soon as I want to do anything more complicated than a power flop, the options for “on prem” start to narrow.

What I am talking about is smarter, more complex devices that can do their thing without calling the mother ship.

For example, this looks like an great thermostat, but from what I can tell any OH integration will be via a cloud service: Same for Nest, etc. And beyond thermostats, same goes for e.g. Ring doorbells, Rachio sprinkler controls, etc. I have trouble finding anything of the power and quality of these devices that’s not internet dependent for integration to OH.

Thanks again for reading and replying!

Too many manufacturers want to lock you into their cloud services to also collect your data. Nest is owned by Google and they are closing that API too to only select partners so OH will not even be able to support it without some reverse engineering or screen scraping.

There are Z-Wave thermostats that are not cloud based. Where in the worls are you located? There are 19 different Z-Wave regions.

Our current supported Z-Wave device database is here.

Interessing topic.

The problem is, the smarter devices are, the more it will call a mothership.
For example the Nest thermostat looks smart, because it calls regularly the mothership Google. OH can operate the device, but the device is made to call mothership Google.

So I think that you have to make sure that all your devices are “dumb”, but can call the mothership OH to be smart. Then make sure OH is equipped with fail-safes, such as a UPS. But also make it redundant (second Pi with a regular sync). And last but not least, make sure the dumb device can be operate without OH (such as a light switch or a “normal” thermostat).

With this in mind, I think you can fly below the clouds with very smart things (OH can be as smart as you can imagine).

1 Like

Hi @ljsquare!

I agree very much with how smart OH can be. That’'s why I chose it as my HA controller.

OH can operate the device, but the device is made to call mothership Google.

What I’m looking for here is for OH to be able to monitor and control the device without needing to go to the cloud API. I want the device to talk to OH, and I want OH to talk to the device. I don’t need or want a server outside my control, thousands of miles away, in the loop of my local automation.

I think that you have to make sure that all your devices are “dumb”, but can call the mothership OH to be smart.

No, I most certainly do NOT want stupid devices that are dependent on an always-on OH. I want a thermostat that could be completely abandoned by outside controllers and still be able to work like a normal thermostat. I want to be able to do things BETTER when integrated (turn on a ceiling fan or something), but that integration should NOT rely on a cloud service.

the smarter devices are, the more it will call a mothership

Yes, indeed. I want that mothership to be OH, not a cloud service. I don’t see why smart = cloud or why wifi = cloud. It’s fine that things like Ring and Rachio offer a cloud-controlled mobile app for people who don’t want to get in the weeds with an HA controller. But more and more they’re going fully proprietary, and not publishing APIs. It’s not a better life to have separate apps for my lights and my sprinklers and my thermostat, that don’t talk to each other. It’s not a more reliable, secure world when my internet has to be up and open, and my home is being monitored and controlled by servers I don’t control.

Thanks for the reply!

1 Like

Thanks @Bruce_Osborne.

I’m in Texas, where having a smart thermostat backed by even smarter OH rules is critical on days when we go from winter to spring to summer and back to winter in a 24-hour period :slight_smile:

Thanks for the link to the database. I’ll start searching from there.

1 Like

I am of the same mindset as you. One issue that you forgot to mention about cloud controlled devices is that when (not if) the manufacturer stops supporting it (such as the Revolv thermostat) you are out of luck. Another is when they change their protocols (such as Insteon and MyQ) you have a non-functioning device until the binding developers can figure out the new protocol.
Because of these reason I replaced the MyQ garage door controllers with Aeon Labs Garage Door Controller Gen5. (, but they are no longer available on Amazon. If you find them you may need to do some modification to get them to work with a security enabled door opener.

1 Like

There are a couple of options here.

Thanks @cbaxter.

One issue that you forgot to mention about cloud controlled devices is that when (not if) the manufacturer stops supporting it

You point out yet another reason why I don’t want to be dependent on third party out there in the cloud for monitoring and control between controllers and devices on my local network. To me, that’s as insane as having a cloud controller monitor my brake pedal and reacting sending by back a command to my car to engage the brakes.

Thanks for the mention of the Aeon Garage door controller. I’m a fan of Aeon labs, and I remember running into that when I was investigating.

I’m not clear on the concept of a “security enabled door opener”. Can’t all garage door openers be controlled by a simple dry contact button? What am i missing?

Thanks again.

Thanks for the link to smart thermostats, @Bruce_Osborne.

I have one of those (CT100) in another home that was installed by the builder to be under the control of the alarm company. I’m aware that I could manage one of those from OH directly.

What all of those have in common is that they’re, well, ugly. As compared to something like this they “look” downright primitive.

I’m probably not alone as a person who wants to tinker with automation but has a spouse that wants things that are easy to use without the automation. I remember a conversation when I wanted to fully automate the house lighting. I said “There’s cool technology that can sense when you walk into a room, and automatically adjust the lights depending on the time of day”. She said “There’s an even cooler technology that senses when I flip a switch and doesn’t screw around with the lights when I don’t”.

That is not what I mean. Example: I’ve a dumb thermostat, which is connect to a Fibaro relay switch, as “switch”. The relay is connected to my boiler. So I can control my heating via OH, but in a event of a failure of OH, I can use it with a “dumb” thermostat.
Other option is a thermostat mentioned before or a Secure Zwave Thermostat.

This is what a I mean with:

All my lights can be operate by motion (or any kind of automation) or manual, with the old-fashioned switch in the wall.

It’s comes down to the devices you have, the devices you’re going to add and what you want. I think it’s certainly possible to use OH without any cloud needed and still not fully depend on OH.
Same as your garage opener, you can fully automated with a Fibaro, Aeotec or Quibino zwave switch (or whatever cloudless technology you’ll use), but also with a wall switch, in case OH is down.

Thanks @ljsquare. I think we’re pretty much on the same page. I’m all about the idea of fail-safe design, where nothing is dependent on OH being up and running. I guess what triggered this whole conversation was, like @cbaxter amplified, there’s an unfortunate trend where the newer, more capable products are going full-on proprietary. The manufacturers want us locked into their brand so they can collect our data and trap us into future purchases.

I must be old fashioned. There seems to be a lot of complacency about this around the HA community in general, where people think it’s OK for an action to go like [switch > router > internet > cloud server > internet > IFTTT > internet > router > hab > light] instead of [switch > hab > light]. I’m not OK with that. One of these days someone is going to realize that they’re seeing searchendising ads for snuggies because Google knows their home temperature and thermostat settings. They’re going to lose their minds about their supposed “privacy” when they themselves opted in to let Google monitor their lives that minutely.


Not to forget, a switch which stops working because the internet is down is a complete no go.

1 Like

It’s not that we are OK with it. It’s not complacency. It’s the only option we have.

As you are finding the venn diagram of thermostats that are:

  • affordable
  • works with openHAB
  • doesn’t require batteries
  • doesn’t require a cloud service
  • looks good

is empty. There are no such devices. As those great poets the Rolling Stones said

You can’t always get what you want

So we have to compromise.

Let’s face facts. Those who are willing to do home automation at all is pretty small. Those who are willing to do the work of setting up a system using something like openHAB or Home Assistant is even smaller. In order to make things worth their while, they have to build products that your grandma can install and set up and use remotely, since that’s one of the major selling points. The only way to do that is through a cloud service.

Frankly, it’s amazing that as many services provide an API to us at all but it’s not surprising it’s through their cloud. They already have to build a cloud based API for their devices to work remotely in the first place. So it’s far less work to just polish that API and make it available to us to use as they have to build it anyway. A local control API would be something else completely and there are not enough of us who would see local control as a selling point for it to be worth while for those companies to build it. We are not enough of an audience. It’d cost more than would account for the increased sales.

The cynics are right too, there is also a profit incentive for them to use a cloud service too as they can get your information and sell it and they retain a certain amount of control over their products. But honestly, that is secondary. It’s just not possible to create a product for the average user that is also remotely controllable without a cloud service. And there are not enough of us to make it worth their while to build an alternative API. It is a sane and rational business and technical decision and not necessarily an evil one.

So what are we advanced users to do?

  1. live with the cost of having a device that works with a cloud service
  2. buy a less attractive device that gives you local control
  3. build it yourself

Each person makes their decision based on their requirements. For some of us, the cost in privacy is worth the gains in capability or attractiveness of the devices or whatever else is an important to that user.


Garage door openers with Security Plus 2.0 (MyQ Technology) are Serial Encrypted and do not have a dry contact switch. To get it to work you will need to open up the wall switch and solder the dry contact wires directly to the switch to simulate a button push.

interesting… but I would say, best rules and number one is :
HA only onpremise and without direct internet access.

Every single item controling my house is only on local lan, without internet acces.
From outiside it’s accessible only via my VPN which is then bridged to given VLAN.
VPN is key-key only, no passwords.

This is my ruleset I’m sticked to :slight_smile: never ever will allow any device to be cloud-connected without me knowing what is going on and why.
I do like my house to be my house, not everyone’s house :smiley:

I think to be fair, you would need to take “does not require batteries” off the equation.
If you build a new house, you probably won’t be deploying radiators.
Smart thermostats are for retrofitting, and noone to have a classic heating system has wires to his radiators. So product marketing managers make it a MUST that their thermostats are battery based.
And you can always put them on wires, replacing batteries by a 3 or 5VDC powered line.

FWIW, I’m using MAX! thermostats.
They have a local control gateway and even continue working if that’s down.
They don’t have any API but some blessed soul reverse engineered the stuff so it works with openHAB now.

1 Like

This x1000. I inherited my tech-junky genes from my tech-junky dad. He’s interested in what I do with OH, but he doesn’t want to install/maintain/troubleshoot one himself (or subject my mom to its whims). He just wants to buy plugs/switches at Costco and control them with Google Assistant and his iPhone.

Personally, I’m not against cloud control, and I’m okay with companies using data about me when I use their services/products so long as they inform me properly. My preference for local control is more about my devices still working when the Internet is offline.

The bigger concern I have about cloud connectivity is that more and more companies are using it as an excuse to release products that aren’t fully baked, with the promise that additional fixes/features will come in firmware updates. I won’t buy anything that talks more about what it can be than what it is right now.

I only added it because the OP mentioned it and doing something like soldering wires from a 5v DC power source would fall into the same category as hardware modification akin to flashing the device which OP also excluded. And OP is working with central forced air heating (same as I have) so there only is the one heater, and it’s actually pretty shocking how many such units don’t have a C wire to power the thermostat.

I admit that the formula above is very carefully tuned to OP’s specific situations. Those with different types of heating have more options. I do look with envy at the seemingly standard radiator heating you guys have in Europe. But every house I’ve ever lived in has had central forced air heating so you have 1 thermostat, one source of heat, and, in the case of my house 10 degrees F difference from the coldest room to the warmest room.