All Posts in Modifications

UPDATE 2022-08-12: updated to v2.90~22

Good morning!

Yesterday we released v2.90~21 for public testing. Various updates since the previous one, v2.90~14.

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.

v2.90 summary and planning

The current status of v2.90 is that we finished all open items, and getting closer to a final release. Its been delayed, so timeline for that is still the same, one or two months from now.

What to test?

• generator control and handling; both on the GX itself as on VRM (new: there is now a generator start/stop control).
• tank monitoring with GX Tank, Cerbo GX, Venus GX as well as the new Mopekas.
• Venus OS Large (due to updates of Node-RED and more)

How to post an issue?

Please keep all findings organised as answers to this question. One answer per issue. So first check the existing threads. If you have the same as someone else already reported, welcome to 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!

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

All the best and have a good day,

Matthijs

Post about prior versions:

• https://community.victronenergy.com/questions/140258/venus-os-v29014-available-for-testing.html
• https://community.victronenergy.com/questions/138776/venus-os-v29012-available-for-testing.html
• https://community.victronenergy.com/questions/137645/venus-os-v29010-available-for-testing.html
• https://community.victronenergy.com/questions/134947/venus-os-v2908-available-for-testing.html
• https://community.victronenergy.com/questions/133780/venus-os-v2905-available-for-testing.html

Change log (compared to v2.89)

Changes v2.90~22

• Add support for more CG Energy Meters. These meters count kWh like the ET340, which is unlike the EM24 and unlike most utility meters do. For more info that, see energy meter manuals. It can nevertheless be interesting due to shortages on the EM24. Meter model numbers (note the 27 suffix):
  • EM330DINAV53HS1X27
  • EM330DINAV53HS1PFB27
  • EM340DINAV23XS1X27
  • EM340DINAV23XS1PFB27
• More underwater changes on how certain drivers are started and stopped.

Changes v2.90~15 till ~21

General:

• Add support for Mopeka Pro LPG and Mopeka Pro Water level wireless sensors. With thanks to Rob and others for their help on this. Some details:
  • Butane ratio can be configured for LPT sensors
  • Both temperature and sensor battery voltage is shown
  • Only the pro sensors are supported, the older non-pro sensors are not and most likely also will not be supported.
• Fix handling of DC Alternator power in relation to the DC system power wrt showing it on the system overview page.
• Lynx Smart BMS: add low SOC alarm as well as timestamps to the error log.

Multis/Quattros:

• fix too long descriptions (Ext. control, Rep. Absorption, Power supply).
• improve the control via VRM for systems with a VE.Bus BMS v1 or Digital Multi Control: for such systems the mode (on/off/charger only) cannot be controlled, and now VRM knows this and will hide the option, rather than showing a non working one.
• Add option to see serial numbers of all Multis/Quattros in a system

RS products:

• Add low SOC alarm
• Add alarm and warning configuration: these can now be configured in the same manner as with VE.Bus products: disabled, alarm only, alarms + warnings.

EV Charger:

• Fix EV Charger input/output position
• Make the remote firmware updating more robust.

Venus OS Large

• update Node-RED from v2.2.2 to v3.0.0
  • Blog with feature highlight video
  • Full change log
• node-red-contrib-victron v1.4.19 and .20
  • input-alternator: add /ErrorCode, /Engine/Speed and /Speed
  • input-vebus: add /Hub4/Sustain
  • input-tank: add new types to /FluidType
  • remove obsolete input-dcdc node
  • remove obsolete dbus paths for: input-alternator, input-system,

    input-dcload, input-dcsource and input-generator.

• update SignalK-server from v1.40 to v1.44

  • also updated @signalk/freeboard-sk from 1.20.0 to 1.21.0
  • Full change log

Under water:

• Changed implementation concerning the starting/stopping for canbus, mqtt, modbus-tcp and other services that are conditionally started and stopped.
• Speed up GUI initialisation
• Re-implement generator start/stop handling
• Change some implemenations concerning tank monitoring.
• VE.Can: fix device instance not able to change above 100 from the gui. thank you Wilco.

Developers / protocols:

• Modbus-TCP
  • Add diagnostic registers for CAN-bms batteries
  • Add registers for low SOC alarm on Inverters RS and Multi RS
