Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change node binding from full service name to VRM device instance #144

Closed
dirkjanfaber opened this issue Sep 13, 2022 · 2 comments
Closed
Assignees

Comments

@dirkjanfaber
Copy link
Collaborator

dirkjanfaber commented Sep 13, 2022

Currently the 4th part of the dbus service path is used to identify the used device. E.g:

        "id": "8bd339f14297d3dd",
        "type": "victron-input-battery",
        "z": "c34346c5425b8f4d",
        "service": "com.victronenergy.battery.ttyS5",
        "path": "/Dc/0/Voltage",

In case of a SmartShunt this can be something like com.victronenergy.battery.ttyS5. If you move the VE.Direct cable to another input, this will change to com.victronenergy.battery.ttyS7. Which causes Node-RED to be unable to locate the D-Bus service.

Instead of using the 4th part of the service name, the first three parts in combination with the VRM Instance (/DeviceInstance) needs to be used. The VRM instance never change on a fw update. The authorative document about all this is this: https://github.com/victronenergy/venus/wiki/dbus-api#vrm-device-instances.

See also https://community.victronenergy.com/questions/155118/venus-os-v29027-available-for-testing.html?childToView=155838#comment-155838

The aim of this issue is to see if we can change from using the full D-Bus service name to using VRM device instances; including migrating running systems. Note that there are also services without an instance, such as com.victronenergy.system.

@dirkjanfaber dirkjanfaber self-assigned this Sep 13, 2022
@mpvader mpvader changed the title Node-RED flow binding to particular device Change node binding from full service name to VRM device instance Sep 13, 2022
@dirkjanfaber
Copy link
Collaborator Author

I tried to get the migration as seamless as possible for the end-user. New flows will store the DeviceInstance.
Handling of existing flows is of course different. If on start-up the node uses an "old style" path, it will query the dbus for the correct /DeviceInstance on that path and update the running flow. In all tested cases, this means that the flow will continue to work and no user interaction is required.

A visual indications that the users should update the flows to use the updated naming has been implemented too. When running such a flow (as implemented in the faberd/issue-144 branch), this is done by showing a "please migrate" message with a blue dot:
image

It also shows a status message that the end user should (re)select the device and re-deploy the flows.
image

Once that has been done, the user should no longer see the blue dots and status messages. Note that the blue dot messages are also given when importing a flow from the examples, where you don't have the devices available via the in the flow defined path.

This still needs a bit more testing to be sure it works in all cases.

@dirkjanfaber
Copy link
Collaborator Author

Now merged into master. See a5b8408

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant