6000xp bug in charge controller setpoint voltages with open loop

tried a few more things, which @jarrett may want to pass along to developers. I have set:

Batt type=lead-acid

Veq= 56.5, days=1, duration=1 hr (minimum). I would prefer to have the minimum duration be 0.1 for LFP, but sitting at 56.5 for a hour once a day is better than all afternoon.

Vcharge= 54.5

Vfloat= 53.5

.... and todays data shows that both EQv and Float v are ignored.... system came up to charge voltage, and is just floating at Charge V. What is important to note is that if I had lead-acid batteries instead of LFP, this behavior is STILL a bug, and not charging lead-acid batteries correctly either.

I am going to leave this setting for today in hopes that TOMORROW it will follow setpoints as programmed until a real fix is made available where the MPPT charge control actually does what you program.

Thank you Mr. Baker, I will pass that information along to the R&D team, as well as the firmware engineers.

My apologies! I didn't have an opportunity to respond yesterday, but I did send all of the information over to our engineers, as well as the post above. 

I appreciate all the information you have provided Mr. Baker!

11/5/24 - I've tried a few different settings, and may have stumbled on something that works, which (weirdly) may depend on the ORDER that charge voltage settings are set. I am seeing the "correct" behavior today with the following settings, set in this order:

Vcharge=56.2

Vfloat=54.0

Veq=56.0   (cannot be set to 0 as suggested in the ? hover help)

eqDays=0

eqHours=0

..... if this gives correct charge curve tomorrow, I'll consider the case closed at my end, but suggest that developers still look at this code carefully to figure out why the order of entry of Vsettings would matter, or determine if the Veq must be LESS than Vcharge to work correctly?

I'd suggest that the online, and App settings pages also clarify documentation and the ? hover help for how to set for LFP. Having done a lot of programming, I am guessing that the internal "allowable range" verification checks may not be setting or clearing some internal flags consistently when eqDays and eqHours are set to 0 to force LFP friendly behavior.

If that is the case, then maybe adjusting the logic of how the setting gets implemented will resolve the issue. I am taking your findings over to R&D now.