search

victronenergy / node-red-contrib-victron

MIT License
87 stars 18 forks source link

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

Closed dirkjanfaber closed 1 year ago

dirkjanfaber commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Now merged into master. See https://github.com/victronenergy/node-red-contrib-victron/commit/a5b84087977fc7527c5f24d0c9c9e1d849ccc67f