victronenergy / gui-v2

Other
29 stars 10 forks source link

overview issue when multi is off #1626

Closed mpvader closed 2 weeks ago

mpvader commented 1 month ago

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.

izak commented 1 month 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.

grid.csv vebus.csv

Play with the play.py from dbus-recorder, eg:

python3 play.py vebus.csv grid.csv

Result on GUI-v1 vs v2:

Selection_182 Selection_183

Selection_181

blammit commented 1 month ago

@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:

izak commented 1 month ago

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.

mpvader commented 1 month ago

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:

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

https://community.victronenergy.com/t/venus-os-3-50-gui-v2-showing-grid-as-disconnected-when-mpii-set-to-off/10037

mpvader commented 1 month ago

Another report:

IMG_3389

blammit commented 4 weeks ago

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

blammit commented 3 weeks ago

Fixed merged; closing.

mpvader commented 3 weeks ago

Fixed for this user 👍

https://community.victronenergy.com/t/grid-not-showing-in-v3-50-on-quattro-ii/9768/3

IMG_3427

mr-manuel commented 3 weeks ago

Now there is a new problem. Before the grid was shown correctly, now it is not anymore. v3.52~2

venus-os-grid

mpvader commented 3 weeks ago

Another positive feedback:

https://community.victronenergy.com/t/gui-v2-is-showing-grid-as-disconnected-while-its-not/8779/4

mpvader commented 3 weeks ago

Hey @mr-manuel you are running a mod there, right? Ie not a standard victron system.

Pls post the vrm url - thanks.

mr-manuel commented 3 weeks ago

I'm running virtual components that reflect 1:1 my productive system. I messaged different VRM systems to bea. You need them too?

mr-manuel commented 3 weeks ago

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.

blammit commented 3 weeks ago

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.

mpvader commented 3 weeks ago

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 :

IMG_3437

blammit commented 3 weeks ago

More fixes:

mpvader commented 2 weeks ago

@blammit , aside from field testing/confirming this is all done now, right?

then lets close the issue

blammit commented 2 weeks ago

Yes, correct. Closing.