Unreliable connection

[Slion]

Even though the entity is shown as available, after switching that Living room light on and off a few times through Logitech Harmony remote it becomes unresponsive. Attached over 40 minutes of logs below:

awox-more-logs.txt

[Slion]

Yeah I can't use the Harmony remote more than a few times in a row after that I don't get any response anymore. Also somehow it queues the actions that was sent so 5 minutes later when comms are working again it starts sending it the queued commands and the light turns on and off seemingly at random until all queued commands are processed which can take a while since the connection is so unreliable.

[fsaris]

Will have a look if I can build a filter or something on queue to prevent double equal command to get queued up.

The unstable connection is also on my list. After processing a few command's the Bluetooth controller looks to freeze. And after a timeout it tries to reconnect. Not default to the same light but the first in the list of devices ordered by RSSI. This process can take some time when the RSSI values are not know. It will try each device until one connect's. I'm thinking of changing this to first try to reconnect with the last device before trying a different device

[Slion]

Will have a look if I can build a filter or something on queue to prevent double equal command to get queued up.

In my use case it does not make sense to have a queue. Either it works now or just give up on it. For some automation use case maybe it makes sense but for instant usage it does not. Maybe we need a configuration option for the queue behaviour.

The unstable connection is also on my list. After processing a few command's the Bluetooth controller looks to freeze. And after a timeout it tries to reconnect.

Is that an issue with Rpi3 drivers or the way this integration is using the BT stack?

This process can take some time when the RSSI values are not know. It will try each device until one connect's. I'm thinking of changing this to first try to reconnect with the last device before trying a different device

Yeah it seems a lot of time is spent trying to scan for devices which are offline anyway. In my case most devices should be offline most of the time. As it is in my configuration it's mostly unusable ATM. It's a very nice tech demo but unusable in real life situations.

There must be ways to improve the scanning efficiency. One easy workaround could be to specify in the configuration the devices we want to target. In my case I only really need 2 of them of 9. soo to be 11. I only want to control The living room and the entrance lights from the Harmony remote. I'm under the impression that could improve responsiveness a bit.

For the scan maybe you could start scanning for switch devices are those should really be plugged-in and powered whereas a lot of the lights go offline when the wall switch is flipped. At least that's my use case.

How did you implement it all in the first place? Did you reverse engineer the Android app? Are they using some well known BT protocol for the mesh?

Alternative could be to use the WiFi instead. Basically those plug switch also serve as WiFi bridge and even have Alexa integration. I'm thinking it might be easier for to control those lights through Alexa. I mean I already have the voice commands working but maybe I could run an Alexa skill from the Harmony button without having to use voice command.

See: https://community.home-assistant.io/t/triggering-an-alexa-skill-from-ha/354530

[fsaris]

In my use case it does not make sense to have a queue

I did not create of maintain the integration specially for you ;)

The queue is there for handling multiple commands in a row like controlling a group of lights.

Is that an issue with Rpi3 drivers or the way this integration is using the BT stack?

I noticed that when the Bluetooth controller has a weaker connection with the connected device it also gets more unstable. Got more reports that the Rpi Bluetooth controller gives issues. An external (USB) controller gives better results.

For the scan maybe you could start scanning for switch devices are those should really be plugged-in and powered whereas a lot of the lights go offline when the wall switch is flipped. At least that's my use case.

That will not work because maybe you have the plugs always powered on. And other have the ceiling lights always powered on and use the plugs only from time-to-time.

What I trying now (current main version) is to exclude the devices that went offline when trying to connect. And also all devices that were not found during scan.

How did you implement it all in the first place? Did you reverse engineer the Android app?

Parts are from https://github.com/Leiaz/python-awox-mesh-light and others from reverse engineering a previous version of the Awox Android app.

Are they using some well known BT protocol for the mesh?

It's bases on a propitiatory BLE mesh protocol. It's not the new BLE mesh protocol and they also didn't fully respect the normal BLE specifications https://github.com/hbldh/bleak/issues/972

Alternative could be to use the WiFi instead. Basically those plug switch also serve as WiFi bridge and even have Alexa integration. I'm thinking it might be easier for to control those lights through Alexa. I mean I already have the voice commands working but maybe I could run an Alexa skill from the Harmony button without having to use voice command.

I do not own a WIFI plug and not sure if it will be that faster as it uses 2 remote services (Alexa + Awox).

I'm currently trying to port the library to eshome to run it on a dedicated esp32 to function as a gateway.

[fsaris]

I released a new beta with some improvements https://github.com/fsaris/home-assistant-awox/releases/tag/0.1.4b2