Neue Versionen und Support zum Modbus-Modul

Begonnen von StefanStrobel, 20 August 2017, 12:11:08

Vorheriges Thema - Nächstes Thema

StefanStrobel

Hallo Ralf,

da hast Du einen Bug gefunden.
Bitte teste doch mal, ob der in dem angehängten Modul behoben ist.
Die neue Version würde ich auch einchecken. Allerdings haben sich inzwischen einige Änderungen angesammelt und ich würde mich wohler fühlen, wenn ein paar Anwender das neue Modul vorher testen und hier posten ob noch alles funktioniert.

Gruss
   Stefan

StefanStrobel

Hallo Apollon,

die Registerbelegung des Zählers für Modbus kann man einfach runterladen. Die direkte Einbindung per RS485 in Fhem wäre also kein Problem. Wenn Du die alten Beiträge zum Modbus-Modul durchliest, findest Du mehrere Fälle, die ähnlich gelagert waren bzw. Anleitungen, wie man schrittweise vorgeht.
Zu Deinem Konverter kann ich jedoch nichts sagen.

Gruss
   Stefan

Apollon

Hallo Stefan,

vielen Dank für deine Antwort. Ich habe gedacht, ich sei in diesem Beitrag richtig. Gesucht und gelesen habe ich schon sehr viel. Je mehr ich gelesen habe, umso verwirrender wurde es für mich.
Ich werde wohl einfach mal den Zähler kaufen und versuchen ihn in FHEM zu integrieren. Wenn es nicht funktioniert habe ich halt pech gehabt.

Gruß
Apollon

RaKoHe

#858
Moin Stefan,

der Bug durch ScanStop ist weg.

Zum Spaß habe ich obj-h0-unpack 0 gemacht was zum sofortigen Absturz führte. ???
Invalid type '0' in unpack at ./FHEM/98_Modbus.pm line 2652.

Mit sonnigen Grüßen

Ralf

MiniBlister

Guten Morgen,

erst einmal vielen Dank für das tolle Module.
Ich bin dabei, ein Grundfos CIM200 Modul zu integrieren.

Was mir noch nicht ganz klar ist, wie ich ein Halteregister, welches mit functions code 0x06 oder 0x10 schreibbar ist bit weise mainipuliere (siehe bild im Anhang)
Ich stelle mir vor, dass ich aus mehreren userattr einen binären Wert generiere und dann über das -set auf das Register schreibe.

Gibt es da eine anderen Möglichkeit? Vielen Dank für die Hilfe
 

StefanStrobel

Hallo MiniBlister,

eine wirklich elegantere Lösung fällt mir auch nicht ein.
Wenn man einen unpack-Code hätte, der die Bit-Werte als Liste erzeugt, dann könnte das Modul daraus automatisch einzelne Readings erzeugen, aber so wie ich den unpack-Code "B" verstehe, erzeugt der leider einen String statt einer Liste.

Gruss
   Stefan

der-Lolo

Hallo Stefan,
ich hoffe Du hattest ein Frohes Fest..!
Bei uns gibt es ein nebengebäude - ein kleines Gartenhaus. In dem sorgt ein Pelletofen für Wärme.
Es ist ein MCZ Ego Air 2.0 mit Rauchabzug oben.

Es gibt von MCZ ein passendes WiFi Modul welches aber mit 320€ eindeutig zu teuer ist.

Beim durchforsten der zugehörigen dokumente ist mir aber aufgefallen das dieses WiFi Modul via Modbus an der Platine des Ofens angeschlossen wird.
Nun würde ich gerne versuchen den Ofen direkt via Modbus in FHEM zu integrieren.

Leider gibt es nicht wie sonst üblich eine Register beschreibung des Herstellers.

Wie hoch schätzt Du den Aufwand ein die notwendigen Register zu erforschen um an ende den Ofen steuern zu können...?

Was ist der eleganteste weg RS485 via Lan ins Netzwerk zu bringen?
Es wäre auch möglich einen eigenen Raspberry zu opfern, ich würde das aber gerne vermeiden.

