MENNEKES AMTRON 4You: OCPP connection lost after several days due to TriggerMessage(MeterValues) every 5 seconds?

[Draexl]

Describe the bug

The OCPP connection between evcc and a MENNEKES AMTRON 4You 510 (Firmware 1.5.41) becomes permanently disconnected after approximately 2-4 days of operation.

The charger itself remains fully operational and reachable via its web interface.

Restarting evcc does not restore the OCPP connection.

Only rebooting the wallbox immediately reconnects it.

MENNEKES support analyzed the OCPP log and stated that evcc continuously sends TriggerMessage(MeterValues) every 5 seconds. According to MENNEKES this eventually results in too many OCPP messages and the charger intentionally terminates the backend connection.

Steps to reproduce

1. Configure a MENNEKES AMTRON 4You 510 with OCPP 1.6J.
2. Connect it to evcc (local OCPP server).
3. Let the system run normally for several days.
4. Eventually the charger disconnects from evcc.
5. evcc reports the charger as disconnected.
6. The MENNEKES web interface reports "Backend: Not Connected".
7. Restarting evcc does not reconnect.
8. Rebooting the wallbox immediately restores the OCPP connection.

Configuration details

evcc version: 0.312.1

Charger:
- MENNEKES AMTRON 4You 510 11 C2
- Firmware 1.5.41
- OCPP 1.6J
- Local OCPP server
- LAN connection
- RFID authorization enabled

Factory reset has been performed twice.
The issue still occurs.

Log details

While connected, evcc continuously sends:

TriggerMessage
requestedMessage: MeterValues

every 5 seconds.

Example:

15:32:35 TriggerMessage MeterValues
15:32:40 TriggerMessage MeterValues
15:32:45 TriggerMessage MeterValues
15:32:50 TriggerMessage MeterValues

The charger answers every request with:

status: Accepted

MENNEKES support replied:

"The problem in this case is that every 5 seconds a TriggerMessage is sent from evcc. Over time this results in too many messages, therefore the backend connection is eventually terminated by the charger. Is it possible to increase this interval?"

Question:
Is the 5 second TriggerMessage interval configurable or could evcc instead rely on the charger's configured MeterValueSampleInterval?

What type of operating system or environment does evcc run on?

Linux

External automation

• I have made sure that no external automation like HomeAssistant or Node-RED is active or accessing any of the mentioned devices when this issue occurs.

Nightly build

• I have verified that the issue is reproducible with the latest nightly build

Version

No response

[github-actions]

Investigation

The repeating TriggerMessage(MeterValues) traffic comes from the WatchDog goroutine in charger/ocpp/connector.go (started for every OCPP charger connector when the charge point declares RemoteTrigger support, see charger/ocpp.go around the conn.WatchDog(ctx, meterInterval) call).

