Skip to content
View in the app

A better way to browse. Learn more.

Tinkerunity

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

WARP3: API-Zähler lässt sich anlegen, aber meters/X/update wird als „unknown topic“ verworfen (Firmware 2.9.0)

Featured Replies

Geschrieben

Hallo Tinkerforge / WARP-Team,

ich versuche einen virtuellen Stromzähler über die API-Meter-Schnittstelle an eine WARP3 anzubinden, stoße dabei aber auf ein Verhalten, das nicht ganz zur Dokumentation passt. Vielleicht übersehe ich etwas – oder es handelt sich um einen Firmware-Bug.

Setup

  • Gerät: WARP3 Charger Smart 22kW

  • Firmware: 2.9.0+69831bfb

  • MQTT aktiviert

  • Broker: Mosquitto im lokalen Netz

  • MQTT-Prefix der WARP: warp3/2hgV

Als externen Zähler verwende ich einen Tasmota-basierten Stromzähler (ESP32), der seine Messwerte per MQTT veröffentlicht.

Beispiel-Payload:

tele/tasmota_385B38/SENSOR
{
  "grid": {
    "power": 2509.91,
    "power_L1": 86.38,
    "power_L2": 2277.76,
    "power_L3": 89.43
  }
}

Ich habe dazu eine kleine Python-Bridge geschrieben, die diese Werte abonniert und an die WARP weiterleitet.


Schritt 1 – API-Zähler anlegen

Das Anlegen des API-Zählers funktioniert problemlos.

Beispiel:

curl http://192.168.0.100/meters/1/config \
  -d '[4,{"display_name":"Grid connection","location":4,"value_ids":[74]}]'

Ergebnis:

  • Der Zähler erscheint in der Web-UI.

  • Im Debug-Report steht:

meters/1/config [4,{"display_name":"Grid connection","location":4,"value_ids":[74]}]
meters/1/value_ids [74]
meters/1/values [null]

Außerdem im Boot-Log:

Meter 1: Meter declared 1 value

Das sieht für mich so aus, als würde die Konfiguration korrekt übernommen.


Schritt 2 – Werte über MQTT senden

Laut Dokumentation sollten API-Zähler über

meters/X/update

aktualisiert werden können.

Mein Test:

mosquitto_pub -h 192.168.0.141 \
  -t warp3/2hgV/meters/1/update \
  -m '[2453.59]'

Im Log der WARP erscheint jedoch:

mqtt | Received message on unknown topic 'meters/1/update'

Das heißt: Die Nachricht kommt an, aber das Topic wird nicht erkannt.


HTTP-Test

Auch der HTTP-Endpunkt scheint nicht zu existieren:

curl http://192.168.0.100/meters/1/update -d '[2453.59]'

Antwort:

Nothing matches the given URI.

Der Zähler bleibt weiterhin bei:

values [null]

Weitere Tests

Ich habe zusätzlich ausprobiert:

  • Slot 2 statt 1

  • value_ids mit mehreren Werten ([39,48,57,74])

  • Updates per HTTP und MQTT

Das Verhalten bleibt identisch.


Auffälligkeit

Im Debug-Report taucht meters/1/update in der API-Liste auf, was vermuten lässt, dass der Endpunkt existieren sollte. Zur Laufzeit meldet MQTT aber konsequent „unknown topic“.


Frage

Handelt es sich hierbei eher um

  1. einen Firmware-Bug in 2.9.0,

  2. eine Abweichung zwischen Dokumentation und Firmware,

  3. oder fehlt noch ein Aktivierungsschritt für API-Zähler-Updates?


Ziel

Ich möchte die Netzleistung eines Tasmota-MQTT-Stromzählers als virtuellen Netzanschluss-Zähler in der WARP nutzen

Vielen Dank schon einmal!

Viele Grüße
Wadim

Geschrieben
  • Autor

Update / Lösung

Ich glaube wir haben das Problem gefunden.

Das Verhalten lag nicht am MQTT-Topic oder an der Payload, sondern daran, wann die API-Meter in der Firmware initialisiert werden.

Ich hatte den API-Zähler per

/meters/1/config

angelegt und danach direkt versucht Werte über

meters/1/update

zu senden.

Der Zähler erscheint zwar sofort in der UI und value_ids werden korrekt gesetzt, aber die Firmware registriert die zugehörigen API-Commands (inkl. meters/X/update) erst beim Boot, wenn die Meter-Instanzen erzeugt werden.

Das führt dazu, dass man ohne Reboot folgendes sieht:

Received message on unknown topic 'meters/1/update'

Die Konfiguration ist also gespeichert, aber der MQTT-Handler kennt den Command noch nicht.

Die Lösung war simpel:

  1. API-Meter konfigurieren

curl http://<warp>/meters/1/config \-d '[4,{"display_name":"Grid connection","location":4,"value_ids":[39,48,57,74]}]'
  1. WARP einmal neu starten

  2. Danach funktionieren Updates sofort:

mosquitto_pub -t warp3/<uid>/meters/1/update \
-m '[L1_power,L2_power,L3_power,total_power]'

Danach werden die Werte korrekt übernommen und erscheinen auch in der UI.

In meinem Fall kommt die Leistung von einem Tasmota-Stromzähler über MQTT, den ich über eine kleine Python-Bridge an die WARP weiterreiche.

Vielleicht hilft das ja jemandem, der über das gleiche Verhalten stolpert 🙂

Geschrieben

Kann es sein dass du nachdem du den Zähler per curl angelegt hast den ESP nicht neugestartet hast? Bei den aktuellen Firmwares muss man nach Config-Änderungen der meters einmal den ESP neustarten (System -> Einstellungen -> Neu starten).

Edit: Oh jetzt hatte es sich überschnitten. Du hast es schon selber herausgefunden gehabt 😅.

Geschrieben
Am 14.3.2026 um 22:23 schrieb wadim:

In meinem Fall kommt die Leistung von einem Tasmota-Stromzähler über MQTT, den ich über eine kleine Python-Bridge an die WARP weiterreiche.

Das Tasmota-Script kann auch selbst WebQueries absetzen. Z.B so:

>S
=>WebQuery http://warp-ip/meters/0/update POST [Content-Type:application/json] [%sml[3]%]

bearbeitet von sfancy

Geschrieben
On 3/14/2026 at 9:34 PM, wadim said:

Das Anlegen des API-Zählers funktioniert problemlos.

Beispiel:

curl http://192.168.0.100/meters/1/config \
  -d '[4,{"display_name":"Grid connection","location":4,"value_ids":[74]}]'

Ergebnis:

  • Der Zähler erscheint in der Web-UI.

  • Im Debug-Report steht:

meters/1/config [4,{"display_name":"Grid connection","location":4,"value_ids":[74]}]
meters/1/value_ids [74]
meters/1/values [null]

Außerdem im Boot-Log:

Meter 1: Meter declared 1 value
On 3/14/2026 at 10:23 PM, wadim said:

Der Zähler erscheint zwar sofort in der UI und value_ids werden korrekt gesetzt, […]

Wenn ich die Config mit deinem curl-Aufruf setze, erscheint der Zähler sofort in der UI und im Debug-Report bekomme ich das hier:

 "meters/1/config": [4,{"display_name":"Grid connection","location":4,"value_ids":[74]}],
 "meters/1/value_ids": [],
 "meters/1/values": [],

Im Ereignis-Log erscheint keine Meldung hinsichtlich der Zählerwerte. Das entspricht alles meinen Erwartungen.

Da die Setup-Funktion eines API-Zählers, die die value_ids setzt, nur beim Booten ausgeführt wird, weiß ich nicht, wie du dein System in den Zustand bekommen hast, dass die value_ids gesetzt sind, aber der update-Endpoint nicht existiert. value_ids und values können vielleicht alte Werte enthalten, da der Formatierung nach deine zitierten Werte nicht aus dem Debug-Report sondern von MQTT stammen, aber die Meldung „Meter 1: Meter declared 1 value“ kann ein API-Zähler eigentlich nicht zur Laufzeit ausgeben.

Falls du das irgendwie reproduzieren kannst, würde ich mich über eine Schritt-für-Schritt-Anleitung freuen.

Geschrieben

Vielleicht kann ich mich hier mal einklinken 🙂

Eine kurze Beschreibung meines Problems: Da ich neben einer konventionellen PV-Anlage zudem ein Victron-ESS betreibe, erscheint solange der 32kWh HausAkku nicht voll ist, kein Überschuss auf dem NetzZähler, der auch in der Wallbox hinterlegt ist. Ich würde jetzt gerne einen virtuellen PV-ÜberschussZähler einrichten, den ich z.B. via NodeRed "befüllen" kann und den die Wallbox dann als Richtwert nutzen kann. Kann ich das einfach umsetzen? 🤔

WARP3 Charger Pro 11kW 2.9.0+

bearbeitet von KNX

Geschrieben
On 3/17/2026 at 6:45 PM, KNX said:

Eine kurze Beschreibung meines Problems: Da ich aber neben einer konventionellen PV-Anlage zudem ein Victron-ESS betreibe, erscheint solange der Akku nicht voll ist, kein Überschuss auf dem NetzZähler, den ich in der Wallbox hinterlegt habe. Ich würde jetzt gerne einen virtuellen PV-ÜberschussZähler einrichten, den ich z.B. via NodeRed "befüllen" kann und den die Wallbox dann als Richtwert nutzen kann. Kann ich das einfach umsetzen? 🤔

Das könntest du wahrscheinlich umsetzen, aber da andere sowas schon mal probiert haben, kann ich dir sagen, dass das meist nicht zum gewünschten Ergebnis führt, bzw. die Regelung extrem mies ist.

Mit welchen Werten würdest du den virtuellen Zähler befüllen wollen?

Falls du einen Victron GX hast, solltest du den Batteriespeicher einfach als zusätzlichen Zähler anlegen und beim PV-Überschussladen als Batteriezähler auswählen. Dann beachtet die Wallbox automatisch die Speicherleistung.

Geschrieben

Danke für diesen Hinweis 👍

Da ich ja eine "normale" Huawei-PV-Anlage habe, könnte ich diesen Überschuss in die Wallbox schicken, während der ESS-Akku mit der Leistung der Victron Laderegler geladen wird.

Leider erkennt die Wallbox den Huawei-Zähler nicht als Zähler an, da die gerichtetet Wirkleistung fehlt. Ich würde also hauptsächlich diesen Wert plusminus wählen wollen. Übergangsweise nutze ich den Zähler, den ich für mein ESS eingebaut habe. Das klappt solange, bis der Akku voll ist.

Geschrieben

Ich bin mir zwar nicht sicher, was für ein Setup du genau hast, aber vielleicht würde es dir helfen, einen API-Zähler für den Speicher anzulegen. Dann musst du den nur mit den passenden Werten für deinen Speicher füttern. Ist der Akku voll, schreibst du halt 0 rein. Die Wallbox verrechnet dann diesen Zähler mit dem Netzbezug.

Geschrieben
On 3/17/2026 at 9:27 PM, KNX said:

Leider erkennt die Wallbox den Huawei-Zähler nicht als Zähler an, da die gerichtetet Wirkleistung fehlt.

Um welche Huawei-Anlage geht es genau? Alle Huawei-Zähler, die wir unterstützen, liefern die gerichtetet Wirkleistung.

Kannst du mir einen Debug Report (im Webinterface der Wallbox unter System > Ereignis-Log abspeichern) zeigen, bei dem der betroffene Zähler in der Wallbox eingerichtet ist?

Geschrieben

Den Batteriespeicher habe ich beim PV-Überschussladen nicht hinterlegt bzw. aktiviert.

Ich habe DreiPhasen-Zähler (Gavazzi EM24 modBus TCP) für das Victron-ESS und die Wallbox selbst. Die Daten für das Netz hole ich aus Victrons CerboGX, das mit einem Gavazzi EM540 via modBus RTU verbunden ist, die der Huawei-Anlage aus dem SmartLogger, der seine Daten aus dem üblichen DTSU-666H auch via modBus RTU erhält. Das sieht bei mir dann so aus:

grafik.png

Abb.: Auszug WARP3 Zähler

Vielleicht würde es schon genügen, wenn ich den Huawei-Zähler richtig einbinden könnte 🤔

Die Debug-Datei habe ich angehängt.

warp3-2hh8-Debug-Report-2026-03-18T09-11-49-597.txt

bearbeitet von KNX

Geschrieben

@KNX Ich denke du hast deine Zähler nicht richtig konfiguriert. Ich sehe im Debug Report folgende Struktur:

Wallbox: Carlo Gavazzi EM24 E1 mit Messort Netzanschluss. Hast du eine WARP3 Smart und extern einen Carlo Gavazzi EM24 E1 davorgesetzt, um daraus eine WARP3 Pro zu machen? Hier solltest du den Messort von Netzanschluss auf Last ändern. Eigentlich sollte der Messort Wallbox sein, aber den gibt es aktuell noch nicht.

Netz: Victron Energy GX mit virtuellem Zähler Netzanschluss am Messort Netzanschluss. So weit so gut, aber du hast den ESS Zähler im PV-Überschussladen als Stromzähler gewählt. Hier muss du stattdessen den Netz Zähler wählen, denn das PV-Überschussladen muss wissen was am Netzanschluss passiert, nicht was deine PV-Anlagen gerade produziert.

ESS: Carlo Gavazzi EM24 E1 mit Messort Speicher. An sich okay, aber ein externer Zähler am Speicher liefert den SoC nicht. Besser wäre, wenn du stattdessen den Speicher auch über Victron Energy GX mit virtuellem Zähler Speicher anbinden würdest, dann wäre auch der SoC verfügbar. Diesen Zähler mit SoC kannst du dann auch für das PV-Überschussladen als Batteriezähler wählen.

Huawei: Huawei Smart Logger 3000 mit virtuellem Zähler PV am Messort PV. Das hier ist die PV-Leistung deiner Huawei-Anlage. Diesen Zähler kannst du zu Recht im PV-Überschussladen nicht auswählen, weil die reine PV-Leistung nicht interessant ist, sondern nur das was davon am Netzanschluss übrig ist und das wird am Netzanschluss gemessen.

Geschrieben

@photron Danke für deine Analyse 👍 Ich habe das entsprechend deiner Hinweise geändert.

Wallbox: Diesen Zähler habe ich zusammen mit meiner ersten Wallbox (Heidelberg EnergyControl) eingebaut. Bei der Installation der neuen WARP3 habe ich ihn bestehen lassen und dachte, ich könne ihn direkt als WallboxZähler 0 nutzen 🤔 Scheinbar ist das aber nicht so einfach möglich, wie ich es mir dachte 😉

ESS: Ich hatte diesen Zähler für den PV-Überschuss gewählt, um mehr Kontrolle darüber zu haben, wieviel Energie in den Haus- bzw. den Auto-Akku fließt. Meine Victron-Anlage belädt den Akku neben AC-Energie auch direkt mit DC-Energie. Diese Leistung erscheint dann als Bezug im ESS-Zähler, obwohl keine AC-Last zum Laden herangezogen wird.

grafik.png

Abb.: Auszug Stromzähler - ESS wird aktuell nur DC-Energie beladen; es erfolgt kein Bezug aus dem Strom- bzw. Hausnetz

warp3-2hh8-Debug-Report-2026-03-19T11-34-52-449.txt

bearbeitet von KNX

Geschrieben
On 3/19/2026 at 11:36 AM, KNX said:

Wallbox: Diesen Zähler habe ich zusammen mit meiner ersten Wallbox (Heidelberg EnergyControl) eingebaut. Bei der Installation der neuen WARP3 habe ich ihn bestehen lassen und dachte, ich könne ihn direkt als WallboxZähler 0 nutzen 🤔 Scheinbar ist das aber nicht so einfach möglich, wie ich es mir dachte 😉

Was misst der Zähler denn? Wenn er tatsächlich nur den Wallbox-Bezug misst, kannst du ihn direkt als Wallbox-Zähler nutzen. Nur der Messort muss halt „Last“ sein.

On 3/19/2026 at 11:36 AM, KNX said:

ESS: Ich hatte diesen Zähler für den PV-Überschuss gewählt, um mehr Kontrolle darüber zu haben, wieviel Energie in den Haus- bzw. den Auto-Akku fließt. Meine Victron-Anlage belädt den Akku neben AC-Energie auch direkt mit DC-Energie. Diese Leistung erscheint dann als Bezug im ESS-Zähler, obwohl keine AC-Last zum Laden herangezogen wird.

grafik.png

Abb.: Auszug Stromzähler - ESS wird aktuell nur DC-Energie beladen; es erfolgt kein Bezug aus dem Strom- bzw. Hausnetz

Mit welcher Leistung soll denn in diesem Fall geladen werden? 10,8 kW, 2,9 kW oder 13,8 kW?

Der ESS-Zähler ist also einfach die Lade- und Entladeleistung des Batteriespeichers, egal ob AC oder DC?

Geschrieben