- hat vielleicht sonst jemand einen MCZ Pelletofen am laufen und nutzt schon die Modbus anbindung?

Allen einen Guten Rutsch ins neue Jahr!


StefanStrobel

Hallo,

das sollte in ein paar Tagen und mit genügend Geduld schon machbar sein.
Mit einem Register-Scan müsste man nach passenden Einträgen suchen, dann manuell am Gerät die relevanten Parameter einstellen und vergleichen, welche Register sich entsprechend ändern.
Am einfachsten wäre es natürlich wenn man das WLAN-Modul mal testweise anschließen könnte und dabei mit dem Fhem-Modbus-Modul im passiven Modus mitlauschen könnte, auf welche Register das zugreift .

Gruss
   Stefan

Cybers

#863
Hallo,

ich habe ein kleines Problem beim Anlegen eines Registers. Ich benutze die angehängte Datei für das Auslesen meines SDM72D-M Drehstromzählers. Grundsätzlich kann ich alle in der Datei hinterlegten Register auslesen.
Jetzt möchte ich aber den Tageszähler über Fhem resetten können. Für den Reset ist folgender Register zuständig:
Adress Register: 461457
Paramter: Reset historical data
Modbus Protocol, Start Address Hex: F0 / 10
Valid rang: 00 03 = reset energy info / Length : 2 byte /Data Format: Hex
Mode: wo
Hier noch der Link zur Übersicht der Register: https://stromzähler.eu/media/pdf/93/17/d7/SDM72DM-V2.pdf

In Zeile 187-198 der angehängten Datei habe ich mal einen Anfang gewagt, komme aber nicht weiter.
"h61457" => { # holding register 0x0014
# Write the network port node address: 1 to 247 for MODBUS Protocol, default 1.
# Requires a restart to become effective.
# https://data.stromzähler.eu/eastron/SDM72DM-manual.pdf
name => "Reset", # internal name of this register in the hardware doc
reading => "Reset", # name of the reading for this value
min => 1, # input validation for set: min value
max => 247, # input validation for set: max value
format => '%u', # format string for sprintf
poll => "once", # only poll once after define (or after a set)
set => 1, # this value can be set
},


Kann mir einer helfen?

Gruß, Sascha
FHEM 6.2 auf Raspberry PI 4 / Smartvisu
Eltako Serie 14: FAM14, FGW14-USB, FSB14, FSR14-4x, FSR14-2x, FDG14, FTS14-EM in Kombination mit Jung F50 24V Tastern
1-Wire Temperatursensoren
aus alter Zeit:
Gott sei Dank nur noch 3 Homematic Jalousie- & Schaltaktoren! Wer sich mit Funk auskennt, legt Kabel

StefanStrobel

Hallo Cybers,

Du musst von den in Hex angegebenen Protokolladressen ausgehen.
Dein Register hat die Adresse F010, das ist dezimal 61456, nicht 61457.
Zudem ist das Register als write only angegeben. Ich würde deshalb gar nicht erst versuchen, es zu lesen. Auch nicht mit "once".
Format %u würde ich weglassen. Dafür ist es aber wichtig, den passenden unpack-code anzugeben. Der wird auch für das Packen beim set verwendet.
Bisher greift hier die Angabe von weiter oben in Deinem File:
Zitat
defUnpack   =>   "f>",   # default pack / unpack code to convert raw values, e.g. "n" for a 16 bit integer oder
Das wäre ein Float, der über zwei Register geht. Du brauchst aber n oder eventuell v.
Die Angaben von min und max kannst Du auf 3 setzen, wenn 3 der einzig akzeptierte Wert ist.
Und dann wäre da noch der function code. Laut Anleitung möchte der Zähler mit function code 10 (hex) beschrieben werden, aber das steht in Deinem File schon so drin (write    => 16), sollte also passen.
Ich hoffe da fehlt nicht noch was ;-)

Gruss
   Stefan


Aurel_B

Hallo zusammen,

ich bin dabei, ein Modbus Relaisboard von Waveshare (https://www.waveshare.com/modbus-rtu-relay.htm) in Betrieb zu nehmen. Modbusprotokoll siehe hier: https://www.waveshare.com/wiki/Protocol_Manual_of_Modbus_RTU_Relay. Einzelne Relais schalten geht, bei den restlichen Funktionen stehe ich aber an: das Board hält sich leider nicht an die Spezifikationen und "missbraucht" Coils als Holding Registers wenn ich das richtig verstanden habe:


Command:01 05 00 FF FF FF FC 4A

Byte    Meaning         Description
01      Device address  0x00 is broadcast;0x01-0xFF are devices address
05      05 command      Command for controlling Relay
00 FF   Address         Fixed 0x00FF
FF FF   Command         0xFFFF:Open Relay;
FC 4A   CRC16           The CRC checksum of the first six bytes


Dieser Befehl schaltet alle Relais ein. Es wird hierfür ein "Coil write" (05) verwendet, der "Command" ist aber nicht "FF 00" sondern "FF FF". Für andere Befehle wird wiederum "FF 00" oder auch "55 00" (toggelt ein Relais) verwendet, dev-c-brokenFC5 65535 z.B. fällt also flach da in der Sichtweise des Herstellers ein Coil nicht 0 oder 1 ist sondern durchaus auch mehrere Werte aufweisen kann  :(

Ich habe mit dev-h-write 5 versucht, Holding Registers als "Coils" zu verwenden, das klappt aber leider auch nicht: es wird immer "FF 00" gesendet sobald ich das Holding Register auf einen Wert !=0 setze (also scheint Modbus_Attr intern das Holding Register dann als Coil zu betrachten).

Hier ein Beispiel:


attr Waveshare_Relay obj-h255-reading Alle_Relais
attr Waveshare_Relay obj-h255-set 1
attr Waveshare_Relay obj-h255-unpack n


führt zu folgendem Logeintrag (auf den Befehl set Waveshare_Relay Alle_Relais 65535)


2022.01.24 20:58:40.100 4: ModBusUSBStick: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 1, sending 010600ffffffb84a via /dev/ttyUSB4@9600, read buffer empty


Das wäre fast das was ich bräuchte (010500fffffffc4a). Also 05 statt 06. Verwende ich attr Waveshare_Relay dev-h-write 5 gibt es folgenden Logeintrag:


2022.01.24 21:21:39.449 4: ModBusUSBStick: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 1, sending 010500ffff00bc0a via /dev/ttyUSB4@9600, read buffer empty,


Auch wieder nur fast das was ich bräuchte (010500fffffffc4a).

Hat da irgendjemand einen Lösungsansatz für mich? Meine Idee wäre: da ich einzelne Relais grundsätzlich an- und abschalten kann würde ich mir ein DOIF o.ä. basteln das nacheinander alle Relais an- oder abschaltet. Elegant ist das nicht (was, wenn >1 Befehle verloren gehen).....

Beste Grüsse, Anton

Cybers

#866
Zitat von: StefanStrobel am 24 Januar 2022, 18:12:59
Hallo Cybers,

Du musst von den in Hex angegebenen Protokolladressen ausgehen.
Dein Register hat die Adresse F010, das ist dezimal 61456, nicht 61457.
Zudem ist das Register als write only angegeben. Ich würde deshalb gar nicht erst versuchen, es zu lesen. Auch nicht mit "once".
Format %u würde ich weglassen. Dafür ist es aber wichtig, den passenden unpack-code anzugeben. Der wird auch für das Packen beim set verwendet.
Bisher greift hier die Angabe von weiter oben in Deinem File:Das wäre ein Float, der über zwei Register geht. Du brauchst aber n oder eventuell v.
Die Angaben von min und max kannst Du auf 3 setzen, wenn 3 der einzig akzeptierte Wert ist.
Und dann wäre da noch der function code. Laut Anleitung möchte der Zähler mit function code 10 (hex) beschrieben werden, aber das steht in Deinem File schon so drin (write    => 16), sollte also passen.
Ich hoffe da fehlt nicht noch was ;-)

Gruss
   Stefan

Hallo Stefan,

vielen Dank für deine Antwort. Ich habe es entsprechend geändert und die Definition für den Reset erweitert:
"s" => { # details for "setting reset" if the device offers them
read => 3, # use function code 3 to read holding registers.
write => 16, # use function code 6 to write holding registers (alternative could be 16)
defLen => 2, # default length (number of registers) per value (e.g. 2 for a float of 4 bytes that spans 2 registers)
# can be overwritten in parseInfo per reading by specifying the key "len"
combine => 10, # allow combined read of up to 10 adjacent registers during getUpdate
defUnpack => "v", # default pack / unpack code to convert raw values, e.g. "n" for a 16 bit integer oder
# "f>" for a big endian float IEEE 754 floating-point numbers
# can be overwritten in parseInfo per reading by specifying the key "unpack"
defShowGet => 1, # default für showget Key in parseInfo
},


"s61456" => { # holding register 0x0014
# Write the network port node address: 1 to 247 for MODBUS Protocol, default 1.
# Requires a restart to become effective.
# https://data.stromzähler.eu/eastron/SDM72DM-manual.pdf
name => "Reset", # internal name of this register in the hardware doc
reading => "Reset", # name of the reading for this value
min => 3, # input validation for set: min value
max => 3, # input validation for set: max value
# format => '%u', # format string for sprintf
# poll => "once", # only poll once after define (or after a set)
set => 1, # this value can be set
},



Ich bekommen aber immer den Fehler "Timeout in Readanswer". Egal ob ich bei "defUnpack" v oder n einsetze. Bei f> bekam ich folgendes als Rückmeldung: 2.52435489670724e-29
Oder muß ich in der 98_Modbus.pm auch noch was ändern da ich ja die neue "Variabel" "s" hinzugfügt habe?

Im Anhang wieder die komplette geänderte Datei.
FHEM 6.2 auf Raspberry PI 4 / Smartvisu
Eltako Serie 14: FAM14, FGW14-USB, FSB14, FSR14-4x, FSR14-2x, FDG14, FTS14-EM in Kombination mit Jung F50 24V Tastern
1-Wire Temperatursensoren
aus alter Zeit:
Gott sei Dank nur noch 3 Homematic Jalousie- & Schaltaktoren! Wer sich mit Funk auskennt, legt Kabel

ch.eick

#867
Hallo zusammen,
ich stehe vor der Problematik, dass ich ein Gerät ersetzt bekomme, was jedoch einen Zähler für "Total" Werte hat. Dieser würde jedoch mit dem Austausch wieder bei null anfangen.
Könnte ich im ModBus reading die monotonic() Funktion mit einbauen, sodaß der Wert im FHEM Device einfach weiter zählt, ohne dass ich ein weiteres reading erzeuge?

EDIT:
Sorry, beim Modul ModBus funktioniert der modifier monotonic . Die Fehlermeldung betraf httpmod und ist dann dort zu finden.

VG
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Aurel_B

Blöde Frage: wieso addierst du nicht den alten Stand zum neuen Stand dazu (in einem Userreading z.B.)? Also ReadingsVal("$NAME","Statistic_Yield_Total",0)+123456}?

ch.eick

#869
Zitat von: ansgru am 25 Januar 2022, 16:48:48
Blöde Frage: wieso addierst du nicht den alten Stand zum neuen Stand dazu (in einem Userreading z.B.)? Also ReadingsVal("$NAME","Statistic_Yield_Total",0)+123456}?
Weil das dann bei jedem Wechsel und bei einigen Geräten bei jedem Reset (Shelly) gemacht werden müsste.

Mit modifier monotonic wird im Hintergrung genau das gemacht und man muss nicht mehr selber darauf achten.

Leider ist mir gerade aufgefallen, dass es beim Modul Modbus funktioniert. Das Device mit dem Fehler ist httpmod.
Ich ziehe dann mal mit meinem Post in den anderern Thread um und mache hier eine Verlinkung.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick