Skip to content

Use Python dbus-next D-Bus library#3234

Merged
agners merged 35 commits into
home-assistant:mainfrom
agners:use-python-dbus-next
Oct 18, 2021
Merged

Use Python dbus-next D-Bus library#3234
agners merged 35 commits into
home-assistant:mainfrom
agners:use-python-dbus-next

Conversation

@agners

@agners agners commented Oct 15, 2021

Copy link
Copy Markdown
Member

Proposed change

Use dbus-next library to communicate with D-Bus. dbus-next is a pure Python 3 library, supporting the asyncio main loop.

Tested & working:

  • Supervisor startup, loading properties from all kinds of D-Bus services like Systemd, NetworkManager, OS Agent etc
  • Waiting for signal, tested with Rauc OS update installation
  • NetworkManager update interface configuration

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New feature (which adds functionality to the supervisor)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Additional information

  • This PR fixes or closes issue: fixes #
  • This PR is related to issue:
  • Link to documentation pull request:
  • Link to cli pull request:

Checklist

  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • The code has been formatted using Black (black --fast supervisor tests)
  • Tests have been added to verify that the new code works.

If API endpoints of add-on configuration are added/changed:

@agners agners mentioned this pull request Oct 15, 2021
12 tasks
@agners agners added the refactor A code change that neither fixes a bug nor adds a feature label Oct 15, 2021
Comment thread Dockerfile Outdated
@agners agners requested a review from pvizeli October 15, 2021 20:48

@pvizeli pvizeli left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to make sure that the error handling is 100% good, otherwise, we can run into boot loops. I already tried to replace the gdbus with a different library as you now use, but I was forced to stop my work on the branch because of a bad design with error handling on that library. This looks better, we need just make sure it works stable on a system with issues. We have also to cleanup the docker file and not install gdbus, and make sure we don't check this on bootstrap

Comment thread supervisor/utils/gdbus.py
Comment thread supervisor/utils/gdbus.py Outdated
@agners

agners commented Oct 18, 2021

Copy link
Copy Markdown
Member Author

We need to make sure that the error handling is 100% good, otherwise, we can run into boot loops. I already tried to replace the gdbus with a different library as you now use, but I was forced to stop my work on the branch because of a bad design with error handling on that library. This looks better, we need just make sure it works stable on a system with issues. We have also to cleanup the docker file and not install gdbus, and make sure we don't check this on bootstrap

I think it was #1248 which actually added dbus-next, this library. But dbus-next evolved quite a bit since then, from the changelog it seems that also error handling got improved since then. Thanks for the input, I'll test with that in mind.

@pvizeli

pvizeli commented Oct 18, 2021

Copy link
Copy Markdown
Member

gdbus.py -> dbus.py ?

Comment thread supervisor/utils/gdbus.py Outdated
@agners

agners commented Oct 18, 2021

Copy link
Copy Markdown
Member Author

gdbus.py -> dbus.py ?

I named it after the implementation just like before, so dbus_next.py. But maybe a generic name makes more sense here?

@pvizeli

pvizeli commented Oct 18, 2021

Copy link
Copy Markdown
Member

gdbus.py -> dbus.py ?

I named it after the implementation just like before, so dbus_next.py. But maybe a generic name makes more sense here?

Yeah, I think the generic is better as we use it as middle layer

@agners agners force-pushed the use-python-dbus-next branch from d17a4b6 to 4c5ba9d Compare October 18, 2021 13:34
@pvizeli

pvizeli commented Oct 18, 2021

Copy link
Copy Markdown
Member

You need rebase it for CI

agners added 16 commits October 18, 2021 20:29
It seems that gdbus (or systemd) automatically pick the correct
interface and return the properties. However, dbussy requires the
correct interface name to get all properties.
The property returns a type "y" which equates to "guchar":
https://developer-old.gnome.org/NetworkManager/stable/gdbus-org.freedesktop.NetworkManager.AccessPoint.html#gdbus-property-org-freedesktop-NetworkManager-AccessPoint.Strength

It seems that the old D-Bus implementation returned an array. With
dbussy a integer is returned, so no list indexing required.
That is what the interface is expecting, otherwise the new lib choks on
the Pathlib type.
Assemble Python native objects and pass them to dbus-next. Use dbus-next
specific Variant class where necessary.
org.freedesktop.NetworkManager.Connection.Active.PropertyChanged is
depricated. Also it seems that StateChanged leads to fewer and more
accurate signals.
RequestScan expects an option dictionary. Pass an empty option
dictionary to it.
@agners agners force-pushed the use-python-dbus-next branch from 5bb715b to 3f3b48d Compare October 18, 2021 18:29
@agners agners merged commit 7a6663b into home-assistant:main Oct 18, 2021
@github-actions github-actions Bot locked and limited conversation to collaborators Oct 20, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

cla-signed refactor A code change that neither fixes a bug nor adds a feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants