Kostal Smart Energy Meter über Modbus TCP

Einleitung

Trotz langjähriger Erfahrung mit dem Loxone Miniserver selbst, gab es bei meinem ersten Projekt in Zusammenhang mit Modbus TCP einige Hürden zu nehmen. Rückblickend betrachtet, sind diese Hürden mit  einem gewissen Grundverständnis zu Modbus TCP und dem Verständnis der herstellerspezifischen Benennung der Parameter sehr einfach zu überwinden.

Nachfolgend habe ich das Vorgehen beschrieben, wie ein Kostal Smart Energy Meter, auch KSEM benannt, vom Miniserver über Modbus TCP ausgelesen werden kann. Ergänzend fügte ich etwas Theorie und ein paar Anmerkungen ein, welche dem Verständnis dienen.

Hinweis: Loxone stell in der Loxone Config unter Sensoren und Aktoren > vordefinierte Geräte die Konfiguration Kostal Modbus-TCP and Battery zur Verfügung. Diese funktioniert nicht mit dem Kostal Smart Energy Meter zusammen.


Master / Slave vs. Client / Server

Das Modbus Kommunikationsprinzip basiert darauf, dass ein Gerät die Kommunikation zu einem anderen Gerät initiiert. Das initiierende Gerät wird als Modbus Client oder Master bezeichnet.

Das angesprochene Gerät liefert dann eine entsprechende Antwort an den Initiator. Das antwortende Gerät wird als Server oder Slave bezeichnet.

Typischerweise enthält die Antwort des Servers die vom Client angeforderten Daten. Im Fehlerfall kann aber auch eine Error-Nachricht an den Client retourniert werden.


Daraus ergibt sich die folgende Client-Server Konfiguration:

Hinweis: Die IP-Adressen sind exemplarisch und an das eigene Netz anzupassen.


Konfiguration KSEM

Damit das KSEM als Modbus Server (Slave) funktioniert, wird im Menü des Kostal Smart Energy Meters unter Modbus-Einstellungen > Slave der Schalter Aktiviere TCP-Slave aktiviert.



Grundkonfiguration Loxone Modbus TCP

1. In der Loxone Config wird unter Miniserverkommunikation ein Modbusserver einfügen. 

Hinweis: Im ersten Moment kann es irritierend sein, dass man einen Modbusserver einfügt, da es sich effektiv um eine Modbus Clientkonfiguration handelt. Wird der einzufügende Modbusserver aber als Zielobjekt für die Miniserverkommunikation betrachtet, macht die Benennung wieder Sinn.


2. Dem Element Modbusserver die Server IP Adresse des KSEM eingetragen. Wichtig: Am Ende der IP-Adresse muss der Port 502 mitgegeben werden, da der Server Modbus Requests nur auf Port 502 empfängt.

Hinweis: Der Loxone Knowledebase-Artikel Kommunikation mit Modbus TCP kann zusätzlich zur Verwirrung beitragen, da dort explizit von einer Client IP-Adresse gesprochen wird, was wohl ein Fehler ist:


3. Nun wird dem Modbusserver ein Modbusgerät hinzugefügt. Diesem muss man die Modbus-Adresse des Modbus Servers (des KSEM) zuweisen. Im Fall des Kostal Smart Energy Meters ist dies die 1.


Hinweis: Die Modbus-Adresse kann je nach Hersteller im Modbus Server selbst definiert werden. Sofern diese nicht zutrifft, wird sie vom Hersteller des Server Gerätes bekanntgegeben. Viele Hersteller verwenden jedoch per Standard die Adresse 1 für Ihre Geräte. Im KSEM (FW-Release 1.2.1) kann die Modbus-Adresse nicht verändert werden.


Sensoren und Datenabfrage

1. Für die Abfrage der Daten aus dem KSEM werden dem Modbusgerät nun Sensoren hinzugefügt.

Hinweis: Da es sich bei den abzufragenden Werten meist um 2 Byte (16 Bit) oder 4 Byte (32Bit) Informationen handelt, werden dafür Analogsensoren verwendet. Für jede abzufragende Informationart wird ein zusätzlicher Sensor eingefügt (z.B. Sensor 1 = Total Wirkleistung aller Phasen, Sensor 2 = Total vom EW bezogene Wirkleistung).


2. Für die Abfrage der Informationen aus dem Server sind die oben gelb markierten Einstellungen entscheidend. Die dafür notwendigen Informationen sind der Hersteller-Dokumentation des Modbus-Gerätes zu entnehmen. Für das Kostal Smart Energy Meter (KSEM) sind sie hier zu finden.

Kostal beschreibt in seinem Interface Manual verschiedene Register, welche mittels den beschriebenen Parametern abgefragt werden können. Für meine Bedürfnisse habe ich mich auf die SunSpec Register bezogen. Mit diese klappt die Anbindung recht einfach. 


