Devices are acquiring data based on their internal clock frequency and based on the sensor – hardware implementation. Please consider to adapt your device settings according these recommendations and limitations.
You may need to support supplementary costs if a not appropriate frequency policy is implemented.
The acquired data can be pushed on the RoboFuse cloud using different policies:
- High Frequency – RoboFuse Cloud accepts devices to send data with frequency determinate by Network latency, i.e. 1 Sec. Is not intended to provide Real Time approach because it is a Cloud service, such approach is not appropriate. This approach consumes a lot of networks and environments resources having enough bandwidth, low latency, short network interruptions, high traffic volume. This method can work well on local network that is designed for IoT, i.e. Industry 4.0 implementations.
- High Frequency of data acquisition Cloud Data Efficiency Frequency – this approach supposes that a device can acquire data at high frequency inside of device store data and with optimum Frequency to be sent to RoboFuse Cloud. i.e. acquire data at 1 sec. and send data to cloud and each 10 sec.
- Optimum Frequency: for different applications is not needed to acquire and send data with high frequency (i.e. read environment temperature at 1 min. and send to Cloud).
- Delta data Frequency – eliminates most IoT challenges and provides substantial efficiency, reliability, and resiliency benefits.
- Fewer and smaller messages sent over the network results in a low and consistent latency profile – data gets to cloud faster, especially on unreliable networks such as mobile or satellite.
- Low network overhead per connection can support vast numbers of concurrent clients.
- Newly connected subscribers automatically receive the latest values for subscribed topics, reducing system complexity.
Since the first 3 approaches are covered by the existing setting : “sensors_reading_frq”, that can take values from 1 min to 100 min. To work with seconds, RoboFuse cloud must be deployed on a local network.
Delta
With this approach:
- data are acquired on local device
- processed on local device for delta value
- if delta value >= threshold then data are sent to Cloud
The needed settings are set on the sensor level and super script the general device settings:
- “delta_data” : 5 – value
- “max_frq” : 4 – value
Delta value is context sensible; the device will interpret it as a numeric formula.
Example:
Device settings:
- “sensors_reading_frq” : 1, meaning – the general setting tell to device that at 1 min. all sensor data are processed
Sensor setting:
- “delta_data” : 1.5 – it mean that for specific sensor when current value is varying with 1.5 (in Absolut value – attention to negative / positive variations) current value must be sent to Cloud.
- Example: temperature is like: 10, 10 , 10.5, 11, 11, 11.5
- Then first data 10, is sent to the Cloud
- Then for each iteration is compared (last value – current value) >= “delta_data” then send current value to Cloud
- “max_frq” : 4 – it mean that at least at 4 times the “sensors_reading_frq” data are sent to Cloud, computed as” 4 x 1 = 4 min. If “max_frq” is missing, then this feature is disabled and is not at all fired.
- Example : 10, 10 , 10.5, 11, 11, 11.5
- 10 is sent on cloud
- Then 11 is sent to data, because the value appears at 4×1 min freq.