// WatchDog triggers meter values messages if older than timeout.
func (conn *Connector) WatchDog(ctx context.Context, timeout time.Duration) {
	for tick := time.NewTicker(2 * time.Second); ; {
		conn.mu.Lock()
		update := conn.clock.Since(conn.meterUpdated) > timeout
		conn.mu.Unlock()

		if update {
			conn.TriggerMessageRequest(core.MeterValuesFeatureName)
		}
		...

It re-checks every 2 seconds whether meterUpdated (last time a MeterValues.req was accepted, see OnMeterValues in charger/ocpp/connector_core.go) is older than the configured meterinterval (default 10s), and if so fires another TriggerMessage(MeterValues). Critically, this loop has no backoff and no cap on repeat attempts — if the freshness condition is never satisfied (e.g. the charger doesn't emit an unsolicited/triggered MeterValues.req while idle/no active transaction, or its self-reported sample timestamp never advances), evcc will keep firing TriggerMessage indefinitely on every watchdog tick, which matches what MENNEKES observed on their side (an unthrottled, continuous stream of TriggerMessage requests that eventually causes the charger to drop the backend connection).

This looks like a plausible real defect (missing backoff/rate-limit in WatchDog), but I can't fully confirm the exact trigger condition (why meterUpdated never advances on this specific device) from the repository alone.

To confirm and scope a fix, could you provide:

• The meterinterval value configured for this charger in your evcc config (or confirm you're using the default 10s)?
• An evcc debug/trace log excerpt (--log ocpp:trace or similar) spanning a few WatchDog cycles, showing whether a MeterValues.req is actually received back from the charger after each TriggerMessage, and its timestamp
• Whether this happens while the charger is idle (no active transaction) vs. during an active charging session

This will help determine whether the fix is a backoff/rate-limit in WatchDog, or better handling of chargers that don't emit MeterValues while idle.

🤖 Generated with Claude Code

[Draexl]

Thanks for the investigation!

Here are the answers to your questions:

MeterValueSampleInterval

I have not configured a custom MeterValueSampleInterval, so evcc is using its default configuration.

One question though: MENNEKES analyzed their charger logs and consistently observed TriggerMessage(MeterValues) every 5 seconds. Since I haven't configured a custom meter interval, do you have an explanation why the effective TriggerMessage interval appears to be 5 seconds?

Trace log

I'll enable OCPP trace logging and capture a complete log covering the period before the issue occurs. I'll upload it as soon as I can reproduce the problem again.

Idle vs. active charging

So far, I have only observed the issue while no vehicle was connected and no charging session was active. I cannot yet confirm whether it can also occur during or immediately after an active charging session.

When the issue occurs, the charger remains fully reachable via its web interface, but the backend status changes to "Not Connected" and evcc reports the charger as disconnected.

Restarting evcc does not restore the connection. Rebooting the wallbox immediately reconnects it.

Additionally, MENNEKES support analyzed their logs and informed me that evcc continuously sends TriggerMessage(MeterValues), which eventually causes the charger to terminate the backend connection due to the high number of requests.

Your analysis of the WatchDog loop seems to match their findings very well.

[premultiply]

Sounds like bugs in Mennekes Firmware.

1. The box does not (always?) send meter values at configured interval.
2. The box does not always send meter values on trigger request
3. The box firmware seems to have a memory leak

Needs to be fixed by Mennekes.

[Draexl]

Thanks for your feedback.

I understand that the root cause may be on the MENNEKES side if the charger does not send MeterValues as expected.

However, I have one question regarding evcc:

Is there any way to configure the MeterValueSampleInterval (or the WatchDog timeout) to a higher value, e.g. 15, 30 or 60 seconds, as a workaround? Or is the TriggerMessage interval currently fixed by evcc?

Regarding the 5-second interval: the attached screenshot is taken directly from the MENNEKES charger log. It shows that the charger receives a TriggerMessage(MeterValues) from evcc every 5 seconds over a long period of time. This is what MENNEKES based their analysis on.

If increasing the interval is possible, I'd be happy to test it and report back whether it changes the behaviour or prevents the charger from disconnecting.

[premultiply]

See the occp trace log.

A fixed interval of 10s is configured.

The Menneks box does not (always) care about.
In this case we try to trigger the meter values on every watchdog loop again if there were not received.

So the issue is that the box firmware does not care about about the configured interval and does not reply to the requested and accepted meter values. Misses the spec and seems to crash somehow internally. That is all.

[Draexl]

Thanks for the clarification.

I received another reply from MENNEKES.

They confirmed that the interval is actually 10 seconds (not 5 seconds as initially stated).

They also mentioned that an OCPP backend would normally configure the charger's MeterValueSampleInterval so that the charger periodically sends MeterValues automatically. According to them, continuously using TriggerMessage(MeterValues) is rather uncommon.

Looking at my OCPP trace, I can see that the charger already sends unsolicited MeterValues periodically while idle. In addition, evcc sends TriggerMessage(MeterValues), which is also answered with Accepted followed by MeterValues.

Could you help me understand why evcc still triggers MeterValues in this situation? Is evcc expecting a different type of MeterValues than the periodic ones sent by the charger, or under which conditions does the watchdog decide that the received MeterValues are not sufficient?

[mfuchs1984]

Please upload an ocpp trace log from evcc.

[Draexl]

I’ll upload a complete OCPP trace as soon as the issue occurs again. At the moment, I only have traces from normal operation, where the charger responds correctly. I want to capture the period immediately before and during the disconnect, as that should be the most useful for troubleshooting.

[premultiply]

They also mentioned that an OCPP backend would normally configure the charger's MeterValueSampleInterval so that the charger periodically sends MeterValues automatically. According to them, continuously using TriggerMessage(MeterValues) is rather uncommon.

Please have a look at the logfiles!
This is the case.

evcc only triggers meter values by timeout if the charger DOES NOT send meter values as configured!

Still looks like that there are just bugs in Mennekes firmware.

[Draexl]

Hi, MENNEKES checked the charger configuration and found that MeterValueSampleInterval is set to 10 seconds by evcc, but ClockAlignedDataInterval remains at 60 seconds.

According to MENNEKES, the charger therefore sends MeterValues every 10 seconds while charging, but only every 60 seconds while idle. This would explain why evcc starts sending TriggerMessage(MeterValues) outside a charging session.

Is there a reason why evcc does not also configure ClockAlignedDataInterval via OCPP, or is this parameter intentionally left unchanged?

[premultiply]

Because ClockAlignedDataInterval is something completly different. See OCPP Spec!

This is for 15 Min values etc. and is limited to energy values and mean power values. No actual measurands.

There is no reason for a charger to stop transmitting measurands at the configured interval outside of an active charging session.

[mfuchs1984]

@premultiply to me the ocpp spec sounds like metervaluesampleinterval is actually just applicable when a charging transaction is active.

3.16.1. Charging Session Meter Values
Frequent (e.g. 1-5 minute interval) meter readings taken and transmitted (usually in "real time") to the CentralSystem, to allow it to provide information updates to the EV user (who is usually not at the charge point), via web, app, SMS, etc., as to the progress of the charging session. In OCPP, this is called "sampled meter data", as the exact frequency and time of readings is not very significant, as long as it is "frequent enough". "Sampled meter data" can be configured with the following configuration keys:
29 • MeterValuesSampledData
• MeterValuesSampledDataMaxLength
• MeterValueSampleInterval
• StopTxnSampledData
• StopTxnSampledDataMaxLength
MeterValueSampleInterval is the time (in seconds) between sampling of metering (or other) data, intended to be transmitted by "MeterValues" PDUs. Samples are acquired and transmitted periodically at this interval from the start of the charging transaction. A value of "0" (numeric zero), by convention, is to be interpreted to mean that no sampled data should be transmitted.

9.1.19. MeterValueSampleInterval
Interval between sampling of metering (or other) data, intended to be transmitted by "MeterValues" PDUs. For charging session data (ConnectorId>0), samples are acquired and transmitted periodically at this interval from the start of the charging transaction.
A value of "0" (numeric zero), by convention, is to be interpreted to mean that no sampled data should be transmitted.

[mfuchs1984]

@Draexl btw., you can increase the meterinterval in the charger settings. Maybe it improves the situation.

[premultiply]

🤔