Good afternoon!

Last night we released v1.40, with a long, long, changelog: many changes, fixes and improvements! So, please get a coffee or tea first, and then start reading. The first major change I’d like to explain is the improved data transmission to the VRM Portal:

• The option to choose between logging to SD Card and logging to the VRM portal has been removed. Instead, this is selection is now automatic: data is sent out via the Internet to the portal when possible, and the CCGX will fall back to non-volatile storage when there is a (temporary) Internet outage. The built-in non-volatile storage can contain 48 hours worth of data. To extend this period, insert a microSD card or USB stick.
• When using this external memory, the CCGX will still make use of an active internet connection to send it’s backlog. That means that even with months worth of backlog, once the CCGX reacquires an Internet connection, all of the backlog is sent out. And because of an enhanced algorithm, which includes compression, this takes considerably less time and traffic than before.
• When a CCGX is permanently without an Internet connection, one can choose to upload the backlog buffer manually. The first step is to select the eject the storage option in the menu; don’t just take out the SD card/USB stick(!). Once ejected properly the media can be removed from the CCGX and inserted into a computer or laptop and the data file on it can then be uploaded to the VRM Portal.
• Because of the aforementioned improvement in the sending data backlog, the data logging is now also highly resilient to bad internet connections. Lines of up to 70% permanent packet loss are still sufficient to get the data out, albeit a bit delayed sometimes.

Note that we’ll soon add a ccgx-storage-to-Excel-file conversion feature to VictronConnect. Analysing the data can then be done without first having to update the files to the online VRM Portal.

VRM Portal online configuration options:

New: BatteryLife in Hub4

The self-consumption principle charges the battery with excess solar energy. This principle also uses power from the battery to power the loads when the available solar power does not meet the demand of those loads. This works well for systems which have plenty of solar power available. However, this doesn’t work so well for systems where the amount of solar energy harvested in a 24 hour cycle is less than the amount of energy used by the loads.

In such a system, the battery will be empty most of the time. Let’s go through a 24 hour cycle to explain this in a bit more in detail: During the daytime, when there is a short period of excess solar power, the battery will be recharged a little. But clearly not fully charged as there is not enough solar energy available for that. And then, in the evening, it will be discharged again as consumption peaks and solar irradiation drops. Before nightfall the battery is now empty again, to be left empty all night and early morning as it waits for a little bit of excess solar energy the next day.

This problem is solved with the introduction of BatteryLife! The lower state of charge limit, initially set at 10% for example, will automatically be increased on a day where there is not enough solar energy available to fully recharge the battery, so the next day it will discharge down to 15%. In case there still hasn’t been enough power to recharge the battery, the lower state of charge limit will be increased again, and so on. This continues until it has arrived at a point where it only discharges the battery to a point where the battery is able to recharge the following day.

That lower limit will be decreased again on subsequent days when there is sufficient solar energy; automatically finding a balance, and adjusting for the seasons. For more details, please see the Hub-4 manual, BatteryLife section.

The graphs below shows a system in the Spring and the battery state of charge graphed over time. As the week progresses you can see more solar energy becomes available, and therefore you can see the depth of discharge being increased. The red line shows how this system would operate without BatteryLife.

User interface improvements

All translations have been updated. Also a memory leak has been fixed, which caused the responsiveness of the GUI to reduce over time. A noticeable improvement!

The time zone selection is improved: there are less double time zones listed, and they are ordered from East to West. Which saves a good deal of clicking when circumnavigating the globe or roaming North America in an RV:

In some installations with a VE.Bus BMS or Digital Multi Control installed, it is not possible to use a CCGX to switch a Multi on and off. The is now explained to the user with a popup.

Fixed a bug causing the screen to lock up when using Remote Console on a touch screen device, such as an iPhone.

Bug fixes for WiFi and Automatic Generator start/stop

• Installing the recovery image of v1.36 would break the WiFi functionality. That is now fixed.
• Automatic Generator Start/Stop. In v1.36 we introduced a new feature: setting what the generator should do when the CCGX no longer receives data from the battery monitor or inverter/charger. The choices are to Stop the generator, Start the generator, or keep running in case it already was running. But there was a bug in the keep running option: once started, the generator would run forever. Even when there was still data received from the battery monitor and inverter/charger. Now fixed. More info about automatic genset start/stop in the manual.
  

More changes

• Added the recently introduced Phoenix Inverters with VE.Direct connection to the list of compatible products.
• Added LG-circuitbreaker-trip detection.
• Several improvements related to Redflow ZBM battery:
  • The maintenance needed and maintenance active signals are no longer shown as an alarm to the user. Maintenance is part of normal behavior of the battery, so there is no need to notify the user, even less to force him to acknowledge an alarm for this.
  • Fixed bug: an air temperature sensor alarm was also reported as a state of health alarm.
  • Fixed bug: sometimes the clear status register bit would not be reset properly.
  • Add logging all individual Redflow batteries to the VRM portal
• Added more data to the modbustcp port: Redflow Battery data, LG Battery data, state of health, solar charger yield (kWh)
• The state of the relay on the CCGX is now logged to the VRM Portal. Handy when diagnosing a system with an automatic genset start-stop configuration. To see the log, download the csv or xslx file from the Advanced tab on VRM.
• Changed the way the CCGX responds to alarms and other data that triggers a near-immediate transmission of data to the VRM portal: it use to wait 5 seconds after an alarm occurred. And only then send data. This could cause VE.Bus Error 1 to miss in the sequence of errors: confusing when diagnosing VE.Bus issues. Now it sends the data immediately. See also this new page explaining VE.Bus errors: https://www.victronenergy.com/live/ve.bus:ve.bus_error_codes

And there are even some more changes. To go through the whole list, go to the Victron Professional Portal and download the full changelog.

Installing the update

By default, a CCGX will automatically download and install new firmware via the Internet, as soon as there is a new version available. For a manual update, follow instructions here.

That’s it for now. Enjoy the rest of the day!

Matthijs Vader

PS, a little bit of information for software developers:

• CI: we have start using a Continuous Integration server that automatically builds the whole CCGX image. CI is also being used for unit testing as well as functional tests. All this both saves time and increases the quality of the product.
• The work for the BeagleBoneBlack is progressing, see the porting venus page on the Venus wiki. What is Venus you might think? Venus is the name of all the software running on the CCGX.
• To make it easier to see what we are working on, we’ll be using the issue tracker on github/victronenergy/venus more intensively.