EEBus: add OHPCF heat pump compressor flexibility#30636
Conversation
The dev branch reworks remote service trust around ship-go's ServiceIdentity and splits the load control write approval event into separate limit and device configuration events. NewConfiguration now takes the device categories as well as an optional SHIP Pairing config and ring buffer persistence; evcc trusts remote services by their configured SKI via RegisterRemoteService and does not use SHIP Pairing, so both are passed as nil. RegisterRemoteSKI/UnregisterRemoteSKI/RemoteServiceForSKI/CancelPairingWithSKI are replaced by their ServiceIdentity-based equivalents, and the service reader callbacks switch from raw SKI strings to ServiceIdentity, gaining the new SHIP Pairing auto-trust events as no-ops. Device configuration writes were applied automatically up to v0.7.0 but now require explicit approval, so the LPC/LPP handlers approve all pending configuration writes to preserve the previous behaviour.
Bumps eebus-go to the branch adding the cem/ohpcf use case and registers it on the CEM entity alongside the other use cases. OHPCF lets evcc, acting as CEM, observe the optional power consumption a remote heat pump compressor announces. The use case is wired read-only: its data update events are read and logged (availability, requested and maximum power, process state, pausable/stoppable flags and the minimal run and pause durations) and the use case is reachable for on-demand reads via CustomerEnergyManagement. Scheduling, aborting, pausing and resuming a consumption process are intentionally left out for now.
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Adds a charger that exposes a remote heat pump compressor announcing optional power consumption (OHPCF) as a switchable load. Status, enabled state and control are derived from the compressor's power consumption process state: running maps to charging, available/scheduled/ paused to connected, everything else to disconnected. OHPCF has no power setpoint, so MaxCurrent instead converts the loadpoint's allotted current to power (using the active phases) and schedules the optional consumption to start now once the available surplus covers the compressor's requested power, pausing or aborting it otherwise.
andig
changed the title
CurrentPower now reports the heat pump's actual measured power consumption through the MPC (Monitoring of Power Consumption) use case instead of the announced OHPCF estimate, capturing the MPC entity from its support update and returning api.ErrNotAvailable when no measurement is available, matching the eebus meter implementation.
meter/eebus.go inlined the eebusapi.ErrDataNotAvailable to api.ErrNotAvailable mapping in eebusReadValue and readPhases. Both now use the existing eebus.WrapError helper so the mapping lives in a single place.
The OHPCF charger now reads and controls the heat pump compressor directly, so the server-side diagnostic logging is no longer needed. OHPCF use case events are forwarded straight to registered devices via ucCallback, like the other use cases.
andig
changed the title
|
@copilot resolve the merge conflicts in this pull request |
Done. I merged |
|
Closed due to missing feedback |
|
Why close this? This could be useful for Vaillant heat pumps, if there is enough surplus we could heat the hot water to a higher than standard temperature |
In case you've missed it: #30636 (comment) |
|
Did not realize that this is already in a state worth testing. In fact I am already failing to configure it... It looks like there is a new Does not seem to work either... Probably can't add EEBUS twice.. |
I think this might be related to this bug |
|
The following config works: Including MPC: So how do I test the feature now? DHW has just been loaded. So there is nothing to do for the heat pump right now. One thing that will sorely be missed opposed to the sensoNET charger is the DHW temperature display. There is however a HVAC use-case (MDT - Monitoring of DHW Temperature) which covers that. |
|
I now also enabled EEBUS Energy Management in Vaillant: Guess we have to wait and see what happens now? Does it make sense to remove any DHW time windows to see whether DHW loading starts anyway? Or check whether it overloads to T+5? |
|
You can add integrateddevice capability, let me check on MDA. We announce flexibility for „now“ (really like FLOA) but its probably bot a good fit. |
|
Not a lot of sun today. So I started a fast charge. I did set the Vaillant upper bound to 52 °C and max. Temp. in evcc to 50 °C. So the fast charge (or Boost) was stopped at 50 °C by evcc. So far so good. evcc went into the Disconnected state afterwards and does not show the temperature bar anymore: Shouldn't it go into Standby state? Not sure whether evcc re-evaluates demands through OHPCF in the Disconnected state? Sorry for the logs getting bigger. But I am now heading towards long-term testing. [EDIT] |
|
Fixed |
Map every connected compressor state except running to standby (B); a stopped or completed boost no longer flips the loadpoint to disconnected and hides the temperature bar. Disconnected (A) is now reserved for a lost entity.
|
Lets merge this, I think it's good enough for broader testing. I really appreciate your time trying this. Didn't think it would work as expected... |
|
One thing that should probably be done is that the OHPCF heat pump becomes a generic heating device in the UI list. |
@naltatis is that possible? |
|
We should probably also mention Vaillant specifically. |
|
Just a note that this won't work for Vaillant unless have HEMS defined. Any reply from Vaillant by any chance @CiNcH83? |
|
Yes. They would like to debug it. Currently trying to reproduce by disabling hems (EnergyGuard). |
|
We‘d also still need to fix dimming. Right now- once the heatpump becomes a loadpoint but doesn‘t have current control I don‘t think we‘d be doing anything useful, but that needs be verified. |
Currently stuck in "Ready to heat..". Should be normal though as there is no demand... |
OK. Will try to perform a dim when I finished looking at EnergyGuard with Vaillant and controlbox is up and running again... |
This can be done with See the |
|
I outsourced the Vaillant topic here. |
|
With regards to dimming, I will test that tomorrow, now that debugging with Vaillant has been finished. What I can say already is that the OHPCF config tile does not mention dimming: |
|
Another thing I just realized is that temperature display via MDT does not give me fractions. 36,5 becomes 37 °C. |
|
Did you check if the log even has fractions? |
|
There are indeed only integers: EDIT: |
|
Dimming... power reduction arrives... ... and boost has entirely been stopped. Trace log is 60MB... [LINK] It looks as if evcc still uses the configured 3,5 kW min. power to determine when to boost? |
|
Re-boost seems to work... 
|
Can you remove that config? |
|
How would I do that? 
|
|
Enter 0.1? Not nice, but... |
Dimming is actually tricky. We dim meters by setting the consumption limit using LPCs. We're also dimming heatpumps using SG Ready. We're currently not dimming controllable chargers since those would usually just be reduced in current/power. Now, since OHPCF only controls flexible power consumption, we should also add dimming similar to SG Ready. |
Stacked on #30633 (eebus-go @dev bump) and based on the upstream OHPCF use case from enbility/eebus-go#223.
OHPCF (Optimization of Self-Consumption by Heat Pump Compressor Flexibility) lets evcc, acting as CEM, observe and control the optional power consumption a remote heat pump compressor announces.
Read (server/eebus):
usecases/cem/ohpcfand registers the use case on the CEM entity (reachable viaCustomerEnergyManagement).Charger (charger/eebus-ohpcf.go):
api.Charger). Status/Enabled are derived from the power consumption process state: running → charging, available/scheduled/paused → connected, else → disconnected.MaxCurrentconverts the loadpoint's allotted current to power (using the active phases fromloadpoint.Controller) and schedules the optional consumption to start now once the available surplus covers the compressor's requested power, pausing or aborting it otherwise. The schedule/resume/pause/stop decision is centralised in one guarded helper so an unchanged state issues no repeated commands.CurrentPowerreports the announced power while running.The control decision logic (state × surplus → action) and the status/enabled mapping are unit tested. The use-case wiring is exercised by the existing eebus integration handshake test.
go build,go vet, charger + eebus tests, and golangci-lint all pass.