You scenario is 90% of what we do with regards to acquisition on Losant.
We have a python agent, that polls COMAP equipment.
We decoupled the components all running on a single device.
python agents (possibly multiple) (on losant gateway) polls modbus slaves (TCP), and publishes to a redis queue.
a seperate agent listens on the redis queue and push data either directly to losant via mqtt or via a moquitto broker acting as a bridge (using QOS1 means we get replay if the link is down).
Originally had single agent doing everything (twisted async server) however dealing with all the disconnect/reconnect networking issues for different parts made the code too complex.
This model also allows us to inject additional specific data for channels (possibly not from modbus) about the device into the same mqtt stream, by simply publishing data from another source to the same redis channel.
So in summary
device <- python agent -> redis queue <- redis subscribe -> mqtt
This is all running on a pi.
We have nearly 20 engines running on a single site Around 20 different sites running at the moment with varying numbers of modbus devices
Example of one pod of engines.
I can’t directly share code, however I can outline specifics.
I am using modbus_tk package.
We parse a config file we download from the COMAP controllers which provides a map of registers (non contiguous) with names, scales, bit decoding (meaning of status bits etc)
The a config file is built listing the names of the registers, the ip address, unit address, cycle time, and what channel to publish on.
This means we can get a modbus device online in a few minutes.
Will follow up with more details.