This is something I’ve been thinking about for quite awhile. Why don’t smart thermostats take a Chromecast approach? With a Chromecast, users don’t need a remote - their phone IS the remote. That removes a lot of complexity, saves on cost, and pushes this functionality to software instead of relying on hardware. With a smart thermostat, is there really a need to have physical controls on the wall? The only reason they do is simply because “thermostats have always had wall controls.” That seems like a silly reason, to me.
Here’s a hypothetical setup. Imagine if the HestiaPi was just a compact and unobtrusive box on the wall (or better yet installed next to the HVAC system in the attic or wherever). Then, users would add ESP8266/ESP22 + DHT11/DHT22 sensors throughout their home in order to measure the temperature in other places besides just where the thermostat is located. If you combine that with a smart zone system, you could independently control the heating and cooling of each location much more efficiently and cost effectively.
Thoughts? (PS, if you decide to capitalize on this idea, could I get a small cut . . . ?)
Having been involved with home automation for quite some time I can say with some experience that if I were to install a thermostat that:
could only be adjusted by using a phone app
could only be adjusted when the network is working
does not provide positive feedback that can be reviewed without needing to bring it up on a phone
I’d be kicked to the curb. For the most part, if step 1 for controlling anything in the home is “get out your phone and open the app…” it’s a home automation failure. It’s the reason so many roll their eyes when showing off some new home automation capability because it doesn’t really solve a real world problem and only makes using it more complicated.
So yes, based on my experience I do believe there really is a need to have physical controls on the wall that can adjust the thermostat as long as the furnace/ac has power.
But other’s may be more tolerant of that awkwardness than those I know and have encountered.
There is one big hand waving statement in your hypothetical. The “smart zone system.” I’ve seen two main types of heating systems:
Forced air where there is one furnace that blows hot air through vents through the whole house, there is only one thermostat that can turn on/off the furnace and all rooms are heated at the same time. The degree of heating is controlled by adjusting the vents. However, closing too many vents greatly reduces the efficiency and could even damage the unit. Therefore zoned control is limited. But there are soem “smart vents” but they are IMO prohibitively expensive and of limited utility given the reduction in efficiency.
Baseboard or radiator type heating where each room has it’s own independently controllable heat source. There may be one central boiler but flowing the heat to a room is independently controlled. In that case there is a thermostat per room attached to a valve (for example) that allows the hot water to flow into that room’s radiator. There is a way for that thermostat to call for heat when there is a central boiler. In this case, you don’t want and couldn’t use one central thermostat. You need one for each room.
So, over all, the ideas are good but in my experience not practical.
For some time we’ve had the desire for an additional simpler design but we never got the chance.
The idea had some of your initial suggestions. Smaller, simpler and cheaper.
A smaller unit based off ESP with additional hardware for protection and maybe configuration storage, small OLED display, sensor, one rotary selector switch, 4 relays, discreet beeper, haptic feedback, PIR sensor and power supply (or any viable combination of lesser features).
Apart from provisioning with your home WiFi where you would need any web browser, the thermostat would be a dumb MQTT 2-way relay pushing all the smartness to an external underlying system (as it seems many people already have these days) to monitor (incoming MQTT messages from thermostat) and command (outgoing MQTT messages to thermostat).
In the absence of another MQTT broker (server) or WiFi altogether, the thermostat would work as a standalone unit with its local button and sensor for input and OLED and relays for output.
From my point of view, having a screen with the temperatures, without having to pick up the phone and fire up the app, is really handy.
In these hot summers in Spain, we try to make the most of the cool of the night, opening all the windows, until the temperature starts to raise badly in the morning when we close everything and hide in the bunker. So we usually take quick looks to the temperatures on the wall.
Besides, I totally agree with @rlkoshak’s point on network resilience.
“Displayless” doesn’t sound fun to me either.
Looking around for my other idea I find this
(Ignore the modbus aspect-or not) that could well work as an MQTT relay if an openHAB server is found or as a standalone if network or server is not found (in both states checking periodically if conditions change that require a state change).
Has anyone worked with that above project before or something similar that could work?
While everyone on this thread will likely still disagree, I don’t think that a “displayless” setup would be that awful. So many smart home devices like security systems and personal assistants are displayless and work just fine. Heck, if you’ve ever used Ubiquiti’s Unifi networking equipment, the controller system itself (the part that provides the configuration web GUI) has to run on a separate networked system, and it works great. Think about it - it’s networking gear that requires a networked system in order for the network itself to be configured and function. That seems like an oxymoron, but it works like a charm. If that is possible, I think having a networked thermostat without a display isn’t a cumbersome impossibility.
There are plenty of fail-safes that could be added to make such a system user friendly:
If networking connectivity is lost, continue following the existing programming and schedules.
Provide an option to alert the user if connectivity is lost for more than a few minutes (assume that brief losses of connectivity are common).
Switch to an AP mode for direct connections if connectivity is lost. Every so often (say, every 5 minutes or unless a client/user is connected), disable AP mode, check for network connectivity, and re-enable AP mode if necessary.
An alternative to AP mode would be using Bluetooth as a fallback networking interface (provided by all modern RPi devices).
Making such a system stable, reliable, and user-friendly would hardly be impossible. Furthermore, it would help differentiate the product from other options on the market because it would not only be less expensive but also distinctly different (which could generate market interest). For those who don’t remember, there were initially questions about how effective the Chromecast would be since it lacked remote like the more traditional Roku or Apple TV devices - here’s just one article:
If done right, it would work and work quite well. In 2020, there is no practical reason for a thermostat to have a display and physical buttons except for the notion that “they’ve always had displays and buttons.” Perhaps it’s time to challenge that concept.
Only the first of these are something my family members would be able to do or respond to on their own.
I’ve been down that path. I’ve been doing home automation for more than decade. I’ve tilted at the no-displays windmill multiple times. The only time it works is when:
manual interaction is something that rarely occurs, e.g. during initial setup
no feedback is required to know what is going on
changing the behavior is something that only the administrator needs to do
An HVAC system doesn’t meet any of these.
But you don’t have to accept the advice from those who have battled this dragon. Who knows, you might come up with something we haven’t thought of. I doubt it but who knows.
I suppose I have to wonder how often you are interacting with your thermostat. I don’t think I touch my thermostat more than once a week (if that). It’s programmable, I’ve set it up, and it does what it’s supposed to do. I bet that most people would prefer a thermostat that requires the least amount of interaction possible - set it, forget it, and it just does its thing.
Consider modern security systems like SimpliSafe. It uses WiFi, and your phone controls the system - a wall-mounted pin-pad is optional and not even necessary. People like it because it’s a no fuss system that just works.
How about smart door locks? If you want to talk about something that would be a serious nuisance if there was a connectivity outage, this would probably be the worst. Getting locked out of your home because your WiFi went down would be awful. Guess what? They work, and I have yet to see a smart lock that has a physical display on it. Why? It’s unnecessary.
Given these examples of similar smart devices that don’t require displays and “just work,” I go back to my original assertion that the primary reason thermostats have displays is because “they’ve always had one.” That’s a terrible reason.
About once a day depending on the weather, how big the temperature changes are throughout the day, and where we are in the house. We have forced air heating/cooling and three floors if you count the basement. There can be a 10-15 degree F difference in temp between the basement and the top floor. The thermostat is on the main floor. It may be comfortable on the main floor, far too cold in the basement and far too warm on the top floor. But not all the time. Mostly when there is a 30-40 degree F change in temperature from the morning to the evening which isn’t all that uncommon here.
If we had per room control, than maybe we could just leave it be. But without it we are boosting the AC or heater or adjusting the setpoint at least once a day, sometimes more than once a day. And everyone in the family will do it at some point including the seven-year-old who does not (and will not) have a phone.
Occasionally we rent out our house and/or have house guests. They need to control the HVAC too and I sure as heck not going to give them direct network access to do so.
I won’t use SimpliSafe but were I to do so I’d have to get the pin pad. Without it I cannot support all the users of the house.
Really?
A display-less thermostat would never work for me. It may work for you. But I tend to see this sort of thing all the time. Someone who lives alone and or with people who are roughly the same age and same set of technical skills as themselves projecting their experience to the whole world. A displayless thermostat may work for you. But in my experience, it won’t work for everyone and I’d even argue it wouldn’t work for most. At least not most of those in North America where forced air is more common than room-by-room heating/cooling.
Here’s a better question. How often do you WANT to be interacting with your thermostat? If you asked the average person, they would probably say “as infrequently as possible.” My idea would be targeting the people willing to spend the money on smart home tech like per-room zoning, smart dampers, etc. to make that a reality. They just want things to work, and they’ll pay for it (either as part of a renovation or a new home build).
Granting access to guests or family members is easy and doesn’t require direct network access. Cloud access is a thing, and that’s how most new smart home devices work. Grant them access to the portal with the permissions you want them to have, and they’re in. Temporary access to revoke permissions after a certain amount of time could be implemented, too.
Let me rephrase my comment about smart locks. I have yet to see a MODERN smart lock that has a physical display on it. The ones you posted are basically 5+ year-old digital upgrades to the mechanical push-button keypad locks that have been around for decades. The vast majority of new smart locks eschew displays because that’s not what customers want, and the technology is there to make that a reality. Wikipedia isn’t the source truth and fact, but there’s probably a good reason that their article on smart locks shows an August lock and makes no mention of devices with pin pads.
I’ll make some blanket statements. Modern smart home tech should:
be as mobile-friendly as possible
accessible from anywhere
require the least amount of interaction as possible
only require buttons or a display when absolutely necessary (since they should be mobile friendly)
That is the clear direction that the market is taking, and it is being done in a way that targets people that aren’t tech-savvy. There’s a reason that the Amazon Alexa didn’t follow in the footsteps of the Chumby. Done right, a displayless thermostat would a) set the HestiaPi apart from other offerings, b) be a lower price point than any smart thermostat on the market, and c) follow the direction that smart home tech is taking.
I decided that the HestiaPi community would be the best project to approach with this suggestion because open source projects are often more willing to innovate and push boundaries. If there’s not any interest, I didn’t mean to start a flame war. However, I think it would be great to see an open source project like HestiaPi make Nest and ecobee look like the Chumby of thermostats by comparison.
Clearly you think you can pull this off. I look forward to see what progress you manage to make. For me and almost all of the non-technical people I deal with a display-less thermostat would be a non-starter, and it’s not because I just accept that it’s this way just because that’s the way it’s always been done. I’ve spent hundreds of hours thinking about, prototyping, and building this sort of stuff. I know what my users will accept and won’t accept. Display-less would not be acceptable.
But I suppose there is a market for just about everything. Go build it and see if they come.
Surely there are people out there that would prefer a displayless thermostat for the reasons you mentioned. I personally could even be one of them.
What we have learned all these years from this and other open projects though is that you have to aim for a solution and a feature set that accommodates “the most”. Surely there are many spinoffs of HestiaPi we can have to help everyone but these won’t really get us the momentum we have at the moment and drives us forward.
Being open source and open hardware is the closest we will get to help people match their exact needs. Of course we understand hardware changes are not as easy as some software changes but then again this depends on the user’s skills and feature requirements.
I have a displayless HVAC setup, it’s great. It’s based off the old Smartthings arduino shield. I rarely need to manually adjust it, maybe once a month. It’s integrated with Alexa & Google Home, so I can always ask what the temp is and what it’s set at. I am migrating to openhab because the newst Smartthings update killed the user created library I was using, so a good time to move to a local solution.
“Alexa & Google Home” and “local solution” don’t go together. Also making a newer version less usable in order to force users use third party non-open services to make it usable again is against our vision. I hope you understand my point
@aboynamedpoo I’m interested in your project. I really think that there’s an opportunity, there. I don’t see a need for physical displays and controls unless absolutely necessary since smartphones can accomplish the same tasks (and often do it better and more conveniently).
@HestiaPi I understand the reservation against Alexa and Google Home. Personally, I don’t have either device, and I would NEVER buy one. However, I DO see the appeal for many users - it would be a useful option, and there’s no reason that FOSS can’t coexist with proprietary services. In many cases, the world is better when they do. It just shouldn’t be the default, that’s for sure.
On that topic (and a bit beyond the scope of this post), I also see the appeal in having some sort of cloud-accessible UI similar to how Ubiquiti does things. If you’re not familiar, a basic Ubiquiti setup is comprised of their networking gear (routers, APs, etc) and a “controller.” Unlike most consumer routers where the GUI and configuration software is installed on the device itself, you need a separate external system running their software to configure and manage the hardware.
There are three ways to set up a controller:
Local-only system like a RPi
Private cloud system
Using either 1 or 2, you can link your controller to your https://unifi.ui.com account
The first option is the most secure - nothing leaves your local network. The second option is still pretty secure, but it provides the added benefit of being able to manage devices remotely. The last option is less secure and relies on Ubiquiti’s systems, but it lets you manage multiple controllers from the same spot (which is convenient).
Is it possible to set up the HestiaPi using something similar to option 2? That would be pretty useful.
The default HestiaPi runs openHAB. You can connect to the openHAB provided myopenhab.org by installing the openHAB Cloud Connector add-on and registering an account. Once done you can add metadata to the Items that will make them discoverable by Google Asssitant or Alexa. Unfortunately you’ll need to do this through the REST API.
It is possible to set up a private version of the openHAB Cloud Server and integrate it with some (all?) of these services as well. The instructions for doing so are usually relatively involved and posted to the readmes on the repo for the integration.
