missing 3 required positional arguments: 'name', 'adapter', and 'stay_connected'

[fightforlife]

After a fresh install of this integration on Home Assisstant 2024.2.0b4 in Docker with an ESPhome BTproxy I always get the following error with v1.1.6:

2024-02-10 19:58:34.280 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Heizung Badezimmer for eq3btsmart
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 442, in async_setup
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/eq3btsmart/__init__.py", line 78, in async_setup_entry
    thermostat_config = ThermostatConfig(
                        ^^^^^^^^^^^^^^^^^
TypeError: ThermostatConfig.__init__() missing 3 required positional arguments: 'name', 'adapter', and 'stay_connected'

with v1.1.5 it changes to:

TypeError: ThermostatConfig.__init__() missing 2 required positional arguments: 'adapter', and 'stay_connected'

I think this is because of the cahnge added in v1.1.1

[EuleMitKeule]

Hey, thanks for trying out the integration. The custom component currently is not working since I was working on merging the integration into core. The integration will be included in Home Assistant 2024.3 and will be removed from this repository. See https://github.com/home-assistant/core/pull/109291

[EuleMitKeule]

If you want to try out the integration before 2024.3, you could copy the homeassistant/components/eq3btsmart from that PR into your custom_components directory and add "version": "0.0.1" to the manifest.json for it to be loaded.

[fightforlife]

I just tried it a few minutes using your workaround. But I do not think it is working as expected.

There is only one field (without any descriptions) which allows me to add the mac adress. If mac is added 1 device with 1 climate entity is created. There are none additional entities (like in the custom component) and there is also no way to configure the device (polling intervall, shown temps, etc..) All of this is most likely because of using it as a custom component (workaorund), so I will just wait for the beta release.

But I think there might be another problem, that I aslo noticed when using you (real) custom component. The first 3 devices/ble connectiosn work fast and reliable. But I am not able to connect to more thermostats. This is most likely because the esphome ESP32 Bluetooth proxy only allows 3 active connections in parallel. Maybe the standard poll frequecy is too high, or you keep the connections active all the time. But the 4th and 5th thermostat I add will never report any info. If I remove any one of the first three, the 4th will update its info.

[EuleMitKeule]

There is only one field (without any descriptions) which allows me to add the mac adress.

True, because more is not needed to manually configure a thermostat. I got told to remove the device name, because you can simply rename the device using the builtin functionality of Home Assistant.

There are none additional entities

I am only allowed to add a single platform (climate, sensor, etc.) per pull request, that's why currently only the climate entity is implemented. The other entities will follow in separate PRs.

there is also no way to configure the device

The options flow (Configure menu) also requires a separate PR and will be added after the main PR is merged.

All of this is most likely because of using it as a custom component

No, all of this is actually intented due to the reasons described above.

But I am not able to connect to more thermostats. This is most likely because the esphome ESP32 Bluetooth proxy only allows 3 active connections in parallel.

True, the BLE proxies only allow three simultaneous connections. We need to keep the connection open for the thermostats to not deactivate their bluetooth radio and go completely unavailable for ~1 minute every ~5 minutes.

Maybe the standard poll frequecy is too high, or you keep the connections active all the time.

Both true, but the poll frequency also needs to be so small for the thermostats not to deactivate their radio.

When the options flow is added in the next PR it will be possible to configure the poll frequency and which adapter is used to connect with the thermostats. I might also re-add the option to not keep the connection open, but this will take some work in the library as well.

[EuleMitKeule]

The benefit of the scan interval and the open connection is that the thermostats should now be online and updating the entity's state 24/7 without any disconnects.

[fightforlife]

Thank you very much for the detailed answers! I think I understood everything and will follow your progress in these points.