[FR] Sammlung modbus modul Eigenschaften

[miesi]

Hallo,

in einem anderen Thread wurde gewünscht die Anforderungen und Priotitäten an ein Modbus Modul zu sammeln.

Ich habe nur wenig direkte Erfahrung mit modbus (Werte lesen und schreiben mit https://www.openhab.org/addons/bindings/modbus/), habe jedoch schon unter Eigenschaften von modbus gelitten (Ausfälle von modbus vernetzten Multimegawatt Klimaanlagen für Rechenzentren durch unterschiedliche interpretation von bytes von verschiedenen versionen der Firmware).

Physical Layer:
Abstraktion das Zugriff über RS-485 oder tcp keine Rolle spielt.

Data Access Layer:
Da modbus eher ein RDMA Protokoll ist (man so wo man wieviel lesen/schreiben will) ist es geschickt in einem Request (mehrere) Bytes statt einzelne Bits zu lesen.
Function codes (FC) FC01 (Read coils), FC02 (Read discrete inputs), FC03 (Read multiple holding registers), FC04 (Read input registers)

Beim schreiben sollten sowohl die einzel als auch die mehrfachfunktionen implementiert werden:
FC05 (Write single coil), FC06 (Write single holding register), FC15 (Write multiple coils), FC16 (Write multiple holding registers)

Die Polling Frequenz sollte im Dataaccesslayer pro poller einstellbar sein. Ich halte eine Frequenzangabe a la "alle x sekunden" für hinreichend.

Ein Gerät wie der systemair Genius hat 98 Datenpunkt die sich mit 4 requests abholen lassen.

Die vom DataAccessLayer gelieferten Daten müssen dann interpretiert werden, also in bit, int8, uint8, int16, uint16, in32, uint32, float32, int64, uint64 zerlegt werden. Es wäre hilfreich Funktionen zu haben um die endianess der int werte anzupassen, der Standard sagt wohl nicht klar genug ob little endian oder big endian die richtige Reihenfolge ist.

Die modbus Programmierer neigen weiterhin zu byte Sparsamkeit und Multipliziren beispielsweise float Temperatur Messwerte mit 10, schneiden die Nachkommastellen ab und stellen den Wert als int16 bereit. Wenn man das liest muß man den Wert durch 10 dividieren und als float bereitstellen. Solche Transformationen sollten "einfach" sein und am besten mit Beispiel dokumentiert.

Ich denke das wären die Grundlagen um damit Geräte oder Spezifikations spezifische Module für systemair Genius/oder sun spec zu bauen.

Ich vermute, praktisch jeder TWS Kunde hat eine PV Anlage, also wäre das sun-spec modul von großem Nutzen.

Ein weiteres Feld wäre die emulation eines/mehrerer modbus adressen an denen modbus Geräte Messwerte pollen können. Ein textuelle Representation eine solchen Software only modbus device könnte so aussehen:

modbus_device [ physical_interface: rs485_0, address: 172, type: input, start:0 length: 4] {
RoomTemp1 [ Start:0, type:int16, conversionRule: "...", tws_data_point: some_tws_datapoint]
RoomTemp2 [ Start:1, type:int16, conversionRule: "...", tws_data_point: some_tws_datapoint]
RoomTemp3 [ Start:2, type:int16, conversionRule: "...", tws_data_point: some_tws_datapoint]
RoomTemp4 [ Start:3, type:int16, conversionRule: "...", tws_data_point: some_tws_datapoint]
}

[StefanW]

Hallo Miesi,

ein toller Beitrag, danke sehr. Hilft uns sehr, nichts zu übersehen.

lg

Stefan