Enhance Alpitronic Hypercharger with new features and tests

[Sn0w3y]

This commit introduces several enhancements and new functionalities to the Alpitronic Hypercharger component. Key changes include the addition of new channel identifiers for UNIX time, number of connectors, station state, total station power, load management enabled status, software version, total charged energy, and maximum AC charging power. It also adds implementation details in EvcsAlpitronicHyperchargerImpl.java, such as automatic firmware version detection and protocol adjustments based on the firmware version. New tests for Modbus register mapping and version compatibility ensure the reliability of these enhancements. The introduction of FirmwareVersion.java aids in handling different firmware versions and their capabilities. Lastly, adjustments to SelectedConnector.java accommodate changes in connector type values across different firmware versions.

[codecov[bot]]

Codecov Report

:x: Patch coverage is 34.94624% with 242 lines in your changes missing coverage. Please review.

:x: Your patch check has failed because the patch coverage (34.95%) is below the target coverage (75.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@              Coverage Diff              @@
##             develop    #3320      +/-   ##
=============================================
- Coverage      59.60%   59.53%   -0.07%     
  Complexity       112      112              
=============================================
  Files           2922     2923       +1     
  Lines         126328   126649     +321     
  Branches        9412     9437      +25     
=============================================
+ Hits           75285    75387     +102     
- Misses         48185    48406     +221     
+ Partials        2858     2856       -2     

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Sn0w3y]

What protocols did you test this with?

Right now i couldn't test it pretty much as we have a Customer (FEMS) which has a FEMS on his site and is pretty sad about the status of the Implementation and that FEMS cannot work with the newest Version anymore (this FW is required due to other Ciscumstances regarding the Chargepoint)

So we would need to test it on his FEMS Live System if the Customer allowes us (you) to do so.

The changes will be made by myself as early as i can - maybe also Port the last recent EVSE changes.

Greetings

[Sn0w3y]

I also made sure, that we use the latest Modbus Protocol if no Protocol has been found - so in the worst case we need to tell the Users to Update their Firmware to the most Recent Version (which is always recommended everywhere).

Please have a look again @kaufmannjohann :)

[Sn0w3y]

@kaufmannjohann is there anything missing? I already tested it now with Version 2.2.3

[sfeilmeier]

@Sn0w3y: Da du gerade so aktiv daran arbeitest, ein kleiner Hinweis. Optimal wäre, wenn wir am Ende Tests für EVSE und EVCS Alpitronic haben, bei denen der Strict-Mode aktiviert ist. So ist sichergestellt, dass jeder Channel in beiden Varianten gesetzt ist: https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.evse.chargepoint.keba/test/io/openems/edge/evse/chargepoint/keba/modbus/EvseChargePointKebaModbusImplTest.java#L28

[Sn0w3y]

@Sn0w3y: Da du gerade so aktiv daran arbeitest, ein kleiner Hinweis. Optimal wäre, wenn wir am Ende Tests für EVSE und EVCS Alpitronic haben, bei denen der Strict-Mode aktiviert ist. So ist sichergestellt, dass jeder Channel in beiden Varianten gesetzt ist: https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.evse.chargepoint.keba/test/io/openems/edge/evse/chargepoint/keba/modbus/EvseChargePointKebaModbusImplTest.java#L28

Hi,

ja, wäre ein nice-to-have, aber:

Unit-Tests mit ComponentTest simulieren Zeit mit .next(new TestCase(), 20), aber:

• Sie warten nicht auf asynchrone CompletableFutures
• Der thenAccept() Callback wird nicht garantiert ausgeführt

Der KEBA-Ansatz ist ideal, aber für Alpitronic technisch nicht machbar wegen:

1. KEBA: Festes Protokoll -> Sofort einsatzbereit
2. Alpitronic: Dynamisches Protokoll -> Asynchrone Konfiguration
3. Unit-Tests: Keine echte Async-Unterstützung

Die erstellten Test-Helper-Klassen (AlpitronicCommonNaturesTest, AlpitronicTest, AlpitronicModbusTest) erfüllen den gleichen Zweck wie KEBA's Strict-Mode: Sie dokumentieren die erwarteten Channel-Werte und können für manuelle Verifikation genutzt werden.

Sag mir gern wenn ich was übersehen hab @sfeilmeier

[Sn0w3y]

@sfeilmeier Just checking on the Status

[Sn0w3y]

Hi @sfeilmeier - can you aswell test this in Prod?

I tested it and it worked (seemingly) fine

We have a Customer (FEMS) where it didn't work to set a Limit and i created this PR to test it then on the FEMS aswell if possible ?