Auslesen FINDER RS485 Energie Zweirichtungszähler

[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?: