Closed mpvader closed 2 weeks ago
Looks like a gui-v1 vs v2 parity issue.
The feature to assume the grid is present based on the presence of a grid meter (even if the Multi is off) is new in Venus 3.50. In the past gui-v1 would have behaved exactly the same.
These two changes:
https://github.com/victronenergy/gui/commit/8794e5aed69dbeeb3b3dae246bbac4b39d7a5fdb https://github.com/victronenergy/gui/commit/dc217efd5f1337a83f232b87ae61f6ac67fc883f
So it looks like this is something that did not quite make it to gui-v2 yet.
To reproduce, you can use the attached simulation files, which emulates a Multi that was switched off at the front panel, and a grid meter.
Play with the play.py
from dbus-recorder, eg:
python3 play.py vebus.csv grid.csv
Result on GUI-v1 vs v2:
@izak
Thanks for the csv
files. I played them and the problem I'm seeing is that com.victronenergy.system/Ac/ActiveIn/Source
is not set, and gui-v2 relies on that to find the currently-active AC input, to show it on the Brief/Overview pages.
However, com.victronenergy.system/Ac/ActiveIn/ServiceType
is set to grid
as expected, so I've made a patch that checks this value in the case that the /Source
is not available: https://github.com/victronenergy/gui-v2/pull/1674
Could it be that the /Source
does not get set in the case that the multi is off?
Also, note that:
/Ac/Grid/DeviceType
; it just looks as the system /Ac/ActiveIn
details to find the AC input details. Could this create problems? Should it be checking the /DeviceType
in case /Ac/ActiveIn
does not have the correct details?/Ac/<x>/Connected = 0
for the input. However, I see that gui-v1 does not care about this /Connected
value, and shows phase measurements regardless. Should gui-v2 do the same? Is it possible for an AC input to have valid power/current even when /Connected = 0
? (E.g. in the case of a multi turned off, and we don't have complete information about the connected inputs.)When the Multi is off, there is no information about what source is active, since the transfer switch (the thing that makes the decision) is inside the Multi/Quattro and is also off.
Parts of systemcalc will make a guess (based on if there is a grid service present), but I never went as far as publishing this guess as /Ac/ActiveIn/Source. I didn't want to do that, because hub4control (the ESS loop for VE.Bus Multis and Quattros) rely on that to know when it should limit power, so changing that would have knock-on effects.
A simpler solution is probably to simply always display the power/current data, if it is valid, regardless of whether it is indicated as active. Which is what GUI-v1 does now.
As for the last question about the AC inputs having different types always: It is possible (though probably rare) for both inputs to be generators. It is also technically possible (though probably rare, and almost always a configuration mistake) to configure both inputs the same for any of the other types, so it is probably better if such an assumption isn't made.
See Izaks comment, and here kds reports it as not fixed:
https://community.victronenergy.com/t/venusos-v3-50-gui-v2-issues-suggestions/9658/35
And here are similar reports:
Another report:
A simpler solution is probably to simply always display the power/current data, if it is valid, regardless of whether it is indicated as active. Which is what GUI-v1 does now.
Okay, will make this change for this task, thanks.
As for the last question about the AC inputs having different types always: It is possible (though probably rare) for both inputs to be generators. It is also technically possible (though probably rare, and almost always a configuration mistake) to configure both inputs the same for any of the other types, so it is probably better if such an assumption isn't made.
This change will need a bit more work and sounds like a lower priority; have made a 1.1.0 task here: https://github.com/victronenergy/gui-v2/issues/1688
Fixed merged; closing.
Fixed for this user 👍
https://community.victronenergy.com/t/grid-not-showing-in-v3-50-on-quattro-ii/9768/3
Now there is a new problem. Before the grid was shown correctly, now it is not anymore. v3.52~2
Another positive feedback:
https://community.victronenergy.com/t/gui-v2-is-showing-grid-as-disconnected-while-its-not/8779/4
Hey @mr-manuel you are running a mod there, right? Ie not a standard victron system.
Pls post the vrm url - thanks.
I'm running virtual components that reflect 1:1 my productive system. I messaged different VRM systems to bea. You need them too?
I made a few more tests. If I reboot I get the problem as in my post above on the device display and WASM build. When I wait a bit and reload the WASM build it shows correctly. If I restart the GUI service for the device display it also works on the display.
Seems that something is stuck until something else is fully loaded.
I made a few more tests. If I reboot I get the problem as in my post above on the device display and WASM build. When I wait a bit and reload the WASM build it shows correctly. If I restart the GUI service for the device display it also works on the display.
Thanks for the details, I will take a look.
Grid & genset reversed? https://community.victronenergy.com/t/3-52-2-grid-and-genset-reversed/10948
And, someone else reports similar issue as @mr-manuel :
More fixes:
@blammit , aside from field testing/confirming this is all done now, right?
then lets close the issue
Yes, correct. Closing.
See https://community.victronenergy.com/t/some-failure-with-em24-and-gui-v2-on-v3-50-37-and-34-also-now-vrm-data-is-missing/8779/1
@izak pls triage and if indeed gui-v2 issue then prepare a recording, or other instructions for Qinetic to reproduce, fix and test it.
no need to fix or report this on vrm yet.