• RV-C
  • Add support for reading tank data from Garnet Seelevel II 709. Note that these products do not have the ability to configure a tank capacity. And therefore, only relative tank level is shown to the user (percentage).
  • Inverter out: Fix wrong DGN for INVERTER_AC_STATUS_1 L2 data.
  • VE.Bus out: Do not charger data for an inverter only product.
  • Inbound battery data has been tested and verified with Lithionics batteries, which support native RV-C. The Lithionics batteries also support DVCC with CVL and CCL. Although other manufacturers might work, this is not tested and also not supported: do not install systems like that.
  • Add support for Phoenix Smart IP43 charger and other Victron AC chargers.
  • Improve RM_RV for tank level transmission
  • Battery out: Set priority to 119 and suppress messages if a node with a higher priority is present.
  • Inverter/charger out: Enforce charge state to "Constant VI" in case of external control.
  • Solar out: Fix operating state as this was always set to 0=Disabled.
  • Solar out: Fix charger instance. Was always 255, now set to 1.
• Remove mqtt-n2k; broken since 2019 and not used.

Developer related (and mostly raspberrypis):

• Available CAN-busses on a system are no longer defined statically. Instead they are enumerated at run time. Naming is handled in udev and is optional. All commercial products (Cerbo, CCGX, etc) still behave the same as they did. What is different in behavior, as a side effect, is that plugging in more canbusses, for example a Kvaser USB is now automatically recognised and results in an extra canbus. (Not officially supported! Works half on a Cerbo: the BMS-can port will disappear. Use at your own risk and don’t be surprised if some day it breaks, we don’t test it). For raspberry pis, the only device for which it was needed and common for a user to tell the system that there is a canbus, things will have changed. It will be easier now to get canbus working on a pi. Making the /etc/venus/canbus_ports file is no longer needed. For mode details, read the code by looking at the commits around July 8th in meta-victronenergy, especially this one https://github.com/victronenergy/meta-victronenergy/commit/e9ba4487c2997f021e7548ddea5e0b16c15bb46c and this one: https://github.com/victronenergy/meta-victronenergy/commit/f3f18a3c521b31a6b6d49ff0c234a59334ead565, as well as here: https://github.com/kwindrem/VeCanSetup/issues/6. Note that all interfaces are automatically recognised, except for slcan: the system only recognises those if something/someone started the slcan binary with the proper parameters. Of which you can see an example in our code. For the einstein for example, we defined in udev that when it sees a certain uart; that it should start slcan.

Changelog of earlier released v2.90 changes - consolidated:

Main new features:

• Add Venus OS Large. PLC like super configurability and automation, as well as SignalK. To learn the details, read its manual.
• Add Wakespeed alternator regulator support (monitoring it). Requires wakespeed firmware which is not available yet. More details to come.
• Add RV-C-out. RV-C is a protocol used mainly in the US, by large RV manufacturers.
• Add remote configuration of VE.Can connected products using VictronConnect. Until now, remote configuration was only possible for connected using the other types of comm. ports (VE.Direct and VE.Bus).
• Add support for new Carlo Gavazzi EM530 and EM540 meter. Sub-Family X and PFC is supported, part numbers:
  • EM530DINAV53XS1X
  • EM530DINAV53XS1PFC
  • EM540DINAV23XS1X
  • EM540DINAV23XS1PFC
• Add option to configure the UI to show all temperatures in Fahrenheit.
• Add support for the Cegasa eBick and eNerlit batteries. Details below.
• Add Generator Start/Stop control widget on the VRM Portal.
• Add suppor for the new VE.Bus BMS v2. Includes control of Solar Chargers and other products via DVCC as well as remotely firmware updating the BMS in case needed.

DVCC:

• Add support for Cegasa eBick and eNerlit batteries. Force enables DVCC, and forces SVS and STS to be off. Documentation: https://www.victronenergy.com/live/battery_compatibility:cegasa
• Force good settings for the FreedomWON eTower batteries: DVCC on, SVC and STS off.
• Better handle BMS disconnection issues: in some cases the solar chargers would not start showing Error #67 when unplugging the BMS. Now they do.
• Detect Dyness batteries, so they no longer show up under as a Pylon battery. No forced settings.
• Inverter/chargers: show state as "Ext. control"; instead of Bulk or Absorption, when controlled by a BMS/DVCC. When controlled by a BMS the inverter/charger would never show float, which caused questions. Now it just shows externally controlled, simpler, and more accurate: there is no bulk -> absorption -> float charge algorithm when controlled by BMS.

Various updates:

• Improve Bluetooth sensor menu & options (continuous scanning, see all inserted adapters, and more)
• GX LTE & GX GSM: Add modem username/password settings, required by some providers
• EV Charging Station: various improvements (menu, connection stability, VRM, new models)
• Fix the sign of the current and power for DC meters that are configured as source (except fuel cell and alternator, which were correct). broken since venus v2.80
• Add missing "Inverter only" mode to mobile overview in the GUI
• HTML5 app: fix white screen issue on MFDs that do not support localStorage, eg. Simrad NSX 3007, 3009 & 3012. Thank you Gustav for reporting.
• Fix IMT Irradiation sensor connection issue; after the sensor is turned off and back on; which happened specially on faster hardware such as MultiPlus-II GX, EasySolar-II GX and certain RaspberryPis.
• Log GX relay functions to VRM
• Log generator start/stop AutoStartEnabled to VRM.
• Fix main battery temperature missing, or wrong value shown, sometimes on the VRM Dashboard.
• Add various new VE.Bus model names (Quattro-IIs and MultiPlus-IIs)
• Add daily tracker history for Inverter RS and Multi RS, including transmission to VRM.
• Prioritise ethernet over WiFi. Background here. This is done by increasing the metric for WiFi routes.

Modbus TCP:

• Add energy registers for energy counters in our inverter/chargers (Multi/Quattro)
• Add registers for Wakespeed alternators

Other Protocols:

• NMEA2000-out: add support to AC chargers, such as the Phoenix Smart IP43 charger. Tested with both the 230V as well as 120-240V Phoenix Smart Chargers.
• Add RV-C protocol.

VRM

• Prepare for Widgets, a feature coming in next version of VRM App for iOS and Android.

RaspberryPi

• Add support for raspberrypi4 board rev 1.4 and 1.5, as well as the Raspberry Pi Zero 2 W. Possibly other models work as well now, such as the RaspberryPi4 Compute Module. The mentioned ones were tested, and work; for an up to date list, always check our RaspberryPi image documentation. Possibly the RaspberryPi Zero2w works now also; Special thanks to @Bathnm for spending lots of hours on this to make it all work; as well as a handfull of other enthusiasts for helping to test and such. Details:
  • u-boot goes to v2022-01
  • kernel goes from 4.19 to 5.10
  • bcm2835-bootfiles go to 2022-331
• NOTE: Reflashing the SD-Card is required: to go from a prior version, ie v2.90~10 or early like v2.86 or even earlier, to a newer version. Pis running those prior versions will not auto-update themselves any further. As an alternative, to prevent having to reconfigure Venus OS, you might be able to extract the new boot files from the new image, and copy them accross; nobody tested this as far as I know.
• Canbus handling is changed; might/will effect some rpi installs. See below.

Developers / under water:

• Update Linux kernel from 5.10.42 to 5.10.109, which updates to LTS for security issues and bug fixes, also adds support for Cerbo B1 and Ekrano, and adds ntfs support.
• Update Open Embedded Dunfell branches: various fixes to low level systems and tools.
• Various stability fixes to the xupd & xupc tools (which are part of remote firmware updates)
• Transmit default gateway to VRM as well as CPU temperature; for debugging.
• Add pre/post hooks to installation from USB stick: https://github.com/victronenergy/venus/issues/853

We have added a Multiplus II after the house had already been wired and the Unit is remote from the main DB so cannot use the AC2 out.

We do have a control system that can receive an Input in a contact closure I/O unit within a meter of the Multi so want to use the Victron I/O on the multi as an output to trigger an input to shed my loads

What I'm stuck on is how to configure the I/O on the multi.

Is there a Charge Current limiter planned? I d like to use Smart Solar 75/15 to Charge the most important Battery and the Orion at the Output of the Smart Solar to charge a second Battery when the first one is fully charged ... I have build my one Display and want to aktivate the Orion if the first battery is going to Abs. mode. But i do not want to take energy out of the first battery. I want to store the Energy from my solar panel in the second Battery by ramping the Curent as long as the first Battery stay in ABS. Fashion. Is this possible?

I have a cerbo gx connected to a router over ethernet and want to allow devices connected to the wireless AP on the cerbo to access the internet.

I attempted to create a bridge intending to add each of the eth0 and wifi0 network devices to it, e.g as root on cerbo:

ip link add br0 type bridge
ip link set wifi0 master br0
ip link set eth0 master br0
ip link set br0 up

But adding the bridge in the first step raises an error:

Error: Unknown device type

The bridge type is listed in the help page and this same command works on most linux systems that I am familiar with

ip link help

.. so I might guess that this is some particularity with the way that ip link is compiled for Venus OS. I thought it might be customised to support CAN/ve.bus etc.

My other thought is to check if selinux might be blocking.

Does anybody have advice or cautions about going in this direction?

I released some major changes to GuiMods today. In no particular order:

• revise Generator overview & add auto run enable/disable button
• add generator service interval and countdown on generator overview
• incorporate GeneratorConnector code in GuiMods - GeneratorConnector now obsolete
• revised "simple" flow overview
• revised "grid parallel" flow overview, now called "AC Coupled"
• added DC Coupled flow overview - shows more DC devices than previous pages
• add alternator, AC charger and wind generator DC sources
• added gauges to mobile overview and generator overview
• add details page access from mobile overview
  • current limit and inverter mode buttons removed/replaced with details pages
• DC system detail added: shows DC system devices
  • as well as other devices not shown on the flow overview
• added detail acces via the CCGX hard buttons
• dropped support for Venus OS v2.4x and 2.5x
• added more detail to the Relay overview generator status
• fixed: Generator buttons don't work on Relay Overview page for some Venus OS versions
• fixed: PV Inverter tile on GuiMods Simple overview formatting errors

If you have automatic downloads and updates enabled in PackageManager you should get the update automatically. If not, manually update via PackageManager or download from:

https://github.com/kwindrem/GuiMods

Please report any issues here or in the issues section of the GuiMods repo on GitHub. Thanks.

Screen shots of some of the new pages

DC Coupled flow overview

[image]

Enhanced Movible Overview

[image]

[image]

How do I send a -1 to modbus register 2704 which is the max discharge power register. Any postive number sets a value but -1 one is suppose to set no limit. Its a 16uint register. The question has been asked in the past but not answered. Using 16 bit 2’s compliment of 65535 does not work. What is the correct value to set a -1.

Anyone else experiencing the VRM portal not updating in realtime? The "last updated" states that it's realtime, and I know my solar production voltage and amperage isn't continuous. I've restarted my raspberry pi which sends data to the VRM and that didn't make any difference. When I look at the browser inspector, there seems to be quite a few errors showing up.
- No dbusServiceType property set on subscription object

- You have included the Google Maps JavaScript API multiple times on this page. This may cause unexpected errors.

- dashboard:1 Uncaught (in promise)

- TypeError: Cannot read properties of undefined (reading 'hasOwnProperty')

Just wonder if anyone else is experiencing the same issue.

If I look at the remote console on my local network, it's updating in realtime.

Thanks,

Adam

Hi,

I fully understand and agree that the services provided by Google are great and appreciated by many.

I would like to challenge you Victron Energy in using alternative solutions to the Google services being used in your website / products. This could be a very long text on the privacy issues related, but to make it short, by using these services, you are making your users/customers pay with their data.

Could you please think about using alternative solutions which are more oriented to the privacy protection? Replacing reCAPTCHA with hCaptcha for example? Using Open Streetmap instead of Google Maps?

Google & Co's behavior is more than questionable and there are many lawsuits related to privacy issues and Google.

Thank you.

Hello,

I build an off-grid solarinstallation.

I want to have a litle Dashboard. And I have installed Venus OS on RPI3.

Sadly the gui is not scaling. My resolution is 1280x800.

I can not find something about that until now. Any ideas here?

[image]

I've inherited a Skylla TG24/100 WHITE charger. Within the white box with blue lettering are two identical printed circuit boards with their own mains connections and outputs. They are only connected to each other via ribbon cables to the front control panel. Can anyone advise on how to wire it up and to test it, and are the two boards independent?

I have been playing around, and it would seem that it is not possible to control a BMV Relay set to remote with venusOS.

Are there any plans to add this capability? If not could it be added to the list?

So I have a three-phase ESS setup with a large battery and a few solar chargers. When the battery is full, the BMS tells the system that Allowed Charge Current Is Now Zero Thank You Very Much, and dbus-systemcalc-py thus tells the chargers to deliver exactly as much current as my MultiPlus trio are pulling from the battery.

This part works perfectly … except that there's a residual current of 2A. This is understandable, as current measurement is not an exact science and we're talking about 120A going from the chargers to the Multis. What I don't understand is that dbus-systemcalc doesn't notice, as the battery monitor does report the 2A current, and I couldn't find a way to fix this. (Also, my BMS can't burn that much power. Nor would I consider that to be a valid solution.)

The end result is that the battery gets overcharged, some cell eventually goes above 3.6V, the protection relay trips, and the whole thing grinds to a very ugly halt.

Any ideas, other than to hack a fudge factor into /opt/VE/dbus-systemcalc-py/delegates/dvcc.py?

I am in the process of designing a solar power system for multiple remote installations that are spread out across multiple kilometers. These locations will each have an RTU or PLC controlling the installation and either radio or fibre communications to remotely control and monitor the installation. The BlueSolar/SmartSolar MPPT charge controllers seemed to be the best product for charging the 48 V batteries that will be used however it seems like I will need to use one of the GX products to remotely monitor instead of being able to use my existing communications hardware. Given tight space, cost and power constraints this is not ideal. Each installation will have a single 48 V, 20 Ah lithium battery and a small solar array.

So the simple question is, can I use the VRM software to remotely control and monitor charge controllers through non-proprietary radio/fibre communications options?

I have a Batrium BMS that reports Battery voltages and consumption info. VRM reports connect consumption and production info until I checked the "Has DC System" using the Cerbo gx.

All the values are correct except in the historical data.

Is this a bug or a misconfiguration

Regards

[image]

Hello Bluetooth-protocol-craving-developers!

Its finally here, a Victron published protocol to get data from our devices over Bluetooth Low Energy aka BLE.

By implementing this protocol, you will be able to read Victron product data such as Voltages, Currents, Power, and so forth.

Each of those values is made available as a GATT characteristic. Which is the normal way of doing that in the official Bluetooth Low Energy protocol. The advantage of doing it that way is that its relatively straight forward to use it. For example you could use a readily available app such as the nRF Connect App by Nordic (screenshot below). And also its possible to query data straight from the command line in Linux.

The details:

• This feature adds a new BLE Service. Its a new BLE service, and its a different one than the BLE Services we use ourselves for VictronConnect communication and firmware updates.
• The UUID for this new service is: 65970000-4bda-4c1e-af4b-551c4cf74769
• This protocol (and its BLE service) is not the same protocol as used by VictronConnect.
• A keep alive is required. Without that, the device will automatically disconnect after one minute.
• For now, this new feature is available only for the SmartShunt only. It was added in SmartShunt firmware version v2.31. Also, you need VictronConnect v5.42 (or later) to enable this feature in the settings, see screenshot.

Instructions:

1. Use a SmartShunt, other devices don't support this yet.
2. Use VictronConnect v5.42 or newer.
3. Update the SmartShunt to version v2.31 or later.
4. Connect to the SmartShunt using VictronConnect, and enable this protocol (screenshot below)
5. Power cycle the SmartShunt
6. Refresh the services cache on your host (ie. phone/tablet/laptop/raspberrypi). This is done by removing the SmartShunt from the list of bonded devices, and then re-add it. This is necessary because Android, Bluez/Linux and so forth all cache the list of available services.

Now its up and running and available. On a phone, try the Nordic nRF Connect App and look for the service with the UUID ending at 4769 as listed above.

On linux, use the gattool. I found a nice primer about it: How to Get Started with Bluetooth Low Energy on Linux. And there must be many more to be found on the internet.

To find out which GATT characteristic is what, you can read the "Characteristic User Description" parameters. Currently I don't have a list of all UUIDs and what they mean.

Now, a bit more detail on the keep alive:

• The default time-out is configered to 60 seconds.
• The UUID for the Keep-alive characteristic is 6597ffff-4bda-4c1e-af4b-551c4cf74769.
• Writing 0xFFFF to it disables the auto connection, resulting in a connection forever.
• We strongly recommend not to use that 0xFFFF in a production environment. During VictronConnect development we learned the hard way that Bluetooth stacks can end up being in weird states, on the host as well as in our product; and one good way to make it robust it is to make the host send a keepalive; and make the device issue an internal disconnect when it no longer receives that keep-alive. This then resets all states and resets the rest of the stack, so its in a connectable state again.

Last, how to get the data? BLE supports multiple methods. First there is the obvious read command, which allows you to read a value, and the host (GATT Client) then sends the read command to the Victron product (GATT Server), after which the response including the data is returned.

The other method is to have the host (GATT Client) subscribe to notifications. Our implementation supports these notifications, and how they work is that whenever a value changes, its automatically sent by the Victron product to your host. Note that notifications are not acknowledged.

That is all for now. We are aiming to write this up in a more complete and technical document, but I can't promise when that is completed.

All the best, Matthijs

Picture one: the setting to enable this "third party implementation"-protocol:

[image]

Picture two, the Nordic nRF Connect App showing the voltage (0x2005 = 0x0520 = 13.12V). Note how the app Allows you to retrieve the data, retrieve the user description, as well as receive other information about the characteristic:

[image]

Picture three: how to enable notifications in the Nordic nRF Connect App.

[image]