You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been hacking at bluezero code attempting a port away from python-dbus and onto pydbus. I have some application successfully running on pydbus and thought I could bring that knowledge here. Unfortunately, the application is proprietary so I can't share it, but much of its structure is making its way as open source in the fork. If/when I get it the way I want it, I might port the app to use bluezero.
Pydbus in my experience works fine for a central device, but have big issues making it work as a peripheral or any exposed dbus service; something python-dbus does quite handily, as shown in the BlueZ examples. I believe it's due to having issues with a parallel service, such as DBus.ObjectManager along with org.bluez object paths. I spent days working this out but couldn't get pydbus to cooperate.
I also took the liberty of changing the GATT arguments a little, to avoid having duplicated Device instances inside each GATT service. This should be a level 100 change that shouldn't affect upper layer applications though.
Thanks to studying bluezero code and its testing structure, I got some experience with python testing that previously didn't have. I much appreciate the work that has gone into bluezero for this.
Unfortunately, until pydbus fixes its issues or someone finds a way to get it to work, the complete port to it will stall to the parts that don't properly work.
It will be interesting to see how things develop in this area.
I am going to close this issue as there is no immediate action required. Please feel free to open a new issue if/when you believe we should look at moving Bluezero to Pydbus.
Hi there,
I've been hacking at bluezero code attempting a port away from python-dbus and onto pydbus. I have some application successfully running on pydbus and thought I could bring that knowledge here. Unfortunately, the application is proprietary so I can't share it, but much of its structure is making its way as open source in the fork. If/when I get it the way I want it, I might port the app to use bluezero.
Pydbus in my experience works fine for a central device, but have big issues making it work as a peripheral or any exposed dbus service; something python-dbus does quite handily, as shown in the BlueZ examples. I believe it's due to having issues with a parallel service, such as DBus.ObjectManager along with org.bluez object paths. I spent days working this out but couldn't get pydbus to cooperate.
I also took the liberty of changing the GATT arguments a little, to avoid having duplicated Device instances inside each GATT service. This should be a level 100 change that shouldn't affect upper layer applications though.
Thanks to studying bluezero code and its testing structure, I got some experience with python testing that previously didn't have. I much appreciate the work that has gone into bluezero for this.
Unfortunately, until pydbus fixes its issues or someone finds a way to get it to work, the complete port to it will stall to the parts that don't properly work.
Thanks @ukBaz and all the contributors,
-Pat
The text was updated successfully, but these errors were encountered: