Description
The MQTT Auto-Discovery of the go-eCharger firmware creates a writable entity
"Set Max Ampere Limit" which maps to the API key ama ("Maximales Ampere Limit").
However, for dynamic charging control (e.g. PV surplus charging, Home Assistant
automations), the correct API key is amp ("Gewünschtes Limit in Ampere, genutzt
für LED Ring Darstellung und interne Logik Abläufe") — not ama.
Currently there is no writable entity for amp provided via MQTT Auto-Discovery,
which leads users to accidentally modify ama instead of the dynamic charging
current.
Evidence
The MQTT Auto-Discovery payload confirms that ama is registered as the writable
command topic for "Set Max Ampere Limit", while amp is not exposed as a writable
entity at all:
homeassistant/number/go-e_313537/set_max_ampere_limit/config
{"name":"Set Max Ampere Limit","":"go-eCharger/313537/ama",
"stat_t":"","cmd_t":"~/set","unit_of_meas":"A","ent_cat":"config",
"min":6,"max":16,...}
Proposed Solution
Add the following two additional Discovery messages to the firmware:
1. Writable number entity for amp:
{
"name": "Charging Current",
"~": "go-eCharger/313537/amp",
"stat_t": "~",
"cmd_t": "~/set",
"unit_of_meas": "A",
"ent_cat": "config",
"min": 6,
"max": 32,
"uniq_id": "go-e_313537_charging_current",
"dev": {...}
}2. Select entity based on clp (predefined charging current presets):
{
"name": "Charging Current Preset",
"~": "go-eCharger/313537/amp",
"stat_t": "~",
"cmd_t": "~/set",
"val_tpl": "{{ value_json }}",
"ops": [6, 10, 12, 14, 16],
"uniq_id": "go-e_313537_charging_current_preset",
"dev": {...}
}This would be a minimal firmware change — just two additional retained MQTT
messages at startup. Nothing existing would change.
The clp preset values are already provided by the firmware and match exactly
what is shown as presets in the go-e app, making this a natural fit for a
select entity.
Hardware & Firmware
- go-eCharger Gemini Flex
- Firmware: 59.4
- HA: 2026.4
Description
The MQTT Auto-Discovery of the go-eCharger firmware creates a writable entity
"Set Max Ampere Limit" which maps to the API key
ama("Maximales Ampere Limit").However, for dynamic charging control (e.g. PV surplus charging, Home Assistant
automations), the correct API key is
amp("Gewünschtes Limit in Ampere, genutztfür LED Ring Darstellung und interne Logik Abläufe") — not
ama.Currently there is no writable entity for
ampprovided via MQTT Auto-Discovery,which leads users to accidentally modify
amainstead of the dynamic chargingcurrent.
Evidence
The MQTT Auto-Discovery payload confirms that
amais registered as the writablecommand topic for "Set Max Ampere Limit", while
ampis not exposed as a writableentity at all:
homeassistant/number/go-e_313537/set_max_ampere_limit/config
{"name":"Set Max Ampere Limit","
":"go-eCharger/313537/ama",","cmd_t":"~/set","unit_of_meas":"A","ent_cat":"config","stat_t":"
"min":6,"max":16,...}
Proposed Solution
Add the following two additional Discovery messages to the firmware:
1. Writable number entity for
amp:{ "name": "Charging Current", "~": "go-eCharger/313537/amp", "stat_t": "~", "cmd_t": "~/set", "unit_of_meas": "A", "ent_cat": "config", "min": 6, "max": 32, "uniq_id": "go-e_313537_charging_current", "dev": {...} }2. Select entity based on
clp(predefined charging current presets):{ "name": "Charging Current Preset", "~": "go-eCharger/313537/amp", "stat_t": "~", "cmd_t": "~/set", "val_tpl": "{{ value_json }}", "ops": [6, 10, 12, 14, 16], "uniq_id": "go-e_313537_charging_current_preset", "dev": {...} }This would be a minimal firmware change — just two additional retained MQTT
messages at startup. Nothing existing would change.
The
clppreset values are already provided by the firmware and match exactlywhat is shown as presets in the go-e app, making this a natural fit for a
select entity.
Hardware & Firmware