Take a look at this post that then jumps to another post showing card-mod solution.
If you don’t want to use card-mod then I would suggest setting up an input_boolean to display the card or not using the conditional card on the thermostat card. This way you are only displaying the card when you set the input_boolean.
You might also want to add an automation that alerts you to the fact that the t-stat has changed.
Kiosk mode hacs addon card has some “hide climate” stuff, you might check it if this is what you want.
Not a direct answer, but when we are away our daughter house-sits for us. She thinks nothing of setting the AC to 60°F in the summer or 76°F in the winter. So I have automations that change the setpoints of the thermostats if she had set the thermostat out of my comfort range.
alias: Heat-upstairs-limit
description: If the heat is set above 72 ° for 5 minutes, set it back to 70°
trigger:
- platform: numeric_state
entity_id:
- climate.upstairs
for:
hours: 0
minutes: 5
seconds: 0
attribute: temperature
above: 72
condition:
- condition: state
entity_id: climate.upstairs
state: heat
action:
- service: climate.set_temperature
data:
temperature: 70
target:
entity_id: climate.upstairs
mode: single
This gives the illusion that the heat or A/C will be responding to the thermostat for five minutes then it gets set to a sensible temperature. She hasn’t caught on yet.
I had the same problem on my phone and switched to the “simple-thermostat” card found in HACS, It is minimalist and make it much harder to change the temp with a simple swipe on the phone.
I tried to write up an automation that did something similar because the wife likes to periodically bump up the heat. I was unable to get it to work. For some reason it would not see changes to the climate entity. I couldn’t even get a notification to work. I abandoned the idea because it would only be a degree or two and I would always notice after a while.
This really sounds like an issue that should be addressed in HA. If people are looking at workarounds and using hac’s just to get around one single issue, it is indicative of a design flaw of that card. We’re not even talking about adding functionality, just preventing accidental changes to something that can have real consequences. It’s now 1:30pm and my house is still cooling off nearly 12 hours after the adjustment was made.
Maybe you should consider voting for this feature request!
It wouldn’t solve my problem with people adjusting the temperature on the thermostat.
LOL, maybe shock therapy
I solve this problem simply by placing sensitive cards inside a subview.
This card IS in a sub view. Doing this does not solve the problem. If one opens the sub view it is just as likely to happen as on any other.
Agreed, messing about with dashboards and cards I have set my heating by accident a few times. Yesterday I found my house a degree hotter than it should.
My old smarthome dashboard simply had buttons to adjust. The slider looks sleek and stylish, but is not safe. Especially since you don’t actually need to adjust the slider and can just tap it anywhere to change. So a fix would be that you’d need to touch or hold the dot first and then slide.
Hm… If a wife “periodically tends to bump up the heat” (just example taken above) then it’s far from design flaw of HA card, but rather a domestic issue. If you (or I) think that temperature is correct and a wife thinks it’s too cold, then it’s time for “house meeting”, not for HA card update… If you lock up the card, it’s just a matter of time when a wife will find the way to unlock it…
I never suggested this particular incident was the wife adjusting the thermostat a few degrees. I mentioned that she has done that before, but this was NOT one of those cases. Reread what happened a little closer. A jump of 10f at 4:30 am when everyone is warm in bed is not the wife purposely increasing the temperature. Especially when she was one complaining about how hot it was too.
While I appreciate the flexibility that is HA, jumping threw hoops using work arounds, hac’s, and custom cards to correct a behavior that introduces unexpected results is not best practice and is a design flaw.
I’m going to reiterate again a little louder for those in the back:
It is bad design if a change can be made inadvertently to something as important as the heat just by scrolling past the controls. If you find yourself using workarounds such as hiding the controls on a sub view, or custom integrations, it is an admission that something is not quite right.
And before someone brings the tried and true excuse of open source I’m going to put it out there now, Home Assistant has in my opinion long crossed the line from a tinker’s project into a paid product. 50$ a year to unlock full functionality means higher expectations.
I just gave an example. It’s not always HA’s fault, but many times it’s user’s one…
But, to go back to the problem: if i install and test a card that it’s not usefull to me (or dangerous…) i just delete it and use another one. It’s just not worthed to complain since nothing from user’s requests will be corrected or updated in a short time (if at all), as i see from history (among the worst example being changes in automations regarding folders organization).
As thermostat goes i personally i hate sliders, circles…. It’s too hard to precisely set a temperature. I only use + and - signs. With that you can accurately set desired temperature. And, it never happened to me yet that i did anything i didn’t want to (i use simple thermostat card for my climates).
I’ll agree that problems that should be resolved first, long before new functionality and features are even considered, are often ignored. Anyone else notice the annoying bug where you have to mash the back button on sub views just to get it to respond half the time? Yea that one drives me crazy. But at least that one is only annoying.
But it’s unacceptable for a change to be made so easily and by accident to something as important as the heat using the default, built in thermostat card. This is one I will not just shrug off and ignore. I will make noise.
