add node-red aka the main Venus OS Large tracking issue

[mpvader]

Todo

• Draw up a plan / specification
• Add nodejs & node-red into Venus OS (done see below; not in master yet)
• Add node-red on/off switch to gui; which starts and stops the node-red daemon service. On the switch in the gui, have a popup warning: 'This functionality is not supported by Victron; instead use https://community.victronenergy.com' for support.
• Implement test nodes (battery & relay output)
• Implement rest of Victron nodes
• Install settings-default.js as /data/home/root/.node-red/settings.js (if not already there). Fixes Victron energy nodes being on the bottom rather than top; and some other things.
• Fix IE bug; see comment below.
• Consider security implications - including to run node-red as root or not
• Add VRM & dataAttribute for each service, which will also be used by next one:
• Auto show remote login buttons on VRM, that remote open node-red dashboard and signalk dashboard.
• Add this to the normal Venus OS builds, which also enabled normal online updates.

Repo for the node-red pallette is here: https://github.com/victronenergy/node-red-contrib-victron

Node-red discussion on Community is here: https://community.victronenergy.com/questions/549/feature-request-scheduled-virtual-switch-for-venus.html.

Download information + user manual for beta version of all this is here: https://www.victronenergy.com/live/venus-os:large

Initial -possible outdated- story:

What problem does this solve?

The value in this is that it enables capable installers that want to automatically control available outputs such as relays, or software set-points such as the ESS Grid set-point, or Max Charge Current.

How to handle support?

The risk is that it creates endless possibilities, and its impossible to support by Victron: our support staff does not contain software developers; nor PLC experts, and also we don't want to start employing them for the support team. This risk is mitigated by declaring that there is no official support for this; only community support on https://community.victronenergy.com.

Details

• Node-red, including Victron nodes, will be installed on the rootfs
• Node-red will be off by default, enabled with a switch in the gui
• The Victron nodes communicate directly to the D-Bus. Not via the mqtt bridge
• Flows will be stored on the data partition; so they survive a Venus firmware update
• Venus OS version X will contain Node-red version Y, with Victron-node-set version Z.

Only runs on Venus GX and newer devices

• Node-red will not run on the CCGX: too small 'disk' size.
• For Venus GX it only works when partitioned with the 2nd revision partitions sizes; introduced in production in 2018 Q3. How well it works remain to be seen; cpu & ram will be strained.
• For the Octo GX; it will work wrt disk space; but cpu & ram will be strained.
• CANvu GX won’t be able to run it
• It runs on the Cerbo GX
• And any other future GX devices will (most probably) be able to run it fine as well
• Raspberry: it will also work on the Raspberrypi image. Needs a recent one. In version v2.20, or a few before that; the partition sizes were increased for it.

More information about available disk space is here.

Concept drawing

[mpvader]

Summary of decisions made today:

• when making flows; the UI needs to know what services are available and what not. So; node-red needs to enumerate them. After some back and forth; we realized that its not possible to do that with dbus-mqtt, since it doesn't support wildcards on read requests. Decided was to instead interface to D-Bus; using this code as a start: https://github.com/sbender9/signalk-venus-plugin
• there will be one relay-output-node. Which will allow user to select any of the relays available on the system. So; the victron node-red code needs to have hardcoded the various possible service and path combinations, for example com.victronenergy.battery + /Relay, or com.victronenergy.system + /Relay/0/State); check which ones are available; and list those.
• For the html5 app; we are abstracting away the fact that a BMV has a second input measuring the voltage of a starter battery; and another example: a three output charger; of which the second and third output charge some stand-alone generator starter batteries. All of it will be under com.victronenergy.system /Batteries, in a dict. For node-red however; we don't want that abstraction; it would be confusing to, more technical, type of person that uses Node-red.

Example of service + path combinations for Battery Monitor node:

For the Battery Monitor node in Node-red:

• com.victronenergy.battery.23234: /Dc/0/Voltage, /Dc/0/Current, /Soc
• com.victronenergy.battery.23243: /Dc/0/Voltage, /Dc/0/Current, /Dc/1/Voltage/, /Soc

Example of service + path combinations for Relay node:

For the Relay node in Node-red:

• com.victronenergy.system: /Relay/xxx/State
• com.victronenergy.battery: /Relay

