"Orphaned Battery Note" repair item appears after each HA Core restart

[altruizine]

Checklist

• I have restarted Home Assistant after the HACS or manual install.
• I have read the FAQ's.
• I have enabled debug logging for my installation.
• I have filled out the issue template to the best of my ability.
• This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
• This issue is not a duplicate issue of any previous issues..

Battery Notes Version

3.3.4

Describe the issue

Device: Fritz Smart!Energy 250 energy monitor by FRITZ! (the company formerly known as AVM), provided by the FRITZ!SmartHome integration

I have added this device to HA Battery Notes manually as it cannot be added via library.json because of blank blank Manufacturer or Model fields.

After each HA restart, Battery Notes creates an "Orphaned Battery Note" repair item, and I get the following warning in the core log:

2026-03-21 15:05:18.444 WARNING (MainThread) [custom_components.battery_notes.coordinator] 01KM8AGK5FMR2RGK1X2RCQ7T5C is orphaned, unable to find device 79c440f845d28942957408d284f24985

However, the device is indeed still present under that same ID.

I speculate that there must be a race somewhere between the Battery Notes and FRITZ!SmartHome integrations. Perhaps the problem is exacerbated by the fact that the device is a manually added one with missing manufacturer/model info.

Reproduction steps

1. Add Fritz Smart!Energy 250 device manually to Battery Notes
2. Restart HA
3. Orphaned Battery Note appears

System Health details

System information
Version core-2026.3.3
Installation type Home Assistant OS
Development false
Supervisor true
Docker true
Container architecture amd64
User root
Virtual environment false
Python version 3.14.2
Operating system family Linux
Operating system version 6.12.67-haos
CPU architecture x86_64
Timezone Europe/Berlin
Configuration directory /config
Home Assistant Community Store
GitHub API ok
GitHub Content ok
GitHub Web ok
HACS Data ok
GitHub API Calls Remaining 5000
Installed Version 2.0.5
Stage running
Available Repositories 2941
Downloaded Repositories 19
Home Assistant Cloud
Logged In false
Reach certificate server ok
Reach authentication server ok
Reach Home Assistant Cloud ok
Home Assistant Supervisor
Host operating system Home Assistant OS 17.1
Update channel stable
Supervisor version supervisor-2026.03.2
Agent version 1.8.1
Docker version 29.1.3
Disk total 78.0 GB
Disk used 20.5 GB
Nameservers fdaa:82bd:b612:0:4a5d:35ff:fed3:1c98, 2a02:810a:8320:0:4a5d:35ff:fed3:1c98, 10.1.1.254
Healthy true
Supported true
host_connectivity true
supervisor_connectivity true
ntp_synchronized true
virtualization oracle
Board ova
Supervisor API ok
Version API ok
Installed apps SONOFF Dongle Flasher (1.3.2), Matter Server (8.2.2), Mosquitto broker (6.5.2), Signal Messenger (0.98.0), File editor (5.8.0), OpenThread Border Router (2.16.5), Zigbee2MQTT (2.9.1-1), Terminal & SSH (10.0.2), Whisper (3.1.0), Piper (2.2.2), Home Assistant Version Control (1.2.0), ESPHome Device Builder (2026.3.0), HA Entity Explorer (1.1.4), DbStats (0.5.12), Let's Encrypt (6.2.0)
Dashboards
Dashboards 4
Resources 3
Views 1
Mode storage
Network Configuration
Adapters lo (disabled), enp0s3 (enabled, default, auto), docker0 (disabled), hassio (disabled), veth7395c37 (disabled), veth21f92d5 (disabled), veth29a9ff7 (disabled), veth1af35f8 (disabled), vethaaaff97 (disabled), veth1fc53c4 (disabled), veth1ec9476 (disabled), veth7f92166 (disabled), vethbb8ec60 (disabled), wpan0 (disabled)
IPv4 addresses lo (127.0.0.1/8), enp0s3 (10.1.0.115/16), docker0 (172.30.232.1/23), hassio (172.30.32.1/23), veth7395c37 (), veth21f92d5 (), veth29a9ff7 (), veth1af35f8 (), vethaaaff97 (), veth1fc53c4 (), veth1ec9476 (), veth7f92166 (), vethbb8ec60 (), wpan0 ()
IPv6 addresses lo (::1/128), enp0s3 (2a02:810a:8320:0:149e:c60d:aef9:ac50/64, fdaa:82bd:b612:0:b405:bead:c1bb:5619/64, fe80::71a3:73a8:6b5f:aef5/64), docker0 (fe80::1c6a:9cff:fe4b:a6c4/64), hassio (fd0c:ac1e:2100::1/48, fe80::54b2:c3ff:feb1:6350/64), veth7395c37 (fe80::a42b:52ff:fec8:f47c/64), veth21f92d5 (fe80::fc61:33ff:fed0:1a46/64), veth29a9ff7 (fe80::28b8:2aff:feef:6daa/64), veth1af35f8 (fe80::d461:50ff:feaf:26d5/64), vethaaaff97 (fe80::60eb:60ff:fedd:4a61/64), veth1fc53c4 (fe80::4032:bbff:feb2:9945/64), veth1ec9476 (fe80::5c4c:52ff:feaf:424e/64), veth7f92166 (fe80::e015:8fff:fedc:7e4e/64), vethbb8ec60 (fe80::7888:faff:fed0:5990/64), wpan0 (fd65:c944:a45c:9b16:0:ff:fe00:8800/64, fd65:c944:a45c:9b16:3b02:149c:4006:72d2/64, fe80::40c9:c467:318c:7119/64)
Announce addresses 10.1.0.115, 2a02:810a:8320:0:149e:c60d:aef9:ac50, fdaa:82bd:b612:0:b405:bead:c1bb:5619, fe80::71a3:73a8:6b5f:aef5
Recorder
Oldest run start time March 11, 2026 at 3:12 AM
Current run start time March 21, 2026 at 3:05 PM
Estimated database size (MiB) 605.63 MiB
Database engine sqlite
Database version 3.49.2
Core metrics
Processor usage
0.8 %
Memory usage
10.4 %
Supervisor metrics
Processor usage
0.1 %
Memory usage
2.4 %

