The generic thermostat in Home Assistant is super useful especially in the cold Norwegian weather. I’m using Aqara battery temperature sensors as the input with a shelly plug to control the heater, works great!
Coming from industrial control systems there is a feature I would love to have implemented on the generic thermostat, a fail-safe mode.
The fail-safe mode would turn the thermostat into OFF mode if the temperature sensor become unavailable. This would make sure that if a thermostat is in HEATING mode and looses the temperature input the heater would not keep heating indefinitely.
Edit after feedback:
In a situation where heating is crucial HEAT mode could be more secure than OFF. F.ex in heating a pipe situation. The user would have to set the safe condition based on the application
Thanks for the automation help @123 and @AllHailJ. That would absolutely be a solution to the problem. However, since Home Assistant is starting to attract more and more “non technical” people I believe such a feature will increase safety and therefore be beneficial to have implemented as a feature directly in the Generic thermostat in the way that @tmjpugh suggests. Could even consider making it default to ENABLED.
I don’t know if you are aware of how Feature Requests work. They’re nothing more than a wish list.
The wish is that a volunteer with appropriate software development skills is sufficiently intrigued by the request to implement it. If the request doesn’t interest them, it never gets implemented (regardless of how many votes it gets). This is usually the fate of requests that are either easily achieved using existing techniques or have a very narrow application.
Regarding “non technical” users, if they can’t understand the concept of automations, they will need to learn it or else there won’t be much “automation” in their “home automation”. In addition, the Generic Thermostat can only be configured via YAML so, from the very start, it requires skills that must be learned by “non technical” users.
Which only confirms my worries that this projects completely lacks of leadership (project or architecture wise). Being dependent only on devs who are ‘sufficiently intrigued’ could be beginning of the end. I hope you are wrong and there are roles who drive this development in proper direction (ie motivating contributors to work not only on intriguing things). And hopefully there are paid programmers who will polish all those great but unfinished prototyped components around
@maxym - I left a commercial project to Home Assistant. IMHO it is no different. Requests that had been out for years never got implemented. The developers did what they thought was best. Home Assistant is constantly being improved and I for one am grateful. Home Assistant is so much better than where I was. The support is better too.
That’s the point. Doesn’t matter it is commercial or not, open source or not… Devs in general shouldn’t do what they think it’s the best. usually they are not able to evaluate what is best for the project.
In the particular thing being asked by OP: it is obviously not to much work with quite big step toward reliability. But likely doesn’t attract any developer unless leading finger point at this (not even asking why it has been developed without handling undefined states from beginning)
It’s an open-source software project. Except for the parts implemented by Nabu Casa’s paid staff (which has only been in the last ~3 years of the project’s 8 year history), everything is created by ‘sufficiently intrigued’ volunteers.
If this situation represents the ‘beginning of the end’ then it began 8 years because that’s how long it’s been the status quo.
beginning of the end must not appear at project beginning. at some point you have to stop prototyping (in most cases it is the thing for devs) and start to polish things up (this it the most annoying and boring thing for devs).
you cannot infinitively repeat that this is open source (which really is not what does matter in this case) as justifying for never finished/polished components
English is not my first language so I might have written in the wrong way. It is by no way any demand it is just a feature I personally as a user think is smart for a thermostat.
Interesting because you are well known in this community for infinitely repeating your dislike with most everything about the project. Regardless of the feature or process, we can all count on maxym to point out why it doesn’t meet his standards.
Actually, it really does because the extent of any feature’s functionality is largely determined by the feature’s volunteer author and subsequent volunteer contributors. It’s the very nature of open-source projects (if something interests no one, it doesn’t get done).
If anyone feels that’s arbitrary and haphazard and leads to a lack of ‘polish’, then they might want to reconsider using an open-source application like Home Assistant. Given Home Assistant’s rapid growth over the past 8 years, it’s fair to say its ‘unpolished’ nature hasn’t impeded its adoption.
No worries; you wrote your Feature Request perfectly.
I just wanted to be sure you understood that they don’t follow any formal process where they are reviewed, categorized, and scheduled for implementation. It’s much less formal than that.
If you have some time, look through some of the existing Feature Requests (at least the ones with a high number of votes) and you’ll find several that propose really good improvements but have remained unfulfilled for one or more years. It all depends on the interest of volunteers to implement a given Feature Request.
The generic thermostat is a fairly common integration (it is used in more than 3 thousand installations(according to analytics), but it lacks a lot of features when compared to other thermostats.
There were many PR (created by volunteer contributors), that sadly went stale because the core team didn’t have time to review them. I don’t blame them, because there are more than 380 PR (all the time) that need review, but I constantly get a feeling, that even when someone creates a PR for the generic thermostat it is pushed to the end of the waiting line and the slate bot closes them after some time.
Another way of seeing this is that it would prevent the heater from turning on, thus freezing pipes and causing other low temperature related damage.
So it would seem that an ideal fail safe would have choices.
Allow the user to turn it off. Or force it on.
Or even better, a configurable fail safe which would assume the last state of the thermostat (ie. cool or heat) then fall back to a schedule to run the mode periodically for a set period of time. Could it result in too warm or too cool a house? Yep. But would it result in a “dangerously” wrong temperature condition? Probably not.
A bit like automotive ECUs that go into limp mode if a critical sensor fails. Definitely not idea operation, but enough to get you to safety.
I’ve been following this thread mostly out of curiosity. I use Honeywell “smart” thermostats, which I had before I went with HA. I don’t like the cloud dependency, but I’m starting to think having both the Honeywell cloud app and the HA integration is a good solution for what amounts to my most critical system.
Without heat, all my pipes would freeze. The house would be uninhabitable for a long time and repair costs would be huge. The fact that I can control the 'stats with HA is great, but knowing they’ll fall back to their default settings if HA, or the cloud connection, fail is comforting.
