nanoframework
Modbus Max-Device-ID too low for devices with high IDs
Library/API/IoT binding
Modbus
Visual Studio version
VS2022.17.4
.NET nanoFramework extension version
No response
Target name(s)
ALL
Firmware version
N/A
Device capabilities
No response
Description
There are devices out there (i.e. https://www.amazon.com/dp/B07ZYVZZKK?ref=ppx_yo2ov_dt_b_fed_asin_title - See section #3 "Read device ID") that use a high ID during calibration or readout of their real ID.
/// <summary>
/// The highest accepted device id on RTU protocol.
/// </summary>
public const byte MaxDeviceId = 0xF7; // 247
This number needs to be increased to 255 to be able to read these parameters off these devices
How to reproduce
Try to access any device with a system parameter device ID larger than 247 like https://www.amazon.com/dp/B07ZYVZZKK?ref=ppx_yo2ov_dt_b_fed_asin_title
Expected behaviour
Should be possible somehow. Maybe with a special call that allows to address these high numbers
Screenshots
No response
Sample project or code
No response
Aditional information
No response
Did you made any investigations on how this is being handled on other open-source Modbus libraries?
I have tested this with other free Modbus testing tools like: https://www.modbustester.com/#download they do accept higher IDs. On the desktop I am using https://github.com/NModbus/NModbus and it does not do any checks on the slave address allowing even 255 as a valid address.
I finally got the time to look into this. Looking at the official Modbus Serial Line Protocol and Implementation Guide V1.02, sections 2.1 and 2.2. Our implementation is correct as it validates the address being in the range [1... 247]. The spec clearly mentions that addresses 248 to 255 are reserved.
Looks like the device you're using is not following the spec...
In principle, our implementation should follow the official spec. I don't see a way of fixing this without hijacking that constant or add a new property that allows the user to shoot itself in the foot (sort of speaking) and disable the checks... Thoughts?
It is correct that 248-255 are "reserved purposes". Some devices use Addresses 248-254 for commissioning "reserved" purposes. The problem is that the nf modbus library does not allow any access to these addresses. Other libraries on Github (like NModbus) have a way to get to these addresses "at the developers risk". It would be great to allow access to these addresses under the same pretense. The developer needs to know what they are doing. For example the device I listed in the description above uses 248 to allow the developer to change the real ID of the device. Its what they interpret as their "reserved purpose". That way they can always change the ID no matter what a previous application has changed the ID to. It should only used during commissioning and does not allow multiple devices connected at the same time as they would all respond to ID 248. If the NF cannot address beyond 247 for commissioning, I would have to connect the sensor to a PC or other device first to commission. That is an additional step in an already lengthy commissioning process.
Implementation suggestion
A bool property added to ModbusClient class. Only setter. With a descriptive name, like AllowAnyDeviceId. IntelliSense comment describing the intent, with a remark clearly stating "Use at your own risk" or similar.
This property would be checked at the ValidParameters methods and skips the validation of deviceId parameter.
If there are no further inputs on the implementation suggestion above, it would be OK to proceed with the implementation. Will you take care of doing it?
I can do it, but it might take some time. I am currently in Germany due to a family emergency. Once I have it resolved, I will work on this.
Understood. Take your time. So far, no one else has raised this issue, so no one is expecting for this particular fix. All the best for your emergency, hope nothing serious!
@muenchris hope everything is OK at your end. Pinging you about this. Do you think you can spare some time to code the changes to make this happen? 😉