Siemens S7 (SIMATIC)¶

Der WattWächter Plus lässt sich über seinen Modbus-TCP-Server direkt an eine SIMATIC S7-1200 oder S7-1500 anbinden. Nötig ist dafür nur die Anweisung MB_CLIENT aus der TIA-Portal-Bibliothek — kein Zusatzmodul, kein CP.

Das Wichtigste zuerst: die Adressumrechnung

MB_CLIENT erwartet am Parameter MB_DATA_ADDR keine Protokolladresse, sondern eine Modicon-Referenz — und rechnet sie vor dem Senden um. Wer die Adressen aus der Register-Map unverändert einträgt, liest eine völlig andere Stelle und bekommt leere Register. Siehe Adressen umrechnen.

Voraussetzungen¶

WattWächter Plus mit Firmware 1.2.0 oder neuer (für Messwerte als Real: 1.2.1 oder neuer)
Modbus TCP am WattWächter aktiviert — Weboberfläche → Einstellungen → Modbus TCP → Modbus-TCP-Server aktivieren → Speichern. Weitere Wege unter Modbus TCP → Aktivieren
S7-1200 oder S7-1500 mit integrierter PROFINET-Schnittstelle im selben Netzwerk
TIA Portal mit der Anweisung MB_CLIENT (Kommunikation → Weitere → MODBUS TCP)
Eine feste IP-Adresse für den WattWächter — per DHCP-Reservierung im Router oder fest am Gerät eingestellt. Wie du die aktuelle IP findest, steht in den FAQs

Der Miniserver-Hinweis gilt auch hier

Die S7 löst keine mDNS-/.local-Namen auf. In die Verbindungsparameter gehört die IP-Adresse, nicht wattwaechter-XXXXXXXXXXXX.local.

Adressen umrechnen¶

Alle Adressen in unserer Dokumentation sind Protokolladressen — die Zahl, die im Modbus-Telegramm steht. MB_DATA_ADDR nimmt stattdessen eine Modicon-Referenz entgegen und zieht davon ab:

Eingabe an `MB_DATA_ADDR`	gesendete Protokolladresse	Function Code bei `MB_MODE = 0`
40001 … 49999	Eingabe − 40001	`0x03` Read Holding Registers
400001 … 465535	Eingabe − 400001	`0x03` Read Holding Registers

Der Bereich 40001–49999 reicht damit nur bis zur Protokolladresse 9998 — für die Register des WattWächters ist er unbrauchbar. Es gilt ausschließlich:

MB_DATA_ADDR = Protokolladresse + 400001

Was	Protokolladresse	`MB_DATA_ADDR`
SunSpec-Kennung `"SunS"`	40000	`440001`
Model 203, Beginn	40070	`440071`
Gesamtwirkleistung `W`	40088	`440089`
Bezug `TotWhImp`	40116	`440117`
Model 213, Gesamtwirkleistung `W`	40205	`440206`

Erst der Selbsttest, dann der Rest

Fang klein an: MB_DATA_ADDR = 440001, MB_DATA_LEN = 2. In den beiden Wörtern müssen 21365 und 28243 stehen — das ist die SunSpec-Kennung "SunS" an Protokolladresse 40000. Kommt die an, stimmt die Adressierung und du kannst auf den vollen Block erweitern. Kommt sie nicht an, liegt es an der Umrechnung und nicht am Gerät.

Schritt 1 — Verbindungsparameter anlegen¶

Leg einen Datenbaustein mit einer Variablen vom Systemdatentyp TCON_IP_v4 an (z.B. DB12, Variable CONNECT). Er beschreibt die TCP-Verbindung zum WattWächter:

Feld	Wert	Bemerkung
`InterfaceId`	Hardware-Kennung der PROFINET-Schnittstelle	Gerätekonfiguration → Eigenschaften → Hardware-Kennung
`ID`	frei wählbar, `1` … `4095`	projektweit eindeutig; mehrere `MB_CLIENT`-Aufrufe mit derselben `ID` teilen sich eine Verbindung
`ConnectionType`	`16#0B`	TCP/IPv4
`ActiveEstablishment`	`TRUE`	die CPU baut die Verbindung auf
`RemoteAddress.ADDR`	IP des WattWächters, z.B. `192.168.178.106`	vier einzelne Bytes
`RemotePort`	`502`	oder der abweichende Port aus den Geräteeinstellungen
`LocalPort`	`0`	von der CPU vergeben

