Pytes battery: Add support for native CAN protocol

[ranma]

The recently added PytesCanReceiver.cpp implements the Victron CAN protocol.

This change additionally adds support for the native Pytes CAN protocol messages.

Features only supported in Pytes protocol:

• High-resolution state of charge / full and remaining mAh
• Charge cycle counter
• Balancing state

Features only supported in Victron protocol:

• FW version
• Serial number

Note that the only known way to select the native Pytes protocol is via the serial console (Cisco-compatible cables work):

login config
setprt PYTES
logout

to return to Victron protocol use:

login config
setprt VICTRON
logout

The protocol switch will take effect immediately.

Tested on Pytes E-Box 4850

See #1188

[AndreasBoehm]

Thanks for your PR, cool that we can get more details about the battery by switching it to a different protocol.
I will test this once my console cable arrives.

Things that we should adjust:

• Figure out what 'balance' actually represents and add it to the UI
• If we can't figure out state/warning flags we should remove the section from the UI, but it also doesn't feel right for me to switch to a different protocol but then we loose important things like warnings
• Remove any information from the UI the JSON that is generated by the BatteryStats for Pytes that is not available anymore when the protocol is switched (Should still be available when the 'Victron' protocol is used)

[schlimmchen]

Remove any information from the UI that is not available anymore

The UI is generic, as far as I remember. Only info that is put into the respective JSON array is displayed in the UI. So I am not sure why you mention this. We have to take care that in the backend, only relevant info is serialized into JSON. The respective BatteryProvider implementation is responsible for that.

[AndreasBoehm]

@schlimmchen That is exactly what i meant with my comment. Don't touch the UI code, adjust the BatteryStats for 'Pytes' to not add values into the JSON that are not available.

[ranma]

Updated the pull request with support for alarms, warnings and online/offline module count (based on Ghidra analysis).

[ranma]

With this change and Victron protocol:

With this change, Victron protocol and below 10% charge ("immediate charging requested" via 0x360 val 0xff):

With this change, Pytes protocol and low charge state:

With this change, Pytes protocol, fully charged and balancing active:

[ranma]

Added HASS auto-discovery for new fields.

[AndreasBoehm]

@ranma could you do me a favor and update the description of the PR to reflect what features/changes we can expect from this PR?
Its a bit hard to follow the comments and the code does not match the description anymore (e.g. support of alarms)

Thank you.

[AndreasBoehm]

I switched to the PYTES protocol and the web ui is showing a strange value for voltage sometimes, the value shown was 1,70 V. In the live view on top and in the battery card on the bottom.

It happens randomly and i could not find anything strange in the CAN messages, they all looked fine and showed the correct voltage of 53,xx

Did you have the same experience @ranma ?

[ranma]

I switched to the PYTES protocol and the web ui is showing a strange value for voltage sometimes, the value shown was 1,70 V. In the live view on top and in the battery card on the bottom.

I don't remember seeing any drops like that, not in the UI nor in the MQTT data.

[ranma]

I switched to the PYTES protocol and the web ui is showing a strange value for voltage sometimes, the value shown was 1,70 V. In the live view on top and in the battery card on the bottom.

I can currently reproduce this in testing right now, I sometimes see 2.90 V instead of 53.15 V.

[ranma]

I can currently reproduce this in testing right now, I sometimes see 2.90 V instead of 53.15 V.

There was a stray setVoltage() fatfingered into the message 0x402 handler at some point, removed that to fix the issue.

Also verified the charge inhibited count with replayed messages from when the battery was full, it shows Charging blocked 1 now:

[AndreasBoehm]

Everything works fine now. I will re-review this PR after my holidays and then we can finally merge it, thanks for providing this :)

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.