Kostal Smart Energy Meter über Modbus TCP
- Roger M.
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 | End | Size | R/W | Func- | Name | Type | Units | Scale factor | Description | Value range / |
|---|---|---|---|---|---|---|---|---|---|---|
40087 | 40087 | 1 | RO | 0x03 | M_AC_Power | int16 | W | M_AC_ | Total Real Power | >0: 1-0:1.4.0*255; |
40091 | 40091 | 1 | RO | 0x03 | M_AC_ | int16 | n/a | n/a | AC Real Power | 1 |
40115 | 40116 | 2 | RO | 0x03 | M_Imported | uint32 | Wh | M_Ener- | Total Imported Real | 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 Wert | Bemerkungen und falls nicht identisch mit dem SunSpec Wert, der "übersetzte Wert" | |
|---|---|---|---|
Bezeichnung | <- | Total Imported Real | Beschreibt die Information, welche vom Server bezogen werden soll |
IO-Adresse | <- | 40115 | Beschreibt die Start Adresse des abzufragenden Server Registers |
Befehl | <- | n/a | Der 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 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 | <- | 2 | Hier bin ich nicht ganz sicher, was die Hintergründe sind. In der Praxis funktioniert es wie folgt: |
Registerreihenfolge | <- | n/a | Muss nur bei Type uint32 berücksichtigt werden. Wenn der Type uint32 ist, dann muss die 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/a | Die Checkbox darf nicht gesetzt werden (also False), da KSEM "BigEndian" verwendet. |
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.