and so forth; note that those paths need to be verified. Use dbus-spy on a working system for that.

Picture provided by Peter:

[mpvader]

Some screenshots of functionality as in the branch on the repo now:

There are two nodes:

These are the settings of the battery node:

And these are the settings of the relay node:

[thomas-pfeifer]

Hi there. I am a new GitHub user, not knowing exactly whether this is the right way to report an issue related to mpvader's message above. However, I have experienced the following after repartitioning the flash and installing venus-swu-beaglebone-20190310172552-v2.30~32-node-red.swu:

1. the Node-Red switch does not appear in the GUI
2. the Node-Red UI can be accessed at IP:1880, but shows two "syntax-error-messages" on startup
   

Do I have to install venus-nodes manually? Or is there any other advice to get it running?
Thx, Thomas

[mpvader]

Hi @thomas-pfeifer, thanks for reporting!

1. the Node-Red switch does not appear in the GUI

Thats correct; its always on for now.

2. the Node-Red UI can be accessed at IP:1880, but shows two "syntax-error-messages" on startup
   Do I have to install venus-nodes manually? Or is there any other advice to get it running?

No, its not necessary to install nodes manually. And actually we have a new version built recently; could you try them? See next comment.

[mpvader]

New test images are available.

• https://www.dropbox.com/s/wl7m4pi8wzviefw/venus-image-raspberrypi2-20190317215210-v2.30_35-node-red.rootfs.rpi-sdimg.zip?dl=0
• https://www.dropbox.com/s/8lk1n4xrns0i5ka/venus-swu-beaglebone-20190317215624-v2.30_35-node-red.swu?dl=0
• https://www.dropbox.com/s/2u20aru076egdwp/venus-swu-raspberrypi2-20190317215210-v2.30_35-node-red.swu?dl=0

Node-red UI is at http://(ip address):1880

And its default on: there is no GUI switch.

See here for how to install on a raspberrypi. For the Venus GX; first follow chapter IV of this issue to repartition it, and then use the normal offline update procedure to install the swu. For Octo GX, no repartitioning is required; just install the beaglebone swu file.

[thomas-pfeifer]

Hi, I have installed the Beaglebone-SWU 2.30-35 from the link above. Unfortunately, I get the same syntax-error messages in Node-Red UI, as before. Victron nodes are not visible in the UI. When disabling / enabling the "node-red-contrib-victron, 1.1.1" nodes under "User Settings" => "Palette", same syntax errors are thrown.
Any ideas?

[jhofstee]

@thomas-pfeifer can you check with Firefox or Chrome? Perhaps it is an IE issue..

[thomas-pfeifer]

Yes, the issue was caused by IE. Tried now with Chrome and Opera - both working fine.
Thanks a lot!

[pkronstrom]

Indeed the frontend code used some features not supported by IE. This should be fixed in the next version (Support for IE 10+).

[SEspe]

Hi thanks. Is there a "noob - howto" to install this on 2.30~39 in an RPi ?

[mpvader]

Hi thanks. Is there a "noob - howto" to install this on 2.30~39 in an RPi ?

No. But search for venus raspberrypi image install in Google, and for questions see the Modifications space on community.victronenergy.com.

If you have inprovements for the documentation while going through the process, please do improve the docs yourself. All this Victron on rpi is a community effort.

Enjoy!

[thomas-pfeifer]

Hi, I have a nice Node-Red "Energy Manager" running on a Venus GX, using the test image provided by @mpvader on March 22, based on Venus OS v2.30_35. However, I recently experienced a Remote Console via VRM connection issue, which hopefully could be solved by updating the Venus Firmware, as indicated in the description of v2.31 bug fixes.
Do you have a Beaglebone-SWU with current Venus OS and Node-Red available?
Otherwise, is there a simple walkthrough to install Node-Red on Venus GX after Firmware-Update?
Will there be a solution (somwhen in future) to have automatic FW updates on the Venus, with Node-Red and programmed flows on the device remaining unchanged?
Thx a lot in advance,
Thomas

[mpvader]

Hi @thomas-pfeifer; yes, actually: this IP address verification issue was solved in v2.30.

I’ll see if I can make a new build for you (v2.32-nodered) tonight.

Wrt the updatability: once we make node-red support official, then you can do updates without (always) losing flows. If it will be 100% watertight remains to be seen.

And, how we’ll manage that for the Venus GX remains to be seen as well; due to the fact that we’ve produced many of them with the small version partition layout. There are solutions; but they’ll take (more) time. And thats whats lacking at the moment: time.

I’ll post here when I have updated images.

[mpvader]

New test image available:

• https://www.dropbox.com/s/15kxnjotbs056nc/venus-swu-beaglebone-20190710201548-v2.32-node-red.swu?dl=0

Note that I did not really test it (I opened node-red once; and thats it). One major change wrt last version is that this has version 1.2.0 of node-red-contrib-victron. Previous images had version 1.1.1. See its repo (its public on this github) and then the releases link for whats been changed.

And, I've updated the two branched (matthijs/wip/node-red in openembedded-core and meta-victronenergy)

[thomas-pfeifer]

Hi @mpvader, thank you so much for quick support. It worked great! Remote Console via VRM is now working again, and Node-Red seems to be functioning as before. Surprisingly (for me), my deployed Flows and additional Palette entries completely "survived" the FW update (via SD card), while Victron nodes were updated to v1.2.0. Of course, I have too less knowledge to understand all this stuff - just wanted to let you know that it worked perfect.

[mpvader]

Hi @thomas-pfeifer: thats great to hear. Thanks for the testing report; useful - even though you might not understand everything; its the info I was looking for :-).

[houser42]

Hello,
Just a few things I am curious about. I am on Venus OS Large v2.82-large-30.
Things are working very well and I am now at a stage where much of the functionality I want is pretty much there, so as I clean up and try to make it as robust as it can be:

1. Is there or will there be a way to check processor usage? I know I can run top on the terminal, but
   a percentage or warning in the VRM or remote control would certainly be very useful?
   I am seeing gradual slowing down of the node red dashboard and find it a little hard to figure out what is slowing it down. Restart always fixes it.

2. The deleting of nodes is still not working 100% as expected and some nodes will not allow deletion.

3. Could/should the Cerbo GX maybe have it's own node to wire in and allow some forms of diagnostics and monitoring?

4. Will CANBus batteries add up their SOC and present a sum in the VRM if you use more than one?
   I ask as the BMV 712 can not see the power used for heat foils.

Thanks as always for a great solution with the Venus OS Large combo!

[dirkjanfaber]

1. Is there or will there be a way to check processor usage? I know I can run top on the terminal, but
   a percentage or warning in the VRM or remote control would certainly be very useful?
   I am seeing gradual slowing down of the node red dashboard and find it a little hard to figure out what is slowing it down. Restart always fixes it.

A quick reaction to this. In VRM you can use the advanced tab to add a custom widget that displays the D-Bus round-trip time. This number is a good indication of the load on the system.

Alternative is to adjust the https://github.com/victronenergy/node-red-contrib-victron/wiki/Example-Flows#monitor-disk-usage example to log and alarm from within Node-RED. And there are other installable nodes to monitor a linux system too.

2. The deleting of nodes is still not working 100% as expected and some nodes will not allow deletion.

Can you file an issue about this on https://github.com/victronenergy/node-red-contrib-victron preferably with some screenshot/log data that will make it possible for me to reproduce?

3. Could/should the Cerbo GX maybe have it's own node to wire in and allow some forms of diagnostics and monitoring?

That is a good suggestion, but we need to look at the existing alternatives too. For example node-red-contrib-process-resources, which can be used for monitoring resources used by the OS processes.

[houser42]

2. The deleting of nodes is still not working 100% as expected and some nodes will not allow deletion.

Can you file an issue about this on https://github.com/victronenergy/node-red-contrib-victron preferably with some screenshot/log data that will make it possible for me to reproduce?

Many thanks @dirkjanfaber
Great suggestion with the custom widget for D-Bus round-trip time. What should I be looking for there?
I am seeing 0 to 3ms with peaks at 9ms. What should a "normal" number be please?
What is a number that is an indication of that something is wrong?
Will check the links you gave for sure. Many thanks again!

Reg. Deleting nodes.
I am not at the site so can't do proper troubleshooting remote at the moment.
Will do it in a few weeks time when I am there.
All I see now is a short message:

Failed to remove: node-red-contrib-bigtimer
Unrecognised module: node-red-contrib-bigtimer
Check the log for more information
Log:
-----------------------------------------------------------
2022-04-13T13:00:43.499Z Remove : node-red-contrib-bigtimer

[dirkjanfaber]

You are welcome, @houser42.
I would say that between 1 and 3ms with an occasional peak is normal, but it does depends on the number of connected devices too. If you have a lot of connected devices to the Cerbo, the round-trip time should be larger. If, as you experience, the system slows down, I would expect the average round-trip-time to increase. Or you might see a lot more spikes. It is a bit hard to predict, so I am not 100% sure that in the correlation between the slow down and the round-trip time will actually show. But it is worth a try.

[xsilvergs548]

I also have difficulty un-installing nodes, please see attached images. Many thanks for all the great work On Wednesday, 13 April 2022, 10:02:17 BST, houser42 ***@***.***> wrote: Hello, Just a few things I am curious about. I am on Venus OS Large v2.82-large-30. Things are working very well and I am now at a stage where much of the functionality I want is pretty much there, so as I clean up and try to make it as robust as it can be: - Is there or will there be a way to check processor usage? I know I can run top on the terminal, but a percentage or warning in the VRM or remote control would certainly be very useful? - The deleting of nodes is still not working 100% as expected and some nodes will not allow deletion. - Could/should the Cerbo GX maybe have it's own node to wire in and allow some forms of diagnostics and monitoring? - Will CANBus batteries add up their SOC and present a sum in the VRM if you use more than one? I ask as the BMV 712 can not see the power used for heat foils. Thanks as always for a great solution with the Venus OS Large combo! — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[dirkjanfaber]

I also have difficulty un-installing nodes, please see attached images. Many thanks for all the great work

I am afraid I don't see any any attachments, but to keep this thread less polluted, I created an issue specific for this: victronenergy/node-red-contrib-victron#131

[SergioRius]

I'm trying to read some meters with a modbus-usb converter but I can't make it to work. Unplugging the dongle from the cerbo and plugging it into a server that runs node-red, works nicely. In both cases using the same flow.

Is there a reason why modbus through usb doesn't work? Venus allocating new usb devices so locking access to com ports? Node-red running user lacking permissions to usb ports?

On cerbo:

On other machine:

PS: I've noticed that from time to time, between errors, some value seems to make it's way. So it will be possible that NR has access to the converter, but could be that Venus is trying to find a new device there and retrying, so messing communication?
If so, is there a way to "exclude" a usb device from venus?

[shaneyake]

Venus has a Service running that is called serial-starter. You can read more about it here.
https://github.com/victronenergy/venus/wiki/howto-add-a-driver-to-Venus
You will need to make it ignore your USB converter.

Or you can just use a Serial to Ethernet adapter like the USR-TCP232-410s
https://www.pusr.com/products/modbus-serial-to-ethernet-converters-usr-tcp232-410s.html
and then do a Modbus-TCP request in NodeRed, this works out the box without any modification to Venus OS.

[mpvader]

Venus OS large v2.90~3

Which is a significant event: Venus OS Large is now part of the standard build!

Beta release announcement here: https://community.victronenergy.com/questions/133592/venus-os-v2903-available-for-testing.html.

Manual: https://www.victronenergy.com/live/venus-os:large

Changes:

• rebased on to Venus OS v2.90~3; our latest beta.
• part of the standard build process.
• online updates most likely work now. But note that online switching from normal to large and back does not work properly yet

Change-logs of the included software:

• Venus OS:
  • Latest official version: https://professional.victronenergy.com (login and then go to firmware -> Venus OS -> changelog)
• signalk-server: https://github.com/SignalK/signalk-server/releases
• signalk-venus-plugin: https://github.com/sbender9/signalk-venus-plugin/releases
• node-red: https://github.com/node-red/node-red/blob/master/CHANGELOG.md
• node-red-contrib-victron: https://github.com/victronenergy/node-red-contrib-victron/releases

Versions:

