Works With Nest - Deprecating on August 31, 2019

This kills five additional Nest Protect’s that I was planning. Stupid move, but I doubt heavily that Google cares - they have done far more controversial and shoot-themselves-in-the-foot types of things in the past without a care.

For folks looking for an openHAB friendly thermostat, I’ve been using a Venstar Colortouch with great success.

Local control, no cloud requirements. (But you can use SkyPort if you want that feature.)

~Mark

What kind of functionality do you need for this? The Thermostat is nothing else than a relay switch which operates based on measured temperature. What else should a thermostat do?

Controlling a gas furnace is bit more involved than simply shorting two wires.

1 Like

I also remember Dr. ZZ’s building a thermostat with either a D1 or NodeMCU and then having Home Assistant perform the logic…I’m sure the same could be done with OH.

1 Like

An SDK to allow local control of devices appears to be in the pipeline. Whether it will be full-featured and functional by August 19th is unknown.

https://developers.google.com/actions/smarthome/local-home-sdk

A central forced air system has five wires for control. One control the fan. One controls the furnace. One controls the air conditioner. And there are a couple of R wires that I think are used to make sure the fan turns on when either the heat or the AC turn on. Usually there is also a C wire for power to the thermostat (without the C wire the battery of the thermostat will only get power from the furnace when the heat is on).

A simple on/off relay is not going to cut it.

For example

image

from https://www.electrical-online.com/thermostat-wiring-explained/.

I have thought of that too but I have three problems with that approach which apply to me personally.

  1. I want it to still be usable independently from openHAB. This is a fundamental principal for all of my home automation. I build escalators, not elevators. I shall be able to control the HVAC even if openHAB is down or the network is down. I could add a touch screen but then I’ll need to program a UI and I’m really starting to get into RPi zero territory and out of NodeMCU territory.

  2. But then I’m absolutely not confident I can build a nice box for it that will look any better than the zwave one’s I’m already complaining about. I’m an OK wood worker but not great. I can’t work in metal at all. And I’ve never seen a quality finish on a 3D printed case that I’d be happy having on my wall as one of the first thing that guests see when they arrive. I know all I really need is something to go around the screen as the rest of the parts can go inside the wall, but I’m not confident I can get a good quality finish on even that.

  3. The only power I have at the location where I have the wires coming out from the furnace is the C wire (blue wire) which I think is 24v. So I’d have to have a step-down relay to go from the 24v to 5v to power everything. Once I do that, I’m a little concerned about heat dissipation, particularly for something that would be inside the wall.

  4. It is notoriously easy to brick an HVAC system if you get the wiring wrong or accidentally run the heater and AC at the same time or the like. I’m not willing to take that risk at this time.

By the time I get all the parts and materials for the display and relays and step down voltage converters and materials for the case and take into account the value of my own time I suspect I’m in the $85-$150 range that a thermostat will cost.

It’s definitely a good idea though. Just not for me. I am glad you posted. Others may be less risk averse or less strict about maintaining local to the device manual controls.

More on this from The Verge, detailing Google’s concerns about allowing unvetted third parties to have too much access to data.

I had laser cut acrylic frames made (via an online supplier) to sit on top of my wall mounted HABPanel tablets. The tablets and wiring etc are all recessed into the wall, leaving the nice laser cut frame as the only thing visible around the screen. Something like this may help overcome the aesthetics if you do decide to go down this route.

Just to add to the discussion on possible alternatives, I have been using the Honeywell Evohome system for the last year. Primary reasons for selecting this over Nest were (a) locally controlled (accessible via cloud) and (b) individual room controls. There is an openHAB binding for this as well. Out of the box, it doesn’t have the full machine learning aspects of Nest to automatically turn the thermostat off when the house is empty etc (though it does have machine learning on each zone to learn how long the zone takes to warm up/cool down), but other than that it works robustly.

This statement is self contradicting. If you have to go through a cloud then you don’t have local control. Or do you mean that you have both local control and cloud control. That could seal the deal because I do like the look of some of the Evo thermostats and know there is a 2.x binding. If it has true local control I’ll definitely consider them. I’ve only discounted them because a quick look at the API looked like access was done through their cloud server the same as it was with Nest (and Ecobee for that matter).

Their FAQ says:

Is this API local control of the device?
No, the API calls and commands back and forth from the device require an internet connection.

I never used that stuff anyway. Someone is home almost all the time so just being able to set a target temp for night versus day is more than sufficient. Any I can implement most of that sort of thing in OH anyway.

Right now I’ve kind of settled on the GoControl GC-TBZ48 which is zwave so no more cloud API. I’m not happy with it’s looks but the value for money it seems to be about right for my needs. It’s Zwave so no cloud service necessary. But it’s also really basic.

Anyone know of Zigbee thermostats? My searching is showing far fewer options there than zwave. I have a dual zwave/zigbee controller and am willing to take the risk of getting it to work with the Zigbee binding.

Sorry, sloppy post. It does have both, but full local access requires a bit more work and is not ‘official’.

Out of the box, programmed schedules are saved on the local controller. Thus if there is cloud outage, these continue to work correctly.

API access officially requires the cloud. However, some enterprising individuals have reverse engineered the radio communications protocols that Evohome uses between the controller and the individual devices (in fact, I recall seeing one one of them, Danny @dty, in the openHAB forums), and written firmware for an arduino to sit in the middle. Over in Domoticz, they have written a two-way interface that both listens to and sends commands to Evohome.

