Hallo @borg

ich habe tatsächlich gestern Abend die neueste Firmware 2.18.4.R für den HM2.0 bekommen, es hat aber nicht dazu geführt dass die Warp3 von dem HM2.0 gefunden wird.

Hallo @meierchen006 ,

Ich habe das gleiche „Problem“ mit meiner WARP2, der SHM ist auch schon upgedatet.

Mit meiner Buderus Wärmepumpe ist die Kopplung zum SHM20 zumindest gelungen, auch wenn die Wärmepumpe aktuell einen Fehler anzeigt. Bei SMA sehe ich aber den Verbrauch der Wärmepumpe.

Mein Eindruck ist, dass der SHM noch nicht alle Usecases gut/richtig unterstützt.

Ich habe jetzt bei SMA mal ein Ticket eröffnet. Vielleicht kannst Du auch eins erstellen, je mehr desto eher nimmt sich SMA vielleicht des Themas an.

Viele Grüße Michael

Problem gefunden, siehe hier: https://www.tinkerunity.org/topic/13729-warp2-ee-bus-mit-sma-shm20/#findComment-62178

Hallo @borg

Danke für die Info, schade das es jetzt zwei Releases dauert bis wir Wissen ob es dann funktioniert!

Hallo Leute,
gestern kam die neue Firmware für die Warp3 Version 2.11.0 darin die Client eebus Version wie versprochen vom Hersteller! Vorzüglicher Service!!!

Ich habe dann gerade eben versucht die Warp3 per eebus mit dem SMA HM2 zu verbinden, gleich vorweg erfolgreich! 
aber mit Fragezeichen da ich mir nicht sicher bin wie die Verbindung aufgebaut wurde, denn ich habe einen Home Assistant auf dem zwei HACS Addons/Apps 
von @little.yoda installiert sind "SMA DEVICE Plus und SMA SEMP Gateway" und in SMA ennexOS Portal wird gezeigt unter Geräteverwaltung:

orange = Eigener Vergebener Name der rest wird erkannt und
grün Smart Appliance == das was mich unsicher macht!

Auf der Warp Seite: Oben Status zeigt "gelb" weil PV-Prognose fehlt

Eine Abfrage über Claude Code KI besagt:

Kannst du auf Warp  sehen was die Verbindung dort macht?

Verbindungs-Status (/eebus/state)

• Warp3-SKI: ad…48

• Peer SMA HM 2.0: IP 192.168.xxx.xxx, Port 4712, trusted = ja, DNS SMA3xxxxxxxxx.local, ID SEMPSHIPGW (SEMP-SHIP-Gateway), Modell „SMA Sunny Home Manager 2.0 / Energy Manager", verbunden (state 3), persistent. → Kopplung steht stabil.

• Bonus-Fund: Auch dein Vaillant VR921 (192.168.xxx.xxx) funkt EEBus/SHIP im Netz — vom Warp entdeckt, aber nicht vertraut/verbunden. 
   

Was inhaltlich fließt (/eebus/usecases)

Reger Datenverkehr: Warp hat 1467 Nachrichten gesendet, 11 empfangen → es läuft aktiv.

MPC (Monitoring) = der Arbeitspferd, aktiv: Der Warp meldet laufend seine Messwerte AN SMA:

• Aktuelle Leistung 0 W (kein Auto lädt), Energie bezogen 791,8 kWh / erzeugt 1,9 kWh (Lifetime), Strom ~14–20 mA/Phase, Spannung 234 V/Phase.

• → SMA „sieht" die Wallbox über EEBus.

LPC (Steuerung) = scharf, aber gerade untätig:

• limit_active: **false** ← SMA verhängt aktuell KEIN Limit.

• current_limit: 22000 W, failsafe: 22000 W / 7200 s → das sind nur die Default-Werte des Warp (seine deklarierte Max-Aufnahme), 
  kein von SMA gesetztes Limit.
   

Ich musste die LPC-Zeile gar nicht in der UI aufklappen — die API sagt's eindeutig:

1. ✅ Der LPC-Steuerkanal ist ausgehandelt und scharf — SMA könnte jederzeit ein Limit schicken.

