Intermittent error when turning on/off

[2m]

Thank you very much for this integration! This is one more reason Home Assistant is so great for these custom integrations. :)

Sometimes I get the following error when turning basestation on or off:

But after trying again once, or sometimes a couple of times, the operation eventually does not emit this error and then basestation turns on/off.

Maybe just retrying on such error a couple of times could solve this?

[neothermic]

Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 401, in async_update_ha_state await self.async_device_update() File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 609, in async_device_update raise exc File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 52, in run result = self.fn(*self.args, **self.kwargs) File "/config/custom_components/basestation/switch.py", line 57, in update self._device.connect() File "/usr/local/lib/python3.9/site-packages/basestation/device.py", line 17, in connect self.client.connect(self.mac, ADDR_TYPE_RANDOM) File "/usr/local/lib/python3.9/site-packages/bluepy/btle.py", line 445, in connect self._connect(addr, addrType, iface) File "/usr/local/lib/python3.9/site-packages/bluepy/btle.py", line 439, in _connect raise BTLEDisconnectError("Failed to connect to peripheral %s, addr type: %s" % (addr, addrType), rsp) bluepy.btle.BTLEDisconnectError: Failed to connect to peripheral xx:xx:Xx:Xx:Xx, addr type: random

Full traceback, i just installed and experience the same issue, except it's at the wrong end of intermittent. Maybe one in every 10 attempts is successful in controlling the lighthouse.

[ZetaPhoenix]

I'm not having any issues with turning on and off the basestations but I am seeing a ton of errors in the logs (400 errors in 12 hours):

Logger: homeassistant.helpers.entity
Source: custom_components/basestation/switch.py:57
Integration: basestation (documentation, issues)
First occurred: August 16, 2021, 11:46:14 PM (389 occurrences)
Last logged: 11:07:18 PM

    Update for switch.lhb_2 fails
    Update for switch.lhb_1 fails

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 446, in async_update_ha_state
    await self.async_device_update()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 654, in async_device_update
    raise exc
  File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 52, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/basestation/switch.py", line 57, in update
    self._device.connect()
  File "/usr/local/lib/python3.9/site-packages/basestation/device.py", line 17, in connect
    self.client.connect(self.mac, ADDR_TYPE_RANDOM)
  File "/usr/local/lib/python3.9/site-packages/bluepy/btle.py", line 445, in connect
    self._connect(addr, addrType, iface)
  File "/usr/local/lib/python3.9/site-packages/bluepy/btle.py", line 439, in _connect
    raise BTLEDisconnectError("Failed to connect to peripheral %s, addr type: %s" % (addr, addrType), rsp)
bluepy.btle.BTLEDisconnectError: Failed to connect to peripheral EF:4D:2B:21:xx:xx, addr type: random

[2m]

Yup, I also see these errors in the logs, even if I have not been using basestation switches for a while now.

[jariz]

Hi! I personally had homeassistant running on a raspberry pi that was in the same room as the basestations, but yes, I also noticed it logging some errors at times, however using the integration itself from homeassistant was generally not a problem (I didn't get any errors in the interface).

We can do a bit more retries, or not log at all (at the very least a bit more discreetly) but there's only 1 real practical solution to this, which is placing the homeassistant instance closer to the basestations. As mentioned in the README, "BLE does not communicate well over long range."

Lastly, if you don't want to move your homeassistant machine and instead make the communication happen on a separate machine, we'll have to think about writing a separate app that uses MQTT for example to be controlled by homeassistant, which was one of my long term goals.

But for the short term, let's add the things suggested here:

• retry for at least 3 times
• ignore errors and log them as warnings if all 3 retries fail (?) - not 100% sure about this one.

[2m]

Lastly, if you don't want to move your homeassistant machine and instead make the communication happen on a separate machine, we'll have to think about writing a separate app that uses MQTT for example to be controlled by homeassistant, which was one of my long term goals.

Actually this was how I initialy was thinking about controlling basestations. But then I found this integration. :)

I was considering ESPHome for this. They have BLE Client out of the box: https://esphome.io/components/ble_client.html?highlight=ble that should be able to be configured to work with basestations.

[jariz]

ESPhome is interesting! I guess i'm ordering a board now... Seems like you can probably do this entirely from config, with a couple of lambda's to interpret the data correctly. https://esphome.io/components/esp32_ble_tracker.html#on-ble-service-data-advertise

Not entirely sure if writing to it (switch) is also supported though.

[2m]

Yup, ESPHome is great! I have been deploying multiple sensors with it, and only a simple config is needed. Some example configurations (not using BLE though) from my devices: https://github.com/samanos/esphome-devices

Yea, I can not see anything related to "write" functionality in the ESPHome docs. But I found an external component that supports it: https://github.com/wifwucite/esphome-ble-controller

[jariz]

Nice find! This however seems to be for a situation where you want a BLE "server" so you can control other ESPHome entities from a BLE client.

I have found this: https://github.com/shmuelzon/esp32-ble2mqtt, which appears to be bidirectional. But it's a firmware on it self, meaning you can not use ESPHome also on the same board.

[ZetaPhoenix]

Jariz,

I also have the system with the bluetooth adapter located in the same room as the base stations both with a near LOS to the adapter so something else may need to be looked at. The EPHome seems like a neat trick if you do not have it locally but it seems like a waist of power to need to do this if they are in the same area.

[jariz]

@ZetaPhoenix i've already made suggestions on how to improve this in this library, see above. ESPhome is just another way of doing this (and out of the scope for this project, obviously).

Additionally we can maybe use notifications instead of polling which might be less error prone because the basestations do appear to be supporting this.

[jariz]

@2m I wrote a blogpost on how to use ESPHome here, if you're interested: https://blog.jari.io/tracking-valve-index-basestation-power-state-with-esphome/

[ZetaPhoenix]

@jariz any updates on masking some of the errors? The reason for using this over an ESP is then (at the moment) I can turn off the base stations remotely.

I have had them randomly turn on and want to have the ability to shut them off without dragging the PC back to the VR setup or going and unplugging them from the wall.

[2m]

Just a note that I am still using this integration as opposed to the ESP Home solution (with read and write functionality), because ESP Home is keeping the BLE connection alive preventing Steam VR or the Lighthouse Power Management from connecting to the base stations.

ESP Home improvement that would have prevented this issue was not merged: https://github.com/esphome/esphome/pull/3434