Moin,

ich stehe vor folgendem Thema: Eine alte PV Anlage soll für PV Überschussladen mit der Warp4 genutzt werden. Hierfür soll ein zusätzlicher Zähler am Hausanschluss installiert werden, welchen die Wallbox über Ethernet abfragen kann. Nach Lesen der Kompatiblitätsliste schwanke ich derzeit zwischen diesen beiden Modellen:

• Shelly Pro 3EM

• Carlo Gavazzi / Victron EM24

Welcher dieser beiden Zähler ist die bessere Option, falls man das so sagen kann? Gibt es eine Empfehlung oder eventuell ein ganz anderes Modell, welches ich noch nicht auf dem Schirm habe?

Zweck des Zählers wird derzeit und auch in absehbarer Zukunft nur PV Überschussladen. Keine ESS Steuerung etc. Er soll also möglichst Preiswert (nicht billig!) sein, Ethernet und natürlich Warp kompatibel zwecks PV Laden.

Danke für eure Gedanken!

MfG Jan

Der Shelly Pro 3EM ist um null Watt herum – also genau dem Bereich für PV-Überschussladen – relativ ungenau und den Shelly, den wir hier zum Testen haben, mussten wir schon zweimal wegen Defekten ersetzen. Ich rate daher zur zweiten Option. 😉

Noch eine andere Option: am eigentlichen Zähler des Netzbetreibers einen IR-Lesekopf anbringen (z.B. bitshake Air).
Dazu muss der Netzzähler natürlich einen IR-Port haben (das haben aber schon seit Jahren alle Zähler) und dessen PIN muss bekannt sein.
Die Option hätte den Vorteil, dass keine 230V-Arbeiten erforderlich sind.

Danke Matze!

@wuesten_fuchs So würde ich das, wäre es meine eigene Anlage, tatsächlich auch in Erwägung ziehen bzw. lese ich meinen Zähler bereits mit einem IR Lesekopf mit esphome aus - allerdings nicht zum Überschussladen sondern um den Akku des Balkonkraftwerks zu steuern. Ist bei meiner mäßigen PV Fläche aber eher Hobby als alles andere und von Überschussladen brauche ich nicht träumen.

Bei der Anlage, um die es hier geht, handelt es sich aber um die eines Familienmitglieds, welche ich mehr oder weniger remote IT technisch betreuen muss/will. Da möchte ich solche, mir grundsätzlich durchaus sympathischen, Bastel-Lösungen nicht unbedingt haben. Wenn dann mal der Zähler getauscht wird, muss man den neuen wieder freischalten, eventuell neues Gehäuse für den Lesekopf drucken etc. und dann steht das Tage bis Wochen bis der Pin da ist, weil die sich da erfahrungsgemäß auch kein Bein ausreißen. Und wenn mal jemand gegen den Lesekopf stößt ist auch gleich aus...

Eine feste Installation mit dem EM24, an die man dann nicht mehr ran muss, die mir ausgiebig erprobt und stabil erscheint und wo auch normalerweise kein Dritter dran geht, ist mir da lieber. Die Installation macht eh der Elektriker - da halte ich mich, zumindest im Bereich Hausanschluss, raus.

Aber um jetzt endlich auch Mal zum Punkt zu kommen. Interessant ist das ja trotzdem. Könnte der Bitshake direkt mit der Warp reden und beispielsweise einen virtuellen Zähler über die API füttern, oder braucht es da noch einen Mittler (home assistant oder was auch immer)?

Edited July 1, 2026 at 08:59 PMJul 1, 2026 by jansch

Am 1.7.2026 um 16:59 schrieb jansch:

Gibt es eine Empfehlung oder eventuell ein ganz anderes Modell, welches ich noch nicht auf dem Schirm habe?

Gibt ja echt viele Optionen, daher fällt eine Entscheidung sicher nicht leicht. Ich kann erzählen, dass ich einen Kostal Smart Energy Meter 2 eingebaut habe und mit der Messung recht zufrieden bin. Deckt sich fast 1:1 mit den vom Netzbetreiber übermittelten Viertelstundenwerten im dynamischen Stromtarif, was aber natürlich nicht die Auflösung ist, die für PVÜ benötigt wäre. Da bin ich aber sicher, dass das auch ganz und gar kein Problem ist, denn die Kompatibilität ist laut Warp Docs gegeben. Gibt's etwas günstiger als den von dir genannten EM24 (z.B. 291€ netto bei Knauer24.de) und ist eben Made in Germany (was mich immer erstmal halbwegs fröhlich stimmt, dass wir auch richtig gute Hardware herstellen können, vgl. Tinkerforge).

Am 1.7.2026 um 23:19 schrieb laubblaeser:

Gibt's etwas günstiger als den von dir genannten EM24 (z.B. 291€ netto bei Knauer24.de)

Danke für den zusätzlichen Vorschlag. Für den EM24 habe ich bisher aber eher Preise in der ~100 Euro Liga gefunden. Bin ich da irgendwo falsch abgebogen?

Am 1.7.2026 um 23:32 schrieb jansch:

Bin ich da irgendwo falsch abgebogen?

Nee, aber scheinbar ich. 😅 Hab das erstbeste Ergebnis eines mir bekannten Webshops als Referenzpreis genommen. Das war Reichelt und die scheinen mit ihrem Preis sehr aus der Reihe zu tanzen.

Edit: Scheinbar gibt's ne MID und ne ungeeichte Version.

Edited July 2, 2026 at 06:28 AMJul 2, 2026 by laubblaeser

On 7/1/2026 at 10:54 PM, jansch said:

