Repository navigation
Device settings sent as {} after HA restart; wake word select restores to None #330
Description
Versions: integration 0.13.4 (also 0.13.3), app 0.13.4, HA 2026.9.3
What happens
After a Home Assistant restart (or an app restart), the device receives an empty settings event:
{"event_type":"settings","settings":{"custom_files":{...},"ha_url":"...","integration_version":"0.13.4","min_required_apk_version":"0.13.4","screen_on":false}}
No wake_word, wake_word_engine, wake_word_sound, volumes, etc. The app keeps its defaults (openWakeWord, no wake word, no wake sound), so the satellite silently stops responding to the wake word until the selects are changed by hand. The wake_word select in HA also shows None.
Cause — two races on startup
-
assist_satellite.py,__init__:self.device.custom_settings = {}. Select/number entities restore their last state intodevice.custom_settings(devices.py,set_custom_setting) concurrently with satellite entity creation. When they run first, the satellite constructor wipes what they wrote, and the next settings event is empty. -
select.py, wake word select,async_added_to_hass: the saved value is restored only ifstate.state in self.options. Options are built fromdevice.infoand the selected engine, which may not be restored yet, so the saved word (e.g. "Hey Jarvis") is not found and the select falls back to None.
Similar in spirit to #262 (fixed in 0.13.0 for motion detection).
Fix
- Only initialise
custom_settingsif it is stillNone— the device object is recreated on every config entry load, so stale keys are not possible. - Restore the saved wake word unless the last state is
unknown/unavailable.
I've been running both changes since 2026-09-25: settings survive HA restarts (docker restart -t 120) and app force-stops. PR follows.
Activity
bpinson999 commentedon Oct 6, 2026
Note: Claude helped diagnose and implement the fixes performed, as well as this comment.
Adding a data point: after an HA restart, the app also crashes natively on 0.13.4, not just loses its settings. I'm fairly sure it's related.
Setup: 6× Echo Show 5/8 on LineageOS 18.1 (Android 11, 32-bit ARM: checkers / cronos / crown), app 0.13.4, integration 0.13.4.
What happens: When HA restarts, several devices segfault in the same second. Today's restart: 5 of 6 crashed between 14:48:09 and 14:49:02, and two of them crashed twice within a minute. Almost every HA restart produces a burst of crashes across the devices at once.
All the crashes are the same: a null pointer dereference inside the TFLite interpreter, on a coroutine
DefaultDispatchthread:My guess is that the settings event after the restart (the empty one described above) changes or resets the wake word or engine. The interpreter gets closed or swapped while the detection loop is still inside
run(). If that's right, the #331 fix would avoid the trigger, but the wake-word loop probably also needs to stop or synchronise before the interpreter is released.Knock-on effect on Android: The app is set as the Home app. When a non-system Home app crashes, Android 11 clears the saved default Home choice. So each crash leaves the device on the "Select a Home app" chooser with the screen off. After a double crash, the app doesn't come back until someone launches it by hand. The device then stays unavailable in HA until its config entry is reloaded. As a workaround, I disabled the stock launcher (
pm disable-user com.android.launcher3) so the app is the only Home candidate, and Android relaunches it after each crash.Header and backtrace excerpts from three devices (one per model) are attached.
tombstone-cronos.txt
tombstone-checkers.txt
tombstone-crown.txt
alexreddy78 commentedon Oct 7, 2026
Hi Mark,
Any updates on this? Really annoying, that Wake word lost sometimes after reboot of HAOS.
BRGDS
msp1974 commentedon Oct 10, 2026
@GlebYavorski I am not clear on the description of the cause of this issue. Can you give me more colour. Please do not post lots of claude output but describe what you do and what you see.
Why I am asking.....
If settings are not provided in the message from the restarting HA, it will not overwrite current settings on the device. The message you show, does not have any key/value pairs that will overwrite values so therefore the app does not keep is defaults, as you state, but keeps its current values. Ie no change.
In looking at your PR, I am also struggling to understand what this actually fixes. The init function isd only called on creation of the class instance so
device.custom_settingswill always be None as this point as it has not been instantiated yet.The change to the select entity should also be ineffective as HA gets its list from the device before the sensor is loaded.
I have done various tests and cannot get this situation to occur, so I need more info please. Thanks
msp1974 commentedon Oct 10, 2026
@GlebYavorski - apologies. I had never seen this happen before but just had it happen and I can see what you mean exactly. Ig nore my last message. I'm looking at this.
msp1974 commentedon Oct 10, 2026
Fixed in v0.13.5.
GlebYavorski commentedon Oct 11, 2026
@msp1974 Thanks, with 0.13.5 the app keeps settings when HA restarts, but if after that the app itself restarts (crash or phone reboot) it gets empty settings from HA again and starts with defaults (openwakeword, no wake word sound). Not sure, but looks like the integration still sends {} after HA restart, I still need my patch from #331 for it to work.