Pixoo on HA-Core as Container / Connected but unable to send notifications

[MrSiO]

Hi.
I'm using the Pixoo on my HA-CORE installation (Docker-Compose).
Installation process went smoothly. Paired the Pixoo with success using the bluetoothctl command.
Then installed the integration via HACS. Device was seen and added.
In DEVELOPER TOOLS i'm trying to send notifications to: notify.divoom_pixoo
But it always fails with message:

Failed to call service notify.divoom_pixoo. Unknown error

I went to my HA container logs and found this weird log:

2024-04-14T21:30:47.860157554Z 2024-04-14 17:45:47.859 WARNING (SyncWorker_21) [custom_components.divoom] Pixoo: connection lost (errno = 97). Trying to reconnect for the 1 time. 2024-04-14T21:30:47.861277139Z 2024-04-14 17:45:47.860 WARNING (SyncWorker_21) [custom_components.divoom] Pixoo: connection lost (errno = 97). Trying to reconnect for the 2 time. 2024-04-14T21:30:49.862110176Z 2024-04-14 17:45:49.861 WARNING (SyncWorker_21) [custom_components.divoom] Pixoo: connection lost (errno = 97). Trying to reconnect for the 3 time. 2024-04-14T21:30:52.863192996Z 2024-04-14 17:45:52.861 WARNING (SyncWorker_21) [custom_components.divoom] Pixoo: connection lost (errno = 97). Trying to reconnect for the 4 time. 2024-04-14T21:30:56.863818226Z 2024-04-14 17:45:56.862 WARNING (SyncWorker_21) [custom_components.divoom] Pixoo: connection lost (errno = 97). Trying to reconnect for the 5 time.

I fond this link as a guide on how to format my notification... are they reliable?
https://user-images.githubusercontent.com/1483070/151658085-fa078b40-20c5-48f3-b7ac-9a3ad887e0b0.png
https://user-images.githubusercontent.com/1483070/151658110-40e7f945-edb2-4c5e-bd0c-3d3c920d8f45.png

Any ideas what might be wrong?

Running latest HA-CORE
Intel NUC with external BT dongle
Docker Compose (Network mode)

[d03n3rfr1tz3]

looks good so far. even the lost connection error is shows, that its fine so far. if you really have a Pixoo (and not a Ditoo or something like that), it should also not be a problem of using the correct port. therefore I currently see two possibilities:

1. your HA with the BT dongle is too far away (or has to much interference, for example caused by USB3) from your divoom device
2. your phone is connected to your divoom device (paired is fine), loses connection when HA connects and then tries to reconnect, which might kick HA again.

try to move your divoom device closer to HA, manually disconnect (not unpair, just disconnect) your phone for a moment and maybe even try another port (default is 1, but for divoom devices with audio support, a different port like 2 might be the right one). then report, if you cannot get any command to work or if its just not stable.

and yes, these screenshots are accurate. even though they use the older "format", that is still supported and should work.

[d03n3rfr1tz3]

hold on, if its not a typo, you might have a bigger problem.

Errno 97 is Address family not supported by protocol. the actual reason for that is hard to guess, but if you are sure you did not mistype your MAC address and such, it might just be your bluetooth dongle. maybe it does not support the bluetooth version (3.0 afaik).

[MrSiO]

Thx for your quick response. The MAC is the right one. I'm paired and see the Pixoo in my paired device list with the right MAC address. My dongle is old... If it's not 3.0, I would still be able to pair but not transfer data? That could explain what is going on. I'll put my hands on a 3.0 dongle and try. Will get back to you. Thx!

…

On Tue., Apr. 16, 2024, 18:41 Dirk Sarodnick, ***@***.***> wrote: hold on, if its not a typo, you might have a bigger problem. Errno 97 is Address family not supported by protocol. the actual reason for that is hard to guess, but if you are sure you did not mistype your MAC address and such, it might just be your bluetooth dongle. maybe it does not support the bluetooth version (3.0 afaik). — Reply to this email directly, view it on GitHub <#30 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL4PN4DHB5DCICH4TQYZRNLY5WSITAVCNFSM6AAAAABGKEZXIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRQGAZDONBQGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[d03n3rfr1tz3]

As the onboard Bluetooth of a Raspberry Pi (which I use) supports Bluetooth 5.0, I'd say any modern BT dongle should work, but I'm not fully sure. maybe a look into the supported dongles list of the HA documentation helps: https://www.home-assistant.io/integrations/bluetooth/#known-working-high-performance-adapters