Aber um jetzt endlich auch Mal zum Punkt zu kommen. Interessant ist das ja trotzdem. Könnte der Bitshake direkt mit der Warp reden und beispielsweise einen virtuellen Zähler über die API füttern, oder braucht es da noch einen Mittler (home assistant oder was auch immer)?

Das geht direkt. Der Bitshake Air ist (daher der Name) selbst direkt im WLAN (mit seinem ESP32). Und im Tasmota-Script des Kopfes kann man einen Web-API-Aufruf einbauen, so dass der Kopf die Zählerstände direkt live an die Wallbox sendet. Funktioniert bei mir bestens. Ich habe sogar das Sende-Intervall von 1 auf 3 Sekunden verlängern müssen, weil es sonst "zu oft" war. Mir war die Lösung (direkte Übertragung vom Lesekopf zur Wallbox) wichtig, um Fehlerquellen auszuschließen.

Edited July 2, 2026 at 09:16 AMJul 2, 2026 by wuesten_fuchs

Ah sehr gut. Ich versuche das gleich heute Abend mal zu Hause sollte ja mit einem http_request aus dem ESPhome auch zu bewerkstelligen sein.

Ich habe bei meinem Bitshake einfach das da ans normale Script angehängt:

>S
if upsecs%3==0{
=>WebQuery http://192.168.200.43/meters/1/update POST [Content-Type:application/json] [%sml[3]%,%sml[4]%,%sml[5]%,%sml[6]%,%sml[10]%,%sml[11]%,%sml[12]%,%sml[1]%,%sml[2]%]
}

Welche der %sml-Felder man wofür braucht, hängt vom Zähler ab. Siehe die Scripts hier: https://bitshake.de/skripte/

Siehe auch hier: https://www.tinkerunity.org/topic/13657-efr-smartmeter/

Moin,

ich konnte es gestern noch erfolgreich testen. Mein Lesekopf am Zähler, der normalerweise seine Daten zu einem MQTT Broker schiebt, schreibt jetzt seine Daten ebenfalls in einen virtuellen API Zähler der WARP3.

Falls jemand mal sowas mit esphome realisieren möchte, hier mein Beispielsketch:

esphome:
  name: "esphome-lesekopf-zaehler"
  friendly_name: Stromzähler
  min_version: 2025.5.0
  name_add_mac_suffix: false

esp8266:
  board: esp01_1m

# Enable logging
logger:
  baud_rate: 0
  #level: INFO

# Enable Home Assistant API
api:
  encryption:
    key: !secret api_enc_key

# Publish to MQTT
mqtt:
  broker: <brokerhost>
  username: <mqttuser>
  password: !secret mqttuser_password
  discovery: False # disable entity discovery
  discover_ip: True # enable device discovery
  topic_prefix: grid/meter

time:
  - platform: homeassistant

# enable http request
http_request:
  esp8266_disable_ssl_support: true
  follow_redirects: false
  timeout: 0.5s

# Allow Over-The-Air updates
ota:
- platform: esphome

wifi:
  min_auth_mode: WPA2
  networks:
  - ssid: !secret wifi_ssid_iot
    password: !secret wifi_password_iot

# To have a "next url" for improv serial
web_server:
  ota: False
  #log: False
  version: 1

button:
  - platform: restart
    name: restart
    internal: True

uart:
  tx_pin: TX
  rx_pin: RX
  baud_rate: 9600
  data_bits: 8
  parity: NONE
  stop_bits: 1
  # debug: 

sml:

sensor:
  - platform: sml
    name: "Bezug Total"
    obis_code: "1-0:1.8.0"
    unit_of_measurement: kWh
    accuracy_decimals: 2
    device_class: energy
    state_class: total_increasing
    filters:
      - multiply: 0.0001
  - platform: sml
    name: "Lieferung Total"
    obis_code: "1-0:2.8.0"
    unit_of_measurement: kWh
    accuracy_decimals: 2
    device_class: energy
    state_class: total_increasing
    filters:
      - multiply: 0.0001
  - platform: sml
    name: "Leistung"
    obis_code: "1-0:16.7.0"
    unit_of_measurement: W
    accuracy_decimals: 0
    device_class: power
    state_class: measurement
    on_value:
      then:
        - http_request.send:
            method: POST
            url: http://<warphost>/meters/1/update
            request_headers:
              Content-Type: application/json
            body: !lambda |-
              return "[" + to_string(x) + "]";

Relevant für den API Teil sind die Abschnitte

# enable http request
http_request:
  esp8266_disable_ssl_support: true
  follow_redirects: false
  timeout: 0.5s

um http_request grundsätzlich erstmal zu aktivieren und globale Parameter zu setzen und

  - platform: sml
    name: "Leistung"
    obis_code: "1-0:16.7.0"
    unit_of_measurement: W
    accuracy_decimals: 0
    device_class: power
    state_class: measurement
    on_value:
      then:
        - http_request.send:
            method: POST
            url: http://<warphost>/meters/1/update
            request_headers:
              Content-Type: application/json
            body: !lambda |-
              return "[" + to_string(x) + "]";

und zwar insbesondere der Abschnitt ab "on_value". Dieser bewirkt in diesem Fall, dass - sobald dieser Sensor einen neuen Wert bekommt, der HTTP Request auf die API getriggert wird. Alternativ wäre auch denkbar dies statt an die Wertänderung einfach an einen Timer zu hängen (on_time, interval).

Edit:

Mein Stromzähler ist übrigens ein SGM-DD von EFR, welcher häufig bei uns von der Digimeto verbaut wird. Falls jemand eine exakt passende Basis für den üblichen Selbstbau-Lesekopf benötigt, wird er hier fündig: https://www.printables.com/model/1437844-lesekopf-stromzahler-sgm-dd

Edited July 3, 2026 at 07:26 AMJul 3, 2026 by jansch