It seems, that there is no answer for the "/?!". Meter does not respond with serial number.
If I try terminal emulator like MINICOM/HYPERTERMINAL and send manually "/?!<CR><LF>" meter correctly respond with serial number (+bunch of registers).
Tried this with Linux/Centos8 stock Python and also with Python 3.9 under Windows.
RX: 15:01:14 bytearray(b'\x00\x00/LGZ5\\2ZMD4104409.B32\r\n\x02F.F(00000000)\r\n0.0.0(51114744)\r\n0.9.1(15:02:55)\r\n0.9.2(21-09-2')
DisconnectRequest
Traceback (most recent call last):
File "main.py", line 108, in main
reader.readAll(settings.outputFile)
File "/home/gurux/Gurux.DLMS.Python/Gurux.DLMS.Client.Example.python/GXDLMSReader.py", line 529, in readAll
self.initializeConnection()
File "/home/gurux/Gurux.DLMS.Python/Gurux.DLMS.Client.Example.python/GXDLMSReader.py", line 302, in initializeConnection
self.initializeOpticalHead()
File "/home/gurux/Gurux.DLMS.Python/Gurux.DLMS.Client.Example.python/GXDLMSReader.py", line 212, in initializeOpticalHead
raise Exception("Invalid responce : " + replyStr)
UnboundLocalError: local variable 'replyStr' referenced before assignment
Ended. Press any key to continue.
-----------------------
It seems that Python/Gurux is confused with output from the meter. After identification, meter starts to send some registers (bytearray(b'\x00\x00/LGZ5\\2ZMD4104409.B32\r\n\x02F.F(00000000)\r\n0.0.0(51114744)\r\n0.9.1(15:02:55)\r\n0.9.2(21-09-2'))
Communication with Gurux DLMS Director works as expected:
------------------------
GXDLMSDirector 8.2.2109.0301
Log created 8:39:51 AM
08:39:53 Initializing serial connection.
08:39:54 IEC Sending:/?!<CR><LF>
08:39:55 HDLC received: /LGZ5\2ZMD4104409.B32<CR><LF>
08:39:55 BaudRate is : 9600
8:39:55 AM Moving to mode E.
06 32 35 32 0D 0A
8:39:59 AM Send SNRM request.
7E A0 07 03 21 93 0F 01 7E
8:39:59 AM
7E A0 1E 21 03 73 C3 7A 81 80 12 05 01 80 06 01 3E 07 04 00 00 00 01 08 04 00 00 00 01 07 22 7E
08:39:59 Parsing UA reply succeeded.
8:39:59 AM Send AARQ request.
7E A0 2B 03 21 10 FB AF E6 E6 00 60 1D A1 09 06 07 60 85 74 05 08 01 02 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 1C 03 20 FF FF 80 AB 7E
8:39:59 AM
7E A0 37 21 03 30 6C 7C E6 E7 00 61 28 A1 09 06 07 60 85 74 05 08 01 02 A2 03 02 01 00 A3 05 A1 03 02 01 00 BE 0F 04 0D 08 00 06 5F 1F 04 00 18 02 20 09 60 FA 00 0A A8 7E
08:39:59 Parsing AARE reply succeeded.
-----------------------------
Maybe Gurux/Python should switch to Mode E immediately after meter responds with its ID.
Thanks for pointing out that exception error. It's now fixed and released in Github.
The meter is in working in Mode A. The reason is that clients don't send the next command fast enough.
Receiving a reply takes 5 seconds and that is too slow. I'll check this because there are changes in the serial port component.
Actually I think, that meter respond with its SN in one second. You can able to see it from Gurux DLMS Director log:
------
08:39:54 IEC Sending:/?!<CR><LF>
08:39:55 HDLC received: /LGZ5\2ZMD4104409.B32<CR><LF>
------
After several seconds, meter starts to print its registers. It seems that Python/GURUX is waiting more that it should. Reply from the meter is in one second.
It seems, that Python/Gurux is waiting more than it should.
Hello,
Hello,
There is an issue with some optical probes. It's under construction and I hope that fix can be released today.
BR,
Mikko
Great! Thank you.
Great! Thank you.
Hi,
Hi,
The new version is released. Get the source codes from the GitHub. Note! You must update gurux-serial component for Python to version 1.0.15.
BR,
Mikko
It seems that it started
It seems that it started (almost) to work. At least I am able to see response from the meter:
----------------
$ python3 main.py -S /dev/ttyUSB1:300:7Even1 -r sn -i HdlcWithModeE -t Verbose
gurux_dlms version: 1.0.107
gurux_net version: 1.0.17
gurux_serial version: 1.0.15
Authentication: Authentication.NONE
ClientAddress: 0x10
ServerAddress: 0x1
Standard: Standard.DLMS
TX: 15:01:09 /?!
RX: 15:01:14 bytearray(b'\x00\x00/LGZ5\\2ZMD4104409.B32\r\n\x02F.F(00000000)\r\n0.0.0(51114744)\r\n0.9.1(15:02:55)\r\n0.9.2(21-09-2')
DisconnectRequest
Traceback (most recent call last):
File "main.py", line 108, in main
reader.readAll(settings.outputFile)
File "/home/gurux/Gurux.DLMS.Python/Gurux.DLMS.Client.Example.python/GXDLMSReader.py", line 529, in readAll
self.initializeConnection()
File "/home/gurux/Gurux.DLMS.Python/Gurux.DLMS.Client.Example.python/GXDLMSReader.py", line 302, in initializeConnection
self.initializeOpticalHead()
File "/home/gurux/Gurux.DLMS.Python/Gurux.DLMS.Client.Example.python/GXDLMSReader.py", line 212, in initializeOpticalHead
raise Exception("Invalid responce : " + replyStr)
UnboundLocalError: local variable 'replyStr' referenced before assignment
Ended. Press any key to continue.
-----------------------
It seems that Python/Gurux is confused with output from the meter. After identification, meter starts to send some registers (bytearray(b'\x00\x00/LGZ5\\2ZMD4104409.B32\r\n\x02F.F(00000000)\r\n0.0.0(51114744)\r\n0.9.1(15:02:55)\r\n0.9.2(21-09-2'))
Communication with Gurux DLMS Director works as expected:
------------------------
GXDLMSDirector 8.2.2109.0301
Log created 8:39:51 AM
08:39:53 Initializing serial connection.
08:39:54 IEC Sending:/?!<CR><LF>
08:39:55 HDLC received: /LGZ5\2ZMD4104409.B32<CR><LF>
08:39:55 BaudRate is : 9600
8:39:55 AM Moving to mode E.
06 32 35 32 0D 0A
8:39:59 AM Send SNRM request.
7E A0 07 03 21 93 0F 01 7E
8:39:59 AM
7E A0 1E 21 03 73 C3 7A 81 80 12 05 01 80 06 01 3E 07 04 00 00 00 01 08 04 00 00 00 01 07 22 7E
08:39:59 Parsing UA reply succeeded.
8:39:59 AM Send AARQ request.
7E A0 2B 03 21 10 FB AF E6 E6 00 60 1D A1 09 06 07 60 85 74 05 08 01 02 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 1C 03 20 FF FF 80 AB 7E
8:39:59 AM
7E A0 37 21 03 30 6C 7C E6 E7 00 61 28 A1 09 06 07 60 85 74 05 08 01 02 A2 03 02 01 00 A3 05 A1 03 02 01 00 BE 0F 04 0D 08 00 06 5F 1F 04 00 18 02 20 09 60 FA 00 0A A8 7E
08:39:59 Parsing AARE reply succeeded.
-----------------------------
Maybe Gurux/Python should switch to Mode E immediately after meter responds with its ID.
Hi,
Hi,
Thanks for pointing out that exception error. It's now fixed and released in Github.
The meter is in working in Mode A. The reason is that clients don't send the next command fast enough.
Receiving a reply takes 5 seconds and that is too slow. I'll check this because there are changes in the serial port component.
BR,
Mikko
Actually I think, that meter
Actually I think, that meter respond with its SN in one second. You can able to see it from Gurux DLMS Director log:
------
08:39:54 IEC Sending:/?!<CR><LF>
08:39:55 HDLC received: /LGZ5\2ZMD4104409.B32<CR><LF>
------
After several seconds, meter starts to print its registers. It seems that Python/GURUX is waiting more that it should. Reply from the meter is in one second.
It seems, that Python/Gurux is waiting more than it should.
Hi,
Hi,
The wrong version from serial port component was released. Update gurux-serial to 1.0.17.
BR,
Mikko
Perfect! It works now! Thank
Perfect! It works now! Thank you.
The issue is resolved for me.