Beispiel aus dem SunSpec Register

Die nachfolgende Tabelle entstammt auszugsweise der Kostal KSEM Dokumentation. Sie zeigt drei Beispiele, welche mit drei Sensoren abgefragt werden können.

  • Die erste Zeile liefert die aktuelle Wirkleistung aller Phasen.
  • Die mittlere Zeile liefert den Skalierungsfaktor* für den Wert der ersten Zeile.
  • Die letzte Zeile liefert die Totale Menge der Wirkenergie, welche vom Elektrizitätswert (EW) bezogen wurde.


Start
adress
(dec)

End
adress
(dec)
SizeR/WFunc-
tion
codes
NameTypeUnitsScale factorDescriptionValue range /
OBIS mapping
40087400871RO0x03

M_AC_Power

int16WM_AC_
Power_SF

Total Real Power
(sum of active phases)

>0: 1-0:1.4.0*255;
<0: 1-0:2.4.0*255

40091400911RO0x03M_AC_
Power_SF
int16n/an/a

AC Real Power
Scale Factor *

1
40115401162RO0x03M_Importeduint32WhM_Ener-
gy_W_SF
Total Imported Real
Energy
1-0:1.8.0*255

* Wichtiger Hinweis zum Skalierungsfaktor aus der KSEM Dokumentation: Obwohl die Skalierungsfaktoren hier als feste Werte angegeben sind, sollten sie nicht als fest betrachtet werden. Die Werte können sich dynamisch ändern, um zu den Messwerten zu passen. Bitte fragen Sie die Skalierungsfaktoren immer zusammen mit den dazugehörigen Werten ab und nehmen Sie Code mit auf, um die Werte dynamisch zu berechnen.


Mapping der SunSpec Register Werte zu den Loxone Sensor Attributen

Die Werte aus der jeweiligen Zeile von der Tabelle oben können nun in den Loxone Einstellungen des jeweiligen Sensors übernommen werden. Hier ein Beispiel für die letzte Zeile der Tabelle oben:

Loxone Sensor Eigenschaften
SunSpec WertBemerkungen und falls nicht identisch mit dem SunSpec Wert, der "übersetzte Wert"
für die entsprechenden Loxone Eigenschaften
Bezeichnung<-Total Imported Real
Energy
Beschreibt die Information, welche vom Server bezogen werden soll
IO-Adresse<-40115Beschreibt die Start Adresse des abzufragenden Server Registers
Befehl<-n/aDer Wert für Abfragen aus dem SunSpec Register ist immer 3 - Holding Register(4x). Ob der Befehl mit dem jeweiligen Function Code korreliert kann ich nicht bestätigen.
Datentyp<-uint32

Loxone schreibt den Wert so: 32-bit unsigned integer
Das u
vor int steht für unsigned. Wenn das u vor int fehlt, bedeutet dies, das der Integer-Wert signed ist.

Signed Integer sind um ein Bit gekürzte Werte, da dieses eine Bit für das Vorzeichen der verbleibenden Bits verwendet wird. Signed Integer könne also + oder - Werte bereitstellen. Im Vergleich zu unsigned Integer können dafür aber nur halb so hohe Maximal-Werte bereitgestellt werden.

2 Register für 32-bit<-2Hier bin ich nicht ganz sicher, was die Hintergründe sind. In der Praxis funktioniert es wie folgt:
Ist der Type uint32, dann ist in der SunSpec Tabelle die Size immer als 2 angegeben. Die Checkbox ist dann in der Loxone Konfig zu setzen, also True.
Registerreihenfolge<-n/a

Muss nur bei Type uint32 berücksichtigt werden. Wenn der Type uint32 ist, dann muss die
Checkbox gesetzt werden, also True.

Auszug KESM Dokumentation: "Im Falle von einem Multi-Register Datenpunkt beinhalten die Register mit der niedrigeren Adresse die „Mostsignificant“ Bits. Die „Least-siginificant“ Bits sind in den Registern mit der höheren Adresse enthalten."

Byte-Reihenfolge<-n/aDie Checkbox darf nicht gesetzt werden (also False), da KSEM "BigEndian" verwendet.
Auszug KESM Dokumentation: "Während der Anfrage werden beide Register in der Netzwerk-Byte-Reihenfolge (Big Endian) wie von Modbus Spezifikation vorgegeben übertragen."


Die Eigenschaften und Werte dazu sehen so aus:


Die Konfig mit dem Energiemonitor sieht wie folgt aus. Den Formelbausteinen sind die Skalierungsfaktoren hinterlegt (siehe AI zu AQ).

Hinweis: Die KSEM SunSpec Register sind gemäss SunSpec Alliance standardisiert.