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
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.
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.
The text was updated successfully, but these errors were encountered:
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:
It also shows a status message that the end user should (re)select the device and re-deploy the flows.
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.
Currently the 4th part of the dbus service path is used to identify the used device. E.g:
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 tocom.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.
The text was updated successfully, but these errors were encountered: