ZE0 with heavily degraded pack will show 12/12bars too soon

[dalathegreat]

The hardcoding of capacity remaining should be removed, and instead use a (Whan new capacity * SOH%). This will avoid showing 12/12 bars of range left when in fact it should be emptier. Not a massive issue, but could be done smarter.

[nzautomate]

@dalathegreat , is there a reason you can't use the calculation I gave to estimate the full pack? It works for the 30kwh pack, and was quite accurate. Does the qc capacity reported by the battery not work the same in a 40 or 62 kWh pack? Qc capacity/0.8 (80wh/gid?)

[nzautomate]

@dalathegreat had a quick look across the code, the 3port code is missing the 30kwh battery detection code. This is staying registered as a 24kwh battery on 3 port bridge. That is why the gids are not raised to the full pack level on startup

[dalathegreat]

Not sure how you sample the QC Capacity, but massive thanks for the review! I added the 30kWh detection to 3-port, PR is up! #36

[nzautomate]

I'll show for fullcap and capremaining, if its helpful. I used these values to create better charge timer estimates also.

Declare the variables

volatile	uint16_t	LB_FullCap_for_QC		= 0;
volatile	uint16_t	LB_CapRemaining_for_QC  	= 0;

Capture the values as they come from the battery, before we manipulate the values to fix fast charging.

case 0x59E: // QC capacity message, adjust for AZE0 with 30/40/62kWh pack swaps
	LB_FullCap_for_QC = (((frame.data[2] & 0x1F) << 4) | ((frame.data[3] & 0xF0) >> 4)) ;
	LB_CapRemaining_for_QC = ((frame.data[3] & 0x0F) << 5) | ((frame.data[4] & 0xF8) >> 3);// collect these for better charge time remaining calcs

And finally use the value to know the gids capacity of the battery, in place of the hard coded values

case 0x5BC:
...
swap_5bc_remaining.LB_CAPR = (LB_FullCap_for_QC/0.8); // for elevating the gids on startup