• Venus OS base: v2.82 - is the latest offical release.
• SignalK server v1.40.0 - is not the latest, v1.41.1 is, or even a later one.
• signalk-venus-plugin v1.25 - is not the latest, v1.26.0 is.
• node-red v2.1.4 - is not the latest, 2.2.0 is.
• nodejs v14.17.4 - not the latest, latest currently is v14.18.something. For later.
• node-red-contrib-victron v1.4.17 - is the latest.

Known issues:

• not all raspberrypi4's work yet, which is a generic issue; not just large-image. See main Venus OS raspberrypi doc for details.
• online updates for large images don’t work yet;

Careful, runs under nodered user instead of root:

• per v2.90, node-red runs under a different user. The user used to be root, now its called nodered. In the new version there is a script that checks if there are no files in the new location as well as are files at the old location, and in that case it moves them to the new one. For 99% of use cases, this goes all unnoticed. But in case you first upgrade to v2.90 and then downgrade to some earlier build of venus os large, then the flows and such have disappeared. They are still there though, on the disk. But just in a different location (the new one) than where that old pre-v2.90 build looks for them (the old location).

Branches:

• sources/meta-victronenergy: matthijs/large-image-30
• sources/meta-victronenergy-private: matthijs/large-image-30
• sources/meta-openembedded: matthijs/large-image-30
• rest is all the default branch when building Dunfell.

Downloads:

• No longer on dropbox. Instead, the normal location for normal Venus OS files, which - for betas - is here: https://updates.victronenergy.com/feeds/venus/candidate/images/.

Comments:
In case you have issues or questions, please use the Modifications section on Community, and clearly mention your question relates to Venus OS Large, and what version.

[SergioRius]

Venus has a Service running that is called serial-starter. You can read more about it here. https://github.com/victronenergy/venus/wiki/howto-add-a-driver-to-Venus You will need to make it ignore your USB converter.

Or you can just use a Serial to Ethernet adapter like the USR-TCP232-410s https://www.pusr.com/products/modbus-serial-to-ethernet-converters-usr-tcp232-410s.html and then do a Modbus-TCP request in NodeRed, this works out the box without any modification to Venus OS.

Hi shaneyake, I don't know if you're part of the staff, excuse me if this doesn't belong to you.
While the procedure to unlock the serial port worked, today I upgraded my venusOs to v2.90 and I can confirm that it's broken. The scripts in /opt/victronenergy/serial-starter doesn't work anymore. stop-tty.sh doesn't seem to do anything.

I was using an ETH converter, but such connection introduced a good amount of lag on the cerbo's work. That's why diched it in favor of a modbus-usb.

Another very ugly issue is that as I went back booting to my previous version, all the .node-red folder contents where deleted and a blank node-red installation was created. I have a backup, but I'm not happy at the moment.

Another thing that also has stopped working is the ability to execute something at the start from /data/rc.local or /data/rcS.local so trying to unlock ttyUSB0 is not called.

[dirkjanfaber]

Another very ugly issue is that as I went back booting to my previous version, all the .node-red folder contents where deleted and a blank node-red installation was created. I have a backup, but I'm not happy at the moment.

The files have not been deleted, but moved to the homedir of user nodered. In one of the last updates we moved the nodered instance to run under its own user account. So your files should still be there.

Another thing that also has stopped working is the ability to execute something at the start from /data/rc.local or /data/rcS.local so trying to unlock ttyUSB0 is not called.

Have you tried making the script executable (chmod 755 /data/rc.local)? I tried and used it successfully today, so that should still work.

I'll check the /opt/victronenergy/serial-starter script tomorrow.

[SergioRius]

@dirkjanfaber Thanks. As the node-red instance was completely empty I assumed it was deleted. The folder was there, but only with the factory files:

On nodered user folder, you're right, things are there. But I was talking about going back / booting the previous v2.80~21-large-23 and node-red being wiped out in that version. Could be that you move the .node-red folder to the v2.90 on install/first run? You should leave the previous version copy there so the dual boot is still an option.

