und hier auch gleich eine neue Version zum Testen.
Neu ist z.B. die Unterstützung von benutzerdefinierten Datentypen. Bei einigen Geräten werden z.B. viele Werte als Fließkommazahl in 2 Registern mit umgekehrter Reihenfolge im big endian Format gespeichert.
um nicht für jedes Objekt 5 Attribute mit Länge, Unpack-Code, revRegs etc. angeben zu müssen, kann man nun einmal den Datentyp mit dev-type- definieren und dann künftig bei jedem Objekt nur noch den Typ zuweisen.
Beispiel:
attr WP dev-type-VT_R4-format %.1f
attr WP dev-type-VT_R4-len 2
attr WP dev-type-VT_R4-revRegs 1
attr WP dev-type-VT_R4-unpack f>
attr WP obj-h1234-reading Temp_Ist
attr WP obj-h1234-type VT_R4
Die ersten vier Attribute erzeugen einen Datentyp mit Namen VT_R4 und legen für diese Typ format, len, revRegs und unpack fest.
Danach wird für das Holding-Register mit der Adresse 1234 ein Reading mit Namen Temp_Ist und der Typ VT_R4 zugewiesen.
Ebenso neu ist ein experimentelles Feature zum automatischen Erzeugen eines individuellen Gerätemoduls aus den Attributen eines Modbus-Attr Geräts.
Mit set WP saveAsModule WP werden die per Attribut definierten Objekte (alles was mit dev- und obj- definiert ist) mit etwas Code drum herum in ein Perl-File geschrieben. Das File würde im obigen Beispiel als /tmp/98_ModbusGenWP.pm gespeichert.
Von dort kann man es ins Modulverzeichnis von Fhem (z.B. /opt/fhem/FHEM) verschieben, Fhem neu starten und dann statt Modbus-Attr mit vielen Attributen ein Gerät mit dem neuen Typ ModbusGenWP definieren.
Wer die Register-Definitionen für seine Heizung oder seinen speziellen Solar-Speicher einfach als Modul weitergeben möchte, kann das mal ausprobieren.
Gruss
Stefan