All Posts in Modifications

Good evening everyone,

A new version is available to test. All bug fixes.

In case you don't know what this message is about, please start with reading this link, which explains the Venus OS beta program.

Changes compared to the previous test version, v2.80~36, are:

• Fix the FzSonick connection no longer working. This was broken per Venus OS v2.73. Thank you @apollo-technics & @imac for reporting.
• Fix problem with battery energy values (kWh counters) doubling up. Thank you @Al for reporting.
• Complete the translations, including a fix for the German version - thank you @Stefanie.
• Ruuvis: Fix behaviour when bluetooth adapters are added/removed.
• Change source of RaspberryPi firmware files, mostly, or perhaps only, used for the Rpi onboard Bluetooth and WiFi chipsets. We tested this on a Rpi3, both the Ruuvis and the Wifi; and there it works. Would be great if someone can test it on the Rpi4.

I've added the full v2.80 draft changelog, compared to v2.73, the latest official release, below. We're getting really close to release now. Which would be about time..!

v2.80 summary

The version we're working on, v2.80, has various highlights: the new AC Load monitoring, the new DC metering function, and also various improvements to the HTML5 MFD App including addition of translations, added support for the Ruuvi Tag wireless temperature sensors, and since this version it adds relay control by temperature.

What to test?

Same as before: the new features I mentioned in the above summary as well basically everything. And the wifi + bluetooth on the Rpi4.

There are several major changes in v2.80, which can each make things break in unexpected places. For those interested in the details, the changes I'm referring to here are (a) that the used Python version has been updated from 2.7 to 3, (b) the Open Embedded release was upgraded from Zeus to Dunfell, and we changed to a read-only rootfs. Also, various application level changes that reduce the CPU load per Victron device, useful when connecting many solar chargers for example, were made. That caused some regressions earlier, which are now fixed.

How to post an issue?

Preferably all issues are 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 here on community.

Lastly, please first revert to v2.73, 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 one of the first things that needs doing in triaging a report is distinguishing between the two.

Thank you! Matthijs.

Ps. full change log - compared to v2.73:

Main new features:

• Add support for the wireless Ruuvi temperature sensors, which also measure humidity and air pressure. Data is available in the GUI, as well as on VRM. The Ruuvi sensors are available for sale via www.ruuvi.com, Victron is not stocking them. Note that while the sensor itself also reports movement aka acceleration data, that information is not available within Venus OS.
• Add DC load monitoring, and production. Details below.
• Add AC load monitoring. Details below.
• Add preliminary support for the new Multi RS. Note that this is incomplete.

AC Load monitoring details:

• All energy meter types can now be configured to a new "role": AC Load monitor. This is done in the menu where you also choose between Grid, PV Inverter and Generator. With AC Load monitor selected, the load will be shown in the Device list. Note that we still need to work on VRM for this (add it to the Advanced page, and perhaps elsewhere as well), and also note that measured loads are not used in any calculations.

DC Load monitoring details:

• SmartShunts and BMV-712s can now be configured to be a DC Energy Meter, rather than a Battery Monitor. Two things happen when one or more SmartShunts are configured as such: (1) the power shown in the DC system box is the sum of powers reported by all SmartShunts configured as such. Allowing multiple meters is done to accommodate for example a catamaran, then you can measure the DC Systems on Port side and on Starboard side. Use the Custom name setting to give each of the meters configured as DC System their own name. (2) the DC System Current is being compensated for when setting DVCC charge current limits to Multis, Quattros and Solar Chargers. Which in more detail mains that for example when a load of 50A is being measured, and CCL by the battery is 25A, the limit given to the Multis & Solar Chargers is 75A. A valued improved for systems with significant DC loads such as Yachts, Coaches and RVs.
  
  Notes and limitations: (A) instead of a SmartShunt, also a BMV-712 can be used. (B) Setting it to be a DC System is done in the settings of the BMV/SmartShunt itself. (C) The NMEA2000-out feature does not support these new types, for example when using a SmartShunt to measure output of an alternator, that data is not made available on NMEA2000.

DVCC and managed batteries, connected by CAN-Bus:

