[Edge] Add Hardy Barth cPH1 EVCS support (ECB1 REST API) - #3940
Open
Christoph-87 wants to merge 15 commits into
Open
[Edge] Add Hardy Barth cPH1 EVCS support (ECB1 REST API)#3940Christoph-87 wants to merge 15 commits into
Christoph-87 wants to merge 15 commits into
Conversation
Adds `Evcs.HardyBarth.cPH1` to the existing Hardy Barth bundle, supporting
the eCharge ECB1 REST API used by the Hardy Barth cPH1 wallbox. The new
component polls `/api/v1/chargecontrols/{id}` and `/api/v1/meters/{id}` for
status and OBIS-coded meter data, and dispatches start/stop/current-set
commands as form-encoded HTTP POST requests.
- `Config.java` – OSGi metatype (ip, chargeControlId, meterId, min/maxHwCurrent)
- `EvcsHardyBarthEcb1.java` – interface with ECB1-specific RAW_* channels
- `Ecb1Handler.java` – HTTP polling and write dispatch via BridgeHttp
- `EvcsHardyBarthEcb1Impl.java` – AbstractManagedEvcsComponent + ElectricityMeter
- JUnit 5 tests with real device JSON fixtures and HTTP write assertions
- `readme.adoc` updated to document both Salia and cPH1 families
The ECB1 device returns 411 Length Required when POST requests have no Content-Length header. Added setBodyFormEncoded(Map.of()) for the start and stop endpoints so the HTTP client sets Content-Length: 0. Verified against real device at 192.168.2.8.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## develop #3940 +/- ##
=============================================
+ Coverage 55.32% 55.34% +0.03%
- Complexity 19443 19471 +28
=============================================
Files 3840 3843 +3
Lines 177236 177454 +218
Branches 14801 14815 +14
=============================================
+ Hits 98041 98198 +157
- Misses 75317 75360 +43
- Partials 3878 3896 +18 🚀 New features to boost your workflow:
|
… failure - Use HttpResponse.data() instead of non-existent .response() - Fix MeterType import: io.openems.common.types, not edge.meter.api - Replace LatestWinsFutureExecutor.submit(Runnable) with execute(Supplier<CompletableFuture>, BiConsumer); chain start/mode requests via thenCompose
…sageDistance Inline single-use variables (manualModeAmp, currentPwmAmp, vendor, version) directly into setValue calls so no variable exceeds the 3-statement distance threshold.
Interleave variable declarations with their setValue calls so each variable is used in the immediately following statement (distance = 1).
…in same cycle Both HTTP requests are now queued immediately so a single executor update flushes them together, matching the test expectation.
Contributor
|
Can you please provide some more information, why this new Hardy Barth component is required? Also we are planning to deprecate EVCS, so we would need a parallel EVSE implementation. |
Contributor
Author
|
@sfeilmeier Thanks for the feedback! The motivation for this component is that I own two Hardy Barth cPH1 wallboxes and there is currently no OpenEMS driver for them. The existing Evse.ChargePoint.HardyBarth targets the cPH2, which uses the Salia/SECC API (PUT /api/secc). The cPH1 exposes a completely different REST API — the ECB1 API (/api/v1/chargecontrols, /api/v1/meters) — so a separate driver is unavoidable. I will add a parallel EVSE implementation (Evse.ChargePoint.HardyBarth.cPH1) in this PR as well. The Ecb1Handler is already decoupled from the EVCS layer, so sharing it with an EVSE component should be straightforward. |
…dyBarth.cPH1) - Extract Ecb1Parent interface so Ecb1Handler works with both EVCS and EVSE - Add EvseChargePointHardyBarthEcb1Impl (Evse.ChargePoint.HardyBarth.cPH1) implementing EvseChargePoint + ElectricityMeter via the shared Ecb1Handler - Both components expose raw ECB1 diagnostic channels (RAW_STATE, RAW_CONNECTED, …) - Move toStatus() logic into EvcsHardyBarthEcb1Impl.onChargeControlStatus()
…field channel() type parameter must extend Channel<?>, not the value type. Track isEvConnected as a plain boolean field updated in onChargeControlStatus().
handleChargeControlResponse/handleMeterResponse must be public so the EVSE test (different package from Ecb1Handler) can call them directly.
Contributor
|
Do you still need EVCS? For new implementations we internally already do EVSE only. Knowing that right now some features of EVCS are missing yet. |
Contributor
Author
|
No, I do not need EVCS. EVSE works fine for me. |
… package Drops the legacy EVCS component (Evcs.HardyBarth.cPH1) and its tests. Moves Ecb1Handler and Ecb1Parent into the EVSE package; integrates the ECB1 channel definitions into EvseChargePointHardyBarthEcb1. The EVSE component (Evse.ChargePoint.HardyBarth.cPH1) is now self-contained.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds support for the Hardy Barth eCharge cPH1 wallbox to the existing
Hardy Barth bundle, using the ECB1 REST API.
What's new
Evcs.HardyBarth.cPH1in bundleio.openems.edge.evse.chargepoint.hardybarth/api/v1/chargecontrols/{id}(status/state) and/api/v1/meters/{id}(OBIS-coded energy data) every cycleManagedEvcs,Evcs,ElectricityMeterTested against real hardware
All API endpoints verified against real devices (cPH1 with Phoenix Contact EVCC Basic / ECB1 API v1.4):