OK, I've done a bit more testing and it looks promising.
What I have found is the following:
Charger Temperature
I spotted a value in byte 3 of PID 286 that rises gradually during charging, then falls slowly afterwards. It seems likely this is charger temperature of some kind. This seems to settle at about 40 higher than the current outdoor temperature in Celsius. It seems odd to be having a different offset to the battery temperature values, but the outside air temperature here is 9.7C and the PID 286 value is 50 with battery sensor average value 65. This would mean the charger is almost exactly ambient and the batteries 5C higher. I have added this as PEM temp.
Motor Temperature
I found that PID 298, which has the suspected motor RPM, has a set of 4 values in a similar range to the possible charger temperature reading. These seem to rise while driving, the forth of them (byte 3) rises fastest and highest. I suspect that these are intimately linked to the motor, either a direct motor temperature, or the motor drive electronics. Again, they settle to about 40 above ambient in C when not in use. I have added this as motor temp.
I have found that the charger temperature rises a little while driving, and the motor temperature possibly a tad while charging (but not much). This could simply be because the two are physically close, or the charger could be involved in regenerative braking.
Rapid/quick charge detection.
During RC the bus has PID 346 messages, but the range in byte 7 is 255 rather than a valid estimated range. I have seen logs showing 255 for a few samples at startup, so maybe we need to add a test for this 255 being stable for more than a second or two. Of course the problem now is that we have lost the predicted range. We have "ideal" range, but that is a bit of a chocolate teapot as you are never going to get that range and it is not correctly calculated in my opinion (due to unusable SOC at the bottom of the battery).
I have studied some of my charging records and it seems that the predicted range hits 0 at about 10% SOC, and it is roughly linear to 100% from there. The slope of the line depends on the recent driving style. I have used this to code a replacement "guess-o-meter" for use during rapid charge. The way it works is as follows: I constantly record valid SOC and est_range until either of them gets too low to be reliable (20% SOC or 5 range) - this gives me an indication of the slope that should be used for the line. During RC I calculate est_range = (SOC-10%) * Slope, where Slope = (Old_Range / (Old_SOC-10%)). This works, but I have only tried one RC with this code and the ranges it gave me were a bit higher than I expected. This might need some debugging.
I have attached the revised code. You will see that I have also optimised the PID filtering a bit to try and reduce load while still capturing the increased number of PIDs we are now monitoring. I wonder how easy it is to check how close we are to running out of CPU capacity in the read code.