Very disappointing...
this was the RSS feed link I followed:
https://i.imgur.com/Ydj3GOj.jpg
Many have started down the road of rolling out non-trivial Internet-of-Things platforms, and you may have, too, to some degree. So, what happens next? Here are some things to think about – particularly in terms of handling all that data, noise and all, coming back live from your IoT network of sensors and gizmos. In short, as …
is the more we work towards unstoppable, data loss sensitive systems, the less the developers of said systems realise you need some sort of hot maintenance functionality for all layers of the implementation stack. The objective of build for deployment, not build for sustain becomes a much greater issue in this scenario.
In many cases of me looking at pitches for these platforms as soon as I ask how to I keep it supported the fixed sales smiles are rigid and answers of "we'll get back to you" start coming out.
Perhaps I am just getting old and fussy, but the old issues have not really gone away...
Y'know, once upon a time, people in car factories and power distribution networks and so on used to do all this with Modbus and some half duplex 9600baud RF modems and a suitably configured SCADA/HMI/alarm-handling package or two. By engineers, for engineers.
Then along came BT, MS, and Similarly Awful Players, and changed the meaning of "telemetry".
Oh well. What could possibly go wring.
one way to accomplish a nice high speed moving average (using integers, even) would be to do something like this:
int accum = 0; // accumulator, in this case stores "impossible" value
...
void loop(void) { int value = read_data();
if(!accum) accum = value; else accum = (accum * 7 + value) / 8;
send_data_to_the_web(accum); time_delay(); }
that way you can respond quickly to changes, but also use a moving average to help get rid of noisy data. It's also simple enough (using integers) in a way that approximates a weighted moving average with an infinite period. [I've done things _like_ this for _years_, so it's nothing new, really]
That being said, it's a possible solution for the data 'noise' and averaging problem. The sensor would do the calculation and send the 'crunched' value to the server. If you need the raw value too, you can still send both. But this also makes scanning for 'alarm' conditions easier, because the 'crunched' value will already be stored on the server [well, ideally].