Neue Versionen und Support zum Modbus-Modul

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

Vorheriges Thema - Nächstes Thema

StefanStrobel

Hallo m-d-ley,

Zitat2023.06.29 12:45:55 5: Test: CreateUpdateHash full object list: h1560
...
2023.06.29 12:45:55 5: Test: CreateDataObjects unpacked 0000000000000000 with q> to 0
2023.06.29 12:45:55 4: Test: CreateDataObjects assigns value 0 to l1_volts_unscaled_UV100_V2

es wird nur dieses eine Reading abgefragt und das hat den Wert 0.
Was fehlt denn? Wie sieht denn die Konfiguration aus?

Gruss
   Stefan

Roger

Zitat von: StefanStrobel am 29 Juni 2023, 17:31:40Hallo Roger,

gleicher Fehler wie beim letzten Mal. Die utils müssen auch aktualisiert werden. Ich hab sie zusammen mit einem Update von HTTPMOD jetzt auch eingecheckt.

Gruss
  Stefan
Danke  :) , soeben eingespielt.
//Roger
Zotac, BBB, RPIs mit 10*FHEM
2*HM-LAN, 2*JeeLink, 2*RS485, SignalESP
HomeMatic, PCA301 Komponenten, ModBus: Stromzähler, Fronius WR, Shelly

m-d-ley

Das Reading sollte eigentlich die Spannung darstellen. Der Wert soll bei ~230V liegen. Allerdings wird er als kommagetrennte Dezimalzahl als Float32 schon im M-Bus übertragen. Ich vermute, dass das Modbbusattr den Wert aufgrund des Kommas verwirft. Alle Werte, welche kein Komma enthalten werden wunderbar ausgelesen. Ich lese mit dem Modul aktuell ca. 40 Zähler, zwei BHKWs und eine Druckluftanlage aus. Nun scheitere ich an einem Stromzähler von Siemens.

Anbei nochmal Bilder zur Config und den Werten im Gateway.

Vielen Dank für den Support.

https://ibb.co/zNLcW6v

https://ibb.co/gwJy7rS

StefanStrobel

Zitat von: m-d-ley am 30 Juni 2023, 09:33:58Das Reading sollte eigentlich die Spannung darstellen. Der Wert soll bei ~230V liegen. Allerdings wird er als kommagetrennte Dezimalzahl als Float32 schon im M-Bus übertragen. Ich vermute, dass das Modbbusattr den Wert aufgrund des Kommas verwirft.

laut Log kommt per Modbus nur 0 an:
Zitat2023.06.29 12:45:55 5: Test: readFn buffer: 00440000000b0a03080000000000000000 mode master
...
CreateDataObjects unpacked 0000000000000000 with q> to 0

welche Komponente macht denn die Umsetzung von MBus auf Modbus?

Gruss
  Stefan

m-d-ley

#1159
Die Umsetzung wird durch ein Gateway von anybus erledigt:

https://www.anybus.com/de/produkte/gateway-index/specific-gateways/anybus-modbus-m-bus-gateway/anybus-m-bus-to-modbus-tcp-gateway


Ohne Einstellungen sieht der Log so aus:
2023.07.03 12:51:22 5: Test: Send called from ProcessRequestQueue
2023.07.03 12:51:22 5: DevIo_SimpleWrite Test: 002d000000060a0306180001
2023.07.03 12:51:22 5: Test: readFn buffer: 002d000000050a03020000 mode master, expect response
2023.07.03 12:51:22 5: Test: ParseFrameStart called from ReadFn protocol TCP expecting id 10
2023.07.03 12:51:22 4: Test: ParseFrameStart (TCP, master) extracted id 10, fCode 3, tid 45, dlen 5 and potential data 020000
2023.07.03 12:51:22 5: Test: HandleResponse called from ReadFn
2023.07.03 12:51:22 5: Test: HandleResponse is now creating response hash, masterHash is HASH(0x55cb0caac600)
2023.07.03 12:51:22 5: Test: HandleResponse is now calling ParseResponse, masterHash is HASH(0x55cb0caac600)
2023.07.03 12:51:22 5: Test: createDevInfoCache fc 3 called
2023.07.03 12:51:22 5: Test: ParseResponse called from HandleResponse, fc 3
2023.07.03 12:51:22 5: Test: now parsing response data objects, master is Test relay is undefined
2023.07.03 12:51:22 5: Test: ParseDataString called from HandleResponse with data hex 0000, type h, adr 1560, op read
2023.07.03 12:51:22 5: Test: SplitDataString called from ParseDataString with data hex 0000, type h, adr 1560, valuesLen 1, op read
2023.07.03 12:51:22 5: Test: CreateDataObjects called from ParseDataString with objList h1560
2023.07.03 12:51:22 5: Test: CreateDataObjects sortedList h1560
2023.07.03 12:51:22 5: Test: CreateParseInfoCache called
2023.07.03 12:51:22 5: Test: CreateDataObjects unpacked 0000 with n to 0
2023.07.03 12:51:22 4: Test: CreateDataObjects assigns value 0 to l1_volts_unscaled_UV100_V2
2023.07.03 12:51:22 5: Test: ParseDataString created 1 readings, errcode undef
2023.07.03 12:51:22 4: Test: HandleResponse done, current frame / read buffer: 002d000000050a03020000, id 10, fCode 3, tid 45,
request: id 10, read fc 3 h1560, len 1, tid 45, master device Test, reading l1_volts_unscaled_UV100_V2 (getUpdate for l1_volts_unscaled_UV100_V2 len 1), queued 0.04 secs ago, sent 0.03 secs ago,
response: id 10, fc 3, h1560, len 1, values 0000
2023.07.03 12:51:22 5: Test: ResetExpect for HandleResponse from response to idle
2023.07.03 12:51:22 5: Test: DropFrame called from ReadFn - drop 002d000000050a03020000
2023.07.03 12:51:22 5: Test: readFn end buffer:  mode master, expect idle

Warum kommt am Ende ein DropFrame?

Gruß

StefanStrobel

Hallo,

Dein anybus-Gateway schickt offenbar 0.
DropFrame ist der Name der Funktion des Modbus-Moduls, die nach dem Verarbeiten eines Modbus-Frames (inkl. setzen der Readings) den Puffer wieder frei macht.
Das ist kein Fehler sondern der Abschluss der Verarbeitung.

Gruss
   Stefan

thomas.z

Moin Gemeinde,
ich versuche meinen Wechselrichter (SMA STP-10.0 SE) per Modbus testweise zu steuern und habe ein Problem beim Schreiben von holding Registern im Format U32 und S32, weil ich mit den Optionen "revRegs" und "unpack" nicht wirklich zurechtkomme.

SMA spezifiziert:
Durch die Datenablage im Motorola-Format "Big-Endian" werden bei einer Datenübertragung erst das High-Byte und
dann das Low-Byte der Modbus-Register übertragen.

Meine Tests erfolgen z. Z. manuell über die FhemWeb mit der Set-Option für die Register.

Beispiel-Register:
attr stp obj-h40149-reading BatChargeMaxW
attr stp obj-h40149-type S32
attr stp obj-h40149-set 1
Verwende ich folgende Typdefinition:
attr stp dev-type-S32-format %d
attr stp dev-type-S32-len 2
attr stp dev-type-S32-unpack l>
attr stp dev-type-S32-revRegs 1
bekomme ich bei verbose=4, wenn ich den Wert "444" setze, folgendes im Log:
request: id 3, write fc 16 h40149, len 2, value 01bc0000, tid 243, master device stp, reading BatChargeMaxW (set BatChargeMaxW), queued 0.03 secs ago, sent 0.03 secs ago,
response: id 3, fc 16, c40149, len 2
444 entspricht 1bc in Hex, aber die Reihenfolge im "value" ist dann definitiv nicht big-endian.

Ändere ich die Typdefinition auf
attr stp dev-type-S32-format %d
attr stp dev-type-S32-len 2
attr stp dev-type-S32-unpack l>
- ohne revRegs, erscheint
request: id 3, write fc 16 h40149, len 2, value 000001bc, tid 80, master device stp, reading BatChargeMaxW (set BatChargeMaxW), queued 0.02 secs ago, sent 0.02 secs ago,
response: id 3, fc 16, c40149, len 2
und der value ist aus meiner Sicht korrekt in big-endian gesetzt.

Das gleiche Problem hatte ich mit einem U32-Register:
attr stp obj-h40151-reading Kommunikation
attr stp obj-h40151-set 1
attr stp obj-h40151-type U32

Erst als ich mit dieser Typdefinition
attr stp dev-type-U32-format %u
attr stp dev-type-U32-len 2
attr stp dev-type-U32-unpack N
also ohne revRegs gearbeitet habe, konnte ich das Register tatsächlich korrekt (Wert 802) beschreiben:
request: id 3, write fc 16 h40151, len 2, value 00000322, tid 221, master device stp, reading Kommunikation (set Kommunikation),
Wenn ich jedoch ein 32bit RO Register auslesen will, benötige ich das revRegs, sonst funktioniert es nicht.
Registerbeispiel:
attr stp obj-i30771-reading DC-Spannung-A
attr stp obj-i30771-showGet 1
attr stp obj-i30771-type S32F2
und Typ
attr stp dev-type-S32F2-expr $val/100
attr stp dev-type-S32F2-format %.2f
attr stp dev-type-S32F2-len 2
attr stp dev-type-S32F2-revRegs 1

Das erscheint mir widersprüchlich und ich verstehe es nicht. Über eine erhellende Erklärung würde ich mich sehr freuen.

Danke und Gruß
Thomas
Gruß
Thomas
--
tinkerboard s, RPI-RF-MOD, debmatic 3.61.7.90, fhem 5.9.21052, HMIP-WTH-x, HMIP-eTRV-x, HMIP-BSM, Delock 11826, RPI 3b mit ebus Adapter 2.2 RPI, SMA-EM, Compleo eBox-Smart

StefanStrobel

Hallo Thomas,

kann es sein, dass Du bei dev-type-S32F2 den Unpack-Code 'N' vergessen hast und das Modul mangels eines anders definierten Default auf 'n' zurückfällt?
Dann würden nur die ersten 16 Bit vom unpack verwendet und durch revRegs schiebst Du zufällig den relevanten Bereich dahin ...
Hast Du https://forum.fhem.de/index.php?topic=103390.30 gesehen?

Gruss
   Stefan

thomas.z

Hallo Stefan,
danke für Deine schnelle Antwort! Durch einen Selektierfehler beim Copy der Typdefinition von S32F2 fehlte der Unpack-Code. Und der stand tatsächlich auf "n" und nicht auf "N" :). Das habe ich gerade korrigiert und getestet. Mit "N" bekam ich nur noch "Unfug" als Wert. Nach löschen des Attributes revRegs=1 war alles wieder o. K.

Da muss ich gestehen, dass ich offensichtlich den Verwendungszweck von "revRegs" völlig falsch verstanden habe. Bis jetzt habe ich angenommen, dass das immer für big-endian Bytefolge gemacht werden muss, damit beim get oder set die fhem- bzw. Perl-internen Variablen für Berechnungn als little-endian im Hauptspeicher landen, aber das ist ja offensichtlich nicht richtig. Hier muss ich mich noch ordentlich weiterbilden.

In welchen Fällen wäre revRegs dann einzusetzen? Die Sätze im Wiki ergeben nun keinen Hinweis mehr auf den möglichen Zweck.

Den Thread zum SMA-WR habe ich noch nicht gesehen bzw. gefunden. Ich habe nur nach modbusattr, signed integer etc. gesucht. Danke für den Link, den Thread werde ich mir jetzt mal zu Gemüte führen ... ;).

Danke nochmal und viele Grüße!
Thomas



Gruß
Thomas
--
tinkerboard s, RPI-RF-MOD, debmatic 3.61.7.90, fhem 5.9.21052, HMIP-WTH-x, HMIP-eTRV-x, HMIP-BSM, Delock 11826, RPI 3b mit ebus Adapter 2.2 RPI, SMA-EM, Compleo eBox-Smart

StefanStrobel

Hallo Thomas,

Es gibt tatsächlich Geräte, bei denen unabhängig von der Byte-Order (big endian oder small endian) die Reihenfolge der Register  umgedreht ist. Ein String mit aufsteigenden Ziffern würde dann statt "123456" als "563412" dargestellt. Da Modbus hier keine Vorgaben macht, ist das alles von den Herstellern frei interpretierbar. Meine Wärmepumpensteuerung von Waterkotte macht das zum Beispiel so.

Gruss
   Stefan

thomas.z

Hallo Stefan,
herzlichen Dank für Deine Erklärung. Auf die Idee, dass Hersteller einfach mal aus Jokus Register vertauschen, bin ich nicht gekommen, und habe revRegs einfach in die big-endian-Ecke positioniert. Mit etwas mehr Nachdenken hätte ich vielleicht drauf kommen können, dass bei big-endian ja nicht je 2x2 byte in umgekehrter Reihenfolge im Speicher stehen, sondern die 4 bytes insgesamt in umgekehrter Reihenfolge gespeichert sind.

Ich denke, nun habe ich's begriffen  ;) .

Gruß
Thomas
Gruß
Thomas
--
tinkerboard s, RPI-RF-MOD, debmatic 3.61.7.90, fhem 5.9.21052, HMIP-WTH-x, HMIP-eTRV-x, HMIP-BSM, Delock 11826, RPI 3b mit ebus Adapter 2.2 RPI, SMA-EM, Compleo eBox-Smart

fireball

Hi,

ich hab hier im Thread ein paar Suchtreffer gefunden, aber so richtig versteh ich die Hardware noch nicht.
Ich habe einen Stromzähler SDM72D-M V2 und der hat ja eine Modbusschnittstelle.

Meine Idee war, da ich schon einen WEMOS D1 mit Tasmota und mit optischem Lesekopf habe und damit meinen Hauszähler auslesen kann, dass ich einfach die Modbusschnittstelle hier noch von dem SDM72D mit auslese.
Tasmota unterstützt ja auch den SDM72D.

Versteh ich das aber richtig, ich kann nicht direkt die Modbus-Ausgänge an den Wemos hängen und kann die Werte auslesen?
Ich muss einen Modbus TTL Konverter dawischen hängen, richtig?!

Würde mich freuen, wenns kurz einer erklären kann?!
VG+Danke
René

holle75

Zitat von: StefanStrobel am 23 Juni 2023, 16:37:43Hallo holle75,

get ist bei ModbusAttr blocking, es sei denn man setzt das Attribut nonPrioritizedGet (hat in der Doku leider gefehlt, da war nur nonPrioritizedSet drin).

Gruss
  Stefan

vielen Dank!

CaptainHook

Moin Zusammen,

ich versuche gerade das Modul 98_SolarEdge um die Funktion die Batterie bzw den Speicher zu steuern zu erweitern.

Aus der Sunspec von Solaredge:
Appendix C – Encoding and Decoding 32-bit Values in Modbus
In Modbus, 32-bit values span two registers. This appendix explains how to encode and decode these registers correctly.
Since 32-bit values span two registers, they must be written in a single transaction of Write Multiple Registers (Function code 10) and
not two consecutive Write Single Register (Function code 06) transactions.

In der Datei im SVN habe ich gesehen, das das Modul beim senden von Werten den Funktionscode 06 benutzt (%fcMap).
Gibt es eine Möglichkeit, zwei Register in einer Transaktion und mit Funktionscode 10 zu senden?

Viele Grüße,
Stephan
Lenovo M53 ThinkCentre 10DC | Docker | SolarEdge SE10K + SE5000H + Energy Bank 10KWh | EspEasy | Tasmota | Hue | Alexa | uvm.

StefanStrobel

Zitat von: fireball am 15 Juli 2023, 19:14:55Versteh ich das aber richtig, ich kann nicht direkt die Modbus-Ausgänge an den Wemos hängen und kann die Werte auslesen?

Hallo Rene,

Du müsstest einen RS485 auf RS232-Konverter haben oder Dein Wemos kann RS485 auf TTL-Level mit einem entsprechenden Konverter.
Dann bleibt aber noch die Frage, ob der Wemos dannn 1:1 das Modbus-RTU über Wifi / TCP hin und her schicken kann.

Gruss
  Stefan