Internet of Things Stack Exchange is a question and answer site for builders and users of networked sensors and control devices in the contexts of smart homes, industry automation, or environmental sensors. It only takes a minute to sign up.
Sign up to join this community
I am configuring a Sonar Distance sensor to send data to a cloud. But the problem for me now is: I do not know when to send the data to this cloud.
As far as I know, I could send the data continuously every second. But in my case, the sensor does not always "sense" the signal. So sending data like the above method seems to be wasteful on network bandwidth.
I want to ask: Normally, with this kind of sensor; How do people often configure to send the data to a cloud?
Sending packets at a high rate 'feels' wrong, and does increase the chances of seeing some odd effects when the network latency spikes occasionally. In this instance, the fact that you're in a development cycle means that any period much above 10-30 sec will start to become painful to debug or adjust.
Batching up the readings is one option, or you can decimate (sample rate reduce) your readings before uploading them (depending on the application). You can also apply a rate-adaptive approach if there are some events that you want to be able to post-process more precisely.
At the highest level of 'not much change', you still probably want to see that the endpoint is alive, so even if you only used daily averaged/processed data, making an upload every hour might make some sense. If you want to measure occupancy, maybe anything over a 10% change would justify an instant update.
If you do anything other than a simple periodic update, consider what the worst case fault condition might look like. Even though a broken sensor won't burn through your monthly broadband allowance, it could cause some effects on your LAN which are inconvenient. It's always useful to think about the extra steps which you would take if this project made it to volume deployment, or if it becomes an exploit target.
I think the best way is to have a different interval for sending data over the air, and a different (preferably settable) time interval for logging the data into your data repository. How this helps?
Lets say you send data every second but log the data only ever 10 seconds
You wont miss any alarms because you could analyse the data sent every 1 second and record and raise alert messages, but you need not store the data every second. Other wise you might miss an alarm in between if you only analyse the data for alarms every 10 seconds. What if the alarm occurred on the 4th second and then got reset on the 9th second?
You will only occupy one tenth of the disk space which you will other wise occupy if you record data every 1 second.
This is a good practice for any type of remote telemetry application. Depending on your application and requirements you could tweak these time intervals to suit your needs.
