'handles'

[BertilJ]

Coming back with this error:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 121, in handle_call_service
    connection.context(msg))
  File "/usr/src/homeassistant/homeassistant/core.py", line 1150, in async_call
    self._execute_service(handler, service_call))
  File "/usr/src/homeassistant/homeassistant/core.py", line 1172, in _execute_service
    await handler.func(service_call)
  File "/usr/src/homeassistant/homeassistant/components/light/__init__.py", line 295, in async_handle_light_on_service
    await light.async_turn_on(**pars)
  File "/usr/src/homeassistant/homeassistant/components/group/light.py", line 176, in async_turn_on
    light.DOMAIN, light.SERVICE_TURN_ON, data, blocking=True)
  File "/usr/src/homeassistant/homeassistant/core.py", line 1150, in async_call
    self._execute_service(handler, service_call))
  File "/usr/src/homeassistant/homeassistant/core.py", line 1172, in _execute_service
    await handler.func(service_call)
  File "/usr/src/homeassistant/homeassistant/components/light/__init__.py", line 295, in async_handle_light_on_service
    await light.async_turn_on(**pars)
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/plejd/light.py", line 111, in turn_on
    plejd_write(pi, pi["handles"]["data"], plejd_enc_dec(pi["key"], pi["address"], payload))
KeyError: 'handles'

I had this working nicely, but now after the weekend it doesn't work any more. No config changes or updates, I did a restart today that's it. Hass.io on NUC.

MiFlora is up and running so Bluepy should be ok.

[klali]

Odd. Can you try it with the latest code on master? there's a couple of bugfixes but nothing touching this path I think.

[BertilJ]

I actually updated the code later yesterday evening and got it all working, but then today the issue was back. A restart of HA got things working again, so let's see for how long.

I'm using as said MiFlora as well that's using Bluepy, I'm throwing a guess that there may be a conflict if both components are calling it at the same time, since as far as I know BTLE is only working with one connection at the time.

But now I'm seeing a new error message:

Encountered bluepy internal error: 'Unexpected response (wr)'

[klali]

Yeah, I'm getting that bluepy warning as well things work mostly fine with it though.

Multiple connections shouldn't be an issue, the bluetooth stack should handle that fine.

I'm currently pondering alternatives to bluepy, I'm not terribly fond of the architecture with a helper program doing the calls, there seems to be issues with that interface as well and no fixes forthcoming.

I've started looking at https://github.com/getsenic/gatt-python which uses the dbus api for bluetoother which seems to be the preferred integration point to bluez. This doesn't seem terribly well maintained either though.

[BertilJ]

I think you understand that better than me. Doing some quick reading, it seems that the only other working integrations (BTLE) I'm able to find for HA is the Zengge lights that's using Bluepy, the MiFlora using Bluepy and Xiaomi BLE Temperature and Humidity sensor that seems to be using Bluepy in combination with btlewrap or as a fallback the gattool, but it also seems that gattool/bluez seems to be deprecated (may still work of course).

[BertilJ]

Doing some further reading I found this that seems to still be maintained. But I'm not sure if it is usable together with Hass.io.

https://github.com/nccgroup/BLESuite

[klali]

Yeah, that library might be an alternative as well, I'll have to take a look.

[BertilJ]

Now the original error came back again. Didn't do any config changes to the component, was only playing around with some automations using the plejd lights.

[BertilJ]

I think this one should be closed for now, I'm not able to reproduce on a regular base.

What I'm now doing is running MiFlora and BT tracker directly from my main installation on NUC and then running the plejd custom component on a pi and using that as a slave. That seems to give me the most stable behaviour. I've tried to move MiFlora as well to the pi, but that messes things up. So I would say that at this point it's not recommended to run MiFlora and Plejd at the same time since it creates a lot of strange behaviour.