Hello,
seams there is something wrong with Node-Red and virtual switches in v3-70~54.
My DemoSwitch.flow was running fine on v3.70~49, with ~54 switches randomly disappear , Venus restarts is very slow ….
here the flow I use for demonstrating the really genius new features of Venus OS & NodeRed.
TestCaseAllSwitches.zip (1,8 KB)
@mpvader Had it again yesterday. It’s not related to the amount of time the Cerbo has been down. I upgraded to ~54 yesterday evening and VRM again shows Energy forward as Total energy forward for that day.
Basically as long as you do not reboot (upgrade?) the Cerbo the Energy forward correctly represents the consumption for any given timeframe.
I guess this is not so much a 3.70 beta bug. Maybe @Barbara can have a look ?
If these are different virtual device types, that is allowed. So a virtual battery and a virtual grid meter can both have id 100.
Can you give that some more context? Where do they disappear from? From Node-RED? Or from the gui? On the local display? Locally via the LAN? Via VRM?
switches disappear from Gui, it happens after one or 2 deploy, in my video switch 06_drop is not on gui~54.
I do not have a local display, only LAN & VRM, Venus OS becomes very slow , gui-v2 sometimes looks frozen, uploaded Video and flow below.
There is no Hardware connected to the Cerbo except a BMV-700, I only use it for Node-Red and Beta Tests
V370-54_Switches.zip (7,4 MB)
Thanks for the extra info and the videos. I’ll try to recreate the issue on my system to see if I can get some more debugging info on the cause.
@Barbara Reading your other post concerning the low amounts of meters having the heat pump role to train the new model for heat pumps. I guess you will get a lot more data to work with if Virtual Devices and the new Shelly support allows for the heat pump role. At the very least it will prevent you from having to work around the data from an increasing amount of users injecting stuff on dbus themselves as not all will get it right from the get-go 
You can always reboot to the previously running software version, check the relevant firmware menu in the UI.
So if you upgraded your GX from v3.70~49 to the ~54 version, you can just reboot back into ~49.
I’m also keeping offline copies of the beta versions, just in case
Additional infos:
did a reset of the Cerbo GX to Einstein 3.66 image than updated to 3.70~54 large seams to be stabil after I synchroniced all names , device - switch - node name, but after some deploys looks likeorder of switches changed (02 .. on top, 01.. on bottom) than the failure was back again.
During this test I observed an other phenomena (looks minor but possible it helps),
when changing the device name in GUI the name in the headerline is changed to the different name
Hope this helps
btw. had 2 findings whereI did not get any feedback (#135)
Since the update to 3.70~54 (updated from 3.70~44) my EVCS is displaying unrealistic charged values:
When I log into the EVCS directly, I get the correct value:
Do you have a switchable device? Looks like those can only have the “acload” role unfortunately: dbus-shelly/shelly_device.py at master · victronenergy/dbus-shelly · GitHub
I’d also like to use an Shelly Plus 1PM as PV inverter
Hi,
during testing switches found a minor bug in translation of “current measurement” into “Strom”(DE) of ”Stroom” (NL).
They say it has been reported and will be fixed. The good news is that it is actually for a good reason. The old path becomes the total path (hence the error) and a new path will be used for session kWh. Now the Cerbo has both numbers!
Same, I think /Ac/Energy/Forward used to give charged energy current/latest session. Since last release it shows total energy charged all sessions
@kudos50 Do you know if the session energy will be available in nodered too?
Can’t speak for Victron but if it’s on the bus and not yet part of the evcs node, you can create a custom node to get it out I guess. That’s what I did before Victron even made the EVCS nodes.
total is now /Ac/Energy/Forward and session is added as /Session/Energy. Brilliant. It allows me to finally stop using the direct modbus connection to EVCS from HomeAssistant and instead get all I need from the MQTT bridge.
If it is on the bus I can get it in node red. I used to get total energy in nodered from two registers on the bus. Getting it directly is much easier.
Would be nice to control an Shelly Dimmer on every Channel of its 4. Actually i can only control Channel 1.
I would spend some time to improve DESS simply because this is the main function of a battery instead of adding buttons or all this fancy Shelly stuff!
When can we expect Beta that solves all these interruptions in charge and discharge cycles?