Before buying new stuff, I would recommend manually connecting to your divoom device with rfcomm. for example like this:
rfcomm connect DEVICE MAC PORT
rfcomm connect hci0 12:34:56:78 1

if the connection works, try to send some random stuff. you can even try the following valid command, which should switch to the clock in 24h mode, first clock design, no weather, no temp, no calendar, red numbers and some other options I'm not sure right now.
010d004500010001000000ff0000530102

you can get more valid commands by activating debug-mode for the component and copying the codes it tries to send (you just have to remove the spaces). if really none of them work, it might actually be a hardware problem.

[MrSiO]

@d03n3rfr1tz3 Thx!
But it looks the problem might be deeper... tried using rfcomm to see it is helped, and look at the error I got:

a185c64fb994:/config# hciconfig -a Can't open HCI socket.: Address family not supported by protocol a185c64fb994:/config# rfcomm Can't open RFCOMM control socket: Address family not supported by protocol

Might be on to something

[d03n3rfr1tz3]

yep, thats the same error. you might be lucky and it's just a software problem. I'm not fully into debugging linux stuff especially from remote, but you need to make sure you have the correct modules activated in your kernel, as far as my googling skills brought me 😉

try lsmod | grep bluetooth and look if rfcomm and l2cap are in the response. another thing might be, that you need to run the docker container in privileged mode. there are a lot of other results I found, so maybe its not the dongle 🤞

EDIT: this might be a good read, because it sounds quite similar: moby/moby#16208
as the home assistant image should have bluez installed and all that, it might actually just be the privileged mode.

[MrSiO]

Thx.

I hope --net=host isn't the only solution because I can't use it. I'm not using the host network but static IP address per containers on VLANS.

Eg. from my HA Docker-Compose:
networks: VLAN-IOT: ipv4_address: 10.10.110.15

I will check how I can install BlueZ on it.
Otherwise I hope I could manage to use a Bluetooth Proxy maybe... ESPHome has a module using a Wemos or NodeMCU...

https://esphome.io/components/bluetooth_proxy.html?highlight=proxy

I'll keep you updated!
Thx alot

[d03n3rfr1tz3]

sadly a Bluetooth Proxy wouldnt help. These Bluetooth Proxies only support Bluetooth Low Energy (BLE) and not Bluetooth Classic. the Divoom devices use Bluetooth Classic for the communication part. therefore it's currently not an option.

do you have privileged: true in your Docker-Compose? if not, try that... maybe that already works.

[MrSiO]

Hi. Ya already in privileged mode. I will try pairing the Pixoo from the host itself and not from ha container... Pretty much my last try.

…

On Wed., Apr. 17, 2024, 02:08 Dirk Sarodnick, ***@***.***> wrote: sadly a Bluetooth Proxy wouldnt help. These Bluetooth Proxies only support Bluetooth Low Energy (BLE) and not Bluetooth Classic. the Divoom devices use Bluetooth Classic for the communication part. therefore it's currently not an option. do you have privileged: true in your Docker-Compose? if not, try that... maybe that already works. — Reply to this email directly, view it on GitHub <#30 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL4PN4FCAONASZYGKEZMQE3Y5YGUJAVCNFSM6AAAAABGKEZXIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRQGQ2DQMZRHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[MrSiO]

lsmod | grep bluetooth

RFCOMM and L2CAP arent listed ??

HA-CORE$ lsmod | grep bluetooth bluetooth 557056 24 btrtl,btintel,btbcm,bnep,btusb ecdh_generic

[d03n3rfr1tz3]

try modprobe rfcomm first. that should theoretically add the module to the kernel. if there is an error, we have to see, if and how we can fix it. if there is no error, lsmod | grep bluetooth should hopefully list rfcomm now. try connecting and sending stuff again.

same goes for modprobe l2cap, but try it without first.

[MrSiO]

I tried an L2PING experiment.
From my host, no problem. I can ping the Pixoo:

sudo l2ping 11:75:58:XX:XX:XX 44 bytes from 11:75:58:xx:xx:xx id 0 time 11.19ms 44 bytes from 11:75:58:xx:xx:xx id 1 time 31.02ms 44 bytes from 11:75:58:xx:xx:xx id 2 time 47.30ms 44 bytes from 11:75:58:xx:xx:xx id 3 time 23.67ms 4 sent, 4 received, 0% loss

But same ping from container:

3baxb4x1s513:/config# l2ping 11:75:58:xx:xx:Xx Can't create socket: Address family not supported by protocol

And from the documentation I found, seems I wont be able to get this to work without network_mode:host
https://forums.balena.io/t/bluetooth-within-docker-compose/3460/8

Is there any know workaround, or even a piece of hardware to bridge BT devices?
Maybe some device (RPi) that could bind to the Pixoo and my MQTT server so HA could control the Pixoo trough MQTT?

Idea ideas are welcome.

[d03n3rfr1tz3]

That's unfortunate. Well, I don't know about any BT hardware for bridging, but in the worst case (and if you are really that desperate), you could run a second HA on a RPi). You could also have a closer look into how the default HASS.io setup (which also uses docker) is different from yours, in hope there is still something we missed (besides the network_mode of course).

But you might also just wait a little bit. Theoretically I'm currently testing if and how good an ESP32 based Bluetooth (Classic) Proxy works. The code was nearly done a few days ago and needs an initial test. If that test is successful, like connecting to WiFi and BT simultaneously and passing commands (through TCP or maybe even MQTT) in any way (raw bytes preferred to make it reusable for other purposes) without losing connections and stuff, I could develop some sort of firmware for an ESP32. That firmware could specifically work with my Divoom custom component as a BT Proxy alternative (instead of connecting to it directly). The thing is, it's so simple, that I'm wondering why nobody else has done it to date (and why ESPHome does not support it) and therefore I'm somehow a bit skeptical, if it actually works.... and that's why I did not mention it until now.

Again, IF that works. I might even use it myself then, because that would allow me to move my Ditoo around more freely while still having a few things (like daylight saving times or current weather) automated through HA. Currently these automations only work if that Ditoo is near my HA RPi and obviously also not in use.

[MrSiO]

Thx I found on HACS an integration called "Remote-Assistant" that connects two HA and shares its entities. So I'll try that using a RPi. Thx for your support.

…

On Wed., Apr. 17, 2024, 21:51 Dirk Sarodnick, ***@***.***> wrote: That's unfortunate. Well, I don't know about any BT hardware for bridging, but in the worst case (and if you are really that desperate), you could run a second HA on a RPi). You could also have a closer look into how the default HASS.io setup (which also uses docker) is different from yours, in hope there is still something we missed (besides the network_mode of course). But you might also just wait a little bit. Theoretically I'm currently testing if and how good an ESP32 based Bluetooth (Classic) Proxy works. The code was nearly done a few days ago and needs an initial test. If that test is successful, like connecting to WiFi and BT simultaneously and passing commands (through TCP or maybe even MQTT) in any way (raw bytes preferred to make it reusable for other purposes) without losing connections and stuff, I could develop some sort of firmware for an ESP32. That firmware could specifically work with my Divoom custom component as a BT Proxy alternative (instead of connecting to it directly). The thing is, it's so simple, that I'm wondering why nobody else has done it to date (and why ESPHome does not support it) and therefore I'm somehow a bit skeptical, if it actually works.... and that's why I did not mention it until now. Again, *IF* that works. I might even use it myself then, because that would allow me to move my Ditoo around more freely while still having a few things (like daylight saving times or current weather) automated through HA. Currently these automations only work if that Ditoo is near my HA RPi and obviously also not in use. — Reply to this email directly, view it on GitHub <#30 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL4PN4EQBNNISEPMZ2WLTRLY54RJJAVCNFSM6AAAAABGKEZXIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRSHA2DSMRWGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[MrSiO]

hi @d03n3rfr1tz3
Got this working yesterday in an odd way but it does work!

1. Used a RPi3 as a second HA Instance and installed and tested "hass-divoom" with success
2. Installed on my main HA instance and Second instance Home-Assistant-Remote and linked both together.

From the MAIN instance I now see my second instance "ha2_notify.divoom_pixoo" entity and using developper i'm now able to send command to my Pixoo!

Thx alot!!!
Great stuff!

[d03n3rfr1tz3]

Nice! Good job! I'm happy to hear, that it works for you now.

Nevertheless I might have some good news. Remember the ESP32 proxy I mentioned? Since today I have it in a state, where I can say, that it works. It's still WIP and partially untested, but the important part (passing raw bluetooth packets through tcp via wifi into the divoom device) works. You could replace your second HA instance with a cheaper ESP32 in the near future. 😉

Support for MQTT as communication protocol is also planned. Therefore this firmware could even be used standalone, without the need of my HA integration. But currently I'm focusing on the proxy part for my HA integration (including auto-discovery), which works via TCP.

The ESP32 firmware (PlatformIO Project): https://github.com/d03n3rfr1tz3/esp32-divoom
The branch on HASS-Divoom with support for it: https://github.com/d03n3rfr1tz3/hass-divoom/tree/feature/esp32-divoom

[MrSiO]

That's great news! I have NodeMCU units laying around I could use! I'll try it. And MQTT support would be the best! I got Mosquito running here would love to try it too! Would you consider adding another TODO to your list? :) How about creating a Node-Red node for easy integration to node-red? Thx for your support and keep us posted!

…

On Tue., Apr. 23, 2024, 20:53 Dirk Sarodnick, ***@***.***> wrote: Nice! Good job! I'm happy to hear, that it works for you now. Nevertheless I might have some good news. Remember the ESP32 proxy I mentioned? Since today I have it in a state, where I can say, that it works. It's still WIP and partially untested, but the important part (passing raw bluetooth packets through tcp via wifi into the divoom device) works. You could replace your second HA instance with a cheaper ESP32 in the near future. 😉 Support for MQTT as communication protocol is also planned. Therefore this firmware could even be used standalone, without the need of my HA integration. But currently I'm focusing on the proxy part for my HA integration (including auto-discovery), which works via TCP. The ESP32 firmware (PlatformIO Project): https://github.com/d03n3rfr1tz3/esp32-divoom The branch on HASS-Divoom with support for it: https://github.com/d03n3rfr1tz3/hass-divoom/tree/feature/esp32-divoom — Reply to this email directly, view it on GitHub <#30 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL4PN4EHQHEIYSLNSNLHCSDY637ALAVCNFSM6AAAAABGKEZXIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZTG42TGOBWG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[d03n3rfr1tz3]

There you go. You can have a look, if you want.

The proxy variant supports the same modes as the direct connection, including sending images. The reason is simple: It just passes through all the TCP packets directly to the Bluetooth output. Next to no processing needed.

MQTT is also supported, but a bit limited. Biggest limitation is, that you cannot send images through MQTT, because of multiple size and memory limitations.

Notice: do not have your HA and that ESP32 both have a Bluetooth connection to your Divoom device. They would battle for the limited amount of connections.

Regarding Node-Red I have to say, that I never used it myself, which means I have exactly zero experience with it. Therefore, chances are quite low, that I will make a Node for it. I already invested quite much time into the HA integration as well as the ESP32 bluetooth proxy.
Regarding the problem you mentioned with Node-Red and the weather mode: Both parameters for the weather mode accept a string. The actual temperature needs a unit (°C or °F) anyway, so its already a string. The type of weather is an int in the examples, but can also be passed as a string and will automatically be converted. So it doesnt matter if it's weather: 1 or weather: "1" for a clear sky weather.

[MrSiO]

Hi!
My issue about the weather has been resolved. It was a technicality in Node-Red that I was finaly able to fix.

I'm about to try your ESP32 proxy, but there is one thing I could not find in your documentation.

How is it integrated into HA/your integration?
Will the proxy be automatically discovered from your integration (if the proxy is on the same LAN as your HA)?
(seems almost to good to be true).

Thx for more details on this.

Site question: Should a "Wemos D1 mini" or "NodeMCU" both work the same or you have other recommendation?

[d03n3rfr1tz3]

Exactly, it will be auto-discovered. And by "it" I mean the actual Divoom device, that the ESP32 proxy found. It will automatically be configured to use the Proxy.

If you want to manually configure it to use the proxy, you just have to fill the new host configuration value. There is even an example in the readme ☺️

notify:
  - name: Divoom Ditoo
    platform: divoom
    host: "192.168.0.123"
    mac: "12:34:56:78:9A"
    port: 2
    device_type: "ditoo"
    media_directory: "pixelart"
    escape_payload: false

Should not really matter, which ESP32 you are using. I have a few different ones and mostly tested on a NodeMCU (don't even know which concrete version). As this project does not really use anything related to the actual Dev Board, you could even use a bare ESP32 Chip, because everything it needs is in there.
Beware: Do not confuse them with the newer ESP32-*, like ESP32-S2 or ESP32-S3. Those might also work, but you have to make sure it actually has Bluetooth. The ESP32-S2 for example does not have Bluetooth. And as I currently do not have one of these, I'm not even completely sure, if they work with the Bluetooth Serial thing this project needs.
Also make sure, that your "Wemos D1 mini" is actually an ESP32. I also have a few Wemos D1 mini, but those are all ESP8266. And those ESP8266 also do not have Bluetooth sadly.