dirkjanfaber
commented
4 months ago That would definitely be a nice enhancement. But also not the smallest of changes. And I expect it to have quite a CPU load effect on the device making the multiple connections. So while this is worth investigating, it will probably take a while before seeing results. Meanwhile we do accept pull requests when someone else feels the urge to implement this before I get around to do this.
Currently the nodes rely a on hard-coded dbus instance: either the default system dbus, or an environment variable pointing to a "dbus over tcp" instance. While that does work for many people, it is frustrating and very limiting for people who have multiple systems where each would require a separate node-red installation. People like myself, already have large automation systems that integrate node-red, home assistant and esphome with smart sensors and devices. In this situation, it makes sense to integrate the venus devices with the existing node-red instance so that it simplifies the logic for controlling your power generation dependant on existing sensors - like, for example, switching to grid when a well pump is needed that would otherwise overload the inverter, or only running a device if SOC is more than xxx.
I have multiple victron systems, so maybe I am an edge case, but it makes sense to "bite the bullet" now and introduce Configuration Nodes to control the venus instance that the worker nodes are referring to. The node could allow selection of the system dbus or an IP address and port of another instance of venus. Multiple Configuration Node instances can then be defined to handle multiple venus os instances.
Node Red provides the ability to define configuration nodes and this feature is used by many node developers. Configuration Nodes
It is possible to glue multiple systems together via a MQTT server or other middleware, it makes it more complicated than it needs to be and harder to maintain for many people.
For your consideration.