question

mvader (Victron Energy) avatar image

Venus OS v2.80~16 available for testing

Hello this Saturday!

The short detour to v2.73 is over. A new v2.80 version is available for field testing, v2.80~16. For the release blog post of v2.73, see here.

In case you don't know what all this is about: this message is part of the Venus OS Beta test program. Read that link for more information.

By now, v2.80 is has some quite noticeable new features. For example the completely new AC Load monitoring, the improvement in the Total of all phases mode for ESS, the new DC metering function and still more.


What to test?

The new features I mentioned just now. As well as, just like announced previously, basically everything: there are several major changes in v2.80, which can each make things break in unexpected places. The first change is that the used Python version has been updated from 2.7 to 3. Also the Open Embedded release was upgraded from Zeus to Dunfell, and lastly we changed to a read-only rootfs. All combined this means that (a) lots of tools and packages used will have changed to a newer version, and (b) lots of Victron code has been changed to be compatible with Python 3.


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, if possible please revert to v2.72, 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 with v2.80

Development and testing will continue for quite a while; I expect at least until late September; possible also into October this year.


Changes since previous test version, which was v2.80~14:

  • Add AC Load monitoring. 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.
  • 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.
  • Fix the MFD HTML5 App, a regression introduced earlier in v2.80 broke it.
  • Slightly renamed a few VE.Bus errors and error 8 & 11 detailed status codes to be less ambiguous.
  • Managed batteries & DVCC
    • add support for charge request message by the battery: if the battery signals that it needs charging, then the Victron system will do so when possible: AC must available on the input. Affects only ESS, and then more specifically one of the Optimised modes, not the Keep batteries charged mode. The GX device will not auto-start a generator for this.
    • detect BMZ-ESS batteries. Next step is to force-enable DVCC for them.
    • add custom name support: user and installer can configure a name for the battery. This name is stored on the GX device.
    • Remove managing Phoenix Inverters VE.Direct with DVCC. This was added earlier during v2.80 development, but doesn't work well; and will not be added back anytime soon. The Inverter RS is still supported.
  • Developers: dbus-mqtt: fix regression introduced earlier in v2.80, that broke it: the (now legacy) method of doing a keepalive when sending messages with a payload. Thank you scuba-shan for reporting that.


Picture: the new AC Load option:

1630759612633.png


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

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.

DVCC & managed batteries:

  • 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.
  • Add full support for the Inverter RS, including CVL, CCL, SVS, STS and SCS.
  • Switch off inverters when a managed battery says DCL=0, same as how that works for inverter/chargers already.
  • Only use the selected battery monitor; affects systems that have a managed battery and a BMV (or similar) Victron battery monitor installed.
  • Add support for charge request message by the battery: if the battery signals that it needs charging, then the Victron system will do so when possible: AC must available on the input. Affects only ESS, and then more specifically one of the Optimised modes, not the Keep batteries charged mode. The GX device will not auto-start a generator for this. The only batteries supporting this are certain models of BYD batteries. I don't know which ones right now, I'll add more info when I have it.
  • Detect BMZ-ESS batteries. Next step is to force-enable DVCC for them, which will be done in next v2.80 version.
  • Add custom name support: user and installer can configure a name for the battery. This name is stored on the GX device.
  • Remove managing Phoenix Inverters VE.Direct with DVCC. This was added earlier during v2.80 development, but doesn't work well; and will not be added back anytime soon. The Inverter RS is still supported.

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 capacity available, and with no impact on billing.

    An example: at night, no solar, there is a large load on L1 - say 6kW. And no load on the other phases, and a 3 x 3kVA inverter/charger configuration. Old: the L1 inverter/charger would be at max power, discharging, which resulted in buying ~3.5kW. New: all three inverter/chargers are each doing 2kW, zero Watts on the meter.

    Similarly in a excess PV situation: if there would be 6kW excess PV on L1, and the same inverter/charger configuration, then in the old situation it would charge the battery with one inverter/charger only, and the rest of the power would be sold back to the grid. In the new situation, it all inverter/chargers will be charging at approximately equal power, and the total being 6kW of charger.

    Lastly, note that the balance of feeding in excess PV power coming from solar chargers, has not been changed. There is no need to actively make that symmetrical, since when there is so much energy available that its necessary each inverter/charger will automatically start operating at full power. No need to actively manage that.

VRM Portal:

  • VRM: transmit status of L2 in a North American split-phase system, to enable proper visualisation. This relates to the recently introduced MultiPlus-II 12V 3000VA 2x120V. Note that the VRM Dashboard itself still needs to work to use this information. Its the last one: all other user interfaces (VictronConnect, GX Touch / Remote Console) already show information on L2.