• Force DVCC settings for Pylontech batteries as per documentation (DVCC on, SVS and STS both off). This is now the same as already in place for various other battery makes.
• Detect- and for good settings for- BMZ ESS Batteries: DVCC=ON, SVS=Off, STS=Off
• Force-enable SVS for the Lynx Smart BMS
• Add custom name support: user and installer can configure a name for the battery. This name is stored on the GX device.
• Only use the selected battery monitor; affects systems that have a managed battery and a BMV (or similar) Victron battery monitor installed.
• Fix bug: Shared Temperature Sense did not work between an temperature sensor attached to the GX device and VE.Can devices. Bug in Venus since v2.40.
• Automatically switch to charging if a grid connection is available and a managed battery requests charge. Currently only Pylontech and some BYD batteries support a charge request indication
• Stop solar chargers when the BMS is disconnected in an ESS system. Solar chargers will show error #67 – No BMS.

ESS:

• Change the "Total of all phases" mode to be symmetrical: all phases are adjusted to convert the same amount of power from, as well as to, DC. In the past, this option primarily avoided passing power through the DC-bus to avoid inefficiency, but didn't take full advantage of the billing arrangement to use all the available power when there is a shortfall on another phase. Now it divides the work equally across the phases, thereby making the full inverter capacity available, and with no impact on billing. More detailed text on the Community v2.80~16 beta announcement, and soon in the manual.

VRM Portal:

• Add information to show detailed Generator information (running/not running, last run, why its running, and more) on the VRM Portal Dashboard, when enabling the Detailed view.
• Add information to show detailed information about AC input (grid/shore) as well as AC Loads. Includes frequency and other information.

Inverter RS:

• complete the support for the Inverter RS. Includes DVCC, control by managed batteries, SOC sync and Extra battery current, showing its error code.
• remove support when connected on VE.Direct. From v2.80 onwards, the only working connection for an Inverter RS to a GX device is on a VE.Can network.

MultiPlus-II 2x120V:

• Show output current & power on the second leg, as well as transmit that to VRM for logging and visualisation on the dashboard.

HTML5 Marine MFD App:

• Fix Garmin MFD issue that appeared in a certain start-up sequence, this issue most likely existed in the design since the beginning.
• Show the inverter/charger widget even when the AC Inputs are configured to Generator or Not available.
• Fix fault description for non-VE.Bus chargers
• Fix on/off state buttons for non-VE.Bus chargers
• Add lock button that helps prevent accidental button presses like "Start generator" or "Multi Off".
• Add Dutch, Chinese, French, German and Italian to thelanguages.
• Add a placeholder & message in case no data is present.
• Add 3A button to the input limit selector.
• Hide 3rd phase in case of a split-phase system.
• Fix keyboard buttons not working in Remote Console.

Various:

• Reduce GX device CPU load for many system types.
• NMEA2000-out: fix Solar sender DC instance storage to non-volatile memory. This never worked right, until now.
• Update recognition of Fimer grid-tie PV Inverters: Fimer recently acquired ABB and is now updating the names and recognition strings in the code.
• Increase the maximum possible power value for starting a generator, was 100kW now 1MW. Thank you Jens-Uwe P for reporting.
• Tank inputs on Cerbo GX and Venus GX: increase max tank resistance to 300 Ohm, thank you Alex Muir for asking.
• Improve WiFi recovery from Failure status.
• Improve ET340 in combination with Zigbee link, when installed in a lossy/noisy environment.
• Fix connection issue with FzSonick batteries, using the RS485-USB cable. Issue was introduced in v2.73.
• Support exfat filesystem, for large removable media (sdcards, usb sticks). Note that this is not for the raspberrypis, since (only they) still ship with a version of Linux that does not support exfat.
• Remove transmission of load averages to VRM. Those values, visible on the diagnostics page on VRM, are not used, confusing, and the D-Bus RTT time is a much better indicator of (over-)load of a GX device, hence remove them.

User interface (CCGX, GX Touch, Remote console):

• Add eject button to the offline firmware update menu.
• Fix issue that caused the overview to change when switching off the Multi in a system configured for ESS
• Fix an issue where the grid meter reading disappeared from the gui when the Multi is off
• Slightly renamed a few VE.Bus errors and error 8 & 11 detailed status codes to be less ambiguous. And VE.Bus error 15.
• Wifi menu: ask for confirmation before forgetting/disconnecting from a network, as well as before disabling the Access Point; to prevent accidental locking oneselves out, especially when remote.
• In the WiFi connection menu, give so-called hidden WiFi networks a name (their mac address), so that they no longer appear as empty rows in the menu.
• Fix missing "Recharge" text in ESS BatteryLife state field. It said "Uknown" since Venus OS v2.20.

Bluetooth:

• Fix Bluetooth pincodes starting with a 0; this was broken since the first release of BLE functionality in Venus OS.
• Implement keep-alive functionality: improves robustness with certain phones by avoiding Venus OS thinking its still connected and then remaining connected while its not.
• Fix GX device not being visible on other phones while already connected to one. Now it is visible in the 2nd phone, but then with an explanation that to connect, the other phone needs to actually disconnect first. This is now on par with how other Victron products work with Bluetooth.
• Improve compatibility with USB-bluetooth dongles, relevant for CCGX and Venus GX.

Developers, ModbusTCP, Node-RED, MQTT:

• Removed the Pv/Current path aka register from our internal databus. D-Bus. Going forward, to use that, you need to calculate it by dividing the power by the voltage. Affects all APIs, including Modbus-TCP.
• Fix the definition for Modbus-TCP register 2710 (DVCC override charge voltage). Since the mistake rendered it largely useless, and this is a fairly new register, no new register is allocated.
• Change the rootfs to be default read-only. Careful, this is quite the change in case you're modifying your rootfs. The reason behind this is quality and robustness. Every boot is now the same, instead of an initial boot possibly being different from the second or the third. And less writes to the storage, which reduces the wear, and more advantages. The downside is obviously that its a bit more hassle in case you want to modify the software. To learn how, read this commit.
• Change the used Open Embedded release from Zeus to Dunfell. More details about OE releases are here. Dunfell is relatively recent LTS (long term support) version. The expectation is to be able to stay at Dunfell for quite some time to come.
• Change the used Python version from v2.7 to v3.. This was something we needed to do anyway, and sort of a requirement that comes with switching over to Dunfell. For those that wrote their own code this does mean work. See also this post on community.
• Enable https support for php

I have recently started having a problem that the system has become unresponsive 4 times over the last three weeks. It had a Raspberry Pi 3B+ running Venus OS large v2.80~33-large-24 during this period . My system is on a narrowboat and has a SmartSolar MMPT 100/20, SmartShunt and Phoenix Smart Inverter 24/1600 and the LAN and internet access is provided by a dedicated tethered Android 4g phone. All the incidents were very similar in that:

• The VRM portal stopped updating and all access was lost to node-RED
• SSH Access was lost to the Pi on the network whilst other devices connected and worked including internet access
• Victron Connect could see the Raspberry Pi using Bluetooth but not connect
• Wifi in the Raspberry still seemed to be connected to the local network but even a ping did not get a response.
• It may be a coincidence but I previously had several months operation without a single access problem with Venus OS 2.73 or 2.80~21-large-23

Initially I thought the OS was completely dead but I found some log files in /data/log and there are major changes at the time the portal updating stopped in the messages log files but it is not obvious to me what has happened. There are no actual errors showing and the kernel still seems to be running. I am not sure where to look for further information and am not familiar with the log file structure in the Venus OS.

I have attached the last two log files, (I had to add the .txt before it would accept them). The last portal update was at 16:01 on 20/01/2022 which is in messages.0 at about line 991. I also have a clone of the SD taken on a separate machine before I restarted the Raspberry Pi 3B +

The above was posted as a potential problem with the Venus OS large v2.80~33-large-24 here as I previously had several months operation without a single access problem with Venus OS 2.73 and then 2.80~21-large-23.

@mvader (Victron Energy) pointed out that the log file showed WiFi issues. For example:

Jan 16 13:13:48 raspberrypi2 daemon.notice wpa_supplicant[742]: wlan0: Trying to associate with SSID 'Big Blue'
Jan 16 13:13:51 raspberrypi2 daemon.notice wpa_supplicant[742]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
Jan 16 13:13:51 raspberrypi2 daemon.notice wpa_supplicant[742]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=1 ssid="Big Blue" auth_failures=1 duration=10 reason=CONN_FAILED
Jan 16 13:13:51 raspberrypi2 daemon.warn connmand[673]: Skipping disconnect of 42696720426c7565_managed_psk, network is connecting.
Jan 16 13:14:21 raspberrypi2 daemon.info connmand[673]: Connection Manager version 1.33

shows a connection failure followed by a restart of the connection manager (connman) and had nothing to do with Venus OS large in itself. He suggested this should be moved to the community area for further discussion.

messages.0.txt

messages.txt

hey,
how can I control the relays via Venus OS?

[image]

Hello,

since i am using a small system with a smartshunt, a Smartsolar 100/20 PV Charger and a Blue Smart 230V Charger there is no need for me to display the red and green fields. Can i somehow remove them on the Dashboard. My Version is 2.73

I‘m running it on an raspberry pi 3b+

any help would be appreciated

thank you

UPDATE 2021-01-11: see accepted answer, the green one - usually on top.

ORIGINAL

Hi all,

As some of you know, Venus OS for raspberrypi is a hobby project by our developers, worked on in their free time.

And raspberrypi4 support has been wanted and asked for since a while now, as thats the now commonly available raspberrypi model.

We hoped and waited for someone in the community to step up and do the work, but that didn't happen. Perhaps too specialised a set of skills required (openembedded, linux, and-so-forth) - and I must admit that its quite the time investment to work on that.

Anyway, the good news is that we have a new set of images available. One image for the raspberrypi2 and 3, and another for the raspberrypi4.

So now, rather than looking to - or waiting for - the community to do the development work, we're hoping for people to do the testing work. Welcome to comment what work in your system and what does not.

Enjoy, Matthijs

Changes compared to our existing raspberrypi images:

1. Update linux from 4.9 to 4.19
2. The whole sdcard is now used and roughly 1/3 is assigned to /data
3. both root filesystems are also increased to roughly 1/3 each
4. u-boot settings are now stored redundantly on the sdcard; the FAT

   partition is no longer written to.

Not much has been tested, so the question is how many thing still work.

Note: these images are intended for that, testing, don't use them in anything serious. There are no automatic updates / bug fixes e.g.

This code is open source, and the changes are in this branch: https://github.com/victronenergy/meta-victronenergy/tree/WIP_rpi4

Downloads:

• raspberrypi2 and 3: http://updates.victronenergy.com/feeds/tmp/venus-image-raspberrypi2-20200517094246-v2.60~22.rootfs.wic.gz
• raspberrypi4: http://updates.victronenergy.com/feeds/tmp/venus-image-raspberrypi4-20200517094427-v2.60~22.rootfs.wic.gz

Note that they are full images. Its not possible to install it as a .swu file. They need to be burned to an sdcard, which erases all contents on that sdcard. For detailed instructions, see the Venus OS on raspberrypi instructions.

Things to test

Report results in the comments and answers below. Always include the exact model of RaspberryPi you are using please, and just to make sure there are no confusions, report firmware version & build number of Venus OS that you are using too.

I am considering making some changes to the partition and file-system in my Venus OS Large version 2.80~33-large-24. I currently have a couple of 64 Gbyte cards bought as Black Friday bargains but want to use smaller cards in the future as most of the space is wasted. Currently the rootfs ext4 file systems do not fill my partitions leaving 19.6 Gbytes unused and un-formatted in each partition whilst each actual ext4 file system already has 91% of 1.2 Gbytes occupied. I also understand that the rootfs is now read only which has a number of consequences including an inability to add packages with opkg.

I have cloned and backed up my existing system using dd on a standard Linux desktop (Mint Cinnamon flavour) and I am using gparted. I understand there are various changes made to the rootfs portion during [major] upgrades but do not understood what exactly is done or may be done in the future. Ideally I would like to reduce the two rootfs partitions and increase their file-systems to fill them allowing extra headroom for the future and possibly return them to read/write. I should then be able to clone onto a smaller microSD card whilst retaining a generous data partition.

But what will happen at the next update to such a non standard configuration? Any advice welcome.

As this is my first post I should note I have filled in my profile with some background information.

Just finished the beta phase. v4.0 now released

