An RS485 Modbus sensor speaks to whoever polls it on a twisted pair. Getting its readings into a cloud means something has to poll it, keep the values, and send them over a network. There are three common ways to arrange that, and they put the work in different places.
| What polls the sensor | What you build | Fits | |
|---|---|---|---|
| Gateway and your platform | A Modbus gateway | The platform: storage, alerts, users | Teams that already run a platform |
| PLC and SCADA | A PLC | Panel, programming, SCADA tags | Sites where a PLC is already there for the process |
| Cellular controller with its cloud | The controller itself | Nothing beyond the wiring | Distributed points with no platform yet |
A gateway forwards values; something else has to store them, survive outages and fill the gaps.
An alarm on a screen in a control room does not reach the person on call. Decide where the alert has to land before choosing the route.
A register map typed into a gateway, a PLC program change, or a sensor added from a dashboard are different amounts of work.
Genesis polls supported Modbus sensors itself, stores each reading with its time, and sends them over 4G-LTE to a cloud with alerts, export and a REST API.
A Modbus instrument that is not supported yet is added on request from its register map.
Usually, yes. If they speak RS485 Modbus RTU, send the models and register maps.
Yes, through the REST API.
Tell us what has to be measured or switched, where, and what it has to report into. We say which approach fits, including when it is not ours.
Talk to us →