Add missing BMS parameters ❘ Deye 3P

[Sopsy]

This PR adds the following BMS parameters:

• BMS temperature
• BMS Battery Force Charge Flags
• BMS Battery Sleep Flag
• BMS State of Health
• BMS Software Version
• BMS Rated Capacity
• BMS Hardware Version

And also secondary BMS support (BMS 2) for a second battery, along with Battery 2 (renamed Battery to Battery 1).

[davidrapan]

I'll have to think about this one, as I don't necessarily want to create "numbered" entities when there's only one battery. :)

[Sopsy]

For LV it might look a bit odd when there's only one BMS port. However I'm not really sure what would be a better way to do it. Battery, Battery 2, BMS and BMS 2 would be okay, but BMS Battery would sound confusing.

If you have some suggestions, let me know. Personally I think always having numbered is fine.
One compromise would be naming the BMS 1 x and Battery 1 x entities as just BMS x and Battery x, and keeping BMS 2 x and Battery 2 x as is.

[Bram-Verhagen]

I've discussed this also with Eniris who used the Battery 1 and Battery 2 values. Turned out the Voltage is not published on the Battery 2 register for example on my LV. Don't know how that works for multiple BMS entries, not yet tested. But something to check before going in this direction. Maybe an idea to split off the HV from the LV?

[Sopsy]

@Bram-Verhagen I believe the LV inverters only have one BMS port, so it would make sense the second one is not returning values. However the BMSes can be daisy chained, so in theory they should be readable in that one port. However aren't multiple batteries always connected in parallel? That means the voltage would always be identical and thus further voltage registers would be unnecessary.

There is a lot of differences between LV and HV, so splitting them would be a good idea, but even better would be a code feature to import other definitions to be able to define the common ones only once. Very hard to avoid duplication here.