Auslesen FINDER RS485 Energie Zweirichtungszähler

[R1F800]

Hallo Zusammen.

Ich stehe gerade auf dem Schlauch.
Ich möchte meinen an den PI RS485 HAT angeschlossenen FINDER Zweirichtungszähler auslesen.

Das RS485 Device ist angelegt, somit ist die Schnittstelle zum Modbus ja etabliert.

Code Auswählen Erweitern

defmod ModbusRS485 Modbus /dev/ttyUSB0@9600
attr ModbusRS485 room interfaces

setstate ModbusRS485 opened
setstate ModbusRS485 2024-10-24 11:48:46 state opened
JETZT wird es schwierig, WIE bekomme ich die einzelnen Daten aus dem Finder abgefragt?

[R1F800]

Keiner, der mir weiterhelfen kann?

Fehlt das Device mit modbusattr ?
Die Doku zu dem Teil verstehe ich nicht wirklich.
ich müsste doch zuerst auf den Modbus zum jeweiligen register raussenden, das ich auslesen will oder?

Code Auswählen Erweitern

defmod FinderEnergiezaehler ModbusAttr 3 60 RTU
attr FinderEnergiezaehler alias Finder Zweirichtungs Zähler
attr FinderEnergiezaehler comment Finder 7M.38
attr FinderEnergiezaehler dev-h-defLen 2
attr FinderEnergiezaehler dev-h-defPoll 1
attr FinderEnergiezaehler dev-h-defUnpack N
attr FinderEnergiezaehler dev-timing-commDelay 0.1
attr FinderEnergiezaehler dev-timing-timeout 2
attr FinderEnergiezaehler enableControlSet 1
attr FinderEnergiezaehler event-on-change-reading .*
attr FinderEnergiezaehler icon stromzaehler_icon@green
attr FinderEnergiezaehler obj-i32752-len 1
attr FinderEnergiezaehler obj-i32752-reading Energy Counter n1
attr FinderEnergiezaehler room interfaces
attr FinderEnergiezaehler verbose 5
attr FinderEnergiezaehler webCmd reread

1) Ist die ID aus der Deviceanlage ModbusAttr frei wählbar?
2) Jetzt die spezifischeren Fragen > die i### Variablen, sind das die Register im auszulesenden Gerät?
UND wie biege ich diese Attribute dem Device bei? Über die Weboberfläche kann ich das nicht > geht nur via edit der CFG

Hier mal das LOG

Code Auswählen Erweitern

024.10.27 16:59:03 1: FinderEnergiezaehler: Can't connect to 33:502: connect to http://33:502 timed out
2024.10.27 17:00:38 5: FinderEnergiezaehler: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active
2024.10.27 17:00:38 5: FinderEnergiezaehler: UpdateSetList: getList=
2024.10.27 17:01:07 4: FinderEnergiezaehler: GetUpdate (V4.5.6 - 7.11.2023) called from Fhem internal timer
2024.10.27 17:01:07 4: FinderEnergiezaehler: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 300.0 sec at 17:06:07.454, interval 300
2024.10.27 17:01:07 5: FinderEnergiezaehler: CreateUpdateHash full object list: i32752 i32754 i32756
2024.10.27 17:01:07 4: FinderEnergiezaehler: CombineUpdateHash objHash keys before combine:
2024.10.27 17:01:07 5: FinderEnergiezaehler: CombineUpdateHash tries to combine read commands
2024.10.27 17:01:07 5: FinderEnergiezaehler: CombineUpdateHash keys are now
2024.10.27 17:01:07 4: FinderEnergiezaehler: GetUpdate will now create requests for
2024.10.27 17:06:07 4: FinderEnergiezaehler: GetUpdate (V4.5.6 - 7.11.2023) called from Fhem internal timer
2024.10.27 17:06:07 4: FinderEnergiezaehler: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 300.0 sec at 17:11:07.481, interval 300
2024.10.27 17:06:07 5: FinderEnergiezaehler: CreateUpdateHash full object list: i32752 i32754 i32756
2024.10.27 17:06:07 4: FinderEnergiezaehler: CombineUpdateHash objHash keys before combine:
2024.10.27 17:06:07 5: FinderEnergiezaehler: CombineUpdateHash tries to combine read commands
2024.10.27 17:06:07 5: FinderEnergiezaehler: CombineUpdateHash keys are now
2024.10.27 17:06:07 4: FinderEnergiezaehler: GetUpdate will now create requests for
2024.10.27 17:11:07 4: FinderEnergiezaehler: GetUpdate (V4.5.6 - 7.11.2023) called from Fhem internal timer
2024.10.27 17:11:07 4: FinderEnergiezaehler: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 300.0 sec at 17:16:07.483, interval 300
2024.10.27 17:11:07 5: FinderEnergiezaehler: CreateUpdateHash full object list: i32752 i32754 i32756
2024.10.27 17:11:07 4: FinderEnergiezaehler: CombineUpdateHash objHash keys before combine:
2024.10.27 17:11:07 5: FinderEnergiezaehler: CombineUpdateHash tries to combine read commands
2024.10.27 17:11:07 5: FinderEnergiezaehler: CombineUpdateHash keys are now
2024.10.27 17:11:07 4: FinderEnergiezaehler: GetUpdate will now create requests for

2024.10.27 19:38:40 5: FinderEnergiezaehler: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active
2024.10.27 19:38:40 5: FinderEnergiezaehler: UpdateSetList: getList=


[Prof. Dr. Peter Henning]

Bitte verschieben ins Unterforum "Verbrauchsmessung"

pah

[StefanStrobel]

Hallo R1F800,

Mit

Code Auswählen Erweitern

define ModbusRS485 Modbus /dev/ttyUSB0@9600

Legst Du das IO-Device fest. Das muss zur Schnittstelle und zu den Kommunikationseinstellungen passen. Wenn Dein Zähler nicht mit 9600, 8, N, 1 kommuniziert, dann wird es nicht klappen. Die korrekten Angaben sollten im Handbuch Deines Zählers stehen.

Dann brauchst Du ein logisches Device, in dem die Modbus-Id, die Register Deines Zählers mit der Art der Kodierung, Länge etc. angegeben werden. Auch diese Werte sollten im Handbuch des Zählers stehen. Wenn Die Modbus-Id nicht stimmt, antwortet der Zähler nicht. Ebenso kommt nichts sinnvolles wenn die Register-Adressen etc. nicht stimmen.

Code Auswählen Erweitern

Define FinderEnergiezaehler ModbusAttr 3 60 RTU

Sieht nicht falsch aus, sofern Dein Zähler wirklich Id 3 verwendet und das Modbus-RTU-Protokoll spricht.

Dein Log-Auszug beginnt aber gleich mit einer Fehlermeldung, die nicht zu der geposteten Konfiguration passt.

Code Auswählen Erweitern

FinderEnergiezaehler: Can't connect to 33:502: connect to http://33:502 timed out

sieht so aus als ob Du mit Modbus-TCP ein Gerät mit Namen 33 auf Port 502 ansprechen wolltest und eben nicht über die serielle Schnittstelle und Modbus-RTU.

Gruß
   Stefan

[R1F800]

Hm. OK direkt mehrere Probleme auf ein Mal.

der Finder 7M.38 hat als Datenblattangabe  "Frame" 8,N,2; "Adresse" 33 und RTU Modbus.

Code Auswählen Erweitern

defmod ModbusRS485 Modbus /dev/ttyUSB0@19200,8,N,2  << der RS485 ist zwar nicht via USB sonder via HAT über UART angeklemmt, aber das sollte ja kein Problem sein.

die ID habe ich dann mal an die Adresse angepasst. Das hatte ich so nicht aus der Doku verstanden.

Code Auswählen Erweitern

defmod FinderEnergiezaehler ModbusAttr 33 60 RTU
Immerhin kommt die Kommunikation jetzt schon mal weiter:

Code Auswählen Erweitern

2024.10.28 16:37:49 4: FinderEnergiezaehler: GetIOHash (called from NotifyFn) did not find valid IODev hash key, calling SetIODev now
2024.10.28 16:37:49 5: FinderEnergiezaehler: SetIODev called from GetIOHash
2024.10.28 16:37:49 4: FinderEnergiezaehler: RegisterAtIODev called from SetIODev registers FinderEnergiezaehler at ModbusRS485 with id 33, MODE master, PROTOCOL RTU
2024.10.28 16:37:49 4: FinderEnergiezaehler: Notify / Init: using ModbusRS485 for communication
2024.10.28 16:37:49 4: FinderEnergiezaehler: UpdateTimer called from NotifyFn with cmd start sets timer to call update function in 0.0 sec at 16:37:49.851, interval 60
2024.10.28 16:37:50 4: FinderEnergiezaehler: GetUpdate (V4.5.6 - 7.11.2023) called from Fhem internal timer
2024.10.28 16:37:50 4: FinderEnergiezaehler: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 60.0 sec at 16:38:50.304, interval 60
2024.10.28 16:37:50 5: FinderEnergiezaehler: CreateUpdateHash full object list: i30406 i32752
2024.10.28 16:37:50 4: FinderEnergiezaehler: CombineUpdateHash objHash keys before combine:
2024.10.28 16:37:50 5: FinderEnergiezaehler: CombineUpdateHash tries to combine read commands
2024.10.28 16:37:50 5: FinderEnergiezaehler: CombineUpdateHash keys are now
2024.10.28 16:37:50 4: FinderEnergiezaehler: GetUpdate will now create requests for
2024.10.28 16:37:50 5: FinderEnergiezaehler: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active
2024.10.28 16:37:50 5: FinderEnergiezaehler: UpdateSetList: getList=
2024.10.28 16:38:50 4: FinderEnergiezaehler: GetUpdate (V4.5.6 - 7.11.2023) called from Fhem internal timer
2024.10.28 16:38:50 4: FinderEnergiezaehler: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 60.0 sec at 16:39:50.306, interval 60
2024.10.28 16:38:50 5: FinderEnergiezaehler: CreateUpdateHash full object list: i30406 i32752
2024.10.28 16:38:50 4: FinderEnergiezaehler: CombineUpdateHash objHash keys before combine:
2024.10.28 16:38:50 5: FinderEnergiezaehler: CombineUpdateHash tries to combine read commands
2024.10.28 16:38:50 5: FinderEnergiezaehler: CombineUpdateHash keys are now
2024.10.28 16:38:50 4: FinderEnergiezaehler: GetUpdate will now create requests for
2024.10.28 16:39:50 4: FinderEnergiezaehler: GetUpdate (V4.5.6 - 7.11.2023) called from Fhem internal timer
 
die beiden I Register sind eigentlich :

i30406 & i30407  (32bit floating point single precision)
i32752 & i32753  (signed long value 32 bit)

die müssten ja eigentlich dann konkatiniert werden ?

Code Auswählen Erweitern

attr PWP obj-i30406-unpack f>

[StefanStrobel]

Jetzt musst Du die Input-Register auch noch abfragen. Bisher hast Du mit dev-h-defPoll zwar alle Holding-Register zur Abfrage festgelegt, nicht aber die Input-Register. Das wäre dev-i-defPoll.

Gruß
  Stefan

[StefanStrobel]

Und wenn zwei Input-Register zusammen einen 32-Bit-Float-Wert enthalten, dann musst Du die kleinere Adresse mit Len 2 angeben.

[R1F800]

Den Zusammenhang hatte ich so noch nicht in der Doku gesehen.

Und wenn zwei Input-Register zusammen einen 32-Bit-Float-Wert enthalten, dann musst Du die kleinere Adresse mit Len 2 angeben.

heisst

Code Auswählen Erweitern

attr FinderEnergiezaehler dev-i-defLen 2
attr FinderEnergiezaehler dev-i-defPoll 1
und dann die Länge bei den abzufragenden OBJ?

Ich brauch eine Kreissäge für das Brett vorm Kopf ...

[StefanStrobel]

def-i-def... bzw. def-h-def... legen Defaults für Objektarten fest. Angaben bei den Objekten können das überschreiben.
Alternativ kannst Du auch Datentypen angeben. Hinter einem Datentyp steckt dann schon die Länge und der Unpack-Code.
Das steht in der commandref für ModbusAttr unter "Handling Data Types"

Gruß
   Stefan

[R1F800]

OK, dann hab ich das ja schon drin:

Code Auswählen Erweitern

attr FinderEnergiezaehler dev-h-defLen 2
attr FinderEnergiezaehler dev-h-defPoll 1
attr FinderEnergiezaehler dev-i-defLen 2
attr FinderEnergiezaehler dev-i-defPoll 1
attr FinderEnergiezaehler dev-timing-commDelay 0.1
attr FinderEnergiezaehler dev-timing-timeout 2
attr FinderEnergiezaehler disable 0
attr FinderEnergiezaehler enableControlSet 1
attr FinderEnergiezaehler event-on-change-reading .*
attr FinderEnergiezaehler icon stromzaehler_icon@green
### Temperaturregister
attr FinderEnergiezaehler obj-i30181-len 1
attr FinderEnergiezaehler obj-i30181-reading FinderGeraetetemperatur:temperature
attr FinderEnergiezaehler obj-i30181-showGet 1
attr FinderEnergiezaehler obj-i30181-type signed short little
#### Register 752 und 753
attr FinderEnergiezaehler obj-i32752-len 2
attr FinderEnergiezaehler obj-i32752-reading EnergieBezug
attr FinderEnergiezaehler obj-i32752-showGet 1
attr FinderEnergiezaehler obj-i32752-type unsigned long little
attr FinderEnergiezaehler obj-i32752-unpack f>
#### Register 754 und 755
attr FinderEnergiezaehler obj-i32754-len 2
attr FinderEnergiezaehler obj-i32754-reading EnergieEinspeisung
attr FinderEnergiezaehler obj-i32754-showGet 1
attr FinderEnergiezaehler obj-i32754-type unsigned long little
attr FinderEnergiezaehler obj-i32754-unpack f>
Jetzt komme ich zumindest schon mal weiter, nachdem ich die timeouts hochgesetzt hab. Die waren zu klein dimensioniert ... ob das besser ist :

Code Auswählen Erweitern

2024.10.29 18:17:56 4: FinderEnergiezaehler: get called with EnergieBezug (i32752)
2024.10.29 18:17:56 5: FinderEnergiezaehler: GetSetChecks with force
2024.10.29 18:17:56 5: FinderEnergiezaehler: GetSetChecks returns success
2024.10.29 18:17:56 4: FinderEnergiezaehler: DoRequest called from GetLDFn created new request, read buffer empty,
request: id 33, read fc 4 i32752, len 2, master device FinderEnergiezaehler, reading EnergieBezug (get EnergieBezug)

[StefanStrobel]

In dem Ausschnitt des Logs sieht man nur dass eine Anfrage vorbereitet wurde.
Der interessante Teil müsste danach kommen.

[R1F800]

In dem Ausschnitt des Logs sieht man nur dass eine Anfrage vorbereitet wurde.
Der interessante Teil müsste danach kommen.

Da kam aber nichts mehr ... das wundert mich auch.

[R1F800]

So, habe auch einnal die RS485 auf Verbose 5 gestellt.
bei einem GET reuqest ist das hier das LOG:

Code Auswählen Erweitern

request: id 33, read fc 4 i30181, len 1, master device FinderEnergiezaehler, reading FinderGeraetetemperatur (get FinderGeraetetemperatur), queued 5.01 secs ago, sent 5.01 secs ago
2024.10.31 14:39:17 4: FinderEnergiezaehler: get called with FinderGeraetetemperatur (i30181)
2024.10.31 14:39:17 5: FinderEnergiezaehler: GetSetChecks with force
2024.10.31 14:39:17 5: FinderEnergiezaehler: GetSetChecks returns success
2024.10.31 14:39:17 4: FinderEnergiezaehler: DoRequest called from GetLDFn created new request, read buffer empty,
request: id 33, read fc 4 i30181, len 1, master device FinderEnergiezaehler, reading FinderGeraetetemperatur (get FinderGeraetetemperatur)
2024.10.31 14:39:17 5: ModbusRS485: QueueRequest called from DoRequest with i30181, qlen 0 from master FinderEnergiezaehler through io device ModbusRS485
2024.10.31 14:39:17 5: ModbusRS485: ProcessRequestQueue called from QueueRequest as direct:ModbusRS485, qlen 1, force, request: request: id 33, read fc 4 i30181, len 1, master device FinderEnergiezaehler, reading FinderGeraetetemperatur (get FinderGeraetetemperatur), queued 0.00 secs ago
2024.10.31 14:39:17 5: ModbusRS485: checkDelays commDelay, last communication with same device was never, required delay is 0.5
2024.10.31 14:39:17 5: ModbusRS485: checkDelays busDelayRead is not required
2024.10.31 14:39:17 5: ModbusRS485: checkDelays sendDelay, last send to same device was 75.477 secs ago, required delay is 0.1
2024.10.31 14:39:17 5: ModbusRS485: checkDelays clientSwitchDelay is not relevant
2024.10.31 14:39:17 4: ModbusRS485: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 1, sending 210475e500013d51 via /dev/ttyUSB0@19200,8,N,2, read buffer empty,
request: id 33, read fc 4 i30181, len 1, master device FinderEnergiezaehler, reading FinderGeraetetemperatur (get FinderGeraetetemperatur), queued 0.01 secs ago
2024.10.31 14:39:17 5: ModbusRS485: Send called from ProcessRequestQueue
2024.10.31 14:39:17 5: DevIo_SimpleWrite ModbusRS485: 210475e500013d51
2024.10.31 14:39:17 5: ModbusRS485: ReadAnswer called from GetLDFn
2024.10.31 14:39:17 5: ModbusRS485: ReadAnswer remaining timeout is 4.99415111541748
2024.10.31 14:39:22 3: ModbusRS485: Timeout in Readanswer, read buffer empty,
request: id 33, read fc 4 i30181, len 1, master device FinderEnergiezaehler, reading FinderGeraetetemperatur (get FinderGeraetetemperatur), queued 5.01 secs ago, sent 5.01 secs ago


[StefanStrobel]

Dein Zähler antwortet nicht. Bist Du sicher dass die 19200,8,N,2 stimmen?

Gruß
  Stefan

[R1F800]

Dein Zähler antwortet nicht. Bist Du sicher dass die 19200,8,N,2 stimmen?

Gruß
  Stefan

Ehm es steht so im Datenblatt
Speed 1200 - 115200   Default 19200
Frame 8 N 2

vielleicht packt die Leitung die Geschwindigkeit nicht?

[R1F800]

Habe die Parameter mal auf beiden Seiten auf 8 E 2 angepasst ... leider auch kein Erfolg

[Prof. Dr. Peter Henning]

Speed 1200 - 115200   Default 19200

Dann würde ich doch mal langsam bei 1200 anfangen und mich hocharbeiten...

LG

pah

[R1F800]

Speed 1200 - 115200   Default 19200

Dann würde ich doch mal langsam bei 1200 anfangen und mich hocharbeiten...

LG

pah

Hm. vielleicht lese ich das falsch, aber warum schreibt mir das LOG immer etwas von READ BUFFER empty? Kommen keine Daten im PI an? (TIMEOUT?)

Code Auswählen Erweitern

2024.11.05 13:41:18 5: FinderEnergiezaehler: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active
2024.11.05 13:41:18 5: FinderEnergiezaehler: UpdateSetList: getList=FinderGeraetetemperatur:noArg EnergieBezug:noArg EnergieEinspeisung:noArg
2024.11.05 13:41:45 5: FinderEnergiezaehler: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active
2024.11.05 13:41:45 5: FinderEnergiezaehler: UpdateSetList: getList=FinderGeraetetemperatur:noArg EnergieBezug:noArg EnergieEinspeisung:noArg
2024.11.05 13:41:51 1: RMDIR: ./restoreDir/save/2024-11-02
2024.11.05 13:41:55 4: FinderEnergiezaehler: get called with EnergieBezug (h32752)
2024.11.05 13:41:55 5: FinderEnergiezaehler: GetSetChecks with force
2024.11.05 13:41:55 5: FinderEnergiezaehler: GetSetChecks returns success
2024.11.05 13:41:55 4: FinderEnergiezaehler: DoRequest called from GetLDFn created new request, read buffer empty,
request: id 33, read fc 3 h32752, len 2, master device FinderEnergiezaehler, reading EnergieBezug (get EnergieBezug)
2024.11.05 13:41:55 5: ModbusRS485: QueueRequest called from DoRequest with h32752, qlen 0 from master FinderEnergiezaehler through io device ModbusRS485
2024.11.05 13:41:55 5: ModbusRS485: ProcessRequestQueue called from QueueRequest as direct:ModbusRS485, qlen 1, force, request: request: id 33, read fc 3 h32752, len 2, master device FinderEnergiezaehler, reading EnergieBezug (get EnergieBezug), queued 0.00 secs ago
2024.11.05 13:41:55 5: ModbusRS485: checkDelays commDelay, last communication with same device was never, required delay is 0.5
2024.11.05 13:41:55 5: ModbusRS485: checkDelays clientSwitchDelay is not relevant
2024.11.05 13:41:55 5: ModbusRS485: checkDelays busDelayRead is not required
2024.11.05 13:41:55 5: ModbusRS485: checkDelays sendDelay, last send to same device was never, required delay is 0.1
2024.11.05 13:41:55 4: ModbusRS485: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 1, sending 21037ff00002da8c via /dev/ttyUSB0@19200,8,E,2, read buffer empty,
request: id 33, read fc 3 h32752, len 2, master device FinderEnergiezaehler, reading EnergieBezug (get EnergieBezug), queued 0.00 secs ago
2024.11.05 13:41:55 5: ModbusRS485: Send called from ProcessRequestQueue
2024.11.05 13:41:55 5: DevIo_SimpleWrite ModbusRS485: 21037ff00002da8c
2024.11.05 13:41:55 5: ModbusRS485: ReadAnswer called from GetLDFn
2024.11.05 13:41:55 5: ModbusRS485: ReadAnswer remaining timeout is 4.99391794204712
2024.11.05 13:42:00 3: ModbusRS485: Timeout in Readanswer, read buffer empty,
request: id 33, read fc 3 h32752, len 2, master device FinderEnergiezaehler, reading EnergieBezug (get EnergieBezug), queued 5.01 secs ago, sent 5.01 secs ago

Ich drehe mal das Speed auf Schneckentempo auf beiden Seiten. Dann schauen wir mal ...

[R1F800]

@

Speed 1200 - 115200   Default 19200

Dann würde ich doch mal langsam bei 1200 anfangen und mich hocharbeiten...

LG

pah

Also an der Geschwindigkeit liegt es nicht. 2400bps und gleiches Ergebnis.

[Prof. Dr. Peter Henning]

Hmm...

Es _könnte_ noch sein, dass das daran liegt:

der RS485 ist zwar nicht via USB sonder via HAT über UART angeklemmt, aber das sollte ja kein Problem sein.

Auf dem Raspberry Pi wird der interne serielle Port in der Software emuliert, das ist keine Hardware-Lösung. Als ich vor etlichen Jahren das erste EBUS-Interface für den RPI entworfen habe, hat dies massive Probleme bereitet. Das ging EBEN NICHT über UART, weil dabei durch die Emulation Latenzen eingefügt wurden, die nicht beherrschbar waren.

Ich habe keine Ahnung, ob das bei aufgestecktem HAT auch noch der Fall ist. Könnte ich mir als misstrauischer Mensch aber durchaus vorstellen.

Vlt. mal probieren, ob das bei einem Anschluss über USB besser ist.

LG

pah

[Aurel_B]

Kurz zur Hardware: Ich habe seit > 2 Jahren drei von diesen im Einsatz: https://www.waveshare.com/product/iot-communication/wired-comm-converter/rs232-rs485-can-dali2/usb-to-rs232-485-ttl-kl.htm (die waren mal viel günstiger bei ca. 20$!), funktionierten in dieser Zeit absolut problemlos an meinem RasPi und jetzt an meinem Mini-PC.

[R1F800]

Ich muss mal schauen, ob ich hier noch einen USB RS485 rumfliegen habe.
Das wäre natürlich schon der Hammer.

Aktuell montiert
Zihatec RS485 hat


und den hier habe ich bestellt.:
Waveshare
I´ll be back

vG
Ingo

[jumpman_junior]

Hallo zusammen, ich habe einen Finder 7m.38 eingebaut und lese den mit einem USB-RS485 (4- EUR aus der Bucht) Adapter aus. Der Port ist mittels ser2net weitergeleitet.
In der Modbus Spec vom E-Meter sind die Input Register mit einem 30000er Prefix aufgeführt. Der muss weggelassen werden und Offset 1 von der Registeradresse abziehen. Das passt dann zumindest bei mir.
Wenn man 32xxx abfragt, kommt nur out of range zurück.

Meine device Config sieht so aus:

Code Auswählen Erweitern

defmod ABLMeter ModbusAttr 33 10 remote-host:20002 RTU
attr ABLMeter DbLogExclude .*
attr ABLMeter dev-type-FL32-len 2
attr ABLMeter dev-type-FL32-revRegs 1
attr ABLMeter dev-type-FL32-unpack f>
attr ABLMeter disable 0
attr ABLMeter obj-i2479-format %.2f
attr ABLMeter obj-i2479-poll 1
attr ABLMeter obj-i2479-reading Runtime
attr ABLMeter obj-i2479-type FL32
attr ABLMeter obj-i2489-format %.2f
attr ABLMeter obj-i2489-poll 1
attr ABLMeter obj-i2489-reading ActivePowerTotal
attr ABLMeter obj-i2489-type FL32
attr ABLMeter obj-i2491-format %.2f
attr ABLMeter obj-i2491-poll 1
attr ABLMeter obj-i2491-reading ReactivePowerTotal
attr ABLMeter obj-i2491-type FL32
attr ABLMeter obj-i2493-format %.2f
attr ABLMeter obj-i2493-poll 1
attr ABLMeter obj-i2493-reading ApparentPowerTotal
attr ABLMeter obj-i2493-type FL32
attr ABLMeter obj-i2495-format %.2f
attr ABLMeter obj-i2495-poll 1
attr ABLMeter obj-i2495-reading PowerFactorTotal
attr ABLMeter obj-i2495-type FL32
attr ABLMeter obj-i2497-format %.2f
attr ABLMeter obj-i2497-poll 1
attr ABLMeter obj-i2497-reading Frequency
attr ABLMeter obj-i2497-type FL32
attr ABLMeter obj-i2499-format %.2f
attr ABLMeter obj-i2499-poll 1
attr ABLMeter obj-i2499-reading U1
attr ABLMeter obj-i2499-type FL32
attr ABLMeter obj-i2501-format %.2f
attr ABLMeter obj-i2501-poll 1
attr ABLMeter obj-i2501-reading U2
attr ABLMeter obj-i2501-type FL32
attr ABLMeter obj-i2503-format %.2f
attr ABLMeter obj-i2503-poll 1
attr ABLMeter obj-i2503-reading U3
attr ABLMeter obj-i2503-type FL32
attr ABLMeter obj-i2515-format %.2f
attr ABLMeter obj-i2515-poll 1
attr ABLMeter obj-i2515-reading I1
attr ABLMeter obj-i2515-type FL32
attr ABLMeter obj-i2517-format %.2f
attr ABLMeter obj-i2517-poll 1
attr ABLMeter obj-i2517-reading I2
attr ABLMeter obj-i2517-type FL32
attr ABLMeter obj-i2519-format %.2f
attr ABLMeter obj-i2519-poll 1
attr ABLMeter obj-i2519-reading I3
attr ABLMeter obj-i2519-type FL32
attr ABLMeter obj-i2529-format %.2f
attr ABLMeter obj-i2529-poll 1
attr ABLMeter obj-i2529-reading ActivePowerL1
attr ABLMeter obj-i2529-type FL32
attr ABLMeter obj-i2531-format %.2f
attr ABLMeter obj-i2531-poll 1
attr ABLMeter obj-i2531-reading ActivePowerL2
attr ABLMeter obj-i2531-type FL32
attr ABLMeter obj-i2533-format %.2f
attr ABLMeter obj-i2533-poll 1
attr ABLMeter obj-i2533-reading ActivePowerL3
attr ABLMeter obj-i2533-type FL32
attr ABLMeter obj-i2535-format %.2f
attr ABLMeter obj-i2535-poll 1
attr ABLMeter obj-i2535-reading ActivePowerLges
attr ABLMeter obj-i2535-type FL32
attr ABLMeter obj-i2537-format %.2f
attr ABLMeter obj-i2537-poll 1
attr ABLMeter obj-i2537-reading ReactivePowerL1
attr ABLMeter obj-i2537-type FL32
attr ABLMeter obj-i2539-format %.2f
attr ABLMeter obj-i2539-poll 1
attr ABLMeter obj-i2539-reading ReactivePowerL2
attr ABLMeter obj-i2539-type FL32
attr ABLMeter obj-i2541-format %.2f
attr ABLMeter obj-i2541-poll 1
attr ABLMeter obj-i2541-reading ReactivePowerL3
attr ABLMeter obj-i2541-type FL32
attr ABLMeter obj-i2543-format %.2f
attr ABLMeter obj-i2543-poll 1
attr ABLMeter obj-i2543-reading ReactivePowerLges
attr ABLMeter obj-i2543-type FL32
attr ABLMeter obj-i2545-format %.2f
attr ABLMeter obj-i2545-poll 1
attr ABLMeter obj-i2545-reading ApparentPowerL1
attr ABLMeter obj-i2545-type FL32
attr ABLMeter obj-i2547-format %.2f
attr ABLMeter obj-i2547-poll 1
attr ABLMeter obj-i2547-reading ApparentPowerL2
attr ABLMeter obj-i2547-type FL32
attr ABLMeter obj-i2549-format %.2f
attr ABLMeter obj-i2549-poll 1
attr ABLMeter obj-i2549-reading ApparentPowerL3
attr ABLMeter obj-i2549-type FL32
attr ABLMeter obj-i2551-format %.2f
attr ABLMeter obj-i2551-poll 1
attr ABLMeter obj-i2551-reading ApparentPowerLges
attr ABLMeter obj-i2551-type FL32
attr ABLMeter obj-i2553-format %.2f
attr ABLMeter obj-i2553-poll 1
attr ABLMeter obj-i2553-reading PowerFactorL1
attr ABLMeter obj-i2553-type FL32
attr ABLMeter obj-i2555-format %.2f
attr ABLMeter obj-i2555-poll 1
attr ABLMeter obj-i2555-reading PowerFactorL2
attr ABLMeter obj-i2555-type FL32
attr ABLMeter obj-i2557-format %.2f
attr ABLMeter obj-i2557-poll 1
attr ABLMeter obj-i2557-reading PowerFactorL3
attr ABLMeter obj-i2557-type FL32
attr ABLMeter obj-i2559-format %.2f
attr ABLMeter obj-i2559-poll 1
attr ABLMeter obj-i2559-reading PowerFactorLges
attr ABLMeter obj-i2559-type FL32
attr ABLMeter obj-i2583-format %.2f
attr ABLMeter obj-i2583-poll 1
attr ABLMeter obj-i2583-reading Frequency_2
attr ABLMeter obj-i2583-type FL32
attr ABLMeter obj-i2637-format %.2f
attr ABLMeter obj-i2637-poll 1
attr ABLMeter obj-i2637-reading EnergyCount_1
attr ABLMeter obj-i2637-type FL32
attr ABLMeter obj-i2639-format %.2f
attr ABLMeter obj-i2639-poll 1
attr ABLMeter obj-i2639-reading EnergyCount_2

Hope it helps

[R1F800]

So, ich habe nun den USB RS485 am PI laufen, den HAT entfernt ... jetzt kommt überhaupt einmal eine Kommunikation.

Nicht das was ich erhofft hatte, aber nun muss ich mal weiter schauen.

Das Ergebnis :

Code Auswählen Erweitern

2024.12.29 12:35:46 4: FinderEnergiezaehler: get called with EnergieBezug (h32752)
2024.12.29 12:35:46 5: FinderEnergiezaehler: CheckDisable called from GetSetChecks returns device is disabled
2024.12.29 12:35:46 5: FinderEnergiezaehler: GetSetChecks returns device is disabled
2024.12.29 12:35:59 4: FinderEnergiezaehler: get called with EnergieEinspeisung (h32754)
2024.12.29 12:35:59 5: FinderEnergiezaehler: CheckDisable called from GetSetChecks returns device is disabled
2024.12.29 12:35:59 5: FinderEnergiezaehler: GetSetChecks returns device is disabled
bei der CONFIG:

Code Auswählen Erweitern

defmod FinderEnergiezaehler ModbusAttr 33 0 RTU
attr FinderEnergiezaehler alias Finder Zweirichtungs Zähler
attr FinderEnergiezaehler comment Finder 7M.38
attr FinderEnergiezaehler dev-h-defLen 1
attr FinderEnergiezaehler dev-h-defPoll 1
attr FinderEnergiezaehler dev-h-read 3
attr FinderEnergiezaehler dev-timing-commDelay 0.5
attr FinderEnergiezaehler dev-timing-timeout 5
attr FinderEnergiezaehler disable 1
attr FinderEnergiezaehler enableControlSet 1
attr FinderEnergiezaehler event-on-change-reading .*
attr FinderEnergiezaehler icon stromzaehler_icon@green
attr FinderEnergiezaehler obj-h30181-len 1
attr FinderEnergiezaehler obj-h30181-reading FinderGeraetetemperatur
attr FinderEnergiezaehler obj-h30181-showGet 1
attr FinderEnergiezaehler obj-h30181-type signed short little
attr FinderEnergiezaehler obj-h32752-len 2
attr FinderEnergiezaehler obj-h32752-reading EnergieBezug
attr FinderEnergiezaehler obj-h32752-showGet 1
attr FinderEnergiezaehler obj-h32752-type unsigned long little
attr FinderEnergiezaehler obj-h32752-unpack f>
attr FinderEnergiezaehler obj-h32754-len 2
attr FinderEnergiezaehler obj-h32754-reading EnergieEinspeisung
attr FinderEnergiezaehler obj-h32754-showGet 1
attr FinderEnergiezaehler obj-h32754-type unsigned long little
attr FinderEnergiezaehler obj-h32754-unpack f>
attr FinderEnergiezaehler room interfaces
attr FinderEnergiezaehler verbose 5
attr FinderEnergiezaehler webCmd reread
NACH setzen auf DIASABLE 0 > erhalte ich TIMEOUTS


____________________________________________________________________________________

Jetzt habe ich einmal den Hinweis Jumpmen eingepflegt.

Code Auswählen Erweitern

2024.12.29 14:41:27 5: ModbusRS485: ProcessRequestQueue called from Fhem internal timer as queue:ModbusRS485, qlen 1, request: request: id 33, read fc 4 i2503, len 2, master device FinderEnergiezaehler, reading U3 (getUpdate for U3 len 2), queued 3.02 secs ago
2024.12.29 14:41:27 5: ModbusRS485: ProcessRequestQueue will return, Fhem is still waiting for response, read buffer empty,
request: id 33, read fc 4 i2501, len 2, master device FinderEnergiezaehler, reading U2 (getUpdate for U2 len 2), queued 3.03 secs ago, sent 1.01 secs ago, qlen 1, try again in 1 seconds
2024.12.29 14:41:27 5: ModbusRS485: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2024.12.29 14:41:28 3: ModbusRS485: Timeout waiting for a modbus response, read buffer empty,
request: id 33, read fc 4 i2501, len 2, master device FinderEnergiezaehler, reading U2 (getUpdate for U2 len 2), queued 4.02 secs ago, sent 2.00 secs ago
2024.12.29 14:41:28 5: ModbusRS485: StartQueueTimer called from ResponseTimeout sets internal timer to process queue in 0.000 seconds
2024.12.29 14:41:28 5: ModbusRS485: ProcessRequestQueue called from Fhem internal timer as queue:ModbusRS485, qlen 1, request: request: id 33, read fc 4 i2503, len 2, master device FinderEnergiezaehler, reading U3 (getUpdate for U3 len 2), queued 4.02 secs ago
2024.12.29 14:41:28 5: ModbusRS485: checkDelays sendDelay, last send to same device was 2.001 secs ago, required delay is 0.1
2024.12.29 14:41:28 5: ModbusRS485: checkDelays busDelayRead is not required
2024.12.29 14:41:28 5: ModbusRS485: checkDelays clientSwitchDelay is not relevant
2024.12.29 14:41:28 5: ModbusRS485: checkDelays commDelay, last communication with same device was never, required delay is 0.1
2024.12.29 14:41:28 4: ModbusRS485: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 1, sending 210409c70002c4ca via /dev/ttyUSB0@9600,8,E,2, read buffer empty,
request: id 33, read fc 4 i2503, len 2, master device FinderEnergiezaehler, reading U3 (getUpdate for U3 len 2), queued 4.03 secs ago
2024.12.29 14:41:28 5: ModbusRS485: Send called from ProcessRequestQueue
2024.12.29 14:41:28 5: DevIo_SimpleWrite ModbusRS485: 210409c70002c4ca
2024.12.29 14:41:30 3: ModbusRS485: Timeout waiting for a modbus response, read buffer empty,
request: id 33, read fc 4 i2503, len 2, master device FinderEnergiezaehler, reading U3 (getUpdate for U3 len 2), queued 6.03 secs ago, sent 2.00 secs ago
2024.12.29 14:41:34 5: ModbusRS485: QueueRequest called from DoRequest with i2499, qlen 0 from master FinderEnergiezaehler through io device ModbusRS485
2024.12.29 14:41:34 5: ModbusRS485: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2024.12.29 14:41:34 5: ModbusRS485: QueueRequest called from DoRequest with i2501, qlen 1 from master FinderEnergiezaehler through io device ModbusRS485
2024.12.29 14:41:34 5: ModbusRS485: QueueRequest called from DoRequest with i2503, qlen 2 from master FinderEnergiezaehler through io device ModbusRS485
2024.12.29 14:41:34 5: ModbusRS485: ProcessRequestQueue called from Fhem internal timer as queue:ModbusRS485, qlen 3, request: request: id 33, read fc 4 i2499, len 2, master device FinderEnergiezaehler, reading U1 (getUpdate for U1 len 2), queued 0.01 secs ago
2024.12.29 14:41:34 5: ModbusRS485: checkDelays sendDelay, last send to same device was 5.971 secs ago, required delay is 0.1
2024.12.29 14:41:34 5: ModbusRS485: checkDelays busDelayRead is not required
2024.12.29 14:41:34 5: ModbusRS485: checkDelays clientSwitchDelay is not relevant
2024.12.29 14:41:34 5: ModbusRS485: checkDelays commDelay, last communication with same device was never, required delay is 0.1
2024.12.29 14:41:34 4: ModbusRS485: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 3, sending 210409c30002850b via /dev/ttyUSB0@9600,8,E,2, read buffer empty,
request: id 33, read fc 4 i2499, len 2, master device FinderEnergiezaehler, reading U1 (getUpdate for U1 len 2), queued 0.01 secs ago
2024.12.29 14:41:34 5: ModbusRS485: Send called from ProcessRequestQueue
2024.12.29 14:41:34 5: DevIo_SimpleWrite ModbusRS485: 210409c30002850b
2024.12.29 14:41:34 5: ModbusRS485: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2024.12.29 14:41:35 5: ModbusRS485: ProcessRequestQueue called from Fhem internal timer as queue:ModbusRS485, qlen 2, request: request: id 33, read fc 4 i2501, len 2, master device FinderEnergiezaehler, reading U2 (getUpdate for U2 len 2), queued 1.02 secs ago
2024.12.29 14:41:35 5: ModbusRS485: ProcessRequestQueue will return, Fhem is still waiting for response, read buffer empty,
request: id 33, read fc 4 i2499, len 2, master device FinderEnergiezaehler, reading U1 (getUpdate for U1 len 2), queued 1.02 secs ago, sent 1.01 secs ago, qlen 2, try again in 1 seconds
2024.12.29 14:41:35 5: ModbusRS485: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2024.12.29 14:41:36 3: ModbusRS485: Timeout waiting for a modbus response, read buffer empty,
request: id 33, read fc 4 i2499, len 2, master device FinderEnergiezaehler, reading U1 (getUpdate for U1 len 2), queued 2.01 secs ago, sent 2.00 secs ago
2024.12.29 14:41:36 5: ModbusRS485: StartQueueTimer called from ResponseTimeout sets internal timer to process queue in 0.000 seconds
2024.12.29 14:41:36 5: ModbusRS485: ProcessRequestQueue called from Fhem internal timer as queue:ModbusRS485, qlen 2, request: request: id 33, read fc 4 i2501, len 2, master device FinderEnergiezaehler, reading U2 (getUpdate for U2 len 2), queued 2.01 secs ago
2024.12.29 14:41:36 5: ModbusRS485: checkDelays clientSwitchDelay is not relevant
2024.12.29 14:41:36 5: ModbusRS485: checkDelays commDelay, last communication with same device was never, required delay is 0.1
2024.12.29 14:41:36 5: ModbusRS485: checkDelays sendDelay, last send to same device was 2.002 secs ago, required delay is 0.1
2024.12.29 14:41:36 5: ModbusRS485: checkDelays busDelayRead is not required
2024.12.29 14:41:36 4: ModbusRS485: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 2, sending 210409c50002650a via /dev/ttyUSB0@9600,8,E,2, read buffer empty,
request: id 33, read fc 4 i2501, len 2, master device FinderEnergiezaehler, reading U2 (getUpdate for U2 len 2), queued 2.02 secs ago
2024.12.29 14:41:36 5: ModbusRS485: Send called from ProcessRequestQueue
2024.12.29 14:41:36 5: DevIo_SimpleWrite ModbusRS485: 210409c50002650a
2024.12.29 14:41:36 5: ModbusRS485: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2024.12.29 14:41:36 1: OWX_Discover: 1-Wire devices found on bus OneWireFRM (OWX_28_F3E979970403)
2024.12.29 14:41:42 5: ModbusRS485: ProcessRequestQueue called from Fhem internal timer as queue:ModbusRS485, qlen 1, request: request: id 33, read fc 4 i2503, len 2, master device FinderEnergiezaehler, reading U3 (getUpdate for U3 len 2), queued 7.98 secs ago
2024.12.29 14:41:42 5: ModbusRS485: ProcessRequestQueue will return, Fhem is still waiting for response, read buffer empty,
request: id 33, read fc 4 i2501, len 2, master device FinderEnergiezaehler, reading U2 (getUpdate for U2 len 2), queued 7.99 secs ago, sent 5.97 secs ago, qlen 1, try again in 1 seconds
2024.12.29 14:41:42 5: ModbusRS485: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2024.12.29 14:41:42 3: ModbusRS485: Timeout waiting for a modbus response, read buffer empty,
request: id 33, read fc 4 i2501, len 2, master device FinderEnergiezaehler, reading U2 (getUpdate for U2 len 2), queued 7.99 secs ago, sent 5.97 secs ago
2024.12.29 14:41:42 5: ModbusRS485: StartQueueTimer called from ResponseTimeout sets internal timer to process queue in 0.000 seconds
2024.12.29 14:41:42 5: ModbusRS485: ProcessRequestQueue called from Fhem internal timer as queue:ModbusRS485, qlen 1, request: request: id 33, read fc 4 i2503, len 2, master device FinderEnergiezaehler, reading U3 (getUpdate for U3 len 2), queued 7.99 secs ago
2024.12.29 14:41:42 5: ModbusRS485: checkDelays clientSwitchDelay is not relevant
2024.12.29 14:41:42 5: ModbusRS485: checkDelays commDelay, last communication with same device was never, required delay is 0.1
2024.12.29 14:41:42 5: ModbusRS485: checkDelays sendDelay, last send to same device was 5.972 secs ago, required delay is 0.1
2024.12.29 14:41:42 5: ModbusRS485: checkDelays busDelayRead is not required
2024.12.29 14:41:42 4: ModbusRS485: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 1, sending 210409c70002c4ca via /dev/ttyUSB0@9600,8,E,2, read buffer empty,
request: id 33, read fc 4 i2503, len 2, master device FinderEnergiezaehler, reading U3 (getUpdate for U3 len 2), queued 7.99 secs ago
2024.12.29 14:41:42 5: ModbusRS485: Send called from ProcessRequestQueue
2024.12.29 14:41:42 5: DevIo_SimpleWrite ModbusRS485: 210409c70002c4ca

ABER Readings habe ich immer noch nicht.

Code Auswählen Erweitern

2024.12.29 14:47:17 4: FinderEnergiezaehler: GetUpdate (V4.5.6 - 7.11.2023) called from Fhem internal timer
2024.12.29 14:47:17 4: FinderEnergiezaehler: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 10.0 sec at 14:47:27.799, interval 10
2024.12.29 14:47:17 5: FinderEnergiezaehler: CreateUpdateHash full object list: i2499 i2501 i2503
2024.12.29 14:47:17 5: FinderEnergiezaehler: CreateUpdateHash will request i2499 len 2 U1
2024.12.29 14:47:17 5: FinderEnergiezaehler: CreateUpdateHash will request i2501 len 2 U2
2024.12.29 14:47:17 5: FinderEnergiezaehler: CreateUpdateHash will request i2503 len 2 U3
2024.12.29 14:47:17 4: FinderEnergiezaehler: CombineUpdateHash objHash keys before combine: i2499,i2501,i2503
2024.12.29 14:47:17 5: FinderEnergiezaehler: CombineUpdateHash tries to combine read commands
2024.12.29 14:47:17 5: FinderEnergiezaehler: CombineUpdateHash keys are now i2499,i2501,i2503
2024.12.29 14:47:17 4: FinderEnergiezaehler: GetUpdate will now create requests for i2499 len 2 (U1), i2501 len 2 (U2), i2503 len 2 (U3)
2024.12.29 14:47:17 4: FinderEnergiezaehler: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 33, read fc 4 i2499, len 2, master device FinderEnergiezaehler, reading U1 (getUpdate for U1 len 2)
2024.12.29 14:47:17 4: FinderEnergiezaehler: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 33, read fc 4 i2501, len 2, master device FinderEnergiezaehler, reading U2 (getUpdate for U2 len 2)
2024.12.29 14:47:17 4: FinderEnergiezaehler: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 33, read fc 4 i2503, len 2, master device FinderEnergiezaehler, reading U3 (getUpdate for U3 len 2)

[jumpman_junior]

Hallo und ein frohes neues Jahr,

ich denke, am besten gehen wir eins nach dem anderen an, um die verschiedenen Fehlerquellen ausfindig zu machen.

Ich habe einen Finder 7M.38 212   (das ist der Typ mit dem Modbus interface) eingebaut, also in die Verkabelung der Wallbox eingeschleift.
Nach dem Einschalten muss man auf jeden Fall die Anschlussart an dem E-Meter einstellen, das war bei mir 3L+N (ist die Voreinstellung).
Laut Datenblatt kann diese Einstellung genau 1x vorgenommen werden, muss aber in jedem Fall durchgefuehrt werden.
Die Modbuseinstellungen habe ich nicht verändert.
Beim Modbus habe ich nur die beiden Datenleitungen mit einem Modbus USB Adapter verbunden. Dabei A auf D+ und B auf D-.
Man kann den Schirm einseitig auf Masse legen, aber am Raspberry würde ich das nicht machen, sondern höchstens am E-Meter. Das habe ich aber auch nicht gemacht.
Abschlusswiderstände habe ich keine verbaut, mein Kabel ist nur 5 Meter lang und es hat direkt ohne die Terminatoren funktioniert.

Der von mir erwähnte Modbus Billig-Adapter hat übrigens nach 2 Wochen den Geist aufgegeben und der zweite davon ist auch alle paar Tage abgestürzt.

Wer billig kauft, kauft häufig zweimal, wie wahr.

Nach der Verdrahtung kam der Test. Der Adapter in den Raspi und schauen ob er erkannt wird. 'dmesg' bzw. 'ls -l /dev/serial/by-i*' zeigen an,
ob und wieviele serielle Schnittstellen erkannt wurden und ob es vielleicht hier schon Probleme gibt.
Das sieht bei mir so aus

dmesg:

Code Auswählen Erweitern

[69442.474106] usb 1-1.2.1: USB disconnect, device number 12
[69442.489907] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[69442.490116] ftdi_sio 1-1.2.1:1.0: device disconnected
[69502.419946] usb 1-1.2.3: new full-speed USB device number 13 using dwc_otg
[69502.577703] usb 1-1.2.3: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[69502.577776] usb 1-1.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[69502.577808] usb 1-1.2.3: Product: USB  to RS485 Cable
[69502.577836] usb 1-1.2.3: Manufacturer: FTDI
[69502.577860] usb 1-1.2.3: SerialNumber: Di95HQCE
[69502.600521] ftdi_sio 1-1.2.3:1.0: FTDI USB Serial Device converter detected
[69502.600897] usb 1-1.2.3: Detected FT232R
[69502.606974] usb 1-1.2.3: FTDI USB Serial Device converter now attached to ttyUSB1

ls -l /dev/serial/by-id*:

Code Auswählen Erweitern

pi@rpi1-teko:~/modpoll $ ls -l /dev/serial/by-i*
total 0
lrwxrwxrwx 1 root root 13 Dec 28 10:18 usb-1a86_USB2.0-Ser_-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Dec 28 10:18 usb-1a86_USB_Serial-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 Dec 28 11:00 usb-FTDI_USB_to_RS485_Cable_Di95HQCE-if00-port0 -> ../../ttyUSB1

Die anderen beiden Adapter sind ein weiterer Modbus Adapter (zur Wallbox selbst) und ein Arduino Nano mit 5 1-Wire Sensoren. ttyUSB1 ist der um den es geht.


Als Test-Tool habe ich modpoll verwendet (https://www.modbusdriver.com/modpoll.html), das tgz file habe ich auf den Raspi kopiert und dann ausgepackt.
Das Binary ist für einige Architekturen dabei, beim Raspi 1 ist es 'armv6-rpi-linux-gnueabihf'.
Mit modpoll kann man genau ein Register 1x abfragen, ich habe damit ausprobiert ob die Kommunikation läuft.

Code Auswählen Erweitern

./modpoll -m rtu -a 33 -r 2940 -t 3:f32 -1 -b 19200 -d 8 -s 2 -p none /dev/ttyUSB1

Code Auswählen Erweitern

-m rtu > Modbus RTU
-a 33 > Device Adresse
-r 2498 > Register 32498, Frequenz
-t 3:f32 > 32-bit float data type in input register table (FC4)
-1 > Einmal lesen
-b 19200 > 19200 Baud
-d 8 > 8 Data bits
-s 2 > 2 Stopbits
-p none > Keine Parity
/dev/ttyUSB1 > Serial device

Damit kommen dann Antworten bzw wenn Timeouts gemeldet werden krankt es schon an den Basics. Beim Register 32498 kam ein Out of range.


Ich habe dann den Adapter per ser2net ins Netz gehoben, der betreffende Teil der ser2net.yaml sieht so aus:

Code Auswählen Erweitern

connection: &wallboxmeter
    accepter: tcp,20002
    connector: serialdev,/dev/serial/by-id/usb-FTDI_USB_to_RS485_Cable_Di95HQCE-if00-port0,19200n82,local
    options:
      kickolduser: true

Das wird noch relevant werden für die Definition des Modbus devices in Fhem.


Hat Fhem direkten zugriff auf den Adapter, sollte man laut Wiki ein IO-Device definieren und dann einen Modbus master.
Hier wäre das theoretisch

Code Auswählen Erweitern

define finderio Modbus /dev/serial/by-id/usb-FTDI_USB_to_RS485_Cable_Di95HQCE-if00-port0@19200,8,N,2
define FinderMeter ModbusAttr 33 10 RTU

Das habe ich nicht ausprobiert (Fhem läuft bei mir auf einem anderen Rechner), nehme aber an, dass beim device 'FinderMeter' das Internal IODev auf 'finderio' sitzen muss, damit es klappt.
Die seriellen Parameter sind in der ersten Zeile die Modbus Adresse beim Master.

Mit der Verwendung von ser2net sieht es dann so aus:

Code Auswählen Erweitern

define FinderMeter ModbusAttr 33 10 rpi1-teko:20002 RTU
rpi1-teko ist der Host wo ser2net läuft, 20002 ist der Port aus der ser2net.yaml.

Bei mir ist es nochmal anders, da der Meter zuerst von EVCC verarbeitet wird und EVCC den wiederum als Modbusproxy zur Verfügung stellt.
Deswegen sieht es bei mir so aus:

Code Auswählen Erweitern

define FinderMeter ModbusAttr 33 10 evcc:2502 TCP
evcc ist der docker container von evcc, 2502 der Port an dem evcc den Proxy bereit stellt.

TCP deswegen, weil evcc beim Proxy nur Modbus TCP unterstützt und intern konvertiert.

Um das Register 2498 (das einen 32 Bit Float enthält zu lesen) habe ich diese Attribute angelegt - man beachte den Offset um 1:

Code Auswählen Erweitern

attr FinderMeter dev-type-FL32-len 2
attr FinderMeter dev-type-FL32-revRegs 1
attr FinderMeter dev-type-FL32-unpack f>

attr FinderMeter obj-i2497-format %.2f
attr FinderMeter obj-i2497-poll 1
attr FinderMeter obj-i2497-reading Frequency
attr FinderMeter obj-i2497-type FL32

Der erste Teil ist nur einmal nötig. Die Attribute bleiben gleich, egal wie die device definition aussieht.

Erst wenn das soweit klappt, macht es mM Sinn mehr Register zu definieren.

Hoffe das hilft weiter.

[R1F800]

Hm. Das "neue" USB Device wird mir als RS232 angezeigt.

Code Auswählen Erweitern

lrwxrwxrwx 1 root root 13 Dez 29 12:27 usb-FTDI_FT232R_USB_UART_B0036AGF-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Dez 29 12:27 usb-SHA_CUL433-if00-port0 -> ../../ttyUSB1

Fhem läuft auf meinem PI in der Zählertafel, und das Finder 7M.38 sitzt 10cm daneben.
Beide Seiten ist der Schirm aufgelegt.

ModBus Interface def:

Code Auswählen Erweitern

defmod ModbusRS485 Modbus /dev/ttyUSB0@9600,8,E,2


setstate ModbusRS485 opened
setstate ModbusRS485 2024-12-29 14:41:14 state opened

Und Testweise dann die ModBusAttr:

Code Auswählen Erweitern

defmod FinderEnergiezaehler ModbusAttr 33 10 RTU
attr FinderEnergiezaehler alias Finder Zweirichtungs Zähler
attr FinderEnergiezaehler comment Finder 7M.38
attr FinderEnergiezaehler dev-type-FL32-len 2
attr FinderEnergiezaehler dev-type-FL32-revRegs 1
attr FinderEnergiezaehler dev-type-FL32-unpack f>
attr FinderEnergiezaehler disable 0
attr FinderEnergiezaehler icon measure_power@green
attr FinderEnergiezaehler obj-i2499-format %.2f
attr FinderEnergiezaehler obj-i2499-poll 1
attr FinderEnergiezaehler obj-i2499-reading U1
Der Theorie nach sollte da eigentlich was ordentliches bei rumkommen ... ABER

Ich werde gleich mal die das genannte Testtool probieren ..

[Prof. Dr. Peter Henning]

Das "neue" USB Device wird mir als RS232 angezeigt.

Nein. Es wird als FTDI_FT232R_USB_UART angezeigt, das ist vollkommen korrekt.

LG

pah

[jumpman_junior]

defmod ModbusRS485 Modbus /dev/ttyUSB0@9600,8,E,2

Was für eine Schnittstelleneinstellung zeigt der Finder denn in seinem Menü an?
Ich hatte nichts geändert und die defaults waren 19200,8n2

[R1F800]

defmod ModbusRS485 Modbus /dev/ttyUSB0@9600,8,E,2

Was für eine Schnittstelleneinstellung zeigt der Finder den in seinem Menü an?
Ich hatte nichts geändert und die defaults waren 19200,8n2

Genau da lag das Problem  ... habe den Finder auf 9600 runtergedreht, und schon kamen die Daten :-/ 

[R1F800]

Moin.
So, nachdem ich nun mir das Ganze ein paar Tage angesehen habe musste ich heute feststellen, dass die Registerzum Auslesen scheinbar immer die gleichen Werte enthalten. WAS kann das sein?:

[jumpman_junior]

Hi,kann ich bei mir nicht bestätigen, wie sieht denn die Registerdefinition aus? Lesefehler im Log?