core: Setting up Aranet devices broken with Bluetooth proxies that don't provide device names fails

The problem

After updating to 2023.11.0 my Aranet 4 CO2 sensor stopped working. It is connected using an ESPHome Bluetooth Proxy. The problem still exists on latest 2023.11.2.

Trying to set up the integration again produces this error in the UI:

Config flow could not be loaded: 500 Internal Server Error Server got itself in trouble

Full log entry is attached.

What version of Home Assistant Core has the issue?

core-2023.11.2

What was the last working version of Home Assistant Core?

core-2023.10.x

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Aranet

Link to integration documentation on our website

https://www.home-assistant.io/integrations/aranet/

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

2023-11-16 10:56:32.786 ERROR (MainThread) [aiohttp.server] Error handling request
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py", line 433, in _handle_request
    resp = await request_handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_app.py", line 504, in _handle
    resp = await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_middlewares.py", line 117, in impl
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 85, in security_filter_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 94, in forwarded_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 28, in request_context_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 80, in ban_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 236, in auth_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/headers.py", line 31, in headers_middleware
    response = await handler(request)
               ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 148, in handle
    result = await handler(request, **request.match_info)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/decorators.py", line 63, in with_admin
    return await func(self, request, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 147, in post
    return await super().post(request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 72, in wrapper
    result = await method(view, request, data, *args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py", line 71, in post
    result = await self._flow_mgr.async_init(
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 880, in async_init
    flow, result = await task
                   ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 908, in _async_init
    result = await self._async_handle_step(flow, flow.init_step, data)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 389, in _async_handle_step
    result: FlowResult = await getattr(flow, method)(user_input)
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/aranet/config_flow.py", line 99, in async_step_user
    adv = Aranet4Advertisement(
          ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aranet4/client.py", line 250, in __init__
    if device.name.startswith("Aranet2"):
       ^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'startswith'

Additional information

No response

About this issue

  • Original URL
  • State: open
  • Created 7 months ago
  • Comments: 16 (7 by maintainers)

Most upvoted comments

I’m going to reopen this because it’s pretty clear there has been a regression in practice, and there are multiple ways to run into this issue. (Not to mention that we shouldn’t throw 500 errors even if there’s a workaround.) I don’t think it’s necessarily any particular person’s fault, it just slipped into the gaps between the Aranet4-Python library’s expectations and what Home Assistant provides, but we ought to be able to fix it.

There’s a bit of discussion in https://github.com/Anrijs/Aranet4-Python/pull/35 about how we might be able to do that, and if I get some time this evening I’ll try to submit a different PR there to update that code and make it not dependent on having a device name. Hopefully that’ll be a quick fix and we can bump Aranet4-Python and everything will Just Work. If not, I guess we can explore alternative solutions.

(Of course, figuring out how to get device names back from Shelly Bluetooth proxies might be handy for other reasons, but that’s well outside the scope of this issue.)

@home-assistant reopen @home-assistant rename Setting up Aranet devices broken with Bluetooth proxies that don’t provide device names

@aschmitz For completeness, my old config looked like this:

esp32_ble_tracker:
  scan_parameters:
    active: false

bluetooth_proxy:

It worked again after just setting scan_parameters.active to true.

The ESPHome docs make it sound like a good idea go to passive, provided it works:

active (Optional, boolean): Whether to actively send scan requests to request more data after having received an advertising packet. With some devices this is necessary to receive all data, but also drains those devices’ power a bit more. Some devices don’t need this, in that case you can save power and RF pollution by setting it to false. Defaults to true.

I believe I initially paired the devices in active mode, then set it to passive. A year later, obviously, I forgot about that and by happenstance the device got unpaired somehow, which I mistakenly correlated to the upgrade of HA/ESPHome.