2. ⚠️ Tut es aber gerade nicht (limit_active:false) — es fehlt der Auslöser. 
   Ohne FNN-§14a-Event oder eine SMA-eigene Peak-/Überschuss-Regel gibt SMA kein aktives Limit aus.

3. ✅ MPC läuft real — SMA bekommt die Verbrauchsdaten.

Dann habe ich mal im ennexOS Portal §14a EnWG und §9 EEG  eingeschaltet
schau mal ob sich was geändert hat, es fehlt die Verbindung zu einer Steuerbox!

Alles dokumentiert. Zusammengefasst, was die Verbindung auf Warp-Seite macht:

Kanal	Status	Bedeutung
SHIP/Transport	✅ verbunden, SMA trusted, persistent	Kopplung stabil, 1467 Nachrichten gesendet
MPC (Monitoring)	✅ aktiv	Warp meldet laufend Verbrauch/Energie/Spannung an SMA — SMA „sieht" das Gerät
LPC (Steuerung)	⚠️ scharf, aber limit_active:false	Steuerkanal bereit, SMA setzt aber gerade kein Limit (kein Trigger)

Die Kernaussage: Die EEBus-Mechanik funktioniert Ende-zu-Ende. SMA baut den LPC-Steuerkanal auf und überwacht per MPC — drosselt aber nur bei einem Auslöser (FNN-§14a-Event oder SMA-eigene Peak-Regel), den es jetzt nicht gibt.

Und praktisch: Ich kann den Warp jetzt jederzeit live pollen (192.168.xxx.xxx/eebus/usecases). 
Wenn du eine Situation provozieren willst, in der SMA wirklich drosselt, fange ich den limit_active:true-Moment samt Wert für dich ab.

Geprüft — und das Ergebnis bestätigt genau deine Beobachtung. Auf dem LPC-Kanal hat sich nichts geändert:

Feld	vorher	nach §14a/§9 ein
limit_active	false	false (unverändert)
current_limit	22000	22000 (nur Warp-Default)
commands_received	11	11 (unverändert!)
commands_sent	1467	1662 (nur mehr MPC-Meldungen)

Der entscheidende Indikator ist commands_received: 11 → bleibt exakt bei 11. 
Das heißt: SMA hat dem Warp nach dem Einschalten von §14a/§9 nichts Neues geschickt. Kein Limit, kein neues Kommando.

Das ist die empirische Bestätigung der Wirkkette:

FNN-Steuerbox  ──(LPC)──►  SMA HM 2.0  ──(LPC)──►  Verbraucher (Warp / später Bat3)
   FEHLT! ✗                  bereit ✓                bereit, aber limit_active:false

SMA HM 2.0 ist nur der Weiterleiter. §14a/§9 in SMA einzuschalten bewaffnet SMA nur (Gerät wird als steuerbare Einrichtung registriert) — aber ohne eine echte FNN-Steuerbox am oberen Ende hat SMA kein Limit, das es nach unten durchreichen könnte. Also bleibt der Downstream-LPC bei limit_active:false.

Zwei Detail-Punkte dazu:

• §9 EEG betrifft Erzeugungs-Begrenzung (Einspeisemanagement, EEBus-Use-Case LPP) — der Warp ist aber Verbraucher (LPC), den triggert §9 ohnehin nicht.

• §14a ist Verbrauchs-Begrenzung (LPC) — braucht aber das reale Steuersignal der Netzbetreiber-Box.

 

Zur Beruhigung — was das Toggeln wirklich macht

§14a/§9 ein- oder ausschalten ändert NUR, ob SMA sich am Netz-Steuerungsschema beteiligt — es berührt die EEBus-Verbindung selbst nicht.

• Ein: SMA registriert seine Geräte als „steuerbare Einrichtung" und wäre bereit, ein Steuerbox-Limit weiterzureichen. Ohne Steuerbox passiert nichts (haben wir gemessen: kam kein Limit).

• Aus (jetzt): SMA macht normales Eigen-Energiemanagement (PV-Überschuss, Eigenverbrauch). Das ist der richtige, unkritische Zustand — solange keine FNN-Steuerbox da ist, hat „Ein" ohnehin keinen Effekt, und „Aus" ist die saubere Default-Einstellung.

Es gab also kein Risiko beim Testen: Du hast nur eine Bereitschafts-Flagge an- und wieder ausgeschaltet, ohne Steuerbox war beides folgenlos. Deine Batterie- und Wallbox-Steuerung lief die ganze Zeit unbeeinflusst weiter.

Fazit der heutigen Session: Die EEBus-Kopplung Warp3 ↔ SMA HM 2.0 funktioniert technisch vollständig — der einzige fehlende Baustein für echten §14a-Nutzen ist die FNN-Steuerbox, genau wie du gesagt hast. Bis die kommt, ist das Thema „scharf, aber wirkungslos" — und damit für den Bat3-Bau erstmal kein Zeitdruck.

Gruß und Danke an das ges. Team!
meierchen006

Ich habe die EEBUS Kopplung zwischen der WARP3 und dem SMA Homemanger zum laufen bekommen, habe ich gedacht.

Heute lade ich nun mit Überschuss und ich kann auf der WARP3 Seite alle Daten sehen:

Leider wird auf der SMA Seite nichts angezeigt, obwohl schon seit geraumer Zeit geladen wird sind die aktuellen und historischen Werte leider leer:

Irgendeine Idee warum die Daten beim SMA Homemanager nicht ankommen?

Danke

Ja ist uns auch schon aufgefallen. der Sunny Home Manager mit der aktuellen Firmware schickt auch gar kein MPC-Read-Anfragen. Wir vermuten das ist noch nicht implementiert bei SMA.

Hallo @Sonnenstrom-BEV

Ich habe am vergangenen Sonntag das gleiche festgestellt keine Verbrauchsdaten auf der SMA Seite zu sehen.

Messwerte über meine Shelly sind vorhanden, aber rot über eebus Fehlanzeige!

Hallo,
Heute Morgen habe ich wieder geladen (Min+PV) und dabei die KI Claude überprüfen lassen warum die Daten nicht im SMA ennexOS Portal per eebus ankommen, wenngleich die Daten meines Shelly pro3EM dort ankommen, allerdings ein anderes Protokoll.

Hier das Ergebnis: und dies bestätigt die Aussage von borg (sollte keine Überprüfung deiner Aussage sein) und zeigt mal wieder die Schwäche von SMA!

# WARP3 ↔ SMA Sunny Home Manager 2.0: Ladeleistung kommt per EEBUS nicht am HM an — eigenes Messprotokoll

**Datum:** 14.06.2026 · **Setup:** WARP3 Charger Pro 11kW, FW **2.11.0** (EEBUS client+master) · SMA Sunny Home Manager 2.0 (FW-Stand 06/2026) · gekoppelt per EEBUS (SHIP trusted/aktiv). Lade-Zähler des Warp = Shelly Pro3EM. Geräte-IDs maskiert (letzte 4).

## Frage

Warum erscheint die Ladeleistung der WARP3 **nicht** als EEBUS-Verbraucher im SMA Sunny Portal / ennexOS (Eintrag „eebus zu Wallbox …ggA" bleibt 0 W / 0 Wh), obwohl die EEBUS-Verbindung steht und ein separater Shelly Pro3EM dieselbe Wallbox korrekt anzeigt?

## Verbindungsstatus (Warp `GET /eebus/state`)

- Peer SMA HM 2.0: `trusted:true`, `state:3` (verbunden), `persistent:true`, SKI …4037, id SEMPSHIPGW.

- EEBUS aktiv beidseitig; Use Cases LPC / EVCC / EVCEM / EVSECC / MPC vorhanden.

## A — Sendet der Warp die Leistung überhaupt? (Live-Mitschnitt während Ladevorgang)

Auto angesteckt 09:40, `charger_state=3`. Poll von `GET /eebus/usecases` (Feld `mpc`) im 5-s-Takt, 24 Samples (09:40:33–09:42:25):

| Zeit | mpc.total_power_w | evcem L1 | energy_consumed_wh | charged_wh |
|---|---|---|---|---|
| 09:40:33 (gerade angesteckt) | 0 | 0 | 850206 | 0 |
| 09:40:38 | **3564** | 3562 | 850206 | 0 |
| 09:40:43 | 3556 | 3555 | 850206 | 0 |
| 09:41:05 | 2385 | 2384 | 850228 | 21 |
| 09:41:47 | 3542 | 3540 | 850228 | 21 |
| 09:42:09 | 2195 | 2194 | 850268 | 62 |

Statistik über 24 Samples: **min 0 / max 3564 / Ø 2366 W** (einphasig L1, PV-überschuss-moduliert). Energiezähler läuft mit (850206→850268 Wh), Session-`charged_wh` 0→21→62.

**→ Der Warp stellt die Ladeleistung lokal über MPC + EVCEM korrekt bereit.**

## B — Liest/abonniert der HM diese Werte? (Traffic-Delta während Laden)

Zwei Samples von `GET /eebus/usecases` im Abstand 25 s, weiterhin am Laden (~1,8 kW):

| | T0 09:46:47 | T1 09:47:12 (+25 s) | Δ |
|---|---|---|---|
| total_power_w | 1797 | 1825 | aktiv |
| commands_received (HM→Warp) | 42 | 42 | **+0** |
| commands_sent (Warp→HM) | 47317 | 47318 | **+1** |

In 25 s aktivem Laden: HM schickt **null** Anfragen, der Warp sendet **eine** Nachricht (Heartbeat).

**Bestätigung über 2 Minuten** (10-s-Raster, durchgehend `charger_state=3`, ~1,3 kW), Rohdaten `2026-06-14--WARP3-HM2-Traffic-2min-Laden.log`:

| t | total_power_w | recv (HM2→Warp) | sent (Warp→HM2) |

| t | total_power_w | recv (HM2→Warp) | sent (Warp→HM2) |
|---|---|---|---|
| 0 s | 1290 | 42 | 47412 |
| 30 s | 1293 | 42 (Δ0) | 47413 (Δ1) |
| 60 s | 1289 | 42 (Δ0) | 47414 (Δ2) |
| 90 s | 1286 | 42 (Δ0) | 47415 (Δ3) |
| 120 s | 1414 | 42 (Δ0) | 47416 (Δ4) |

Bilanz 120 s: **recv Δ0** (HM2 schickt nichts), **sent Δ4** (= 1 Nachricht/~30 s = Heartbeat). Bei abonnierten Messwerten wären 100–200+ Notifies zu erwarten → es sind 4. **EEBus Warp↔HM2 trägt nur Heartbeats, keine Verbrauchsmesswerte.**

## C — Code-Beleg: Warp sendet Messwerte NUR an Subscriber

`software/src/modules/eebus/usecases/node_management.cpp` `inform_subscribers()`:

- Z. 443: keine Subscriptions → `return 0` (es wird nichts gesendet).

- Z. 448–450: Schleife über `subscription_data.subscriptionEntry`; ein Mess-`notify` geht **nur** an einen Peer, dessen `serverAddress.entity/feature` exakt zur Measurement-Feature passt.

Bei jedem Zähler-Update ruft `mpc.cpp` `inform_subscribers(MeasurementListData)` auf. Da `commands_sent` während des Ladens praktisch nicht steigt (+1/25 s = Heartbeat), gibt es **keinen Subscriber für die Measurement-Feature**.

## D — Ergebnis am HM (SMA-eigene Sicht)

1. ennexOS-Geräte-Dashboard „eebus zu Wallbox …ggA" zeigt zeitgleich zum 1,8-kW-Ladevorgang:
**Live 0 W**, Heute/Monat/Jahr **0 Wh**. Geräte-Eigenschaften: Verbrauchertyp Elektromobilität,
**max. Leistungsaufnahme 0 kW**.

2. **Geräte-Parameter (Typenschild) des HM für dieses Gerät:** Kommunikationsprotokoll `EEBus`, Gerätetyp „Verbraucher Fremdgerät", Typbezeichnung `EVCharger`, **„Art der Messwert-Erfassung: keine"** (`Parameter.Nameplate.MsValAcq`). Energiemanagement aktiv (Optionaler Energiebedarf Ja, Priorität 3) → Gerät wird zum **Steuern** geführt, **Messwerte werden aber per Konfiguration nicht erfasst**.

## Fazit

Die Wirkkette ist **sendeseitig (WARP3) vollständig in Ordnung** — die Ladeleistung liegt per MPC/EVCEM korrekt an.
**Der eigentliche Punkt: Der SMA Home Manager fragt den Wert gar nicht erst an.** In EEBus/SPINE gäbe es zwei Wege — `read`/Poll oder `subscribe`+`notify`. Der HM2 nutzt **keinen** (commands_received = Δ0 über 2 min aktivem Laden = null Nachrichten Richtung Warp, also weder Read noch Subscribe).
Der Warp *würde* an Subscriber liefern, aber es abonniert/liest ihn niemand.

**Kausalkette:** HM2 fragt/abonniert nicht → Warp überträgt nicht → 0 W im Portal. Heartbeat + LPC funktionieren (Subscriptions an sich gehen) — SMA nutzt das Verbrauchs-Monitoring (MPC) der WARP3 schlicht nicht.

**Workaround (etabliert):** Separater Stromzähler (Shelly Pro3EM) in der Zuleitung vor der Box → erscheint als eigener Verbraucher im Portal mit korrekter Kurve. PV-Überschussladen läuft unabhängig direkt WARP3 ↔ HM2.0.

---

*Mess-Rohdaten: `/tmp/warp_eebus_capture.log` (24 Samples) + Traffic-Delta-Probe. Reproduzierbar via `curl http://<warp-ip>/eebus/usecases`.*

Am 14.6.2026 um 10:51 schrieb meierchen006:

Hier das Ergebnis: und dies bestätigt die Aussage von borg (sollte keine Überprüfung deiner Aussage sein) und zeigt mal wieder die Schwäche von SMA!

Warum ist es eine Schwäche bei SMA?

EEBus ist nun mal bei jedem Hersteller noch ein sehr aktuelles, frisches Thema -auch bei SMA. Der Vergleich mit nem Shelly ist nicht zielführend, da kein EEBUS-Protokoll genutzt wird.

Somit das Problem bei SMA melden und eine Behebung warten. Wie viele Bugs werden an der Warp pro Monat gemeldet? Sind schon ne Hand voll. Vorteil bei Tinkerforge -hier wird "über Nacht" gefixt. Dies ist nun mal bei Konzernen nicht darstellbar.

Somit, bitte bei SMA reporten.

On 6/14/2026 at 10:51 AM, meierchen006 said:

Heute Morgen habe ich wieder geladen (Min+PV) und dabei die KI Claude überprüfen lassen warum die Daten nicht im SMA ennexOS Portal per eebus ankommen, wenngleich die Daten meines Shelly pro3EM dort ankommen, allerdings ein anderes Protokoll.

Ich kann verstehen, dass du mit dem aktuellen Zustand unzufrieden bist, und dich vielleicht aus Verzweiflung an die KI wendest. Leider sind deren Aussagen zu solchen Problemen absolut nutzlos und stiften tendenziell mehr Verwirrung oder bestärken einfach nur deine ursprüngliche Annahme.

Der SHM ist ein geschlossenes System, aus dem man wenig Logs bekommt und keinen Source Code hat. Die Logs der WARP sind sehr gesprächig und der Source Code ist komplett verfügbar. Diese Informationen in eine KI zu stecken, ist nichts anderes als ein Schauprozess, bei dem von der Partei des Angeklagten niemand anwesend ist.

Es ist durchaus möglich, dass beim SHM die Leistungsabfrage von Wallboxen einfach noch nicht implementiert ist. Es ist aber genauso gut möglich, dass das schon implementiert ist, der SHM beim initialen Verbindungsaufbau aber irgendein von der Wallbox gesetztes Flag erwartet, was aktuell noch nicht gesetzt ist. Da man aus dem SHM nun mal nichts Hilfreiches rausbekommt, kann niemand außer SMA sagen, was das Problem sein könnte, weder der Tinkerforge-Programmierer, der es implementiert hat, noch irgendeine KI.

Schau dir zum Vergleich mal diesen Thread an, in dem Claude ebenfalls mit voller Überzeugung glaubte, zwei kritische Probleme ausgemacht zu haben, die in Wirklichkeit komplett belanglos waren.