Debug logs

Logfile is too large for this field (>64 KB), so I attached it below.

Diagnostics dump

config_entry-battery_notes-01KHCNEH91HKB9Y564674T67B7.json

home-assistant_battery_notes_2026-03-21T14-41-04.797Z.log

[andrew-codechimp]

Hi,

It looks like this integration adds devices at runtime so yes a bit of a race condition. The manufacturer/model missing wouldn't be a problem though.

If you do the repair (submit I think the button is) then restart HA does it re-appear? The battery note for the device should be removed.

If it is removed and you have to re-add it, re-add as an Entity relation rather than device might solve this.

[altruizine]

No, it remains removed.

I have tried adding it as an Entity relation before (tying it to the device's battery state), but that results in the same repair issue, perhaps because the entities are dynamically added as well. Is there another entity I can bind it to so that it still finds the device's battery state?

[andrew-codechimp]

Ah, yes, the entity is validated against the device as well, sorry only just spotted that.

I don't think there is, it looks like all entities are created at runtime with this integration.

Looking further I think you'd find a similar issue if you added a core Helper/Template/Sensor with just some text as a test, associated it with the device and then restarted, you'd find the template wasn't in the device either after restart, just would not throw a repair.

I don't think you'd be able to add a battery note, or other helpers added to this device from the way it's designed.

[altruizine]

Would it be possible to add a delay after startup (say 1 min, or 10 min, or even configurable) to give devices some time to appear? This seems to be how some other integrations handle dependencies on external devices; for example, Versatile Thermostat is quite forgiving with respect to sensors showing up late.

Thank you very much for sharing your thoughts, and for your Battery Notes integration in general!

[andrew-codechimp]

It looks like Versatile Thermostat just listens for other devices, it doesn't add entities to them which is where the issue is here.

An overall delay on startup I'd want to avoid, either a retry before raising the repair or a delay configuration per device may be options but they would require quite a bit of thought, leave it with me but it will be a future enhancement rather than a quick bug fix.

No problem, it's always interesting to try and tackle these sorts of edge cases.