Jablotron JA-121T MODBUS

[Teemo]

Hallo, ich habe ein Problem mit dem Anschluss des Jablotron JA-121T.
Die Standardverbindung ist über die RS485-Schnittstelle, aber wir wollen es über Modbus tcp und ModbusAttr.pm-Modul tun, wir verwenden Waveshare RS485 TO ETH-Konverter für das. Hat jemand versucht, dieses Gerät über Modbus zu kommunizieren?

Gerätedefinition:

Code Auswählen Erweitern


defmod MODBUS1 ModbusAttr 1 0 <ip> TCP
attr MODBUS1 dev-timing-timeout 10
attr MODBUS1 obj-h1-len 60
attr MODBUS1 obj-h1-reading test
attr MODBUS1 obj-h1-set 1
attr MODBUS1 obj-h1-showGet 1
attr MODBUS1 obj-h1-textArg 1
attr MODBUS1 verbose 5

Ich habe ein gefälschtes obj-h1-reading erstellt, damit ich ein Signal senden kann, aber ich erhalte keine Antwort

Code Auswählen Erweitern

2022.03.04 10:03:13 4 :  MODBUS1: set called with test (h1) setVal = HELP
2022.03.04 10:03:13 5 :  MODBUS1: GetSetChecks with force
2022.03.04 10:03:13 5 :  MODBUS1: GetSetChecks returns success
2022.03.04 10:03:13 5 :  MODBUS1: set packed hex 48454c50 with n to hex 0000
2022.03.04 10:03:13 4 :  MODBUS1: DoRequest called from SetLDFn created new request, current frame / read buffer: 4f4b0d0a,
request: id 1, write fc 16 h1, len 60, value 0000, tid 220, master device  MODBUS1, reading test (set test)
2022.03.04 10:03:13 5 :  MODBUS1: QueueRequest called from DoRequest with h1, qlen 0 from master  MODBUS1 through io device  MODBUS1
2022.03.04 10:03:13 5 :  MODBUS1: ProcessRequestQueue called from QueueRequest as direct: MODBUS1, qlen 1, force, request: request: id 1, write fc 16 h1, len 60, value 0000, tid 220, master device  MODBUS1, reading test (set test), queued 0.00 secs ago
2022.03.04 10:03:13 5 :  MODBUS1: checkDelays clientSwitchDelay is not relevant
2022.03.04 10:03:13 5 :  MODBUS1: checkDelays sendDelay, last send to same device was 24.606 secs ago, required delay is 0.1
2022.03.04 10:03:14 5 :  MODBUS1: checkDelays commDelay, last communication with same device was 9.330 secs ago, required delay is 0.1
2022.03.04 10:03:14 5 :  MODBUS1: checkDelays busDelayRead, last activity on bus was 9.330 secs ago, required delay is 0
2022.03.04 10:03:14 4 :  MODBUS1: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 1, sending 00dc0000000901100001003c780000 via <ip>, current frame / read buffer: 4f4b0d0a,
request: id 1, write fc 16 h1, len 60, value 0000, tid 220, master device  MODBUS1, reading test (set test), queued 0.00 secs ago
2022.03.04 10:03:14 5 :  MODBUS1: DropBuffer for ProcessRequestQueue clears the reception buffer with 4f4b0d0a
2022.03.04 10:03:14 5 :  MODBUS1: Send called from ProcessRequestQueue
2022.03.04 10:03:14 5 : DevIo_SimpleWrite  MODBUS1: 00dc0000000901100001003c780000
2022.03.04 10:03:14 5 :  MODBUS1: ReadAnswer called from SetLDFn
2022.03.04 10:03:14 5 :  MODBUS1: ReadAnswer remaining timeout is 9.99186992645264
2022.03.04 10:03:14 5 :  MODBUS1: ReadAnswer got: 4f4b0d0a
2022.03.04 10:03:14 5 :  MODBUS1: ParseFrameStart called from ReadAnswer protocol TCP expecting id 1
2022.03.04 10:03:14 5 :  MODBUS1: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2022.03.04 10:03:14 5 :  MODBUS1: ReadAnswer remaining timeout is 9.31063485145569

Wenn wir versuchen, die Modbus-Kommunikation, z.B. das Holding-Register, mit einem für diesen Zweck konzipierten Programm einzusehen, erhalten wir in der Regel keine Daten.
Wenn wir hingegen das Signal über ein externes Programm senden, erhalten wir einen Frame mit Daten im fhem, die jedoch nicht verarbeitet werden, da sich das Gerät im Zustand IDLE befindet:

Code Auswählen Erweitern


2022.03.04 09:52:24 5 : MODBUS1: readFn buffer: 4f4b0d0a5052465354415445203030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030300d0a4f4b0d0a
2022.03.04 09:52:24 5 : MODBUS1: ParseFrameStart called from ReadFn
2022.03.04 09:52:24 4 : MODBUS1: ParseFrameStart (TCP, master) extracted id 97, fCode 103, tid 20299, dlen 30067 and potential data 54415445203030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030300d0a4f4b0d0a
2022.03.04 09:52:24 3 : MODBUS1: readfn got data while EXPECT was set to idle: 4f4b0d0a5052465354415445203030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030300d0a4f4b0d0a
2022.03.04 09:52:24 5 : MODBUS1: DropBuffer for ReadFn clears the reception buffer with 4f4b0d0a5052465354415445203030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030300d0a4f4b0d0a
2022.03.04 09:52:33 5 : MODBUS1: readFn buffer: 4f4b0d0a
2022.03.04 09:52:33 5 : MODBUS1: ParseFrameStart called from ReadFn
2022.03.04 09:52:33 5 : MODBUS1: readFn did not see a valid TCP frame start yet, wait for more data

Könnte hier die Übertragung des ASCII-Signals über RS485 der Schuldige sein?


Manual: https://jablotron.com.hk/image/data/pdf/manuel/JA-121T.pdf