It is not an esp01, it is an AC by daikin so there’s no settings to modify.
I don’t know about that Daikin AC integration.
Maybe it should be adapted for the latest release of HA.
You can always open a ticket for that.
In the mean time, either go back to previous version of HA or disable the Daikin AC integration.
Unless someone else has a better idea?
It’s not the core Daikin integration, it does not use the ESPHome API.
They may have an ESPHome IR remote that controls their Daikin A/C?
That’s also what I thought when I saw the
but now I’m confused by
Yeah totally confusing. The core Daikin integration uses this: pydaikin · PyPI
This is what it looks like from the entity registry : IR Remote Climate — ESPHome
Though even then, in the entity registry it is only a temperature sensor, not a climate device.
I think I just had a stroke :'D
So, lets sumarize, shall we:
- The core.entity_registry contains an invalid character, a “?C” that should be a “°C”
- Correcting the file is useless as next HA restart is bringing back that “?C”
- Identifying the source of that corruption seems impossible as
3.1 The core.entity_registry file seems to indicate that it was created by an ESPHome sensor
3.2 But it is not an esp01, it is a Daikin AC sensor
3.3 But it is not coming from the Daikin AC integration
Wow!
From what *** file can this entity come? (I’m censoring myself)
1 Like
My guess is some sort of ESPHome based ir remote that controls the AC.
Sorry everyone for the delay. The integration is the core Daikin integration.
In any case, i noticed that this error occurs also in one of my z-wave based temperature sensor:
},
"config_entry_id": "645f5c225c839ffac1d4fa6d81c15fd5",
"device_class": null,
"device_id": "0b6af9320e8b4a1aaf8fc5a447fb4c2f",
"disabled_by": null,
"entity_category": null,
"entity_id": "sensor.living_room_temperature",
"hidden_by": null,
"icon": null,
"id": "9e3e59afe0ed0dd28805cdd796af3639",
"has_entity_name": false,
"name": null,
"options": {},
"original_device_class": "temperature",
"original_icon": null,
"original_name": "Living Room Temperature",
"platform": "esphome",
"supported_features": 0,
"translation_key": null,
"unique_id": "esp01sensorliving_room_temperature",
"unit_of_measurement": "?C"
},
EDIT: the issue occurs for all the instances of “°”, that is on every sensor that reports temperature.
Again, that is not a zwave sensor:
This is the same “sensor” as you showed above … If this has anything to do with your Daikin, then "remove/disable) this sensor , and try again and if it’s not to much hazzel, stop/prevent the Daikin-integration from load , to see whether that help … some time it better/easier to use the “exclude” approach to narrow down the culprit
btw are you sure you mean every “degree-sign sensors” ?, or could it be so that it actually just stops(and fails to start) on this occurrence ?
Quick update: for some reason the “°” symbol does not appear as a question mark in core.entity_registry anymore but appears properly as “°”. However, I still get the same error.
I have tried removing and adding back all the entities that contain temperature but the only success was what I mentioned in the first sentence of this post.
It really seems like a bug to me, do you guys have any other idea?
The problem is the encoding of the file, we have established that.
Next step i would have performed, is to “commend out” your automations( in conf.yaml), to see / verify that it’s not something in an self-made-automation that causes this
… but unfortunately, i simple " dot " in the wrong place in core.entity.registry is enough for ha to “prevent loading”
I have an update. Now for some reason core.entity_registry is empty and HA complains about it. I have to delete the empty file and restart HA to create a new one.
2023-01-18 12:17:04.808 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2023-01-18 12:17:07.435 ERROR (SyncWorker_2) [homeassistant.util.json] Could not parse JSON content: /home/homeassistant/.homeassistant/.storage/core.entity_registry
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.9/site-packages/homeassistant/util/json.py", line 39, in load_json
return orjson.loads(fdesc.read()) # type: ignore[no-any-return]
orjson.JSONDecodeError: input length is 0: line 1 column 1 (char 0)
EDIT: what is interesting is that my previous theory that all “°” are not readable by HA is wrong. I suppose that core.entity_registry is read from top to bottom and the character that breaks the file is not the first “°” that appears.
From which install-media/version to which version ? ,are you running Supervised on ubunty, or VMware homeassistant-os, on windows ?
I am running HA core 2023.1.4 on raspbian in venv. I upgraded from 2022.06.something
EDIT: I did not upgrade. I actually uninstalled and reinstalled HA as I was getting the error we are discussing about.
Good luck, im out
Problem solved!
I am a genius. I just had to reconfigure the locale of my system using dpkg-reconfigure locales and choose UTF8.
Thank you @Olivier1974 @boheme61 @tom_l for your support, it was highly appreciated and without your help I wouldn’t have been able to figure out the problem.
1 Like
I had a similar issue with a migration to a new Raspberry pi 5. However, dpkg-reconfigure locales did not solve the issue. Here are the steps that were needed to solve the issue:
The file core.entity_registry was being saved as ISO-8859-1 and should be UTF-8. This can be checked with: file -i /home/homeassistant/.homeassistant/.storage/core.entity_registry
The file /etc/default/locale had not been updated completely. LANG was changed, but not LC_ALL After editing the file, it now works fine.
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8
If needed, the file can be converted to UTF-8 with: iconv -f ISO-8859-1 -t UTF-8//TRANSLIT core.entity_registry -o core.entity_registry
1 Like