Watch Battery Sensor / Watch Battery State Sensor reporting incorrect values

[yyolk]

iOS device model, version and app version

Model Name: iPhone 13 Pro Max, Apple Watch Series 6 Software Version: iOS 17.6.1 (21G93), WatchOS 10.6.1 (21U580) App version: 2024.9 (2024.803)

Home Assistant Core Version

2024.8.3

Describe the bug Testing the iOS Beta through testflight. For #2945 - I received the testlfight build overnight from 2024.9 (2024.796) where the watch-battery sensor was still reporting correctly.

After an automatic update to build to 2024.9 (2024.799) (also 2024.9 (2024.803)), the sensor appears to reporting but continues to report the same value it was previously. After waiting over a day to see if "it would resolve itself" I tried to debug.

• The watch-battery sensor continues to report its last known state.

  • Manually updating the state for watch-battery will result in the state eventually reverting when a sensor update comes through (back to the previous state that didn't change.)
  • For example in the screenshot below, 60% was where the sensor was seemingly locked reporting in.

• The watch-battery-state doesn't change

  • Similar I think to the watch-battery not updating, or reporting the same value, this sensor is locked in Not Charging

• After uninstalling, rebooting, and re-installing the app, watch-battery reports -1.

To Reproduce

1. Have a paired Apple Watch
2. Update to 2024.9 (2024.803) from testflight or optionally uninstall, reboot and install.
3. The watch-battery sensor will report the last known value repeatedly, persisting through reboots of the device or -1 if you uninstalled, rebooted and re-installed

Expected behavior

The sensor accurately report the current watch-battery level and watch-battery-state.

Not the last known value (or the default value in the case of a uninstall, reboot, reinstall).

Screenshots

My phone is named "Frequency Between Disasters №" which is a reference to when I have to move to a new phone it feels disasterous.

This screenshot depicts:

• a long period of a few days 60% being reported (trying to let it "work itself out")
• a manual change of the state of watch-battery to 35 and then 30
• the sensor is seemingly reporting as the sensor value gets updated back to the last known value when updated past 2024.9 (2024.796) of 60
• a current value of -1 while testing uninstalling, rebooting, re-installing

This screenshot depicts:

• the same as the first screenshot
• a current value of 10 after a downgrade to 2024.9 (796) where the sensor reports correctly

Additional context

I've switched between 2024.9 (2024.803) and 2024.9 (2024.799) and saw the same results.

As co-author of #2945 I don't know for sure what would be causing this behavior, below is all guesswork.

I focused primarily on the changes in https://github.com/yyolk/home-assistant-iOS/blob/009b4d0ecd37664a049f89fc2363f8a5abc5e946/Sources/Shared/API/Webhook/Sensors/WatchBatterySensor.swift#L11-L40

It is returning an array of promises my thought is that it seems that there might be some behavior where it will deliver before both promises are fulfilled (if they're getting fulfilled at all?). Since this worked while there was one Promise in the array, the difference could be trying to fulfill multiple.

Additionally the behavior seems to point to some caching happening in the watch communication where it will continue to use the last known value, as seen in updating while it was reporting accurately, and continuing to report that value even when manually changing it within home-assistant dev tools.

[bgoncal]

I was also testing the change and noticed the issue, I'll investigate during this week. Thanks for the very complete report.

[bgoncal]

Apparently sending WKInterfaceDevice.current().batteryState as enum was not working, so I update it to send as rawValue then I recreate it in iOS side, check PR above.

[bgoncal]

Testflight beta coming soon

[yyolk]

Apparently sending WKInterfaceDevice.current().batteryState as enum was not working, so I update it to send as rawValue then I recreate it in iOS side, check PR above.

Wow! Thanks for the insight. That makes a lot more sense than what I was thinking 🤔

I now see why passing WKInterfaceDevice.current().batteryState enum wouldn't work versus a primitive float value from the battery level now that we know it doesn't.

I got the latest TestFlight overnight 2024.9 (2024.813) and I can confirm I see both sensors are now working and reporting the values correctly.

Thank you for looking into it, explaining the issue, making the fix, merging it, and pushing out a new TestFlight build!