FHEM > Sonstiges

Neue Versionen und Support zum Modbus-Modul

(1/172) > >>

StefanStrobel:
Hallo,

da der alte Thread ziemlich groß geworden ist und auch Titel des alten Threads (https://forum.fhem.de/index.php/topic,25315.0.html) nicht mehr so gut passt, mache ich einen neuen auf und schließe den alten.
Das Modul unterstützt ja schon lange Modbus RTU oder ASCII über RS232, RS485 oder auch als Modbus-TCP oder Modbus-RTU über TCP.

Hier werde ich in Zukunft neue Versionen zum Testen posten und Fragen beantworten.
Bitte keine Fragen zum Modul als PM. Es ist sinnvoller,  diese hier zu stellen, damit auch andere von der Diskussion profitieren können.

Gruss
    Stefan

StefanStrobel:
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:

--- Code: ---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

--- Ende Code ---
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

Goulasch:
Meine Konfig:

--- Code: ---define PWP ModbusAttr 3 30 192.168.1.38:502 TCP
attr PWP userattr obj-h30051-reading obj-h30051-unpack obj-h30051-poll
attr PWP obj-h30051-reading WRtyp
attr PWP obj-h30051-unpack N
attr PWP obj-h30051-poll 1
attr PWP verbose 5
--- Ende Code ---
Die Slave Adresse lautet "3".

Das Log:

--- Zitat ---2017.09.17 18:45:54 5: PWP: GetUpdate called
2017.09.17 18:45:54 4: PWP: update timer modified: will call GetUpdate in 30.0 seconds at 2017-09-17 18:46:24 - Interval 30
2017.09.17 18:45:54 5: PWP: GetUpdate objects from attributes: h30051
2017.09.17 18:45:54 5: PWP: GetUpdate full object list: h30051
2017.09.17 18:45:54 5: PWP: GetUpdate check h30051 => WRtyp, poll = 1, last = 0
2017.09.17 18:45:54 4: PWP: GetUpdate will request WRtyp
2017.09.17 18:45:54 5: PWP: GetUpdate tries to combine read commands
2017.09.17 18:45:54 5: PWP: don't sort objList before sending requests
2017.09.17 18:45:54 4: PWP: Send called with h30051, objLen 1 / reqLen 1 to id 3, op read, qlen 0
2017.09.17 18:45:54 4: PWP: Send queues fc 3 to 3, tid 146, for h30051 (WRtyp), reqLen 1
2017.09.17 18:45:54 5: PWP: handle queue check commDelay (0.1) for PWP: rest -29.9109320640564
2017.09.17 18:45:54 5: PWP: handle queue check sendDelay (0.1) for PWP: rest -29.9211559295654
2017.09.17 18:45:54 5: PWP: HandleSendQueue: finished delay checking, proceed with sending
2017.09.17 18:45:54 4: PWP: HandleSendQueue sends fc 3 to id 3, tid 146 for WRtyp (h30051), len 1, device PWP (TCP), pdu 0375630001, V 3.7.0 - 20.8.2017
2017.09.17 18:45:54 5: SW: 009200000006030375630001
2017.09.17 18:45:54 5: PWP: raw read: 0092000000030383
2017.09.17 18:45:54 5: PWP: ParseFrames got: 0092000000030383
2017.09.17 18:45:54 5: PWP: ParseFrames: Modbus TCP PDU too small (expect 3): 2
2017.09.17 18:45:54 5: PWP: raw read: 02
2017.09.17 18:45:54 5: PWP: ParseFrames got: 009200000003038302
2017.09.17 18:45:54 4: PWP: ParseFrames got error code 83 / 02, illegal data address
2017.09.17 18:45:54 5: PWP: ParseFrames returned error: device replied with exception code 83 / 02, illegal data address
--- Ende Zitat ---

Gemäß SMA definiert sich das auszulesende Register:

--- Code: ---Modbus register address   Short description   Type   Format   Unit   Access
30051                           Device class           U32   ENUM      RO
--- Ende Code ---

Kann mit diversen Modbus-Server-Client Utillities auf den WR zugreifen.
Verstehe nicht, warum hier jetzt ein "exception" kommt.

Im alten Thread hat der User @Fantomas offensichtlich mit Erfolg auf das Interface zugreifen können.

Goulasch:
Antwort kann ich selbst geben :

--- Code: ---attr PWP obj-h30051-len 2
--- Ende Code ---
fehlte in der Konfig.

Roger:
Hi Stefan,
ich Roger bin's nach langer Zeit mal wieder mit einer Frage.

Beim Fronius Wechselrichter werden einige Werte aus zwei Registern gebildet: Wert*10**ScaleFactor.
Nun muss sichergestellt werden, das vor dem Auslesen und der Berechnung von Wert der ScaleFactor ausgelesen wurde.
Wie kann mal das sicherstellen?
Im Log sehe ich, das die Werte in unterschiedlicher Reihenfolge reinkommen --> und machmal ergibt die Berechnung falsche werte, da ScaleFactor zu spät kommt.
Fällt Dir dazu was ein?

Roger

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln