Introduction
There are two methods to collect data from an monitoring device. The device can be asked to provide the data or the device can be programmed to deliver the data without prompting. The situation is similar for control devices.
Push or pull?
When researching the devices connected to the Internet of Things (IOT) you will see some debate on whether to pull information from a device or whether the device should push information. Is one approach better than the other?
Pull
With the “pull” model, a monitoring device doesn’t actively send information but waits until it is prompted to do so by a second device initiating a connection. As an example, if a monitoring device has a simple HTTP server incorporated which delivers an HTML page with the measurements or readings it is tracking then any other device can “pull” information at will.
Push
An different approach is to program the monitoring device to regularly send, or “push”, information to a defined destination. An example of this would be to publish, at defined intervals, a message containing the current readings, to an MQTT topic on an MQTT server. With this approach the monitoring device needs no prompt to send information. It is the device that initiates the communication.
Choices for monitoring devices
There’s no right or wrong approach. With the “pull” model information is provided on demand to the recipient so it gets the data it needs, when it needs it. If there are several recipients and they all need the same data there’s potentially duplicate processing effort on the monitoring devise which, if it is a small, low resource device, may not be able to cope.
With the “push” model a data recipient will only get data when the monitoring device provides it. If a reading is needed between the regular messages then that’s too bad. However, a small, low resource device, can be programmed and tested to provide the data within its resource constraints. This may be crucial for a battery powered device that has a low power budget.
As well as considering resources when making a choice between the two models some thought should go into error detection. How critical is it to know that a device has failed? With the “pull” model the recipient knows a device has failed when it fails to respond to a request for data. The “push” model requires the data recipient to track the time from that last communication as to raise an error situation if that duration goes beyond some defined limit.
Choices for control devices
For a device that has a control function the choice of “push” or “pull” will be influenced by the way the device exercises its control.
If the device is simply controlling the state of one or more outputs, whether they are digital or analogue, then the device simply awaits instructions. In this case a “push” models works well. The data source initiates a communication. If this is successful the data source knows the device is active. To handle communication problems the device may be programmed to set the outputs to safe states at start up and after a period of no communication.
A device that is controlling a process, possibly as part of a feedback loop, would tend to be executing a control loop. In this case the device may “pull” control data at appropriate intervals in its processing. Being able to determine when the data communication occurs may be important if the process control loop has timing or memory constraints.
Control devices can have a have a monitoring function to provide feedback to a data source. While a successful “push” communication confirms the device is active there’s no guarantee that the device has responded to the communication. To close this loop the device would monitor its state and provide its status, either through a “push” or “pull” model.