Using their work, and Danny’s firmware, I put together a simple python based ‘listener’ that directly listens to Evohome messages and posts them to an mqtt broker (https://github.com/smar000/evohome-Listener). This then updates my openHAB, Grafana charts etc.

What I haven’t yet done is add the additional functions to send messages to the controller/devices, though this is there in the Domoticz repo, and hopefully shouldn’t be too difficult. I haven’t had a need to do this and have been using the cloud API for sending instructions, but may get round to it one day if time permits and the need arises. As of date, the Evohome 2 binding does not use the local arduino based ‘listener’, though the binding author over in the thread expressed interest in doing so at some stage. I don’t know if he has progressed this side of things as yet.

Some notes/photos on the arduino setup: Evohome binding 2.0

Edit: I forgot to mention that ready built arduinos with the radio board, both soldered onto a proper PCB are available on Ebay.

That’s the piece I really need. It’s critical in order for me to control the heater’s fan based on temp sensors scattered throughout the house.

I’ll definitely need to take it under consideration. Thanks for the info.

I haven’t looked recently, but others may well have progressed alternative solutions towards sending messages locally without going over the cloud API. This is the original thread that got me started down this route: https://www.automatedhome.co.uk/vbulletin/showthread.php?5085-My-HGI80-equivalent-Domoticz-setup-without-HGI80/page14.

The HGI80 they talk about is the model number of an official Honeywell device that listens/sends radio messages, i.e. the arduino hardware that I mentioned above is a poor man’s version of this HGI80.

One final thing to note is that even as just a ‘listener’, the above solution gives a lot more information than is available from the official API, including individual zone heat demand, whether or not windows are open, battery levels etc. Plus as it is listening in real-time, it is much more accurate than the cloud API data. Having said that, posting commands via the cloud API for setting zone temperatures, changing modes etc has been reasonably quick from my experience, and well within the 4 minute limit that each zone has anyway (due to device battery conservation).

My biggest issue I think is that I already have sensors everywhere and am not looking to replace them. I already get all the information I need without the Nest as the Nest sensors were never fast, precise, nor even in the best location. Any sensor data I get from a replacement simply doesn’t matter. I only have one zone for the whole house. All I need is a thermostat that lets me set the target temp and independently turn on and off the fan.

This is sounding a lot like buying/building a controller for just one zwave light. I’m just not seeing the benefit of spending $100 for a single thermostat and then needing to build an Arduino “controller” just for these two functions to avoid the cloud interface when I can get a not quite as attractive zwave one that does what I need for $85 and not needing to build it code anything else.

I’m not really wanting to buy into a whole new home automation technology stack just for these, even if the thermostat looks better than the zwave ones.

But this is all very useful information for others who may have more needs than I do where this makes more sense.

Why is that an issue? So long as it has good support in Openhab, just hide the controller anywhere you wish so it is not seen and then if you need to see the controls on the wall, mount a tablet running Habpanel to create something that looks nice and also can be multiple use at the push of a button. View cameras, see weather forecasts, news feeds. Still a stand alone system that has a controller to fall back to if Openhab has an issue, but can look great and used for multiple things when Openhab is up.

1 Like

I believe Rick has an issue with his thermostat being the first thing people see when they enter into his house via the front door. Hard to hide and I’m sure difficult to move the wires to a location to hide the uglier device.
Then you also have to consider if its hidden, how does a family member access the device if OH currently has an outage (or some other technical issue)?

Because automation is not the only criteria that I use to determine what does and does not get added to my home. Given that the thermostat is one of the first thing anyone sees when they come in the front door I want it to be something that either blends in with the over all decor which for us is mid century modern, or at least as much as we can afford.

As some have said, good design is fractal. No matter where you look and no matter how closely you look, the design should be consistent and complete.

I don’t have that option without punching holes in the dry wall and running new wires. The five wire bundle from the furnace comes out in exactly one location and the way the walls work there is no intermediate location I could move it to along the path of the wire.

The thermostat location is fixed and it’s very prominent. I’m not willing to spend the time and money to move it.

Believe me. I’ve considered all these sorts of options. They may work for others and I’m glad they after being raised in this thread. But they won’t work for me because they either cost too much in money or labor than I’m willing to spend right now.

Bingo. It really is a horrible location for the thermostat. With it being so close to the front door in the winter the heater can come on when we open the front door. It’s a big pain. And the wire goes straight down to the basement utility room, after crossing 15’ of floor joists. To move it if have to run a new wire and the way the walls are laid out I don’t think it’s something I can do myself.

I knew there would be a reason :slight_smile:

You may be surprised that it may be as little as an hours work to move the cabling and there are people who do that for a living and the cost would be lower than buying a Nest. Every now and then I install cabling for a job and it is like most things, with the right tool and ‘know how’ it is possible and far quicker then you first think. If you are renting then I understand ruling out moving cables, but when you have an issue with cold air from the front door and your unhappy with the look of units, it may be worth having a second think about if a location is suitable.

My house is an old style home where modern gear looks out of place so I am always trying to hide it away and have a clean look.

I looked into it even when I first moved in. There are functional reasons as well as aesthetic reasons why I wanted to move it when we first moved in. We were quoted $300 at that time, largely because of the way the walls are framed even the two experts I asked for a quote said there was going to be drywall work involved.

I’ve basically solved the functional problem with diy sensors and OH. For the aesthetics I was ok with the nest and underwhelmed by the zwave options. But it’s not a problem I want to throw $300 at right now.

Yeah I got it as well. Extremely disappointed and yet another reason to consider that long-time idea of actually building my own thermostat