(There should also be an option for pinning a version so it's not overwritten on the second upgrade and one could always return to that good old version. ;) )

So going back to v2.90, could then the issue accessing the modbus usb dongle be just a problem with the user nodered not having permissions to access the USB ports? Just an idea. Anyways I've seen that the stop-tty.sh crashes when launched after a reboot until the usb dongle is replugged. And then runs silently but files remain on the /service folder.

On the rc.local...

[dirkjanfaber]

@dirkjanfaber Thanks. As the node-red instance was completely empty I assumed it was deleted. The folder was there, but only with the factory files.

When booting from the backup version, the new files get recreated. So this is expected behavior, but I can imagine that you thought that the files got deleted.

So, could then the issue accessing the modbus usb dongle be just a problem with the user nodered not having permissions to access the USB ports? Just an idea.

The nodered user is member of the dailout group, so that should not be the cause. But you can always try to do a chmod 666 on the device to see if that fixes it. Then we know where to look for the fix.

[SergioRius]

When booting from the backup version, the new files get recreated. So this is expected behavior, but I can imagine that you thought that the files got deleted.

Sorry, I was editing my precious message bc it was unprecise and confusing. Yes, I guess you do a move on the .node-red folder, but I think that should be a copy so the previous version still works.

I'll try the perms thing now.

EDIT: chmod 666 /dev/ttyUSB0 does the trick

[mpvader]

Hi both, wrt the move and such: I've added a note to the release note above with the details as well as a link to the script that takes care of it. Most users won't even notice it. Its only when updating to v2.90, and then downgrading to a prior venus os large version, that it looks like all files are gone. (which they are not)

In general, maybe bad timing but still I'm going to say it: please do always backup your flows. Things can go wrong, by a mistake of us, or by a faulty storage device, as well as other reasons, and it would be terrible to have to remake all your flows.

[dirkjanfaber]

EDIT: chmod 666 /dev/ttyUSB0 does the trick !

That is good to know! Can you provide me with some more information on the device? Is it a normal serial to usb dongle? With the devices I tested, the permissions become when plugging in:

root@einstein:~# ls -alh /dev/ttyUSB0 
crw-rw----    1 root     dialout   188,   0 May 25 10:22 /dev/ttyUSB0

So the nodered user has access to it. What is the output of lsusb for the device?

[SergioRius]

That is good to know! Can you provide me with some more information on the device? Is it a normal serial to usb dongle? With the devices I tested, the permissions become when plugging in:

root@einstein:~# ls -alh /dev/ttyUSB0 
crw-rw----    1 root     dialout   188,   0 May 25 10:22 /dev/ttyUSB0

So the nodered user has access to it. What is the output of lsusb for the device?

The permissions of the device where just like you posted. The output below is after running chmod.

root@einstein:~# ls -lha /dev/ttyUSB0
crw-rw-rw-    1 root     dialout   188,   0 May 25 11:02 /dev/ttyUSB0

That converter is a proven 4-wire modbus to USB dongle. It's reading some energy meters and I use that information on Venus for changing parameters to better adapt to EV charging and Heating, for example to avoid overloads. Or diverting only when really is energy available. My grid supplier doesn't allow export, so I have to slowly "steal" production and keep the system active.

root@einstein:~# lsusb
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
==> Bus 003 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 003: ID 0bda:b720 Realtek Semiconductor Corp. 
Bus 005 Device 002: ID 0424:2422 Standard Microsystems Corp. 
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

It was working without problem on v2.80~21. Only the serial-starter unlock was required.

I recognize is strange. It should work out of the box.

root@einstein:~# groups nodered
dialout nodered

Thank you so much for your work.

[dirkjanfaber]

I recognize is strange. It should work out of the box.

root@einstein:~# groups nodered
dialout nodered

In the current release Node-RED is started via setuidgid, causing the extra groups to be dropped. I have made a patch that keeps the extra groups, so it should be fixed when the next update is released.

[prein2]

Looking for methods of turning off the charger in my lithium setup with cerbo, multiplus and REC bms.. on my boat when on shore power for a few days I don't want the battery charger to be on, keeping my batteries at 100% since this is not recommended for lithium.
Since I have a Cerbo and a multi control to limit input current I can't use the multiplus states (on, off, inverter only, charger only) since they are blocked.
Thought the best way to disable the charger in node red is to alter the DVCC max charge current to zero when I want it (for example, set to zero amps if battery is at 100% and set back to 120A when battery is at 80 or so)

For this I want to read the 'DVCC max charge current' in node red, but I cant.. I can however set this value in the settings node. In the settings input node I can only select the state of charge for ESS (which is not enabled).

any thoughts on this?

[antiguasky]

On my setup which uses a Cerbo, a Quattro and a Batruim BMS I control this by changing the charging profile in the BMS when on shore for a few days.

…

On May 27, 2022, at 11:45 AM, Rein Boshuisen ***@***.***> wrote: Looking for methods of turning off the charger in my lithium setup with cerbo, multiplus and REC bms.. on my boat when on shore power for a few days I don't want the battery charger to be on, keeping my batteries at 100% since this is not recommended for lithium. Since I have a Cerbo and a multi control to limit input current I can't use the multiplus states (on, off, inverter only, charger only) since they are blocked. Thought the best way to disable the charger in node red is to alter the DVCC max charge current to zero when I want it (for example, set to zero amps if battery is at 100% and set back to 120A when battery is at 80 or so) For this I want to read the 'DVCC max charge current' in node red, but I cant.. I can however set this value in the settings node. In the settings input node I can only select the state of charge for ESS (which is not enabled). any thoughts on this? — Reply to this email directly, view it on GitHub <#378 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQBY5AMYJX5BGPKW5IILXDVMDU2LANCNFSM4GGXANCQ>. You are receiving this because you are subscribed to this thread.

[prein2]

I have this setup which works, but the 'set max charge current' value is set every minute, which is useless of course.
Wanted to solve this with a status check...

I like my method more, because it is automatic and does not rely on myself forgetting to change parameters..

[ { "id": "a104fe3699143820", "type": "switch", "z": "6df8eccb24a30264", "name": "SoC switch", "property": "payload", "propertyType": "msg", "rules": [ { "t": "lte", "v": "80", "vt": "str" }, { "t": "gte", "v": "100", "vt": "str" } ], "checkall": "true", "repair": false, "outputs": 2, "x": 250, "y": 220, "wires": [ [ "9654fc7e1a7de48f" ], [ "25466003a4b86014" ] ] } ]

[nmbath]

@prein2 Maybe another option is to use an Assistant in the Multiplus. This can control the shore AC relay which will ignore the AC inout and therefore not charge. This is on the community forums and you will see what someone has done. Does require a little bit of control wiring on the Multiplus, but does a great job and is a neat solution. The generator start stop can be set to trigger the use of shore power based on SOC, voltage, load, etc. An override switch can be set to force the system on if you need a charge. I use this when on shore to ensure that I favour Solar over shore, but then the shore can be used if Solar can't keep up.

BTW do you disable the Solar as well, so that it dose not bring the batteries to 100%?

[prein2]

Thats another possibility. I think I'll leave it this way..
disadvantage of turning off the entire shore power is that all my AC appliances have to work on the inverter, als kinda useless..

My solar is not disabled, but i have very limited solar (80Wp) on a quite large battery (600Ah Lifepo4), so my current setup keeps the battery at minimum 80% by shore power en provides the rest by sun..

[mpvader]

Dear all,

Venus OS large (includes Node-RED as well as SignalK) is now included in our normal builds; and as such will also be part of official releases. Right now only as v2.90 beta versions. And as soon as we release v2.90 then its available as official builds. Which is still one or two months away minimum.

This message is to thank everyone everyone for their help in making this a reality. Having node-red in Venus OS is a really cool improvement; adding an amazing level of flexibility.

I'll close this issue now. Any discussion on how to do this or that, please use Community, Modifications section. And same for bug reporting or improvements: please all on Community, Modifications sections.

For software developers: pull requests for our node definitions can go here: https://github.com/victronenergy/node-red-contrib-victron.

all the best, Matthijs

Ps. for anyone coming accross this and wanting to know what its all about and current status, read the manual: https://www.victronenergy.com/live/venus-os:large.

[alnavasa]

@mpvader is it going to include signalK?

[mpvader]

Hi @alnavasa SignalK is already included. I've improved my wording the message above. thanks.

[houser42]

Just a closing comment from me too if I may since I am one of the many on this since at least early 2020 ;-)
The 5-6 systems I maintain are all now on v2.90~xx via online updates and is so far working great.

Yes, it is a really cool and useful feature set. Including the ability to integrate with pretty much anything
including propriety things like Home Kit and the like. Major piece in the PV/home automation jigsaw..
Many, many thanks for this! Keep it up..