Fix a scenario were measurements were provided after the last limit change. But if the interval is set >15s and measurements even came in after 15s timeframe, this was considered to be invalid.
To fix this, every time measurements are provided and the limitUpdate timestamp is not zero, meaning a limit was set, consider data to available by setting limitUpdate to zero again.
Some EEBUS wallboxes like the PCMP do report the OSCEV usecase to be available, but it doesn’t provide the necessary recommendation limit data.
This change adds checks for this case.
If a limit has been set, a measurement is expected to provided within 15s. If this is not the case, then show a warning and return an error.
Also add support for the Elli Connect Pro internal meter again.
This should now lead to those EEBUS wallboxes not providing measurements, to fall back to the actual limit being assumed as being the current measurement. And the user is informed about non function metering in the wallbox.
- Update SHIP and EEBUS libraries to latest dev code
- Support IPv6 connections and devices only reporting IPv6 mDNS addresses
- Re-Add support for overwriting the IP address in the charger config, also added to the meter config (just in case)
- Make sure to use VWVAS feature only if the vehicle reported SoC is 25% or higher, as charging via this feature in a Taycan only works if the vehicle internal MinSoC is reached which can’t be lower than 25%
- For detecting if the EV is charging, use the reported power data first, and only use currents if no power data is available
Some EVSEs using EEBUS sometimes do not provide any current charging limits and also do not provide valid ranges just ignore these scenarios and hope for the best.
- Check if sending the heartbeat even more often helps
- Use avahi as mDNS provider if available. this might help finding the Elli device after disconnections quicker and maybe even ones own mDNS entry better
- Fix a small bug with resetting recommendation limits to inactive when using VAS EVs
- Tested with Elli Charger Pro Gen 1
- Handle missing power and use current data in evcc instead of eebus library
- Check for use case scenario availability for power and current data
This updates the eebus charger implementation to use the latest version of cemd, eebus, spine and ship.
Only use OSCEV if the a wallbox with ISO15118-2 VW VAS is connected, and the EV is using this. This also enables full charging control and putting the EV to sleep. All other current implementations of the usecase are basically wrong and are no different than using OPEV.
The golang mock package has been archived and is now maintained by uber.
> Update, June 2023: This repo and tool are no longer maintained. Please
> see go.uber.org/mock for a maintained fork instead.
[1] https://github.com/golang/mock
[2] https://github.com/uber-go/mock
- Make sure the check using an external meter is identical to using an internal meter
- Fix check using internal meter to compare sum of all charge currents to idlefactor * min. single phase charge current
* Ignore a max number of meter no data errors
When an EV is connected, measurements are not available right away, as the initial communication is not done. And due to bugs in the Elli software, the EEBUS stack can not generally wait for data being available and only then set the EV as being connected.
This change ignores a maximum amount of specific EEBUS `no data available` errors, and only propagates them if the error occured more often.
The error will come anyway, if evcc is startet while an EV is connected to the Elli wallbox!
