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

[Feature] Configuration Node rather than a hardcoded single instance #190

Open
rrroonn opened this issue Feb 13, 2024 · 2 comments
Open
Labels
enhancement New feature or request

Comments

@rrroonn
Copy link

rrroonn commented Feb 13, 2024

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.

@rrroonn rrroonn added the enhancement New feature or request label Feb 13, 2024
@dirkjanfaber
Copy link
Collaborator

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.

@Subnum12
Copy link

I would not say it's a feature but a bug by design. It does not follow the implementation guidelines.

Not having configuration nodes and not have capability to disable service makes it impossible to remove packet from node red via Palette Manager.

grafik

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

No branches or pull requests

3 participants