Other:

  • Support the new DC Monitor feature, recently released as a firmware update for the BMV-712s (v4.07) and SmartShunts (v4.07). The purpose is to be able to use those dc meters not as a battery monitor but as a dc meter. For example to measure the output of an alternator, or a wind generator. Or, measure the power draw of a certain load or group of loads. First of all to visualise it, and later it can perhaps be used in DVCC as well. Note that this release is just the first step, more coming later such as proper visualisation in the overview and VRM.
  • Add AC Load monitoring. 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.
  • 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.
  • 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.

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.

Developer / under the hood

  • 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 here this commit.
    • /opt/victronenergy/swupdate-scripts/remount-rw.sh will make it writable again (until the next swu update)
    • additional services should now be stored in /opt/victronenergy/service instead of /service or else they won't survive a reboot
    • closes https://github.com/victronenergy/venus/issues/217
  • Change the used Open Embedded release from Zeus to Dunfell. More details about OE releases are here. For a long time, Venus OS was based on Rocko. Recently we changed it to Zeus, which was an intermediary step to get to Dunfell. Dunfell is relatively recent LTS (long term support) version; so happy to be at that version, and expecting to be able to leave it at this 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.


Known issues

  • Installations with an Inverter RS connected via VE.Can might have an issue: continuous crashes of the systemcalc service. To be fixed in next v2.80 test version.
Venus OS
1630759612633.png (27.7 KiB)
2 comments
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

@mvader (Victron Energy) is there a build I can use with conman?
Hi Nick, no we didnt make that. We’ll add that wifi fix in the next candidate build; so no more special -connman builds
4 Answers
dennis avatar image
dennis answered ·

Thanks for the update. Symmetrical phase compensation seems to work very well.

Is there any new behavior with the intervall of publishing values via mqtt? It seems the updatefrequency is much less then before (v2.73 -> v2.80~16).

23 comments
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Hi dennis, good to hear that that works well; thanks.


wrt publishing of values via mqtt: I'm not aware of any changes in update frequency. I'll check to make sure.

dennis avatar image dennis mvader (Victron Energy) ♦♦ ·

Hi, i am very sorry. After some investigation, i am sure, that this is not your fault.

Home Assistant with Node Red is causing this!

//EDIT: Sorry but it seems to be caused by you :-)

Update published by venus GX every ~22-35 Seconds.

bildschirmfoto-vom-2021-09-07-19-45-09.png


//EDIT2: VRM (ID14286 ) is slow in refreshing the live values, too. Maybe because of high load on venusGX?

snag-0140.jpg


root@beaglebone:~# tail -f /var/log/dbus-mqtt/current

@40000000613852271095431c Traceback (most recent call last):

@400000006138522710a10abc File "/opt/victronenergy/dbus-mqtt/dbus_mqtt.py", line 438, in _service_queue

@400000006138522710a129fc self._client.publish(topic, value, retain=True)

@400000006138522710c00854 File "/usr/lib/python3.8/site-packages/paho/mqtt/client.py", line 1269, in publish

@400000006138522710c02b7c rc = self._send_publish(

@400000006138522710c3b1d4 File "/usr/lib/python3.8/site-packages/paho/mqtt/client.py", line 2580, in _send_publish

@400000006138522710c3e884 return self._packet_queue(PUBLISH, packet, mid, qos, info)

@400000006138522710c60f4c File "/usr/lib/python3.8/site-packages/paho/mqtt/client.py", line 2927, in _packet_queue

@400000006138522710c645fc self._sockpairW.send(sockpair_data)

@400000006138522710cc6c34 BrokenPipeError: [Errno 32] Broken pipe

@40000000613852271147d5f4 ERROR:dbus_mqtt:[Queue] Error publishing: N/985dad36843b/settings/0/Settings/CGwacs/BatteryLife/Schedule/Charge/3/Day {"value": -7}

See more dbus-mqtt log with errors: mqtt.txt

dennis avatar image dennis mvader (Victron Energy) ♦♦ ·
@mvader (Victron Energy)

Did you have seen my additional info in this post?

Hi Dennis, thanks for the ping, I don't get updates about edits in to an existing comment.


To your issue: yes indeed, at 0% idle, the system won't work any more. So, try reducing the load, ie. don't run node-red. And see what happens then.

dennis avatar image dennis mvader (Victron Energy) ♦♦ ·

Hi, thanks for your reply.

I am not ronning nodered on venus. Only getting values via MQTT to my seperated nodered installation.

Do you think the nodered requests could affect this?


dennis avatar image dennis mvader (Victron Energy) ♦♦ ·

So, load ist going down, if i disable nodered. But why ... i only get some values (maybe 20) via mqtt from venus gx.

if you ask me, i would say that this is starting from the update v2.73 -> v2.80~16

Is there any info regarding performance of mqtt and how many mqtt access is good for venusg gx?

Is there any possibility to use an own mqtt server in my network to unload the venus gx?

solved in Venus OS v2.80~24 for me

gnagflow avatar image gnagflow mvader (Victron Energy) ♦♦ ·
Hello, symmetrical distribution works well with one exception.


The dashboard doesnt work anymore acceptable in my use-case. The system got slower, i mean, the real time actualisation of the values at the dashboard does not work well any more since the update. Sometimes it needs 10sec. for a new value sometimes 30sec. sometimes a minute. I use the VenusGX. I updated from an old "large" image to the 2.80.16. without any node-red etc. I turned off most services to reduce cpu usage. When i am interested into real-time values i have to open the Remote-console.



Thanks gnagflow, thats exaclty what i have, too. Additionall i use node red. And the values are much slower than in the past.

Thank you both, we'll look into this.

Wrt the questions:

> Is there any info regarding performance of mqtt and how many mqtt access is good for venusg gx?

No there is not. you can increase / decrease and meanwhile look at or plot CPU idle percentage.

> Is there any possibility to use an own mqtt server in my network to unload the venus gx?

Probably, but it involves changing the source code, quite a lot if you don't want to loose the live updates on the VRM portal.

Further discussion on those is out of scope of the beta testing, please make a new post; and in all honesty don't expect any help from my side. What we'll do now is focus on seeing if there is a regression somewhere.

dennis avatar image dennis mvader (Victron Energy) ♦♦ ·
Thanks. If possible, i will not change the source code of the system. I am pretty happy with your environment. It was totally stable the last years.

So hopefully your team will find someting. If you need more info, please ask! :-)