Schritt 2 — Datenbaustein für die Register anlegen¶

Leg einen zweiten Datenbaustein für die gelesenen Register an, z.B. DB11 mit einer Variablen Daten vom Typ Array[0..106] of Int — 107 Register entsprechen genau dem Model-203-Block.

Optimierten Bausteinzugriff ausschalten

MB_DATA_PTR braucht einen ANY-/Zeigerausdruck wie P#DB11.DBX0.0. Der lässt sich nur auf einen Datenbaustein ohne optimierten Bausteinzugriff bilden.

Rechtsklick auf den DB → Eigenschaften → Attribute → Haken bei Optimierter Bausteinzugriff entfernen. Danach zeigt die Bausteinansicht eine Spalte Offset mit 0.0, 2.0, 4.0 … — daran erkennst du, dass es gepasst hat.

Schritt 3 — MB_CLIENT aufrufen¶

Ruf MB_CLIENT im zyklischen Programm auf (z.B. in OB1) und parametriere ihn so:

Parameter	Wert	Bedeutung
`REQ`	Taktmerker oder eigene Zeitsteuerung	startet einen Auftrag; flankengesteuert
`DISCONNECT`	`FALSE`	Verbindung aufbauen und halten
`MB_MODE`	`0`	Lesen
`MB_DATA_ADDR`	`440071`	Protokolladresse 40070 — siehe Adressen umrechnen
`MB_DATA_LEN`	`107`	Anzahl Register, höchstens 125
`MB_DATA_PTR`	`P#DB11.DBX0.0`	Zielbereich aus Schritt 2
`CONNECT`	`P#DB12.DBX0.0`	Verbindungsparameter aus Schritt 1

Ausgänge: DONE, BUSY, ERROR, STATUS.

EN dauerhaft freigeben, REQ takten

MB_CLIENT muss in jedem Zyklus bearbeitet werden, bis DONE oder ERROR ansteht. Gestartet wird ein Auftrag über REQ, nicht über EN. Fällt der Freigabeeingang zwischendurch ab, bleibt BUSY stehen, DONE kommt nie, und der Datenbaustein bleibt leer.

Ein Abfragezyklus von 5 s für Leistungswerte und 30 s für Zählerstände ist ein guter Ausgangspunkt — dieselben Zyklen verwenden auch die Loxone-Vorlagen.

Schritt 4 — Werte aus dem Block herausziehen¶

Liest du 107 Register ab MB_DATA_ADDR = 440071, landet Protokolladresse 40070 in Daten[0]. Der Index eines Registers ist also Protokolladresse − 40070:

Wert	Protokolladresse	Index in `DB11.Daten`	Typ	Skalierungsfaktor
Gesamtwirkleistung `W`	40088	`[18]`	Int	`[22]` (`W_SF`)
Leistung L1 / L2 / L3	40089–40091	`[19]` / `[20]` / `[21]`	Int	`[22]` (`W_SF`)
Summenstrom `A`	40072	`[2]`	Int	`[6]` (`A_SF`)
Strom L1 / L2 / L3	40073–40075	`[3]` / `[4]` / `[5]`	Int	`[6]` (`A_SF`)
Spannung LN (Mittelwert)	40077	`[7]`	Int	`[15]` (`V_SF`)
Spannung L1 / L2 / L3	40078–40080	`[8]` / `[9]` / `[10]`	Int	`[15]` (`V_SF`)
Netzfrequenz `Hz`	40086	`[16]`	Int	`[17]` (`Hz_SF`)
Einspeisung `TotWhExp`	40108–40109	`[38]` + `[39]`	2 × Int	`[54]` (`TotWh_SF`)
Bezug `TotWhImp`	40116–40117	`[46]` + `[47]`	2 × Int	`[54]` (`TotWh_SF`)

Skalierung. Model 203 überträgt Ganzzahlen; der echte Wert ist Rohwert × 10^SF. Die Faktoren liegen im selben Block und werden mitgelesen — nimm sie aus dem Register, statt sie fest einzutragen. Dann bleibt das Programm auch nach einem Firmware-Update korrekt. Mit W_SF = 1 bedeutet ein Rohwert von 217 also 2170 W.

32-Bit-Werte. Die Energiezähler belegen zwei Register, Highword zuerst. In SCL:

