3.7.2 Broadcast Behavior

[nicholas-a-guerra]

Hi,

I'm updating to the latest version of pymodbus and have some questions about the api changes. From 3.7.x it appears broadcast_enable has been removed. However, I do not see in the docs what consequence this will actually have. Right now a broadcast message with broadcast_enable=True, will return quickly with the assumption that there should be no response. Without broadcast_enable, what is the new expected behavior? If I use slave_id=0, should it still return immediately or will there be a new behavior? How is it expected to use broadcast now?

** Also, it's noted in the docs that using broadcast is not advised. I wanted to share feedback that this general guidance is somewhat limited. In industrial applications right now there are many power control devices that advise from the manufacturer to use broadcast. For instance, if you are controlling several inverters in parallel and need to issue a power command, it is advised from many manufacturers to use broadcast so that all devices receive the command all at once. For example, there is a brand new inverter only designed and manufactured within the last few years that also keeps with this methodology. So there are definitely still use cases where broadcast is highly advised and actually necessary. Just because it is may be less common does not necessarily mean that "modern devices do not allow broadcast" or that it is "inheriently dangerous". Just as with any technology, it just should be used responsibly and with knowledge of the consequences.

Thanks

[MrWaloo]

Hi,

I don't know why (like you I am not a pymodbus specialist) but I found this. Basicaly if the slave_id is 0, False, '' (empty string) or None, the response is None. I have wondered too. But there is a reason, for sure.

--> So broadcast is always disabled.

[nicholas-a-guerra]

It looks like possibly before that line though, the request is still sent. This would indicate that broadcast is not disabled but just none is returned. In this case that would be fine. But It could be good to get an official response from the devs if possible.

[janiversen]

Broadcast (slave=0) is part of the modbus standard and is not especially documented.

Feel free to submit a pull request with a documentation update, if you want it documented.

slave=0 returns imidiatly without waiting for a response. next version will return a response if there are any.

all devices support slave=0, that is a demand to be modbus compatible.....however it is not recommended to use slave=0 for production, but merely for device detection.

[nicholas-a-guerra]

Returning immediately seems like there is no behavior change. So then the broadcast_enable flag is just not required anymore. Which I think is totally reasonable.

For the next version, you mention it will return a response if there is one. Does this mean it will then require the full timeout period for even truly broadcast messages? Causing an unnecessary hang in the tcp connection?

** To clarify, my question is really related only to writes. Reading from broadcast is obviously never recommended. But I'd hope that a write to broadcast would still return immediately since none of the devices are expected to respond.

[nicholas-a-guerra]

Also, I work with several manufacturers directly who strictly recommend using broadcast slave id 0 in production. It may not be recommended in other use cases but it is not universally true that industrial applications don't use it.

** These manufacturers could be the exception to the rule. But generally paralleled power systems have a similar methodologies. So I would argue it is relatively common in this use case. And power control systems are common. So at least it seems that there are not a small amount who would benefit from the continued support.

** Also, to clarify, manufacturer guidance is to use broadcast only for writing registers. Meaning you send something like a power command to all the devices at once. Obviously reading registers via broadcast is never recommended. So I agree at least with that.

[janiversen]

And what do you want to say by that?

slave=0 is supported by modbus, exactly as the standard indicates, so I really do not know what your problem is ?

broadcast_enable was no longer used internally so it was removed, but that does not in any way affect the functionality.

[nicholas-a-guerra]

Sorry, I'm not saying there is a problem. I'm only trying to make sure I understand any new or future behaviors. When the docs mention that it's not recommended to use broadcast, I wasn't sure if its support had changed or would in the future.

As long as write to slave id 0 is expected to continue to immediately return in current and future versions of pymodbus, then everything is perfect as is. I only shared my experience with broadcast as an anecdote to express its significance in case there was a consideration that it was unimportant and if somehow that could impact how it behaves on return from the function calls.

[daveyvanniftrik]

Hi,

Hopefully this is of any help, the Huawei Smartlogger is one of those devices that does reads over slave_id = 0

2.1 Register Definitions for the SmartLogger

Note: In the following table, the operation object of the register is the SmartLogger or all inverters accessed by the SmartLogger. In the Modbus-TCP communications protocol, the logic device ID is fixed to 0.

https://support.huawei.com/enterprise/en/doc/EDOC1100050690

In 3.6.9 this was used:

if self.broadcast_enable and not request.slave_id:
    resp = None
    break

In 3.7.2 the line is:

if not request.slave_id:
    resp = None
    break

In the case of 3.7.2. it means that I won't get a response when doing a read from slave_id = 0. In 3.6.9 I could set broadcast_enable = False + slave_id = 0 and it would return a response.

Thanks!

[janiversen]

Changed on dev.