All Posts in Modifications

I am having difficulty installing Venus OS 2.93 on BeagleBone Green Wireless. The BBG Wireless is similar to BeagleBone Black Wireless without the HDMI port, so I thought Venus OS would work on this board.

As others have reported, when I flash BBG with Venus OS 2.93 microSD, the board initializes, the LEDs flash in the following sequence

• LED1 D2 ~5 secs
• LED2 D3 ~30 secs
• LED4 D5 ~1 sec
• LED3 D4 ~1 sec
• LED2 D3 continuous flashing, stuck

As pointed out in other posts, I tried earlier Venus OS versions, including 2.73, 2.85, 2.90... I also tried pressing the 'Reset' button after waiting a bit on the continuous LED2 flashing.

After rebooting, the BT and green power LEDs are on, with the LED4 D5 light blue flicker. I don't know the state the board is in, though.

Before attempting to install Venus OS, I made sure the wifi and bluetooth worked using the original Cloud9 "bone firmware"; I could access the BBG board ssh, web html browser, etc. The board, wifi and BT seem fine.

It is possible Venus OS is properly installed, but VictronConnect on my iPhone does not connect. There's no BT or WiFi connections. The BBG Wireless does not have an ethernet port, so I can't ssh/telnet into the board.

Is there a Venus OS image that is known to work with BT and WiFi already enabled? Any startup scripts I could copy to the microSD drive to reset Venus OS BT and WiFi? Any other help would be most appreciated.

Thank you,

UPDATE 2023-03-25: v3.00~26 is now available for testing. Minor changes, see below.
UPDATE 2023-03-20: v3.00~25 is now available for testing. Minor changes, see below.
UPDATE 2023-03-16: v3.00~24 is now available for testing. Minor changes, see below.
UPDATE 2023-03-13: v3.00~23 is now available for testing. Minor changes, see below.
UPDATE 2023-03-06: v3.00~22 is now available for testing. Minor changes, see below.

Good evening, or any other time of day,

Per just now, v3.00~21 is available for testing. Two minor updates compared to the previous version.

The status of v3.00 is that we're finishing up, ie. testing for stability, making sure all is as it should be.

What is new in v3.00?

• Peak shaving for ESS
• Disable the touch feature on a GX Touch: great for rental and other systems where the whish is to display system status while not allowing any other user interaction.
• Improved ESS control speed
• RV-C canbus protocol for (mostly USA-built) motorhomes: lots of improvements
• Many other small changes, see below.

Introduction to Venus OS beta testing

In case you don't know what this message is about, please start with reading this link, which explains the Venus OS beta program. Venus OS is the software running on all our GX devices, such as the Cerbo GX.

How to post an issue?

By posting an answer below. Do please keep all findings organised: one answer issue per issue. So first check the existing threads if your issue has already been seen. And if it does, add a comment saying "me too". And preferably some more details. And in case its not listed yet, add a new Answer.

Note that Answers and Comments are two different things on this portal.

Lastly, before posting issues, preferably first revert to the latest official release (v2.93), to double check if the issue you're seeing was present there as well. Regressions require a different treatment than other issues and bugs.

And include information about the results/differences in behaviour in your report.

Changes v3.00~25 -> v3.00~26
All rather minor:

General

• Recognise Batrium BMS (this actually wasn't included in the previous version). No functional changes.

Signalk-Server (part of Venus OS Large)

• minor change: call sync after modifying files before starting the server, to make sure they're written to disk immediately.

Changes v3.00~24 -> v3.00~25

Signalk-Server (part of Venus OS Large)

• On start-up, check if any of the now default installed plugins was installed manually, and remove that one.

Changes v3.00~23 -> v3.00~24

General

• Recognise Batrium BMS; no functional change

Signalk-Server (part of Venus OS Large)

• Add and default-enable plugins sending NMEA data out on TCP, includes AIS data
  • With this change, the GX device is a LAN and wireless AIS and navigation server for popular apps like Navionics, iSailor, iNavX, and Aqua Map on phones and tablets. This blog post by S/V Renaissance explains it nicely; but ignore all explanations about configuring plugins: that is all already done. Two examples: (1) Aqua Map App (link to Wifi connections page), (2) Navionics Boating App (link to AIS feature page).
  • This feature requires a NMEA2000 connected AIS receiver on board. No internet is needed.
  • The data is available as NMEA0183 packets on the default TCP port (10110), as well as signalk messages on the default websocket port.
  • Note that this is not tested. If you have a navigation system, please test and let us know if it works; and if indeed no further configuration was required.
  • All powered by the opensource signalk-server.
• Fix pre-installing venus-signalk-plugin, it was missing. Unknown since which version; on v2.93 it was missing; most likely many prior versions as well.
• Fix disabling updates of the pre-installed plugins

• Known issue with signalk-server: mDNS advertisements most likely don't work.

Changes v3.00~22 -> v3.00~23

• Internal changes

Changes v3.00~21 -> v3.00~22

• RV-C out: increase timeouts on some battery and tank messages to match the maximum send interval. The previous timeout was too strict.

Changes v3.00~20 -> v3.00~21

Developer / Venus OS large related:

• Node-RED (v1.4.29 & v1.4.30)
  • Fix default for the new "Only changes" setting, it now defaults to off.
  • Add option to round float values
  • Filling out service and path of a node is now required
  • Fix reporting relay state changes when the "only changes" option active. As well as other changes that use the dbus PropertiesChanged instead of ItemsChanged signal.
  • New paths:
    • /Settings/SystemSetup/AcInput1 and 2 for input and output-settings
    • /Ac/Frequency for input-gridmeter
  • Update documentation
  • Thank you @mr-manuel for your help with above!
• MQTT: Improve response when receiving a R/<portalid here>/system/0/Serial message. Instead of just activating the keep-alive, it will now always also respond by publishing the VRM Portal id.

Changes v3.00~19 -> v3.00~20

• Fix the issue that was introduced in ~19.

Changes v3.00~18 -> v3.00~19

• Internal changes only
• Has known issue related to MQTT and also the HTML5-App and possibly VRM real time controls. A new version, v3.00~20 is expected later today.

Changes v3.00~17 -> v3.00~18

• Node-RED: fix the Node-RED Victron control nodes. The previous version (v3.00~17) broke all control nodes.

Changes v3.00~15 -> v3.00~17

General

• ESS: Add peak shaving option (by observing the AC input current limit using PowerAssist)
  • Peak shaving already worked in Keep batteries charged mode; no changes there, other than making it more obvious by adding in the Peak shaving menu entry.
  • Peak shaving did not work will in the Optimised modes. It did work as long as battery SOC was above the configured ESS Minimum SOC level, but once discharged there the system would not assist the loads. This is now solved: use the new peak shaving option in the ESS menu, to let the system keep PowerAssisting when needed. And as soon as the peak is over, it will recharge the battery using power from the grid, while prioritising solar. Note that there is a 5% hysteresis on that: lets say Minimum SOC is set to 80%, it will then start recharging back to that 80% once (by peak shaving) the battery dropped to 75%.
  • The default setting, when using the Optimised mode, is off. To not change behaviour of running systems.
  • Warning: this works for the critical loads only. Not by energy meter.
  • For further details, see screenshots below.
• GX Touch: add option to disable the touch input. See settings -> I/O -> Digital inputs for the new feature. This is intended for systems where the GX Touch is wanted to show the users what the system is doing; but nothing else. The status of the touch (enabled/disabled) is toggled by pulling the gpio down to ground. More information about locking a system down is here; that text was recently updated, amongst other things a "Hardening a GX device" chapter was added.
• EV Charging Station: show progress indication during a firmware update.
• GUI, in the Multi & Quattro advanced menu, reword Reset to Restart. Less ambiguous in relation to a factory reset.
• VRMLogger: add various new fields to be sent to VRM to improve the dashboard and dashboard controls.
• Support the Fronius Tauro via SolarAPI: This is a rare edge case. Customers should use Sunspec instead of SolarAPI whenever possible, as per documentation. This change allows using SolarAPI in cases where Sunspec cannot be used. For example where modbus-RTU is in use on the DataManager and modbus-TCP cannot be used.
• Energy meters:
  • Fix issue with EM24 reported values being more erratic since earlier v3.00 releases. Now the behaviour is back to how it was pre v3.00
  • Fix issue with EM540 phase sequence check for three phase systems. It reported the phase sequence as being incorrect while it wasn't.

Few changes that were also made available in v2.93:

• Fix a problem where Remote Console wouldn't work, and required a factory reset to be repaired. Any systems now having the issues will be fixed automatically once updated to v2.93 or v3.00~16.
• Fix timezone bug related to ESS Scheduled Charging: after changing the time zone, a reboot was required to make that use the new time zone. Bug was introduced in v2.80. Thank you Patrick M. for your help on this!
• Add the new Scheduled mode and more for the EV Charging Station. Fixes "unknown" showing when the EV Charging Station is configured for that mode. For more information on that, read here.

Developer related

• RaspberryPis: fix bluetooth connection to VictronConnect using the rpi-built-in bluetooth radio. This was broken during v3.00 development.
• Node-RED, update node-red-contrib-victron from v1.4.26 to v1.4.27:
  • Added option to input nodes to only broadcast changed values (see issue #147)
  • Added missing input-vebus paths: /Bms/PreAlarm and /VebusChargeState
  • Update documentation
• Update the uPnP data (see this commit)
• Update PHP from v7.4.28 to v7.4.33; next step is no longer using PHP at all.

Internals

• Update MK3 firmware from v215 to v216. If already on v215, this update will happen automatically. If running an earlier version, the update will need to be triggered manually, as explained below.
• Prepare VE.Bus firmware updater for some internal changes.

Changes v3.00~14 -> v3.00~15

General

• add logging of generator runtime to VRM Portal (actual visualisation might still need work)
• ESS: add support for all EM300 meters
• ESS: add option to scheduled charging to allow discharging the battery (if SOC is below the configured minimum) while in the window; and more.
• EV Charger: various features and fixes
• Add support for Pylontech batteires having 16 cells in series (rather than usual 15 cells). Thank you Brian Finley!
• Force good settings for Hubble batteries (DVCC on, STS off, SVS recommended off)

Protocols

• Lots of improvements concerning RV-C; to be detailed
• Modbus-TCP: fix issue related to inverter/charger state vs “ext control”.

Changes v3.00~8 -> v3.00~14

General

• Fix Zigbee (DRF2685C) detection. (also available in Venus OS v2.93)
• VE.Bus BMS v2: Improvements to remote firmware update feature
• VE.Bus BMS v2: Add sending the pre-alarm status to VRM.
• Bluetooth improvements for Cerbo GX with serial-nr HQ2208 and later, as well as all Cerbo-S GX production. The temperature issue which makes the built-in bluetooth unreliable/unusable no longer applies:
  • Per mentioned serial numbers, a second Bluetooth radio has been added to the hardware. And per v3.00~14, Venus OS also uses that one; rather than the unreliable one. In more detail:
  • For VictronConnect connection, new radio is used.
  • For Ruuvis, all radios are used including any externally inserted ones (USB).
• Fix bugs in the GUI that could cause it to show glitches and/or get stuck.
• Add Thai language

Modbus-TCP

• Fix register 31, the /State path for the VE.Bus inverter/chargers. Since v2.89 it returned value 252, Ext Control, for systems where the Inverter/charger is externally controlled. Instead of 3 (Bulk), 4 (Absorption) and so forth. Breaking customer integrations. (also available in Venus OS v2.93)

Venus OS Large

• Update signalk-server from 1.44 to 1.46.2

Changes v3.00~4 -> v3.00~8

General

• Multi/Quattro: Fix issue causing a repetitive low battery alarm in case the battery is disconnected
• ESS: Fix bug introduced in v3.00~2 related to external control mode.
• Add progress indicator (0 to 100%) to Venus OS firmware download.
• Fix tank temperature unit (Fahrenheit)
• Add new VE.Bus product ids (2681, 2723, 2766, 2776)
• Add diagnostic fields for Multis/Quattros (uptime counter per unit, terminal voltage, Vsense voltage for L1 master and DC ripple)

Modbus-TCP

• com.victronenergy.battery: Add /Dc/0/Power and /Mode, add missing fields to /State enum
• com.victronenergy.digitalinput: Add "Generator" to /Type enum
• com.victronenergy.multi (applies to RS products): fix in enum /State

Venus OS Large

• Major change in node identification. Now using /DeviceInstance to find the correct node on the dbus instead of using the full service path. Full changelog and description here: https://github.com/victronenergy/node-red-contrib-victron/releases/tag/v1.4.25

Changes v2.92 -> v3.00~4

• For systems having multiple BMSes connected, allow selecting which one should be used for DVCC. It also allows the use of a BMV for SOC tracking -- by selecting BMV as battery monitor -- while still using the BMS for DVCC. A bit of a niche issue for special systems, more technical background here: https://github.com/victronenergy/venus/issues/901 (but please don't start posting on our github - thanks).
• Detect Hubble batteries, untested as of yet.
• Add Polish translations, thank you Jakub T for helping with that!
• ESS: increase control speed of systems using todays supported meters (ET112, ET330, EM24, and also the ABB ones) a little. But, for faster meters, such as the EM540 which is not available yet, increase it very significantly. Requires updating the built-in MK3-chip, see next bullet.
• Include a newer version of onboard MK3-chip firmware, v215. Updating that has a 1 to 10% chance of a short system outage (Multi/Quattro shuts down in VE.Bus Error 14, restarts after 30 seconds). And therefore the update needs to be initiated manually from within the menu. Note that this is a reversible action, no need to worry about being unable to roll back. After updating, and then rolling Venus OS back to v2.92 or some other earlier version, the MK3 will automatically (and silently) be downgraded to the for that version of Venus OS required MK3-firmware version.
• Improve text for tank sensor name in pump configuration.
• ESS: Fix bug where PV is not used for loads when scheduled charging to 100% during daytime
• Fix bug where a PV-inverter on AC-in-2 would not be shown in the ESS overview. The workaround was to configure the PV inverter as being on AC-in-1. Not needed anymore.

Venus OS Large

• Fix issue sometimes causing certain values to update slower than necessary.
• Add client_max_body_size to nginx config for larger flows.
• Update nodejs to v14.17.6, which is the latest v14.17.* LTS. Change log here: https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V14.md#14.17.6

Under water / developer

• Various small under the hood changes, mostly resulting in small reductions of CPU load
• Replace Hiawatha webserver with nginx; which is better kept up to date (security)
• Include various OE Dunfell fixes
• DVCC: simplify transmission of the charge voltage setpoint by sending it always, rather than only if devices that work with it are detected. This won't make a difference to any commonly known system type.

MK3 firmware update related screenshots

On systems not updated yet, you'll see this (after going to the Device list, and then into the MultiPlus, Quattro or EasySolar listing):

[image]

And for anyone wanting to make sure its updated, in that same menu, scrolling all the way down to the Device submenu, and going in there, and scrolling down again, you'll find this listing:

[image]

Wherein the 212 digits are the version number, and thats the old one. And here is what you see after the update:

[image]

Note that this is necessary only for this one update. Hereafter, updates will be silent again, like they used to be; since there is no longer a risk of a short system outage.

Prior threads:

• https://community.victronenergy.com/questions/187176/venus-os-v3007-available-for-testing.html
• https://community.victronenergy.com/questions/180667/venus-os-v30015-available-for-testing.html (CLOSED)
• https://community.victronenergy.com/questions/176323/venus-os-v30014-available-for-testing.html
• https://community.victronenergy.com/questions/170590/venus-os-v3008-available-for-testing.html
• https://community.victronenergy.com/questions/164781/venus-os-v3004-available-for-testing.html (CLOSED)

Hallo liebes Victron Forum,

Ich finde das ESS System von Victron ist wirklich perfekt!

Was unter den Einstellungen noch perfekt wäre, dass ich z.B. per Zeit vorgebe wann eingespeist wird, oder auch nicht?

Eventuell auch eine zweite SOC Einstellung ,von 80% - 100% wird zusätzlich eingespeist und von 30% bis 100% ist nur für reinen eigenverbrauch.

Vielleicht hat auch jemand eine andere Lösung wie man so etwas umsetzen könnte.

L. G.

Alpin28

Hi,

in the coming summer (first summer with solar for me) I would like to make "cold" during the day and "release" it at night so not an air conditioner that would work directly on the room whilst running, more of an ice-maker that stores up coldness to re-melt later.

Does this kind of thing exist or would I have to invent something?

Apologies if this is not the place for this sort of question.

Here's my current setup. I'm getting ready for summer (Australia) and will soon have more solar than I can store, as well as hibernating the wood heater till next winter. This setup responds to MQTT data to drive a buck converter which will sink spare power into my water heater. It positions itself as lowest priority, modulating the buck current against: MPPT state, PV voltage, battery current, AC draw and so on. Here's a pic:

[image]

Here's the mini TFT display giving me a summary of what's going on:

[image]

And remote dashboard for same here: https://community.victronenergy.com/idea/160811/hot-water-heater-opportunity-load.html

Hello Kevin

I did a Venus OS update today and the touch on the display didn't work anymore.
Can it be that RpiDisplaySetup doesn't work with V2.93?

Thanks

I have a flow that is reading the Victron "Inverter" node and outputting the Output Power (W AC) to a gauge on the node red dashboard. I cannot get the node to output a value other than "null" both to the gauge and debug nodes. Other nodes that read the voltage and state from the inverter in question work fine. I also thought perhaps I could read the output amps and just multiply by the output voltage for the gauge but that also shows "0" no matter what the load. The inverter displays its output load in VRM and VIctron connect so I am assuming it is some sort of communication glitch.

I have Venus OS v2.90 running on an RPI4 with I think Node Red v. 3.02

Any suggestions would be helpful. TIA

[image]

I read these posts:

https://community.victronenergy.com/questions/178547/multiplus-ii-connection-with-daly-bms-daly-interfa.html

https://community.victronenergy.com/questions/142216/multiplus-ii-gx-with-daly-bms-and-can-bus-connecti.html

But I could not get it working. Here is what worked for me. I will try to be as comprehensive as possible as most guides and posts miss out many steps, thereby confusing those who are not so familiar with these devices.

If you are adding this modification to an existing system, please turn your inverter off or at least switch it to not being in inverter mode, whilst you make these changes, they will require resetting your BMS a few times.

[image]

1. Daly BMS - I am using one of the bigger units. I have the 250amp 16S aimed at LiFePO4 cells.

I believe the smaller units do not always have the full suite of communications including rs485 and CAN as well as UART. When buying the BMS enquire about the comms and ensure you get one with all the comms. If you plug in your interface board and it doesn't light up, your BMS doesn't have advanced comms. You can still use UART to Bluetooth or UART to USB for monitoring but you won't be able to connect to Victron using this guide.

I tried it on a 100 amp 4S BMS.

2. Interface board also called WNT board.

I ordered this from Daly Smart Store on Aliexpress, although you could also order from Daly Official Store too (and others). When ordering I specified to them by message, that I needed to connect Victron via CAN when they asked me. I believe this is important, don't skip this.

This unit comes with an rj45 to rs485 adaptor cable which you will need.

3. Since I am using Venus OS on Raspberry Pi and not a VenusGX or CerboGX or Multiplus GX unit, I also needed a CAN interface for my Raspberry Pi.

There is a unit called a Canable which was out of stock from its original creator. So sadly I had to buy a copied unit from China. Sadly, as I invented a 3D printer sensor some years ago and the Chinese copied almost straightaway and were selling it on Aliexpress. Karma I guess.

The Canable unit plugs into the RPI via USB. However, I was told that you have to flash it to new firmware called Candlelight to make it work.

The guide to flashing it is here:

https://canable.io/getting-started.html#alt-firmware

You follow that page to the following page

https://canable.io/updater/canable1.html

Where after you set the "boot" jumper on the Canable - you can flash it from the webpage to "candlelight (a8a0757)".

Also download Cangaroo for PC, which is a can monitoring software for testing:

https://canable.io/utilities/cangaroo-win32-ccdcb64.zip

Once you have done this you can connect the Canable to a PC to test the CAN connection.

4. PC. Any small NUC or old laptop running windows 10/11 will work fine.

Download the latest version of PCMaster the windows software for DalyBMS here:

https://diysolarforum.com/resources/dalybmsmonitor-v217beta2-to-set-up-inverter-protocol.310/download

Unzip this somewhere and make a shortcut to PCmaster.

Unzip and create a shortcut for Cangaroo too.

5. Connect your BMS to the interface board/WNT using the supplied cable, it plugs into the port between the UART and Temp sensor ports. Carefully, make sure the plug is firmly inserted, they don't always go in easily.

[image]

I disconnected the interface I was using which was plugged into the UART port. I don't know if you have to - but it was not working when both were connected.

[image]

At this stage, I reset my BMS by turning off my battery master switch and also pulling out and re-inserting the balancing cable plug.

6. Attach the RS485 cable supplied with the interface board to one of the two RS485 RJ45 ports and the other end to the PC USB port.

[image]

The PC will show in "device manager" a USB COM port, it will give it a number, mine was COM3.

Now open the PCmaster2.17 software.

[image]

Hit CommSet - choose your com port and hit open port. Connection will fill the first tab "data monitoring with your battery voltages" If this doesn't connect, reboot the PC and try again, this always works for me in the event of no RS485 connection.

You can now see the data from your BMS and you can change any settings you need to.

I will not cover setting up your BMS for your battery chemistry and series etc. This assumes you have a working battery and BMS configured for it correctly.

[image]

I set VictronEnergy and CAN in the bottom right box in the "engineering model" tab. Then reset the BMS.

7. CAN cable. To attach the CAN to the interface board you need to make or adapt a network cable. Test the cable before use with a multimeter. Set it up like this (thanks to panicman for the image below):

[image]

Pin 4 usually solid blue - goes to the Canable CAN-L connector (or pin 8 on VEcan)

Pin 5 usually blue & white goes to the Canable CAN-H connector (or pin 7 on VEcan)

[image]

Showing connection from interface board to Canable - Canable connectors go L, H, GND from left to right (so pin 3, pin 5, pin 4 on the interface board side left to right). The Canable has a little jumper next to the connectors for a built-in 120ohm terminator. Leave it connected, it seems to work fine with this jumper connected.

Please note, the red bank of dip switches on the interface board are for identification. Some posts say they must all be down for this to work, so I put them all down. I think if you have more than one interface board, you can give the second one a different ID by setting a different DIP switch config, but don't quote me on it.

8. Test the connection.

At this point, I have the Canable attached to the PC. I ran Cangaroo. Hit "start measurement" and selected my Canable as the interface.

You might need to restart the BMS using PCmaster as in step 6 if you don't see any CAN data or check all steps and connections.

If all is working you will see CAN data on the screen which is a bunch of numbers in hexidecimal.

[image]

This has verified that the DalyBMS is sending CAN data. Well done, you're nearly there.

9. Disconnect the Canable from the PC and plug it into a spare USB port on the Raspberry Pi.

If you are not using RPI, plug in your CAN cable into your Cerbo/Venus/GX device VEcan port.

In theory, the RPI should not require rebooting, but if it doesn't work reboot it.

You will see in the remote console under "services" a Linux standard CAN interface which is automatically available on the latest versions of VenusOS 2.90 onwards I think.

If you cannot see the can0 interface check everything or update your VenusOS to the latest version here https://updates.victronenergy.com/feeds/venus/release/images/raspberrypi2/

[image]

[image]

Make sure that "CAN-bus BMS (500 kbit/s)" is selected.

In your remote console main menu you should now see the BMS:

[image]

Showing as "Lithium".

You may immediately get a low battery warning:

[image]

This is because the Multiplus II has had its battery monitor changed, and it needs a reset.

I reset the inverter from the "multiplus-II 48/5000/70-50" menu "advanced" - "system reset"

[image]

At that stage, normal operation resumed. I am using my system as a grid parallel ESS and so the status for the inverter changed to "ext. control". I presume this is because it isn't using its internal battery monitor anymore.

At this stage things are working, my system is now using the BMS as the battery monitor and SoC is determined by the BMS which should track much better than when I was using the Multiplus II as the battery monitor. I will report back any quirks or issues below.

The current does jump about more than it did when I was using the Multiplus' built-in battery monitor. It is possible to calibrate the current on the DalyBMS using the PCmaster software but I have not yet figured out how to.

I hope this guide is helpful. I have not got a "proper" GX device so I have not actually tested this guide when used to connect a Daly BMS to a VEcan port but I presume that it is basically the same without the Canable interface being involved.

Please post any comments/suggestions/your experience below.

TLDR - I solved my problem via the Node-Red flow below, where standard ESS would haunt me with triggering many, many high-voltage-alarms while charging my Pylontech Batteries. Hope this helps someone else.

I've been haunted with high-voltage-alarms from my pack of 6xUS3000C, deployed in late october.

The victron recommended solution did not work for me, as even with voltages below 51.4V and charging slowly, sometimes the alarm was triggered, but the pack would never fill up to 100% SoC or start balancing.

Hence, I decided to try an alternative approach and created a NR flow that

• introduces a "kill-switch", setting the allowed max. charge current in DVCC to 0A, if a cell reaches a Voltage above 3.55V
• will reduce the allowed max. charge current in DVCC in steps, according to the value of the actual imbalance in the stack, as reported by the BMS.

The flow has been activated over the last four weeks now, and with PV intake increasing due to spring coming, the pack has been charged to 100% SoC just fine for many times, without triggering a single alarm.

In fact, for the last 5 days the pack charged fine, with a max imbalance of 25mV (which is below the value of 30mV, from where the BMS would even start balancing). Here the flow never triggered a counter measure, so I assume my pack is now well balanced enough, but I'll keep the flow running just in case.

Here it is:

[image]

ESS-NodeRed-Pylontech-avoid-high-voltage-alarms-while-charging.json.txt

With the flow keeping track, there was no need to adjust the charge voltage in DVCC anymore. The pack charged fine up to the victron defined, internal limit of 52.24V for Pylontech batteries, as stated in the documentation.

Note1: This uses MQTT and interaction with my local broker. I am using a bridge to interface with my Cerbo GX. So all mqtt topics, including VRM ID, need to be adjusted/added to suit your local setup

Note2: In my ESS setup, there is no PV via DC (like from a MPPT), only PV via AC-In from my grid-tied inverter.

Note3: This is an empiric approach, where the steps to reduce the max. charge current, according to cell imbalance, might be specific for my pack. I used reports via my TIG Stack setup, to evaluate the best numbers for a given situation.

[image]

...these are the values that worked fine for me, configured in the switch node shown above:

[image]

• no max. charge current limit, if imbalance is less-or-equal 21mV
• max. charge current limit set to 100A if imbalance is between 22-48mV
• max. charge current limit set to 8A if imbalance is between 49-99mV
• max. charge current limit set to 1A if imbalance is above 100mV
• all else, max charge current limit is set to 25A (which is exact 100mV in this case - rarely used, I've seen the need to top-up some charge sometimes, where 8A and 1A would not be enough)

...maybe I am going to adjust these later on, again. For now, these worked fine for me.

Note4: The Cell imbalance needs to be calculated from the Cell-min and Cell-max Voltage, reported by the BMS. In my setup, this is another flow, that publishes this to another mgtt topic. This is the main part to do this: Node-Red-calc-Cell-imbalance-from-Pylontech-BMS.json.txt ... add it to the main flow, if need be.

I have a the following setup:

Multiplus II 48/5000

MPPT 450/100

Cerbo GX

Pylontech batteries

I have it setup as ESS with charging schedules for overnight charging during cheap rate. I have a Home Assistant automation that sets the SOC limit using MQTT based upon expected solar generation the next day. I had expected an individual ESS schedule to stop when the SOC level has been reached but it continues to draw power from the grid until the schedule ends. My preference would be to automate the battery charging overnight via MQTT rather than using the schedule. Is this possible? And if so, can someone please provide some advice on how it is achieved.

Thanks.

Dear community,

1. how can I (preferably, automatically) check whether a SmartSolar MPPT is currently limited (due to no-feed in and full battery)? (from VRM, Venus, Node-RED, Bluetooth...) - I can see this data in VenusOS for my AC-coupled Fronius Primo, under "Zero feed-in power limit", but not for the Victron MPPTs (if this value is below the maximum inverter power, this means there is active limiting)

2. My AC-coupled Fronius Primo is working fine, and set up in Venus according to the Victron documentation. However, it does not seem to send information on the currently generated power per string. However, it would be good to have this data in Venus for optimal analysis. Any suggestions? The value does not seem to be on MQTT Broker or DBus, but maybe I am mistaken. There seem to be some very old python scripts doing that, but maybe there is an option with better integration in Venus.

Thank you!

Hello, I would like to build an 16S 48V LiFePO4 battery pack with 280Ah EVE cells and 200A Daly BMS with CAN-Port. As inverter I decided for an MultiPlus-II 48/3000/35-32 GX. I asked the Daly support if the BMS will communicate with the Victron MultiPlus-II GX and they confirmed. In an other thread sombode wrote that the Daly BMS will not communicte by CAN-Bus with the Victron Multiplus II GX. Does anybody has experience with the Daly BMS and if it works by CAN-Connetion out of the box with the Victron devices?

Hi!

I'm using a MP2-48/5000, a 3rd party LiFePo4-battery with integrated BMS (connected vis CAN) and a Cerbo GX. The ESS is controlled externally via Modbus by adjusting the AC-Setpoint.

Now I'm wondering why VRM displays "BatteryLife active" although the mode is set to "External Control". Using Modbus, I see that the corresponding register shows "5" (discharging disabled) but I can't see the cause of this. Nevertheless, discharging works as expected.

It only happens if SoC is <40%.

Is this just a cosmetic thing or do I face any drawbacks?