"DB11".Bezug_Wh := UINT_TO_UDINT("DB11".Daten[46]) * 65536
                 + UINT_TO_UDINT("DB11".Daten[47]);

Nicht gelieferte Werte. Steht in einem Register -32768 (0x8000), liefert dein Stromzähler diesen Wert nicht — das ist der SunSpec-Sentinel für not implemented. Welche Register aktuell gültig sind, zeigt der Status-Endpunkt.

Messwerte als Real (ab Firmware 1.2.1)¶

Ab Firmware 1.2.1 liefert der WattWächter dieselben Messwerte zusätzlich als float32 in Model 213 — ohne Skalierungsfaktoren. Für die S7 ist das der Datentyp Real, und zwar ohne Umsortieren: Modbus überträgt Highword zuerst, genau so legt die S7 einen Real ab.

Wert	Protokolladresse	`MB_DATA_ADDR`	`MB_DATA_LEN`
Gesamtwirkleistung `W`	40205	`440206`	`2`
Leistung L1 / L2 / L3	40207 / 40209 / 40211	`440208` / `440210` / `440212`	je `2`
Einspeisung `TotWhExp`	40237	`440238`	`2`
Bezug `TotWhImp`	40245	`440246`	`2`

Als Zielbereich genügt ein DB mit Array[0..n] of Real — die gelesenen Register stehen dann direkt als Gleitkommawert bereit, ohne SF-Register und ohne Zehnerpotenz.

Model 213 passt nicht in einen Auftrag

Der Block umfasst 126 Register, Modbus erlaubt aber höchstens 125 je Leseauftrag. Lies deshalb gezielt die Werte, die du brauchst (je 2 Register), statt den Block am Stück zu holen.

Nicht gelieferte Werte sind NaN

Felder, die dein Zähler nicht sendet, enthalten NaN statt einer Zahl. Ein Real mit NaN führt in Rechenoperationen zu ENO = FALSE. Ausgenommen sind W, TotWhExp und TotWhImp — die stehen von Anfang an auf 0.

Fehlerbehebung¶

Die Register bleiben alle auf 0

Mit Abstand häufigste Ursache: die Adressumrechnung. Steht an MB_DATA_ADDR z.B. 40071 statt 440071, sendet die S7 die Protokolladresse 70 — dort liegt beim WattWächter nichts, und das Gerät antwortet mit der Modbus-Ausnahme 02.

Mach den Selbsttest mit 440001 und Länge 2. Und lass dir ERROR und STATUS in einer Beobachtungstabelle speichern — beide stehen nur einen Zyklus lang an und sind sonst nie zu sehen. Ein STATUS beginnend mit 16#838 bedeutet, dass der WattWächter die Anfrage mit einer Modbus-Ausnahme beantwortet hat.

BUSY bleibt stehen, DONE kommt nie

Wird MB_CLIENT wirklich in jedem Zyklus bearbeitet? Ein abfallender Freigabeeingang lässt den Auftrag hängen. REQ ist das Startsignal, EN muss durchgängig anstehen.

Werte wie 16#7001 … 16#7006 an STATUS sind dabei kein Fehler, sondern Zwischenzustände während der Bearbeitung.

MB_DATA_PTR lässt sich nicht eintragen

Der Zielbaustein hat noch optimierten Bausteinzugriff. Haken in den Baustein-Eigenschaften entfernen — siehe Schritt 2.

Verbindung kommt nicht zustande

Ist Modbus am WattWächter aktiviert? Prüfe /api/v1/modbus/status → enabled: true, running: true.
Steht in RemoteAddress eine IP-Adresse und kein .local-Name?
Stimmt RemotePort (Standard 502) und ist ActiveEstablishment = TRUE?
Der WattWächter erlaubt höchstens 2 gleichzeitige Modbus-Verbindungen. Läuft parallel noch ein Test mit modpoll, Home Assistant oder Loxone, trenn den zuerst.
Ist die ID in TCON_IP_v4 projektweit eindeutig?

Werte sind um Faktor 10 daneben

Der Skalierungsfaktor von Model 203 fehlt oder ist fest eingetragen. W_SF hat sich mit Firmware 1.2.0 von 0 auf 1 geändert. Lies den Faktor aus dem SF-Register mit, statt ihn im Programm zu hinterlegen — oder wechsle auf Model 213, das ganz ohne Faktoren auskommt.

Weitere Punkte in der Modbus-TCP-Fehlerbehebung.