I think the difference with this and Logitech is that Logitech was trying to close a security hole that was never advertised as a feature. Something had to be done to protect users, and they did it. When the automation community made noise, Logitech realized that they could turn the security hole into a feature for the small number of people who want it. The whole thing presented very logically: company fixes security risk, fix affects some users negatively, company adapts for those users.
In this case, Google has taken something that was a feature (though one aimed at developers, not consumers) and decided to end it. It was a strategic decision, same as Lowes shutting down Iris. It’s very likely that they already considered the impact on the automation community in making this decision. If not, someone isn’t doing their job.
As Rich notes, I suspect that a lot of the stalled development stems from in-house politics over the past few years.
Exactly this. Per my earlier comment, I’m really surprised that they left IFTTT out in the cold.
I’m personally very pragmatic about Google. I don’t mind giving them data in exchange for the many free services I’ve benefited from over the years: search, GMail, Chrome, Drive, Docs, Android Auto, Google Assistant, etc… They also offer a free enterprise version of GSuite for non-profit organizations, which I’ve set up for the charity I volunteer with. I may not like everything they do, but the positives have far outweighed the negatives. That makes it a little easier for me to swallow when they make weird decisions I don’t agree with.
My guess is that Google is planning upgrades to Works with Assistant that they think will account for most of the functionality third parties currently enjoy. Whether that’s true or not will determine how accurate the current reactions are. But for the moment, they’ve chosen to give the impression that specific needs will not be served. I don’t think anyone’s misreading that.
The new program will allow data sharing between connected devices and apps, but only for a handful of tightly screened partners, Google’s Rishi Chandra told Variety . While that’s potentially helpful for security and privacy, it’s also likely to break a number of smart home tie-ins – including some you may miss.
…
Update 05/07/19 8:01PM ET: Based on an email IFTT sent Nest will be retiring its Works with Nest program on August 31st, 2019. Nest Thermostat, Protect and Cam will all be affected.
Several IFTTT users above have also reported getting an email from IFTTT that Nest support will be going away.
But the biggest change is the discontinuation of “Works with Nest,” a program that allowed device makers and app developers to build things that would interact with Nest products. Google is replacing it with a more restrictive “Works with Google Assistant” program later this summer, and Chandra said that it would give a small numbers of thoroughly vetted partners access to additional data if customers explicitly allowed such data sharing.
One impact of these changes, according to Chandra: “It will break IFTTT.” IFTTT, short for “if this then that,” is a web-based service that allows users to build a wide variety of custom integrations for smart home products. It’s especially popular with early adopters, who use the platform to fine-tune specific tasks across multiple devices.
IFTTT can for instance be used to change the temperature on a user’s thermostat when they leave the office, or operate obscure smart home devices not officially supported by Google with voice commands from a Google smart speaker. Chandra said that the company planned to replace much of IFTTT’s functionality with its own Google Assistant routines.
Rishi Chandra, vice president of product at Nest, said the change is part of a broader shift in the company’s stance on consumer privacy. Whereas Works with Nest allows a large number of manufacturers and developers access to data sharing framework, Works with Google Assistant is more restrictive. Under the incoming program, Google is granting only a small number of vetted partners access to data gathered by Nest products, and only with express consent from end users.
The updated policy promises to have wide-reaching ramifications for smart home devotees invested in the Nest ecosystem. For one, Chandra confirmed “[i]t will break IFTTT,” or “if this, then that,” a popular automation service used to connect apps and devices through easy-to-use applets.
…
Instead of IFTTT, Google intends to implement similar features through Google Assistant routines.
I could go on. The take away though is IFTTT will no longer work with Nest. We can use Google Assistant Routines, but there is no way to kick off a GA routine from OH as far as I know and even if we could, they won’t allow us access to any of the sensor data collected by Nest products since we are not among the small number of vetted partners.
Does anyone know if the Alexa skill uses the same work with Nest API? I assume it does, it will be interesting if Google will allow Amazon to have access to the new Google API… If Alexa integration goes away along with OH, then I’m left with 3 thermostats and an app to control them. I’ve always wanted to design and make my own MQTT based thermostats with ESP8266 and some Nextion LCD touch displays. This may be a good time to start that project.
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.
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?
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.
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).
I have thought of that too but I have three problems with that approach which apply to me personally.
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.
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.
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.
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.
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).
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.
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.
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.
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)?