@MatzeTF Ok, der Wallbox-Zähler ist nun auf Last umgestellt.

Bei der angezeigten Abbildung ist der Zähler, wie von @photon angeraten, als VictronGX-Zähler hinterlegt und misst die ganze Last, die mein ESS erzeugt (AC und DC). Der physikalisch verbundene Gavazzi-Zähler, der aktuell nicht hinterlegt ist, misst nur die reine AC-Last meines Victron ESS.

Würde die Wallbox bei der aktuellen Konfiguration nun 10.851W minus 2.991W oder plus 2.991W als Überschuss laden? 🤔Wunsch wäre es in diesem Beispiel, dass sie die 10.851W nutzt.

Mein Ziel ist es, Einfluss auf die Ladeleistung in Abhängigkeit vom SoC meines Haus-Akkus, der solaren Vorhersage und meinem Bedarf zu nehmen. Das würde ich gerne via NodeRed bestimmen.

bearbeitet von KNX

Geschrieben

Wenn du beim PV-Überschussladen den Zähler „Netz“ für den Stromzähler am Netzanschluss einstellst und „ESS“ als Stromzähler des Batteriespeichers und dann die Speicherpriorität so einstellst, dass bis zum gewünschten SoC der Speicher bevorzugt wird, erledigt die Wallbox alles automatisch. Wenn du in dem Beispiel aus dem Screenshot den Mindest-SoC auf 80 % gestellt hast, würden unter 80 % SoC 10.851 W für dein Auto freigegeben, also nur das, was nicht in deinen Speicher sondern als Überschuss ins Netz geht, und über 80 % SoC würden 13.842 W fürs Auto freigegeben, also Netz-Überschuss plus das, was sonst in den Speicher gehen würde.

Wenn deine Anforderungen darüber hinausgehen, musst du anfangen, irgendwelche Werte zu verpfuschen und die modifizierten Werte an die Wallbox zu liefern. Beispielsweise könntest du abhängig von irgendwelchen Kriterien die Speicherladung als 0 W melden und so die Speicherleistung verstecken, sodass die Wallbox den Speicher laden lässt und dessen Leistung nicht fürs Auto freigibt. Eine vorgefertigte Lösung gibt es dafür aber nicht, die müsstest du selbst bauen.

Geschrieben

Ok, das ist doch schon mal eine gute Basis 👍

So könnte ich diesen Mindest-SoC in Abhängigkeit von der Jahreszeit ändern, um der veränderten Einstrahlung Rechnung zu tragen. Könnte man diesen Wert auch extern (z.B. über einen HTTP-Befehl oder Ähnliches) manipulieren? 🤔

bearbeitet von KNX

Geschrieben

Danke für den Input 😎

Ich werde das Ganze jetzt mal für mein Setting bzw. meine Anforderungen testen und dann wieder berichten 😀

Geschrieben

Erster Test:

grafik.png

Abb.: Auszug Verlauf Stromzähler

Die Ladung klappte, solange der Netz-Überschuss die magischen 1380W nicht unterschritt. Der SoC des ESS steht aktuell bei 99%; die Wallbox darf also auch daraus Energie beziehen, was sie allerdings nicht tat 🤔

Geschrieben

Im PV-Modus soll die Wallbox nie dauerhaft Strom aus dem Speicher beziehen. Der Speicher wird nur bis zu vier Minuten lang zum Überbrücken von durchziehenden Wolken genutzt. Wenn abends die PV-Leistung sinkt, dauert es allerdings aufgrund um 1380 W herum schwankender Leistung oft auch länger als vier Minuten, bis die Ladung beendet wird.

Wenn du es eilig hast und auch ohne PV-Leistung laden möchtest, musst du entweder den Min+PV-Modus oder den Schnellmodus nutzen.

Geschrieben

Danke...langsam lichten sich die Fragen 🙂

Wenn ich also eine SoC-abhängige Entladung umsetzen möchte, müsste ich den eingenstellten Wert für die Mindestladeleistung manipulieren. Ließe sich das automatisieren? 🤔

Hintergrund: Das BEV (42kWh) ist meistens erst nachmittags zuhause. Bis dahin hat meine PV-Anlage (24kWp) den Haus-Akku (32kWh) meistens relativ gefüllt und ich kann einen Teil dieser Energie auch ins Auto laden

bearbeitet von KNX

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

Account

Navigation

Suche

Suche

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.