0.83.3+ entity state issue (core.restore_state)

Configuration
1

Is there a way to exclude devices from this? It’s messing with my device GPS states (it’s present in the file) where a device is reporting in but being overwritten/restored (after restart) with the contents of the state stored in this file? It’s also messing with other states that I don’t want restored on restart and the problem stops when I delete this file and then restart and it starts acting as expected. These are device_tracker values that I’m running into problems with.

2

+1

restore_state is messing up some my states too. I would also like to be able to exclude some entities from its reign.

3

Looks like this is the commit that added it by @armills

I looked through the commit/files but I don’t see anything that allows for exclusion per se. However, a possible workaround might be to remove the entity before shutdown using the shutdown automation so the entity isn’t stored state-wise. I’m only guessing here but seems like it might work based on my understanding of the code.

EDIT: Updated topic title as well to be more accurate. Included a tap to the author to see if there’s something else that can be done as well (visibility.)

4

Just to flesh out the issue here. When I restart HASS and I have say device_tracker.chris which is a “meta” tracker for other device_tracker (combined) and one of the other sources for this meta tracker tries to update it, it restores the data (almost immediately, like ~1sec and visible through dev-state editor when it happens) to what is stored in core.restore_store

If I remove the file (or just the entity entry itself from this file) then the device_tracker starts behaving as expected since there’s no restored data and it updates. So in the example below if device_tracker.chris_gps receives new data and tries to update device_tracker.chris with this data what happens is I can see the data update for ~1sec and then it reverts back to the original data stored in core.restore_state even if I use the dev-state editor to forcibly try and change the values.

device_tracker.chris:
{
  "source_type": "gps",
  "latitude": coords,
  "longitude": coords,
  "gps_accuracy": 25,
  "battery": 45,
  "velocity": 0,
  "tid": "is",
  "friendly_name": "Chris",
  "icon": "mdi:cellphone-android",
  "meters": 100
}

device_tracker.chris_gps:
{
  "source_type": "gps",
  "latitude": different_coords,
  "longitude": different_coords,
  "gps_accuracy": 25,
  "battery": 91,
  "velocity": 0,
  "tid": "is",
  "friendly_name": "Chris"
}
5

OK this problem is even bigger than I realized. It does it with all entities; if I forcibly try to set a state (dev-state panel) or a state is being updated by a custom component/python script/etc it immediately reverts back to the cached state. This is breaking all kinds of things for me. I even tried symlinking to /dev/null (file gets created anyways) among other hacks/kludges (chmod 0000 for example.)

EDIT: This should be opt-in vs forced-in; I’d even settle for opt-out.

6

I added a comment on GitHub asking if it can be made opt-out for entities. My wife’s iPhone reported in several times over the course of the night and I woke up to over a hundred notifications this morning as the data reverted to cached data from the updated data her phone was sending. I had the same problem with Zanzito which forced me to Owntracks for the time being. My only other choice is to revert to 0.7x.x I was at before upgrading or re-work my entire device_tracker methodology or submit a source change (unfortunately my Python isn’t that good.)

7

Hi - Im having the exact same problem on 86.3 using a meta device_tracker has there been any progress or a fix?

8

Sort of. Apparently the way I was going about it (changing the public state machine value) is not an accepted method. Guess that’s that:

https://github.com/home-assistant/home-assistant/issues/19702#issuecomment-458511767

9

Would appear so - been working for a long time just fine and broken now with no solution?

10

In my case, I found a solution - seems obvious now in retrospect. I’m guessing in most cases, the older HASS would allow updates to entities but there’s apparently a “public” and “internal” entity pointer; the public side would be updated by scripts/etc previously and I guess internal would accept that which doesn’t work anymore.

I want to verify what I’ve found before I start talking like an expert but pretty sure I’ve got it figured out now :slight_smile:

11

you might be onto something then

12

Any luck? I tried renaming the device_tracker entities I was using, everything started working again, then a short time later the same problem happened as before.

13

Yes, the issue in my case is that I had my meta tracker in known_devices.yaml - while this worked before, it no longer does and ties the meta tracker to the internal state engine. Comment out your meta trackers from known_devices.yaml and see if they keep their changes (it’s working for me here.)

You’ll need to restart HASS of course after the change.

14

thanks tried that - now the script fails as the entities don’t exist, do you create them somewhere else?

15

Yes, I’m creating them in my script.

16

could you link to your latest version of the script - I can’t get to seem to get mine to create. Thanks

17

I don’t have a latest version online. How are you creating yours script-wise? My original script can be found here:

18

try this:

try deleting the files that refer to the ghost entity in your config folder. Then use the recorder.purge service with the following:

{
  "keep_days":"0",
  "repack":"true"
}