Tinkerforge WARP HTTP API (BC) #26334

lehmanju · 2026-01-01T16:33:21Z

Die WARP Charger von Tinkerforge implementieren inzwischen alle eine HTTP API. Dieser PR implementiert diese API analog zur MQTT API. Die MQTT API wird weiter unterstützt, ist aber als deprecated markiert. Zukünftige Nutzer können die Wallbox jetzt einfacher konfigurieren, es ist nur die Angabe einer IP/eines Hostnamens erforderlich.

Damit wird der MQTT Broker für mich dann auch endlich überflüssig und kann abgeschaltet werden.

Außerdem:
~~- devcontainer baute nicht, deswegen moby deaktiviert~~ #26335

Das Phase Auto Switching Warp2/3: phase mismatch when Warp switches to 1p #14403 wird jetzt einfach beim Start deaktiviert, wenn vorhanden. So sind dann die Templates wieder einheitlich.

sourcery-ai

Hey - I've left some high level feedback:

In meterValues the length check len(res) <= 5 will still allow slices of length 5 and then currents/voltages index up to res[5], so this should be len(res) < 6 (or equivalent) to avoid a potential out-of-bounds panic.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In `meterValues` the length check `len(res) <= 5` will still allow slices of length 5 and then `currents`/`voltages` index up to `res[5]`, so this should be `len(res) < 6` (or equivalent) to avoid a potential out-of-bounds panic.

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

andig · 2026-01-01T16:48:01Z

devcontainer baute nicht, deswegen moby deaktiviert

OT, bitte neuer PR.

templates/definition/charger/tinkerforge-warp-http.yaml

charger/warp-http.go

andig · 2026-01-01T16:51:40Z

Nice PR!

andig · 2026-01-01T17:06:36Z

Die MQTT API wird weiter unterstützt, ist aber als deprecated markiert

Hast Du dazu eine Referenz?

lehmanju · 2026-01-01T17:08:05Z

Die MQTT API wird weiter unterstützt, ist aber als deprecated markiert

Hast Du dazu eine Referenz?

Ah, missverständlich. Die ist nicht in der WARP Firmware deprecated, sondern die evcc Templates sind als deprecated markiert ;).

andig · 2026-01-01T17:10:28Z

Ah- für mich auch ok. Ohne Umwege ist egtl. immer besser!

mfuchs1984 · 2026-01-03T13:15:45Z

charger/warp-http.go

+// CurrentPower implements the api.Meter interface
+func (wb *WarpHTTP) currentPower() (float64, error) {
+	var res warp.MeterValues
+	uri := fmt.Sprintf("%s/meter/values", wb.uri)


According to https://docs.warp-charger.com/docs/interfaces/mqtt_http/api_reference/meter this endpoint is deprecated. They recommend to use https://docs.warp-charger.com/docs/interfaces/mqtt_http/api_reference/meters

Ja, stelle ich um. Habs erstmal einfach 1:1 von MQTT übernommen.

Ich werds so machen, dass am Anfang geprüft wird, ob die meters API überhaupt unterstützt wird, sonst Fallback auf die alte API.

mfuchs1984

See inline comment.

deadrabbit87 · 2026-01-03T13:32:47Z

Für Setups wo neben evcc auch andere Systeme auf die Wallbox zugreifen, hat MQTT den Vorteil dass alle Clients parallel per Publish/Subscribe lauschen können, ohne die Wallbox mehrfach zu pollen. Wäre es sinnvoll, die MQTT Templates nicht als deprecated zu markieren, sondern als gleichwertige Alternative zu belassen – für Nutzer die ohnehin einen Broker betreiben?

deadrabbit87 · 2026-01-03T13:48:14Z

charger/warp-http.go

+
+	var phases func(int) error
+	var getPhases func() (int, error)
+	if cc.EnergyManagerURI != "" {


Bei der WARP3 ist kein separater WEM notwendig, da die WARP3 die Phasenumschaltung selbst über die /power_manager/ API unterstützt. Der Code sollte prüfen ob die Wallbox-URI selbst das Feature hat.

Weiterhin sollte der Kommentar im Template angepasst werden, da dies für WARP3 Nutzer sonst irreführend ist.

Guter Punkt, in dem Fall würde ich vermutlich für WARP3 einfach ein eigenes Template machen und dort die EnergyManagerURI auch auf die Wallbox URI hardcoden. Dann kann man auch die Dokumentation auseinander ziehen.

Wie wäre es so?

if cc.EnergyManagerURI == "" { wb.emURI = wb.uri wb.emHelper = wb.Helper } if res, err := wb.emState(); err == nil && res.ExternalControl != 1 { phases = wb.phases1p3p getPhases = wb.getPhases }

Das hier wäre die Antwort einer WARP2:

curl http://172.20.10.50/power_manager/state {"config_error_flags":0,"external_control":1}

WEM:

curl http://172.20.10.60/power_manager/state {"config_error_flags":0,"external_control":0}

und einer WARP3:

curl http://192.168.179.250/power_manager/state {"config_error_flags":0,"external_control":0}

Ich hab einfach so gedacht:

template: tinkerforge-warp3-http products: - brand: TinkerForge description: generic: WARP3 Charger Smart - brand: TinkerForge description: generic: WARP3 Charger Pro capabilities: ["mA", "1p3p", "rfid"] evcc: ["skiptest"] params: - name: uri required: true - name: user - name: password render: | type: warp-http uri: {{ .uri }} user: {{ .user }} password: {{ .password }} energyManagerUri: {{ .uri }} energyManagerUser: {{ .user }} energyManagerPassword: {{ .password }}

Da muss man als Nutzer dann auch nur noch eine URI eingeben. Und die Beschreibung mit WEM und Firmware Version ist auch gleich weg.

Wieder Geschmackssache, bin ich persönlich neutral. Hat beides Vor- und Nachteile.

deadrabbit87 · 2026-01-03T14:08:30Z

charger/warp-http.go

+	}
+
+	var res interface{}
+	return wb.DoJSON(req, &res)


Verursacht bei mir einen EOF mit WARP2 und WEM:

[warp-http] TRACE 2026/01/03 14:54:57 GET http://172.20.10.50/info/features [warp-http] TRACE 2026/01/03 14:54:57 ["evse","cp_disconnect","button_configuration","ethernet","firmware_update","meters","nfc","evse_gp_output","meter","meter_all_values","meter_phases"] [warp-http] TRACE 2026/01/03 14:54:57 GET http://172.20.10.60/power_manager/state [warp-http] TRACE 2026/01/03 14:54:57 {"config_error_flags":0,"external_control":0} [warp-http] TRACE 2026/01/03 14:54:57 PUT http://172.20.10.50/evse/phase_auto_switch [warp-http] TRACE 2026/01/03 14:54:57 {"enabled":false} [warp-http] INFO 2026/01/03 14:54:57 disabling phase auto switch skipped: EOF [warp-http] TRACE 2026/01/03 14:55:01 GET http://172.20.10.50/meter/values [warp-http] TRACE 2026/01/03 14:55:01 {"power":2.832569361,"energy_rel":7784.958984,"energy_abs":7784.958984} [warp-http] TRACE 2026/01/03 14:55:03 GET http://172.20.10.50/evse/external_current

Das hier ist die Antwort des WEMs auf den Endpunkt:

curl http://172.20.10.60/power_manager/state {"config_error_flags":0,"external_control":0}

EOF bei phase_auto_switch ist expected, weil die WARP2 das nicht unterstützt (glaube ich), deswegen auch nur ein INFO log und kein Fehler.

Aber nicht wenn ich einen WEM konfiguriert habe. Dann sollte kein EOF kommen, weil die WARP2 damit ja auch Phaseumschaltung kann.

Aber ja, ist korrekt, die WARP2 kann nur mit WEM Phasenumschaltung.

Auf der offiziellen Dokumentationsseite der API existiert der Auto Switch Endpunkt nur für WARP3: https://docs.warp-charger.com/docs/interfaces/mqtt_http/api_reference/evse/?hardwareType=warp3#evse_phase_auto_switch_warp3

Wenn man rechts WARP1/2 auswählt, dann fehlt dieser. Da ich selbst eine WARP2 habe, kann ich bestätigen, dass der Endpunkt nicht existiert.

Das heißt nicht, dass die WARP2 keine Phasenumschaltung kann, sondern bedeutet nur, dass sie das nicht selbst automatisch macht und man ein Verhalten wie hier #14403 hat.

lehmanju · 2026-01-03T14:19:18Z

Für Setups wo neben evcc auch andere Systeme auf die Wallbox zugreifen, hat MQTT den Vorteil dass alle Clients parallel per Publish/Subscribe lauschen können, ohne die Wallbox mehrfach zu pollen. Wäre es sinnvoll, die MQTT Templates nicht als deprecated zu markieren, sondern als gleichwertige Alternative zu belassen – für Nutzer die ohnehin einen Broker betreiben?

Die API wird ja nicht tausendfach pro Sekunde gepollt, insofern ist das denke ich kein Problem. HTTP mit JSON kann schon einiges ab, da kommt man mit evcc nicht so schnell an Grenzen. Andere Clients können ja weiterhin MQTT nutzen. Sollte sich Gegenteiliges herausstellen, kann man das deprecated ja wieder rückgängig machen. Aber besser ist glaube ich schon perspektivisch nur eine API zu pflegen.

deadrabbit87 · 2026-01-03T14:33:59Z

charger/warp-http.go

+}
+
+// phases1p3p implements the api.PhaseSwitcher interface
+func (wb *WarpHTTP) phases1p3p(phases int) error {


Gleiches Problem wie https://github.com/evcc-io/evcc/pull/26334/files#r2658941559 :

Der WEM gibt hier nichts zurück. Schalte ich auf "Schnell" wird zwar mit 3p geladen, aber nur mit 6 A weil evcc davon ausgeht, dass der Phasenwechsel fehlschlug.

Bei Bedarf kann ich die Trace Logs auch noch zur Verfügung stellen.

Danke, ist tatsächlich ein anderes Problem. Auf der Startseite der API Doku schreiben sie, dass MQTT und HTTP dieselbe API haben und dann ist es doch nicht so :D. Jedenfalls heißt der Endpunkt bei HTTP wohl einfach nur external_control.

Danke fürs Testen!

deadrabbit87 · 2026-01-03T14:39:17Z

Ich nutze ein WARP2 mit WEM der die Phaseumschaltung macht.

Für Setups wo neben evcc auch andere Systeme auf die Wallbox zugreifen, hat MQTT den Vorteil dass alle Clients parallel per Publish/Subscribe lauschen können, ohne die Wallbox mehrfach zu pollen. Wäre es sinnvoll, die MQTT Templates nicht als deprecated zu markieren, sondern als gleichwertige Alternative zu belassen – für Nutzer die ohnehin einen Broker betreiben?

Die API wird ja nicht tausendfach pro Sekunde gepollt, insofern ist das denke ich kein Problem. HTTP mit JSON kann schon einiges ab, da kommt man mit evcc nicht so schnell an Grenzen. Andere Clients können ja weiterhin MQTT nutzen. Sollte sich Gegenteiliges herausstellen, kann man das deprecated ja wieder rückgängig machen. Aber besser ist glaube ich schon perspektivisch nur eine API zu pflegen.

Ich wollte das nur anmerken, da ich persönlich lieber weiter den Broker nutzen wollen würde.

Ist aber nicht konstruktiv begründet, sondern nur Geschmackssache.

evcc-bot added devices Specific device support enhancement New feature or request labels Jan 1, 2026

lehmanju force-pushed the warp-http branch from e95f693 to ae42721 Compare January 1, 2026 16:34

sourcery-ai bot reviewed Jan 1, 2026

View reviewed changes

andig reviewed Jan 1, 2026

View reviewed changes

templates/definition/charger/tinkerforge-warp-http.yaml Outdated Show resolved Hide resolved

lehmanju force-pushed the warp-http branch from ae42721 to 193e08d Compare January 1, 2026 16:50

andig reviewed Jan 1, 2026

View reviewed changes

charger/warp-http.go Outdated Show resolved Hide resolved

lehmanju force-pushed the warp-http branch from 193e08d to d908dee Compare January 1, 2026 16:55

lehmanju added 2 commits January 1, 2026 17:58

feat: tinkerforge warp http api

8cbc86f

feat: tinkerforge warp: disable phase auto switch on startup

2d664be

lehmanju force-pushed the warp-http branch from d908dee to 2d664be Compare January 1, 2026 16:58

andig changed the title ~~Tinkerforge WARP HTTP API~~ Tinkerforge WARP HTTP API (BC) Jan 1, 2026

andig requested a review from premultiply January 1, 2026 17:10

mfuchs1984 reviewed Jan 3, 2026

View reviewed changes

deadrabbit87 reviewed Jan 3, 2026

View reviewed changes

Uh oh!

Tinkerforge WARP HTTP API (BC) #26334

Are you sure you want to change the base?

Tinkerforge WARP HTTP API (BC) #26334

Conversation

lehmanju commented Jan 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sourcery-ai bot left a comment

Choose a reason for hiding this comment

Uh oh!

andig commented Jan 1, 2026

Uh oh!

Uh oh!

Uh oh!

andig commented Jan 1, 2026

Uh oh!

andig commented Jan 1, 2026

Uh oh!

lehmanju commented Jan 1, 2026

Uh oh!

andig commented Jan 1, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mfuchs1984 left a comment

Choose a reason for hiding this comment

Uh oh!

deadrabbit87 commented Jan 3, 2026

Uh oh!

deadrabbit87 Jan 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lehmanju Jan 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

deadrabbit87 Jan 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lehmanju commented Jan 3, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

deadrabbit87 commented Jan 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

lehmanju commented Jan 1, 2026 •

edited

Loading

deadrabbit87 Jan 3, 2026 •

edited

Loading

lehmanju Jan 3, 2026 •

edited

Loading

deadrabbit87 Jan 3, 2026 •

edited

Loading