No indeed, the presence of a device is not managed, nor is the presence of a user via a device… it’s quite limited for the moment: battery level and temperature if thermometer… but it mainly paves the way for other more specific services.
Oops, I missed that one. No, I don’t know, I haven’t investigated this point. That doesn’t stop me from doing it. I’ll still monitor the developments on the library and see new features and fixes being integrated.
I invite you to create a dedicated topic in the dev category if needed. I am closing this feature request to release the voting tokens.
I’m taking up the topic of the Bluetooth bug (tracked in a topic « Bluetooth: Xiaomi »).
After some exchanges, the problem was due to a custom Docker image not having the correct parameter --network=host.
So problem solved.
Note that this information is written in the README (in the Bluetooth service).
Ok, good to know!
Wouldn’t it be worth adding a warning banner in the Bluetooth service if this is not the case? (the container is not in NetworkMode=host?)
Not stupid, but maybe low-effort. But we can keep this in the backlog 
Or disable the service if docker and if network is not in host mode
This could significantly slow down the app’s startup…
Mm that’s true
A first step is to communicate at least in the UI, currently the user is a bit lost.