Timxon A0 (OCPP 1.6J): Maximum Current broken since 0.12.0 — ChargePointMaxProfile NotSupported, absolute schedule gets no response

[alcrow68]

Describe the bug
Since 0.12.0 the charging current of my Timxon charger can no longer be changed. In 0.11.4 the Maximum Current slider worked (Current Offered followed it, e.g. 10 A), presumably through the silent fallback to a TxDefaultProfile, since the charger answers NotSupported to ChargePointMaxProfile. With that fallback removed in 0.12.0 (#2131), none of the available paths works on this charger.

To Reproduce

1. Maximum Current slider (default, relative): Failed to set variable: ChargePointMaxProfile: NotSupported.
2. Session Current Limit slider, during a transaction: charger rejected the session limit for connector 1 (NotSupported). So the charger refuses both ChargePointMaxProfile and TxProfile.
3. Enable "Send the station charging limit as an absolute schedule" and move the slider: the charger does not answer.

   Failed to set variable: Waited 10s for response on [2,"...","SetChargingProfile",{"connectorId":0,"csChargingProfiles":{"chargingProfileId":1000,"stackLevel":1,"chargingProfileKind":"Absolute","chargingProfilePurpose":"ChargePointMaxProfile","chargingSchedule":{"chargingRateUnit":"A","chargingSchedulePeriod":[{"startPeriod":0,"limit":32.0}],"startSchedule":"2020-01-01T00:00:00Z"}}}]
   

   On other attempts the connection was closed: sent 1001 (going away); no close frame received. This option seems to make the charger unresponsive.
4. ocpp.set_charge_rate with a custom TxDefaultProfile (Relative, connector 0, id 8, stack level 0): no error shown, but Current Offered did not change on the running transaction. Not yet tested on a new transaction.

Expected behavior
A way to set the station charging limit on chargers that support neither a relative nor an absolute ChargePointMaxProfile. Could the previous TxDefaultProfile fallback for the station-wide slider be kept as an option for single-connector 1.6 chargers?

Charger

• Timxon EAW-A007S (A0 platform), single phase, 7.4 kW, one connector
• Firmware A0-V2.2.4, OCPP 1.6J
• Reported features: CORE, FW, SMART, RES, REM, AUTH

Environment

• Integration: 0.12.0 (last working: 0.11.4)
• Home Assistant OS 18.3, Core 2026.9.3, Supervisor 2026.09.2, Frontend 20260826.7

Additional context

• The charger is sometimes slow: GetConfiguration for ChargingScheduleAllowedChargingRateUnit occasionally gets no answer within 10 s (seen in 0.12.0, and once in 0.11.4). Once it also sent a malformed frame (sent 1002 (protocol error) incorrect masking), which looks like a firmware websocket bug.
• The log was captured with the idle sampling interval at its default 900, hence the ClockAlignedDataInterval read-only warning on every connection. I normally keep it at 0: writing this key previously caused a reboot loop on this charger.
• Downgrading to 0.11.4 after enabling the absolute schedule option leaves the charger unable to set up: ChargerSystemSettings.__init__() got an unexpected keyword argument 'charge_point_max_profile_absolute', repeated every ~12 s. Probably out of scope, but worth knowing for users rolling back after this breaking change.

Log excerpt attached (integration lines only, serial masked).

ocpp-0.12.0-timxon-log-excerpt.log

[ellep94]

Version 0.12.0

Failed to set variable: ChargePointMaxProfile: Rejected

[webuser0815]

with this version i have the same problem:
Failed to set variable: ChargePointMaxProfile: Rejected (ABB Terra AC)
Downgrading to v0.11.4 works

[papatwiki]

Same issue here, but as a workaround this action seems to work:

action: ocpp.set_charge_rate
data:
conn_id: 0
limit_amps: 28

[malakudi]

Same issue after 0.12.0 with ABB Terra AC
"Failed to set variable: ChargePointMaxProfile: Rejected"

[alcrow68]

Follow-up: what this charger actually accepts (captured on the wire)

I put a plain ws:// relay in front of the charger and captured the traffic, both against Home Assistant and against the vendor CSMS. Log excerpt attached.

What the charger refuses

Profile	Result
ChargePointMaxProfile, Relative, connector 0, stackLevel 5	NotSupported
ChargePointMaxProfile, Absolute, connector 0, stackLevel 1	no answer at all, then 1001 (going away)
TxProfile (Session Current Limit), connector 1	charger rejected the session limit for connector 1 (NotSupported)

The charger advertises SmartCharging, ChargeProfileMaxStackLevel: 5 and ChargingScheduleAllowedChargingRateUnit: Current,Power, so smart charging itself is supported — only the station-wide profile is not.

What the charger accepts

The vendor CSMS never installs a ChargePointMaxProfile at all. ClearChargingProfile for that purpose returns Unknown, i.e. nothing was ever stored. Instead it clears and re-sends a recurring TxDefaultProfile on connector 1, stack level 1:

[2,"...","SetChargingProfile",{"connectorId":1,"csChargingProfiles":{"chargingProfileId":41951,"stackLevel":1,"chargingProfilePurpose":"TxDefaultProfile","chargingProfileKind":"Recurring","recurrencyKind":"Daily","chargingSchedule":{"duration":86400,"startSchedule":"2026-09-24T22:00:00Z","chargingRateUnit":"A","chargingSchedulePeriod":[{"startPeriod":0,"limit":12.0,"numberPhases":3},{"startPeriod":21600,"limit":8.0,"numberPhases":3},{"startPeriod":79200,"limit":10.0,"numberPhases":3}]}}}]

Answer: {"status":"Accepted"}. Profiles persist between sessions — a later ClearChargingProfile for the same purpose returns Accepted.

Why 0.11.4 works and 0.12.0 does not

In 0.11.4 the slider sends the station profile at stack level 5, gets refused, and silently follows with a TxDefaultProfile on connector 1 at stack level 4. That second message is what actually applies the limit: Current Offered follows the slider (10 A slider → 10.00 A offered, 9.94 A drawn). 0.12.0 sends only the first message, so nothing applies.

Suggestion

For single-connector 1.6 chargers, keeping the TxDefaultProfile path as an option would cover this hardware. Going further, accepting a recurring TxDefaultProfile would let the charger hold a daily schedule on its own — the vendor app does exactly that, and it survives a CSMS outage.

Charger side quirks (may explain some of the timeouts in the original report): GetConfiguration for ChargingScheduleAllowedChargingRateUnit occasionally gets no answer within 10 s, on both versions; one frame from the charger was malformed (1002 (protocol error) incorrect masking); ClockAlignedDataInterval is read-only and already 0, so writing the default 900 always fails.

timxon-a0-charging-profiles-capture.log