The interesting part is MANY of sensors are getting populated with data.
Unexpected error fetching subscription_update_coordinator data: Error code 293
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py”, line 191, in _async_refresh
self.data = await self._async_update_data()
File “/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py”, line 150, in _async_update_data
return await self.update_method()
File “/usr/src/homeassistant/homeassistant/components/withings/common.py”, line 663, in async_subscribe_webhook
return await self._do_retry(self._async_subscribe_webhook)
File “/usr/src/homeassistant/homeassistant/components/withings/common.py”, line 659, in _do_retry
raise exception
File “/usr/src/homeassistant/homeassistant/components/withings/common.py”, line 648, in _do_retry
return await func()
File “/usr/src/homeassistant/homeassistant/components/withings/common.py”, line 705, in _async_subscribe_webhook
await self._hass.async_add_executor_job(
File “/usr/local/lib/python3.9/concurrent/futures/thread.py”, line 58, in run
result = self.fn(*self.args, **self.kwargs)
File “/usr/local/lib/python3.9/site-packages/withings_api/init.py”, line 348, in notify_subscribe
self.request(path=self.PATH_NOTIFY, params=params)
File “/usr/local/lib/python3.9/site-packages/withings_api/init.py”, line 115, in request
return response_body_or_raise(
File “/usr/local/lib/python3.9/site-packages/withings_api/common.py”, line 830, in response_body_or_raise
raise InvalidParamsException(status=status)
withings_api.common.InvalidParamsException: Error code 293
Also one of the most basic senors of in_bed does work and just says unavailable.
There’s an issue with withings in 2022.6.x (it has not been fixed as of .6). I’d also bet money your a Nabu Casa user.
Something changed in HA that withings didn’t expect. It misreports the external endpoints for webhooks. (see your log post…)
Essentially it broke authentication with Withings and things that use webhooks (like your bed sensor) broke. (both of mine did too)
Current workaround if you’re a Nabu Casa user is to go to the Settings panel where the external URL is set and UNCHECK use Nabu CASA, then when doing that opens the text box for your url, put in your external Nabu Casa URL. (yes seems lame, I know).
I have 2 sensors each exhibiting a different behavior:
The first still does what it has done for the past 6 months… it shows as needing reconfiguration ALL the time, but it actually works. If you lie on the bed for at least 10 seconds, it lights up as presence detected in HA and automations work based on it.
The second, though, just shows unavailable no matter what. I can’t see how it would be an HA/Nabu Casa/Webhook thing if 1 is working since none of that is configured on a device-by-device basis.
The in bed sensor is the only sensor solely relyant on webhooks. The other also get populated by polling if the webhooks are either turned off or do not work. The in bed sensor is unavailable until the first successful webhook after a reboot.
If webhooks work but the token cannot be refreshed, I expect you could have what you describe.
Do note that since 2022.6 the return url has changed due to the new oauth support, according to the docs. I needed to supply the new return url in Neato developer settings to get that to refresh the token. Maybe Withings has the same problem, because the return url needs to be set in the Withings App in the Withings Developer portal. It used to check that, so likely they now no longer match.
The need to specify the external url in configuration.yaml was a bug that existed long before 2022.6, so I do not think that was introduced lately. It used to be mentioned in the dos as a requirement. The new Oauth stuff was new in 2022.6, so personally I think the new return url is the cause. I hope that new return url does not mess up the webhooks too.