Regression in 3.8.5: slave-id 0 should function as any other slave-id for Modbus TCP

[wlcrs]

Modbus 3.8.5 introduces change #2567 , which causes any response from a slave with slave-id 0 to return an ExceptionResponse with code 0xFF.

While this is correct for Modbus RTU, where slave-id 0 is reserved for broadcasting messages, this does not apply to Modbus TCP. In Modbus TCP you have no concept of broadcasting, and this slave ID should function as any other slave ID. While this is not a widely used practice, it is not against the Modbus TCP standard.

Please revert PR #2567 .

Related to wlcrs/huawei_solar#940 : Huawei uses slave ID 0 as the default slave ID for it's inverters.

Example logs:

2025-02-09 18:51:40.301 DEBUG (MainThread) [pymodbus.logging] Connecting to 192.168.0.250:6607.
2025-02-09 18:51:40.301 DEBUG (MainThread) [pymodbus.logging] Connecting comm
2025-02-09 18:51:40.307 DEBUG (MainThread) [pymodbus.logging] Connected to comm
2025-02-09 18:51:40.307 DEBUG (MainThread) [huawei_solar.modbus] Waiting for 1500 milliseconds after connection before performing operations
2025-02-09 18:51:40.365 DEBUG (MainThread) [pymodbus.logging] -> transport: received eof
2025-02-09 18:51:40.366 DEBUG (MainThread) [pymodbus.logging] Connection lost comm due to None
2025-02-09 18:51:40.366 DEBUG (MainThread) [pymodbus.logging] Wait comm 1000000 ms before reconnecting.
2025-02-09 18:51:40.408 INFO (MainThread) [huawei_solar.huawei_solar] Waiting for connection
2025-02-09 18:51:41.808 DEBUG (MainThread) [huawei_solar.huawei_solar] Reading register 30000 with length 65 from slave 0
2025-02-09 18:51:41.809 DEBUG (MainThread) [pymodbus.logging] send: 0x0 0x1 0x0 0x0 0x0 0x6 0x0 0x3 0x75 0x30 0x0 0x41
2025-02-09 18:51:41.809 ERROR (MainThread) [pymodbus.logging] Exception response 255 / 0
2025-02-09 18:51:41.836 DEBUG (MainThread) [pymodbus.logging] recv: 0x0 0x1 0x0 0x0 0x0 0x85 0x0 0x3 0x82 0x53 0x55 0x4e 0x32 0x30 0x30 0x30 0x2d 0x36 0x4b 0x54 0x4c 0x2d 0x4c 0x31 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x54 0x41 0x32 0x32 0x43 0x30 0x33 0x37 0x35 0x31 0x37 0x32 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x30 0x31 0x30 0x37 0x35 0x33 0x34 0x35 0x2d 0x30 0x31 0x35 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x56 0x32 0x30 0x30 0x52 0x30 0x30 0x31 0x43 0x30 0x30 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x56 0x32 0x30 0x30 0x52 0x30 0x30 0x31 0x43 0x30 0x30 0x53 0x50 0x43 0x31 0x33 0x30 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 old_data:  addr=None
2025-02-09 18:51:41.836 DEBUG (MainThread) [pymodbus.logging] Processing: 0x0 0x1 0x0 0x0 0x0 0x85 0x0 0x3 0x82 0x53 0x55 0x4e 0x32 0x30 0x30 0x30 0x2d 0x36 0x4b 0x54 0x4c 0x2d 0x4c 0x31 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x54 0x41 0x32 0x32 0x43 0x30 0x33 0x37 0x35 0x31 0x37 0x32 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x30 0x31 0x30 0x37 0x35 0x33 0x34 0x35 0x2d 0x30 0x31 0x35 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x56 0x32 0x30 0x30 0x52 0x30 0x30 0x31 0x43 0x30 0x30 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x56 0x32 0x30 0x30 0x52 0x30 0x30 0x31 0x43 0x30 0x30 0x53 0x50 0x43 0x31 0x33 0x30 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
2025-02-09 18:51:41.836 DEBUG (MainThread) [pymodbus.logging] decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[21333, 20018, 12336, 12333, 13899, 21580, 11596, 12544, 0, 0, 0, 0, 0, 0, 0, 21569, 12850, 17200, 13111, 13617, 14130, 0, 0, 0, 0, 12337, 12343, 13619, 13365, 11568, 12597, 0, 0, 0, 0, 22066, 12336, 21040, 12337, 17200, 12288, 0, 0, 0, 0, 0, 0, 0, 0, 0, 22066, 12336, 21040, 12337, 17200, 12371, 20547, 12595, 12288, 0, 0, 0, 0, 0, 0], status=1)
2025-02-09 18:51:41.836 DEBUG (MainThread) [pymodbus.logging] Frame advanced, resetting header!!
2025-02-09 18:51:42.244 DEBUG (MainThread) [pymodbus.logging] Connecting comm
2025-02-09 18:51:42.249 DEBUG (MainThread) [pymodbus.logging] Connected to comm
2025-02-09 18:51:42.250 DEBUG (MainThread) [huawei_solar.modbus] Waiting for 1500 milliseconds after connection before performing operations
2025-02-09 18:51:42.292 DEBUG (MainThread) [pymodbus.logging] -> transport: received eof
2025-02-09 18:51:42.293 DEBUG (MainThread) [pymodbus.logging] Connection lost comm due to None
2025-02-09 18:51:42.293 DEBUG (MainThread) [pymodbus.logging] Wait comm 1000000 ms before reconnecting.
2025-02-09 18:51:47.118 DEBUG (MainThread) [pymodbus.logging] Connecting to 192.168.0.250:6607.
2025-02-09 18:51:47.118 DEBUG (MainThread) [pymodbus.logging] Connecting comm
2025-02-09 18:51:47.121 DEBUG (MainThread) [pymodbus.logging] Connected to comm
2025-02-09 18:51:47.121 DEBUG (MainThread) [huawei_solar.modbus] Waiting for 1500 milliseconds after connection before performing operations
2025-02-09 18:51:47.155 DEBUG (MainThread) [pymodbus.logging] -> transport: received eof
2025-02-09 18:51:47.156 DEBUG (MainThread) [pymodbus.logging] Connection lost comm due to None
2025-02-09 18:51:47.156 DEBUG (MainThread) [pymodbus.logging] Wait comm 1000000 ms before reconnecting.
2025-02-09 18:51:47.222 INFO (MainThread) [huawei_solar.huawei_solar] Waiting for connection
2025-02-09 18:51:48.622 DEBUG (MainThread) [huawei_solar.huawei_solar] Reading register 30000 with length 65 from slave 0
2025-02-09 18:51:48.622 DEBUG (MainThread) [pymodbus.logging] send: 0x0 0x1 0x0 0x0 0x0 0x6 0x0 0x3 0x75 0x30 0x0 0x41
2025-02-09 18:51:48.622 ERROR (MainThread) [pymodbus.logging] Exception response 255 / 0
2025-02-09 18:51:48.696 DEBUG (MainThread) [pymodbus.logging] recv: 0x0 0x1 0x0 0x0 0x0 0x85 0x0 0x3 0x82 0x53 0x55 0x4e 0x32 0x30 0x30 0x30 0x2d 0x36 0x4b 0x54 0x4c 0x2d 0x4c 0x31 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x54 0x41 0x32 0x32 0x43 0x30 0x33 0x37 0x35 0x31 0x37 0x32 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x30 0x31 0x30 0x37 0x35 0x33 0x34 0x35 0x2d 0x30 0x31 0x35 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x56 0x32 0x30 0x30 0x52 0x30 0x30 0x31 0x43 0x30 0x30 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x56 0x32 0x30 0x30 0x52 0x30 0x30 0x31 0x43 0x30 0x30 0x53 0x50 0x43 0x31 0x33 0x30 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 old_data:  addr=None
2025-02-09 18:51:48.696 DEBUG (MainThread) [pymodbus.logging] Processing: 0x0 0x1 0x0 0x0 0x0 0x85 0x0 0x3 0x82 0x53 0x55 0x4e 0x32 0x30 0x30 0x30 0x2d 0x36 0x4b 0x54 0x4c 0x2d 0x4c 0x31 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x54 0x41 0x32 0x32 0x43 0x30 0x33 0x37 0x35 0x31 0x37 0x32 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x30 0x31 0x30 0x37 0x35 0x33 0x34 0x35 0x2d 0x30 0x31 0x35 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x56 0x32 0x30 0x30 0x52 0x30 0x30 0x31 0x43 0x30 0x30 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x56 0x32 0x30 0x30 0x52 0x30 0x30 0x31 0x43 0x30 0x30 0x53 0x50 0x43 0x31 0x33 0x30 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
2025-02-09 18:51:48.696 DEBUG (MainThread) [pymodbus.logging] decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[21333, 20018, 12336, 12333, 13899, 21580, 11596, 12544, 0, 0, 0, 0, 0, 0, 0, 21569, 12850, 17200, 13111, 13617, 14130, 0, 0, 0, 0, 12337, 12343, 13619, 13365, 11568, 12597, 0, 0, 0, 0, 22066, 12336, 21040, 12337, 17200, 12288, 0, 0, 0, 0, 0, 0, 0, 0, 0, 22066, 12336, 21040, 12337, 17200, 12371, 20547, 12595, 12288, 0, 0, 0, 0, 0, 0], status=1)
2025-02-09 18:51:48.696 DEBUG (MainThread) [pymodbus.logging] Frame advanced, resetting header!!
2025-02-09 18:51:58.969 DEBUG (MainThread) [pymodbus.logging] Connecting to 192.168.0.250:6607.
2025-02-09 18:51:58.969 DEBUG (MainThread) [pymodbus.logging] Connecting comm
2025-02-09 18:51:58.981 DEBUG (MainThread) [pymodbus.logging] Connected to comm
2025-02-09 18:51:58.981 DEBUG (MainThread) [huawei_solar.modbus] Waiting for 1500 milliseconds after connection before performing operations
2025-02-09 18:51:59.030 DEBUG (MainThread) [pymodbus.logging] -> transport: received eof
2025-02-09 18:51:59.031 DEBUG (MainThread) [pymodbus.logging] Connection lost comm due to None
2025-02-09 18:51:59.031 DEBUG (MainThread) [pymodbus.logging] Wait comm 1000000 ms before reconnecting.
2025-02-09 18:51:59.082 INFO (MainThread) [huawei_solar.huawei_solar] Waiting for connection
2025-02-09 18:52:00.483 DEBUG (MainThread) [huawei_solar.huawei_solar] Reading register 30000 with length 65 from slave 0
2025-02-09 18:52:00.483 DEBUG (MainThread) [pymodbus.logging] send: 0x0 0x1 0x0 0x0 0x0 0x6 0x0 0x3 0x75 0x30 0x0 0x41
2025-02-09 18:52:00.484 ERROR (MainThread) [pymodbus.logging] Exception response 255 / 0
2025-02-09 18:52:00.526 DEBUG (MainThread) [pymodbus.logging] recv: 0x0 0x1 0x0 0x0 0x0 0x85 0x0 0x3 0x82 0x53 0x55 0x4e 0x32 0x30 0x30 0x30 0x2d 0x36 0x4b 0x54 0x4c 0x2d 0x4c 0x31 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x54 0x41 0x32 0x32 0x43 0x30 0x33 0x37 0x35 0x31 0x37 0x32 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x30 0x31 0x30 0x37 0x35 0x33 0x34 0x35 0x2d 0x30 0x31 0x35 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x56 0x32 0x30 0x30 0x52 0x30 0x30 0x31 0x43 0x30 0x30 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x56 0x32 0x30 0x30 0x52 0x30 0x30 0x31 0x43 0x30 0x30 0x53 0x50 0x43 0x31 0x33 0x30 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 old_data:  addr=None
2025-02-09 18:52:00.526 DEBUG (MainThread) [pymodbus.logging] Processing: 0x0 0x1 0x0 0x0 0x0 0x85 0x0 0x3 0x82 0x53 0x55 0x4e 0x32 0x30 0x30 0x30 0x2d 0x36 0x4b 0x54 0x4c 0x2d 0x4c 0x31 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x54 0x41 0x32 0x32 0x43 0x30 0x33 0x37 0x35 0x31 0x37 0x32 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x30 0x31 0x30 0x37 0x35 0x33 0x34 0x35 0x2d 0x30 0x31 0x35 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x56 0x32 0x30 0x30 0x52 0x30 0x30 0x31 0x43 0x30 0x30 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x56 0x32 0x30 0x30 0x52 0x30 0x30 0x31 0x43 0x30 0x30 0x53 0x50 0x43 0x31 0x33 0x30 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
2025-02-09 18:52:00.527 DEBUG (MainThread) [pymodbus.logging] decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[21333, 20018, 12336, 12333, 13899, 21580, 11596, 12544, 0, 0, 0, 0, 0, 0, 0, 21569, 12850, 17200, 13111, 13617, 14130, 0, 0, 0, 0, 12337, 12343, 13619, 13365, 11568, 12597, 0, 0, 0, 0, 22066, 12336, 21040, 12337, 17200, 12288, 0, 0, 0, 0, 0, 0, 0, 0, 0, 22066, 12336, 21040, 12337, 17200, 12371, 20547, 12595, 12288, 0, 0, 0, 0, 0, 0], status=1)
2025-02-09 18:52:00.527 DEBUG (MainThread) [pymodbus.logging] Frame advanced, resetting header!!

[janiversen]

Even for tcp you should use the correct device id, simply because a modbus tcp server can contain (and often does) contain multiple slaves. All tcp-rs485 converters allow multiple slaves, as a consequence setting the id correctly is important.

There is a fix being made as we speak, that will allow id=0, but only if the device also responds with id=0.

And just for information my own Huawei SUN2000-6ktl and SUN2000-4ktl respond with id = 1, but accept id=0 in the request.

[MrWaloo]

You asked for devices using dev_id = 0 in the discussion:

• Victron Cerbo GX but it responds also to dev_id = 100
• SUN2000 (Jeedom community thead in french) did not work with dev_id = 0 or 1 with pymodbus V3.7.2. If I remember, dev_id = 0 can only be replaced by dev_id = 1 if a dongle is installed, over wifi it is not possible (this last sentense can be wrong, I am not sure).
• Crouzet M3: some user wrote that he had an issue (with pymodbus V3.7.2)
• some other devices too had communication issues, after I migrated the MyModbus plugin for Jeedom to pymodbus 3.7.2.

[janiversen]

I think you misunderstand something all devices must respond to device id 0 because it is broadcast, but all devices I know have a distinct id like the victron which should be properly addressed as 100.

The sun2000 works over wifi with dev_id 1, it simply depends whether or not you have changed the default configuration of the device. I have had it running for quite a while with 3.7.2. Please remember wifi only works, if you change the default configuration to allow 3rd party access, in the same way you can set the modbus id.

[janiversen]

Adressing the Victron with id=0 is exactly the case we want to avoid, because you often do not know if there are multiple devices real or virtual on the connection.

[wlcrs]

The Modbus standard agrees with Jan's view that the unit identifier MUST match between request and response:

Just for future reference, the standard also explicitly allows 0 as unit identifier for Modbus TCP connections:

I tested against my SUN2000 inverter, and that one only responds to queries against slave 0, which is a perfectly legal thing to do, cfr. the snippet above.

[janiversen]

in the SUN2000 inverter you can configure the modbus id, on my devices the default was 1, but it might be 0 on other models.

Try to have (as I have) multiple SUN2000 cascaded, then you need to set the id in every device in order to address them via the master sun2000.

[MrWaloo]

I also agree with Jan

I think you misunderstand something

I may misunderstand something, especially the gap between this code:

pymodbus/pymodbus/transaction/transaction.py

Lines 137 to 138 in 6e499e4

	if not request.dev_id or no_response_expected:
	return ExceptionResponse(0xff)

And this sentence:

all devices must respond to device id 0 because it is broadcast, but all devices I know have a distinct id like the victron which should be properly addressed as 100.

And as I said, I did not test the new version.

I will migrate the plugin to use this new version of pymodbus and will let you know if users' device are blocked. But only in 2 weeks, when I will be back from the hollydays.

---

I tested against my SUN2000 inverter, and that one only responds to queries against slave 0, which is a perfectly legal thing to do, cfr. the snippet above.

Did you test it with this last version (3.8.5) ?