I am using orange pi zero 3 as a server which has single usb A type port directly available. I have connected one USB to RS485 to communicate with multiple modbus RTU slaves. Some of them are with configurable baudrate. Since I have too many outputs to be controlled fast, i have opted for 57600 as a baudrate as a sweet spot for fast response and long rounting distance. However, I need some devices which are fixed baudrate 9600.
I have tried to configure them on same serial port. It is allowing me to configure different baudrates in things file.
However it make all things communicate on baudrate of the first modbus thing in things file.
Adding one more serial to usb converter changes my hardware architecture drastically. I suppose it is technically possible to communicate with multiple slaves of different baudrates as it is half duplex single master protocol. The slaves of same baudrate with different ID would neglect query as it is not matching with their ID. The slaves of different baudrates would see garbage which anyway will be neglected.
Requesting to do the needful to allow slaves with different baudrates to be accessible on same RS485 port to optimize the hardware cost.
I do agree that it might be good not to take chances in industrial environment. However, in case of home automation, where economy is important constraint, exploiting single serial port for multiple baudrate should be possible. Openhab things currently allows me to configure different things with different baudrates. But it is using baudrate configured for first thing for all the remaining slaves though they are of different baurdarates.
From my own modbus tcp slave debugging, I also know that openhab opens and closes connection between different modbus queries.
Only thing that need to be allowed is while opening port again, it need to follow the configured baudrate for that slave.
This way, only one serial port can be used for different baudrates.
The era in which modbus protocol standard was defined was decades ago with electronics failing now and then. Today the controllers are much capable of handling this kind of scenarios.
@Openhab team, please let me know your take on this. This would help me architect my future projects accordingly.
I have been using Openhab extensively and would like to have this feature implemented to save the components which could be facilitated by allowing different baudrate on same serial bus.
As far as the people who want to strictly comply with modbus standards are concerned, they can always assign same baudrates to all the modbus slaves with when they want to communicate.
However, those who want to economize on the hardware architecture by exploiting such suble tricks, they can configure different baudrates for different thing and keep their life simple by having single serial port in the server to take care of all the modbus slaves of different baudrates.
Currently I am using usb to serial for saving the time and complete the project before deadline. However, I am trying to switch to on board native uart (serial port) of SBC like raspberry pi or orange pi for higher robustness for 24X7X365 operation. In this case, implementing second serial port becomes almost impossible as many of the SBCs tend to carry single serial ports.
Requesting again to allow this trick to be possible in openhab.
I am interested to see if this works, as you say, server devices should be able to handle baud rate mismatches by simply ignoring malformed UART frames. But in terms of a solution, hoping for a change to OH in the short term is likely going to disappoint.
The 2 main solutions are going to be switching hardware to something like the RPi5, with GPIO serial port as well as multiple USB ports.
Does the orange pi not work with 2x USB → RS485 devices simply plugged into a USB hub?
Alternatively, roll your own serial script. Although I heavily utilise MODBUS, I don’t use OH to handle the transactions. I use a separate python script running as a systemd unit. It handles all the MODBUS transactions and converts them to MQTT messages, and vice versa.
Thanks Johno for your interest and curiosity. I prefer native modbus over mqtt. In case of any slave failure i can directly check the opehab console for things and discover if which slave is offline. This is because modbus is query reply protocol unlike mqtt. Let me know if I am thinking correctly. I will be happy to switch to mqtt if it allows to monitor if the device is offline. Monitoring if the device is offline and which device is offline allow me to go prepared for client visit if he is facing any problem.
For economy of implementation for masses, I have chosed orange pi zero 3 which has all the bells and whistles for minimal architecture. Off course, I can expose onboard usb ports of orange pi bergstrip on base board and use USB to UART chip along with RS485 transceiver, but it not only adds to the bill of material but also the PCB size. Increasing both of this is not an issue. However, our hardware is also supposed to be retrofit for switch board boxes already installed in older home, where saving every millimeter matters.
MQTT itself has configurable levels of message receipt in it’s quality of service (QoS) setting, however that’s not really the issue here - MQTT is pretty rock solid especially if the broker is on the same device.
For my implementation, I used OpenHAB’s command and state topics to reflect a successful read/write to a server device. The library I use, pymodbus, has error attributes for any MODBUS transaction, so that you can process successful or unsuccessful calls . For example, if there is a successful R/W, it will send an MQTT state message back to OH to update the needed items, if there’s an error it reverts back to previous values. In your case you could create dedicated online/offline messages for unavailable devices. Python can even handle the device availability polling internally, and just update OH when needed.
This all assumes you are willing to do a bunch of python scripting, but it’s a solution that is likely to materialise in a reasonable timeframe.
Variable baurdate for single serial port used to work in older version of OH. I guess OH2. I don’t know why it was taken away.
It would be great if the multiple baudrates are allowed on same bus. Off course the responsibility of the functionality of the system is with the one who is configuring it with multiple baurdates.
Requesting to either allow multiple baudates on same serial bus or warn the user about inconsistent things file.
Please let me know the stand for deciding the architecture of our hardware. Our master and slaves are capable of handling multiple baurdates. Enabling to configure multiple baudrates would really keep the architecture optimized.