This is a major rewrite to SetupHelper.

It uses menus in the Venus GUI to control automatic and manual downloads and installs, uninstalls.

You no longer need a command line to install my packages. Blind install SetupHelper, then use the menus for everything else.

NOTE: this is beta software and you can expect bugs. Also, please report issues in the repo.

Packages are auto discovered by their existence in /data, so if you have some packages already stored in /data, they should appear in the versions menu.

Default packages appear in Package Editor when Add Package is chosen.

Current version is v4.0, and available here:

https://github.com/kwindrem/SetupHelper/

just download venus-data.tgz and follow the blind install instructions in the ReadMe.

You can leave the branch set to beta to participate in the next beta phase, or change the branch to "latest" to stay on the latest released version. The beta tag will continue to point to the latest version whether it is a released or a beta version.

As always, please report any issues or if you have questions

Hello All,

I have been digging through my Cerbo GX settings trying to find a way to display data from both of my PV controllers on the main screen. I found this image online that shows exactly what I'm trying to do.... Any idea how to get this additional data to appear on the display as shown below?

[image]

Since there is currently no support for rpi 4 v 1.4 I post the latest original venus-os images with kernel v. 5.10.92-v7l+ and a folder with all overlay files from this kernel compile

venus-image-raspberrypi4v1.4-v2.80_41.rootfs.img.gz

venus-image-raspberrypi4v1.4-v2.80_41-Lage.rootfs.img.gz

Google Disk

I cannot for the life of me get DC Feed-in working.

Gear:

Multiplus II 5000

2x 150/35

Batrium BMS to 45kwh Lion battery

A stack of AC solar on the AC Input side

EM24 grid meter

EM24 - to measure AC solar production.

Scenario:

Battery full 4.1v per cell or 57.4v

BMS sending CCL of 0

DC Feed-In enabled

Settings:

MPII and MPPT float / absorption set to 57.4, However it doesn’t seem to make any difference as I’ve set these higher without effect.

What Happens:

With DC Feed-in enabled the MPPTs correctly go flat out. However rather than the power being inverted by the MP II and going into the grid, it goes into the battery despite it being full.

If I disable DC Feed-in the MPPTs correctly ramp down (because the battery is full)

I cannot get a safe system with DC Feed-in enabled -

It will cook the battery.

From what I can gather, my BMS is sending the correct target voltage 54.7 and correct CCL of either 0 or 0.5 ( the balance current)

I see many other posts with DC Feed-in issues but none with any resolution to this specific issue.

Note: I don’t have any limits on feed-in set.

any help would be appreciated.

Good morning all, and a very good 2022 to all of you.

Just now we released v2.80~36 for testing, various changes compared to the previous test version (v2.80~33), see below for the details.

In case you don't know what this message is about, please start with reading this link, which explains the Venus OS beta program.

v2.80 summary

The version we're working on, v2.80, has various highlights: the new AC Load monitoring, the new DC metering function, and also various improvements to the HTML5 MFD App including addition of translations, added support for the Ruuvi Tag wireless temperature sensors, and since this version it adds relay control by temperature.

What to test?

Same as before: the new features I mentioned in the above summary as well basically everything:

There are several major changes in v2.80, which can each make things break in unexpected places. For those interested in the details, the changes I'm referring to here are (a) that the used Python version has been updated from 2.7 to 3, (b) the Open Embedded release was upgraded from Zeus to Dunfell, and we changed to a read-only rootfs. Also, various application level changes that reduce the CPU load per Victron device, useful when connecting many solar chargers for example, were made. That caused some regressions earlier, which are now fixed.

How to post an issue?

Preferably all issues are 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 here on community.

Lastly, please first revert to v2.73, 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 one of the first things that needs doing in triaging a report is distinguishing between the two.

The plan for v2.80

We're (still) speeding up now, to make this final as soon as possible.

Change log below.

All the best and have a good 2022!

Matthijs Vader

v2.80~36 change log, comparing to v2.80~33

• Fix the unit for the pressure (kPa -> hPa) in the gui, for the Ruuvi sensors
• Give hidden wifi networks a name (their mac address), so that they no longer appear as empty rows in the menu
• More Multi RS (add ModbusTCP registers, add transmission to VRM Portal)
• Remove transmission of load averages to VRM. Those values, visible on the diagnostics page on VRM, are not used, confusing, and the D-Bus RTT time is a much better indicator of (over-)load of a GX device, hence remove them.
• HTML5 MFD App: Fix missing Chinese font for Garmin MFDs and other MFDs that do not carry those fonts natively.
• Ruuvis: include status info in transmission to VRM, needed to fix hanging sensors on VRM Dashboard and other places in VRM.

v2.80~33 change log, comparing to v2.80~32

• Add relay control based on temperature. For now, the best explanation about the new feature is here: https://github.com/victronenergy/venus/issues/721#issuecomment-991024894.. One remark: please do not post on that issue on github. Any remarks, questions and so forth can go down below in this thread on Community instead
• Changed atmospheric pressure from kPa to hPa since thats the more common unit for that. Note that this will mess up graphs on VRM, to be fixed later - and probably means some data of past weeks will have to be deleted from the database
• Add SOC sync and Extra battery current for Inverter RS and Multi RS.
  • SOC sync: For systems with a dedicated battery monitor, such as BMV or a Lynx Smart BMS, that SOC is auto-synced to the RS, so that the RS can use it for controlling a relay for example.
  • Extra battery current: for systems without a battery monitor but with Solar chargers, the current as reported by the solar chargers it synced to the Inverter RS or Multi RS, where they'll use it for their SOC calculations.

Changes between v2.80~29 and v2.80~32

• Further complete the support for the Multi RS. In more detail, a page in the UI has been added
• Change how Shared Voltage Sense, Shared Current Sense and Shared Temperature Sense are transmitted out on VE.Can; note that this still needs further improvements, coming in the next v2.80 update.
• Inverter RS: Add showing an error - if there is an error
• Reduce CPU load induced by Fronius, SMA and other PV Inverters.
• Fix bug where Shared Temperature Sense (STS) did not work between an analog temperature sensor connected directly to a GX Device and VE.Can-connected chargers such as MPPTs. This bug has been in the system since its introduction, approx v2.40, and does not affect any other combinations.
• Add various data to allow the details in the Generator block on VRM Dashboard. See one of the slides in here and then the orange star.
• Add transmission to VRM of humidity % as well as barometric pressure of the wireless Ruuvi sensors.

Developers, ModbusTCP, Node-RED, MQTT:

• Note that, throughout various v2.80 beta versions, we removed the Pv/Current path aka register from our internal databus. Going forward, to use that, you need to calculate it by dividing the power by the voltage.

Various fixes for regressions introduced earlier in v2.80 development:

• Fix poor wifi performance that either in some or all cases occurred when enabling Bluetooth connection to the wireless temperature sensors. Introduced earlier during v2.80 development
• Fix bug in NMEA2000-out. The PV array current (Amps) was no longer transmitted. Bug was introduced earlier during v2.80 development.
• Fix issue in Generator Start/Stop. Bug was introduced earlier in v2.80 development. Thank you @Kevin Windrem and @Elimac for reporting.
• Fix bug where data flow from VE.Can connected devices could get stuck after a connection issue. Bug introduced earlier during v2.80.

Changes between v2.80~24 and v2.80~29:

• Support SmartShunt DC Energy meters configured as "DC System". Two things happen when one or more SmartShunts are configured as such: (1) the power shown in the DC system box is the sum of powers reported by all SmartShunts configured as such. Allowing multiple meters is done to accommodate for example a catamaran, then you can measure the DC Systems on Port side and on Starboard side. Use the Custom name setting to give each of the meters configured as DC System their own name. (2) the DC System Current is being compensated for when setting DVCC charge current limits to Multis, Quattros and Solar Chargers. Which in more detail mains that for example when a load of 50A is being measured, and CCL by the battery is 25A, the limit given to the Multis & Solar Chargers is 75A.
  
  And the notes: (A) instead of a SmartShunt, also a BMV-712 can be used. (B) Setting it to be a DC System is done in the settings of the BMV/SmartShunt itself.
  
  
• VRM Portal Connection: prepare for more details on Generator box on the VRM Dashboard.
  
  
• Reduce CPU load. By making various changes, all relating how the different software components exchange their data, the CPU load is reduced. Note that by how much this is reduced, and if and how this changes the maximum number of connectable devices is not yet known, we still need to measure that in detail.
  
  
• Fix broken status updates during VE.Bus (Multi/Quattro) firmware updates
  
  
• Fix missing "Recharge" text in ESS BatteryLife state field. It said "Uknown" since Venus OS v2.20.
  
  
• Fix Garmin MFD issue that appeared in a certain start-up sequence, this issue most likely existed in the design since the beginning.
  
  
• NMEA2000-out: fix Solar sender DC instance storage to non-volatile memory. This never worked right, until now.
  
  
• Fix support for Multi firmware versions prior to version 153. This was broken in v2.80~2.
  
  
• Some more VE.Bus protocol related stability improvement, mostly affecting quite specific systems or circumstances.
  
  
• Update recognition of Fimer grid-tie PV Inverters: Fimer recently acquired ABB and is now updating the names and recognition strings in the code.

Previous changelogs:

• v2.80~29: https://community.victronenergy.com/questions/108453/venus-os-v28029-available-for-testing.html
• v2.80~24: https://community.victronenergy.com/questions/104939/venus-os-v28024.html
• v2.80~21: https://community.victronenergy.com/questions/102911/venus-os-v28019-available-for-testing.html
• v2.80~17: https://community.victronenergy.com/questions/101754/venus-os-v28017-available-or-testing.html
• v2.80~16: https://community.victronenergy.com/questions/100658/venus-os-v28016-available-for-testing.html
• v2.80~14: https://community.victronenergy.com/questions/98618/venus-os-v28013-available-for-testing.html
• v2.80~10: https://community.victronenergy.com/questions/97155/venus-os-v28010-available-for-testing.html

Complete v2.80 change log, compared to v2.73:

(still..) no time for that now, I'll make that later.

Good morning!

A new version is available for testing. Changes compared to previous one, v2.80~36 are:

• User interface around configuring the relay control by temperature has been improved
• Fix Ruuvi sensors not showing up for relay control by temperature.

All the best, Matthijs

Ps. for more details on v2.80, see https://community.victronenergy.com/questions/114181/venus-os-v28036-available-for-testing.html

Hi all, I have a Cerbo GX with the large image installed and running Node Red. It is connected to a lithium battery with a JBD BMS, which is interfaced using the driver here: https://github.com/Louisvdw/dbus-serialbattery/

Everything seems to be working fine, except I was really hoping to get access to the min/max cell voltages within Node Red. I can see this data on VRM, and using dbus-monitor while logged into the cerbo I can see that /System/MinCellVoltage and /System/MaxCellVoltage are being updated regularly. Looking through the node-red-contrib-victron repo it seems that this data should be available under the battery monitor node, but it is not showing up in the drop down. Nor is it in the System node.

Is this simply a case of the Large image containing an older version of the node red nodes, or is there something else going on here?

Thanks!

Info only for those who are interested.

the below works on all 123 smart BMS - Gen 2 and Gen 3 BMS systems.

GX Units MUST BE on FW 2.80 or latter

123 smart have released a free app that installs to all GX devices, they can also supply a small USB interface /or you can supply your own - that connects to the 123 end board ext data out connection and then via USB to the Cerbo,CCGX,Venus

this then adds another battery monitor to the system if you have more than one

you can also add extra 123BMS USB interfaces if you have more than one BMS to monitor

you can then see the Highest and the lowest cell voltage

also if a high or low even occurs then a alarm is sent to the notifications area.

The software is added by inserting a sdcard into the gx units SD card slot, Softare can be downloaded from 123smarts site. Download site HERE

(Edited 23/01/2022 ) I now used Kevins GuiMods program to install - as onced the GuiMods Package manager is installed you can also select to install the 123smart BMS software = Plus GuiMods updates the software if a new release is issued by 123 = Download Gui Modes Here

Copy of the screen displays are below.

[image]

[image]

[image]

[image]

Hi,

The latest release (38) appears to have removed my Ruuvi temperature sensors.

[image]

thanks in advance

Hello All ,

I have a victron system using a victron Cerbo Gx. I have a smart shunt in line with my house battery bank. I would like to monitor my wind generator. I was thinking of using a second smart shunt inline with the wind generator to do this.wile there are no guide lines to do this I think this should work, any thoughts?I have an Eclectic Energy D400 wind generator

As GoogleGroop die...

In the https://github.com/victronenergy/dbus_modbustcp/blob/master/CCGX-Modbus-TCP-register-list.xlsx specified follow d-bus gps (gnss?) paths:

/Position/Latitude
/Position/Longitude
/Course
/Speed
/Fix
/NrOfSatellites
/Altitu

But in really on venus-image-raspberrypi2-20220115193611-v2.80~38.rootfs.wic I also see

gps/0/Mgmt/Connection 
gps/0/Mgmt/ProcessVersion 
gps/0/Mgmt/ProcessName 
gps/0/Connected 
gps/0/DeviceInstance 
gps/0/HardwareVersion 
gps/0/FirmwareVersion 
gps/0/ProductName 
gps/0/ProductId

What does "Mgmt/" mean?

What does "Connected" mean?

I'm using Venus OS 2.73 on a Raspberry Pi 2B+ with a Wifi dongle.

Wifi works fine, but after a while Venus OS goes offline and shows "error" on the Wifi, and I have to manually reboot the Pi. I know, there's a "power saving" mode in Raspberry Pi regarding Wifi and normally I would add to my /etc/network/interfaces

wireless-power off

But from what I see inside that file, connman is used for Internet connectivity, which I don't know and I didn't find powersaving options in connman man-pages...

Is there some way I can deactivate power saving - or do something on my Pi losing Wifi? (the router is right next to the Pi, so signal is strong enough.

strangely enough, power_save seems to be off anyways:

root@venus:~# iw wlan0 get power_save
Power save: off

Could you post a simple example of a python program to log in to VRM API and return a piece of data, eg SoC of batteries please? I have been going round in circles for hours and just can't get the simplest thing to work!

I have a Venus GX and a Teltonika RUT955 router installed in my motorhome. The router has a separate GPS antenna and aware of the current location. I was wondering if there is any way to transfer this to the Venus GX device and then to the VRM portal?

The router has RS232 and RS485 ports, it also supports Modbus TCP. It is highly customisable so I was wondering if there is any way VGX can receive it? Which would be the easiest way?

Hi,

We're using the Victron API for M2M backend communication and we use the "personal access token" approach for authentication.

Following the 8.4.3 point of the documentation https://docs.victronenergy.com/vrmapi/overview.html#revoke-a-personal-access-token, a GET request is required for the API to revoke the tokens.

The headers we send to the revoke API at the:

{'X-Authorization': 'Token ...'}

The URL is:

https://vrmapi.victronenergy.com/v2/users/.../accesstokens/.../revoke

The problem is that the API returns

HTTP 403 Forbidden url for...

Could someone help us?

Cheers,

Ivaylo Donchev

OR - Do i connect the converter panel to my "LOAD" and remove the ability to have the battery charge when on "SHORE POWER"?

Here is what i have now.

[image]

[image]

[image]

I hope this all makes since.

Many of you already know about my driver for the Morningstar Tristar MPPT controller but thought I should post it here now that we have a mods space :-)

Ready to install binary under releases:
https://github.com/osaether/dbus-tsmppt

Can i run multiple remote on off connections in parallels off the BMV712 smart relay output

I want to switch off all mppt devices and an Orion dc/dc if ever and when battery reach's 14.5v as an added level of overcharge protection....it appears so??

Since a while I wanted to have my Minimum SoC setpoint controlled by weather (solar yield) forecast and others parameters. So in the end to get a dynamic SOC control.
After digging into the matter I have a solution that might be interesting for others too.

[image]

@Guy Stewart (Victron Community Manager)

Is it possible to launch and display the Node-RED dashboard, directly on the Cerbo GX - Touch 50 display?

Like swiping left and right between different default Venus OS screen layouts, could the Node-RED dashboard perhaps be accessible this way, as a fourth screen layout?

Thanks, Anton

The new and updated Raspberry Pi Zero 2 W was just released. Will it be possible to run Venus OS Large on it? It seems to be pretty much an RPI 3 but with a lot less power consumption.