It is unclear how to define the unit ID when implementing a client

[GoogleCodeExporter]

I'd like to create a client which calls its read_* and write_*
methods (defined in ModbusClientMixin from pymodbus/client/common.py). 
But there seems to be no way to define the unit ID that should be used 
in the requests.

Since a request has the (invalid) unit id 0 by default, the
requests are not handled by the server.

One option might be to initialize the client with the unit id
of the server (this should be constant). After adapting the
request classes accordingly, the methods in ModbusClientMixin
could be adapted like this:

   def write_coils(self, address, values):
        request = WriteMultipleCoilsRequest(address, values,
                                            self.server_unit_id)
        return self.execute(request)

Right now, I'm using a simpler version of this:

    def write_coil(self, address, value, unit_id = 1):
        request = WriteSingleCoilRequest(address, value)
        request.unit_id = unit_id
        return self.execute(request)

But I think it would be better to properly represent the server unit
id in the client.

Please have a look.

Original issue reported on code.google.com by albert.k...@gmail.com on 9 Feb 2011 at 2:44

[GoogleCodeExporter]

The 0x00 unit id (slave address) is used to represent the broadcast address.  
All servers are required to respond to this (and this or 0xff is the default in 
modbus tcp/udp) unless they are operating as a bridge.

I agree it should be specified, and I like the simple implementation as that 
allows the user to choose which slave they would like to hit (defaulting to 
broadcast). I do however need to add the address specifying and checking on the 
server side.  Let me know if this is okay.

Original comment by Bashw...@gmail.com on 9 Feb 2011 at 4:02

• Changed state: Started

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Here is the relevant change:
http://code.google.com/p/pymodbus/source/detail?r=106

As for the server, I think I am actually handling that correctly, so it 
shouldn't be an issue.

Original comment by Bashw...@gmail.com on 9 Feb 2011 at 4:10

[GoogleCodeExporter]

Sure. Didn't know about the broadcast address; obviously the device I'm
communicating with doesn't either ;-). At least it refused to respond
to messages with uid 0...

Original comment by albert.k...@gmail.com on 9 Feb 2011 at 4:13

[GoogleCodeExporter]

Original comment by Bashw...@gmail.com on 9 Feb 2011 at 4:20

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for the quick fix. In the future, there might be other use cases
that demand a different unit_id. If this happens, you might want to
consider adding unit_id as a third parameter to the *Request classes.
But for now, the solution seems sufficient.

Regards, Albert

Original comment by albert.k...@gmail.com on 10 Feb 2011 at 8:24

[GoogleCodeExporter]

This issue was updated by revision r108.

I forwarded the kwargs for the request/response messages to the base
pdu which pulls out the unit and sets it.

Original comment by Bashw...@gmail.com on 10 Feb 2011 at 4:38

[GoogleCodeExporter]

Just use this, I tried and It works:
res = client.read_holding_registers(3999, 24, unit=2)

Original comment by longq...@gmail.com on 26 May 2014 at 7:33