Conversation
_extract_mobile_app_entities() matches mobile_app sensors by checking
whether the entity's unique_id contains a suffix like '_battery_level'.
That holds for iOS devices, but macOS's companion app reports the
internal battery as a labeled power source and embeds a serial number
in the unique_id instead (e.g. unique_id ending in
'<serial>_level' rather than '_battery_level'), even though the
human-readable entity_id (sensor.<device>_internal_battery_level)
still carries the expected suffix.
When discovery misses the entity this way, start_ic3.py builds
Device.mobapp[BATTERY_LEVEL] as the literal string "sensor." (the
dict lookup falls back to an empty string), which is not None, so the
Gb.conf_data_source_MOBAPP/self.mobapp.get(BATTERY_LEVEL) is None
guard in update_battery_data_from_mobapp() doesn't skip it.
entity_io.get_attributes("sensor.") then hits hass.states.get()
returning None, raises AttributeError, and the caller's own error
handling logs an ERROR every poll cycle (as often as every 5s)
indefinitely for that device.
Falling back to entity_id when unique_id doesn't match fixes discovery
for these devices without changing behavior for anything already
working, since the working iOS entity_ids already contain the same
suffix their unique_id does.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #632
What
_extract_mobile_app_entities()inmobile_app/mobapp_interface.pydiscovers a mobile-app device's battery/trigger sensors by checking whether the entity'sunique_idcontains an expected suffix (_battery_level,_battery_state,_last_update_trigger). This one-line change also checksentity_idas a fallback whenunique_iddoesn't match.Why
The macOS Home Assistant companion app reports the Mac's internal battery as a labeled power source and embeds the battery's serial number into the sensor's
unique_id, so it ends in<serial>_levelinstead of_battery_level— even though the human-readableentity_id(sensor.<device>_internal_battery_level) still ends with the expected suffix. Discovery misses the sensor entirely for these devices, which (see #632 for the full trace) leads toupdate_battery_data_from_mobapp()logging an ERROR every poll cycle indefinitely, sinceDevice.mobapp[BATTERY_LEVEL]ends up set to the literal string"sensor."instead ofNoneor a real entity_id.Every iPhone/iPad in my own setup already has
entity_idandunique_idagreeing on this suffix, so this fallback only ever engages for devices where the primary match fails - it doesn't change behavior for anything currently working.Testing
Device.mobapp[BATTERY_LEVEL]was"sensor.",update_battery_data_from_mobapp()threwKeyError: 'state'every ~5s (5128 times logged over 7.5h for one device).battery_level or last_update_trigger sensor entities were not foundto a cleanMac, TrackedwithMobApp Entity: mac_oneassigned, and the repeating ERROR stopped entirely (0 occurrences since).python -m py_compileon the changed file.No CONTRIBUTING.md, issue template, or PR template exists in this repo (checked
.github/, repo root, and common legacy paths), so this follows the general commit-message/PR conventions visible in the existing history.