I’m pretty new to HA. I’ve set it up and I keep editing the confirmation and everytime I restart to apply the changes, all the switches, sensors and even the thermostat lose their values. The most annoying is the thermostat (classic thermostat entity) because I have to turn it on selecting heat/cool and set the temperature. Is there a way to keep all these values across restarts?
Edit: I’m using HA OS on Proxmox. All the sensors and switches slowly goes back to “normal” as soon as they publish their state, apart from some entities that have values provided by HA itself and not by the devices (like the thermostat).
You must log in or # to comment.
That’s strange, it usually does keep that, because the values are coming from the devices themselves. Like a switch is either on or off as soon as HA reconnects, it requests the state of the switch. Same for thermostats, at least in my case, because mine are connected via the router via DECT. It may helps to provide some more details on your installation (Docker, HASS OS, …) and devices
I’ve edited the post with some other information. About your configuration, how does HA ask for the state? This mean that your HA loses all the values too, but it repopulates them automatically. What about the entities that provides values FROM HA itself? For example the setpoint of the thermostat?
During restart all entities are in state unavailable. When the integrations are loaded all the entities with their current states become available again, but that’s something of seconds. The internal entities, like Helpers, are immediately available - that’s the closest to “value from HA itself” I have in my setup
The internal entities, like Helpers, are immediately available
This is my problem:in my main HA instancd the internal entities are in state “unknown” when I reload the configuration. In another instance of HA everything works fine and the thermostat goes back to their previous state when I reload the configuration, in the “main” instance they don’t :(
If you set up your HASS with docker, make sure that PATH_TO_YOUR_CONFIG is appropriately replaced with desired location.
I used to have kinda same problem, then I noticed that there was a suspicious directory named /PATH_TO_YOUR_CONFIG lol
Are you using Docker? Forgive me if you know and understand docker - I’m just checking to make sure, but if you’re using Docker are you sure you set up your volumes correctly? Docker is stateless, so on any restart it would lose all of your info and be a clean install if you did not set up your volumes correctly
Something’s wrong with your configuration. What hardware, OS and HA config are you running?
My HA install does not lose anything when restarted. All my wifi, Z-wave & Zigbee devices, various entities and thermostat come back in the same state as prior to restart. I’ve run HA Supervised on two HW platforms and 3 distros and they’ve all functioned this way.
I’m using HA OS on Proxmox. About the configuration, what do you need to know? Do you wanna see it all? All the sensors and switches slowly goes back to “normal” as soon as they publish their state.
HA OS on its own doesn’t behave that way, so that leaves Proxmox or perhaps your specific hardware. Can’t help you though. Haven’t tried HA in any kind of virtual environment.
Indon’t think that the problem can come from Proxmox/HW since it happens everytime I restart the services, not the VM. So strange…
Perhaps so, but I’ve run HA on a Raspberry Pi under Raspberry OS, HA OS on that Pi, and HA Supervisor on a PC using Debian and am currently running it on a PC under Linux Mint. All of these worked with little or no delay between HA start and device status updates.
Since the updates comes from the devices and ate not requested from HA, some exposes their statuses in less than a minute, some (like temperature sensors that are battery powered) sends their statuses very less frequently (if the temperature doesn’t change, they communicate every 30/40 minutes.
When you restart HA, keep an eye on the Summary tab for the Proxmox guest. If you’re seeing CPU or memory spikes going into the red, you might need to assign more resources to the guest. Also take a look at swap and boot disk utilization - do they seem particularly high?
Also, over what period of time to the “go back to normal”? A few minutes, half an hour, more?
Nothing like that, the resources are more than enough, no peaks. It “goes back to normal” when all the sensors/switches have sent their status and when I manually turn the heater back on and set a new setpoint for the thermostat
How network-savy are you? I’m thinking you could run tcpdump on your HA server and capture network packets while restarting HA, then inspect in Wireshark.
Most devices don’t actually “send” their status to HA directly. It’ll (usually) be HA querying their status (the exception being devices that publish via intermediate services, like MQTT). Inspecting the network packets might reveal more about what’s going on.
All the devices (sensors and switches )sends their status via MQTT; I’ve manually configured them all via yaml. The problem is in HA itself since as soon as I reload the config, the thermostat (which is a HA entity by itself), loses the setpoint and the status (heater/cool/off).
@peregus @DeltaTangoLima I am not an expert by any means, but I think there is a state “recall” somewhere that tells mqtt and or ha to keep last state
For MQTT that’s the retain flag, but for HA I don’t know what that is and I really need it!!!
The retained flag simply tells the MQTT broker to keep the last message published for that topic, so it’s always available (rather than timing out and emptying the topic).
Like I said, you should probably do a packet capture to see what’s happening when HA queries states (either from devices or MQTT - it doesn’t matter).
HA doesn’t query any state. The thermostat is within HA, it doesn’t have to query anything from anything, that’s what I’m investigating. The setpoint is set in HA and HA retains that number.