You do a great work!

@mvader

CPU usage is always between 80-85%. When i made the calculation algorithm for symmetrical distribution with node-red i also had this problem once, than i changed the number of calculations per time to get rid of that problem. maybe this should be adapted!?

Enclosed my cpu usage of the VenusGX and the open processes:

1632230073003.png


1632230073003.png (282.2 KiB)

its interesting that the mqtt process is using much of the cpu ressources even if i switched mqtt off:

1632230282252.png


1632230282252.png (36.3 KiB)
if i kill the dbus_mqtt.py service its always starting again.

maybe because of VRM connection?

i closed the browser with the dashboard, than it goes down to around 45% cpu usage, still the mqtt service uses 8/45%. if i kill it, it starts again. realtime dashboard is unusable.
so obviously, the dashboard gets the data from an mqtt publisher

cpu usage without DASHBOARD open in a browser:

1632232262083.png


1632232262083.png (289.8 KiB)
Hi all, this is fixed, or at least improved, per v2.80~19. Which will be available somewhere in the coming week. I typed more details in the similar ~17 thread.
dennis avatar image dennis mvader (Victron Energy) ♦♦ ·
Thanks a lot!
gnagflow avatar image gnagflow mvader (Victron Energy) ♦♦ ·

Thank you for great and fast fix! My dashboard works with v.19. CPU usage reduced from 85% to 30% with open dashboard.

1632535507903.png


1632535507903.png (316.1 KiB)
Show more comments
pau1phi11ips avatar image
pau1phi11ips answered ·
1 comment
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

hi ok, thats good to hear, thank you!
Mark avatar image
Mark answered ·

f6fa9cd8-ad51-45fc-b542-c0823e6faa0a.png

Fuel tank levels appear on the VRM, after update, even though they are not configured and can’t be removed,this issue is present on least 2 of my sites!


4 comments
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Hi Mark, did you disable them on the GX device? Please send a screenshot of those settings. Also, you might need to one time delete them from Device list on VRM.
Mark avatar image Mark mvader (Victron Energy) ♦♦ ·

20775017-a2cf-41db-9f7f-f69570b1c6c7.png8ed032fe-4da7-4356-9784-d8808b63369b.png

They only appear on the VRM, as per above

pau1phi11ips avatar image pau1phi11ips mvader (Victron Energy) ♦♦ ·
@mvader (Victron Energy) this was the same for me. I got a notification on my phone that VRM had refreshed as there was an update and the extra, unused, tank sensor was showing. It looks to have been fixed now tho.
hi both; yes fixed this morning. Thank you for the report!
Dosheimer avatar image
Dosheimer answered ·

We updated to V2.80-16-large21 on a Raspi4B 1.2 4GB last weekend. Everything fine so far except the possibility to download a config file for a multiplus in VRM (Remote VEConfigure) which worked well before the update.
1-1.jpg 1-2.jpgConnection multi to raspi is a MK3. As said, it worked a few days ago on a former Venus version


1-1.jpg (80.3 KiB)
1-2.jpg (65.0 KiB)
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.