We’ve been testing successfully with Octave, getting raw sensor data through to our cloud stack.
Now looking suggestions as we refine and port over our logic from a competitor’s platform. Our challenges are more to do with understanding when best to use Octave features such as querying buffered data, filtering, etc. We think what we’re trying to do is a fairly common scenario, but we couldn’t find many examples. Thank you for any tips:
Goal: Read a sensor value periodically, and determine at the edge if the value surpasses a threshold, sustained over a period of time. Retain only these values and send them to the cloud at certain times throughout the day. Here we go:
var X is the resource event value from the sensor
var Y is a sensor value threshold we define
var C is a counter
var T is a time value (e.g. 180 seconds = 3 minutes)
Get a resource event value X every 5 seconds
While (X > Y && C <= T)
{
Retain the value of X (e.g. push X into an array, maybe defined as a Virtual Resource JSON type)
Increment the Counter by 5 seconds (e.g. C+=5)
}
Send these values over the cloud several times a day
Bonus: ULPM or sleep to conserve msgs and batteries during off-hours
What would help is to know what are the key features of Octave which we can explore and structure our business logic to help us achieve this?
set a 5 seconds period counter with /util/counter. Set period to 5 and enable to true
set an edge action Observation on /util/counter/value
in this edge action, read sensor value, if X > Y then read the JSON virtual resource, add the new value, update the Virtual Resource
set another edge action Observation on /util/counter/value
in this 2nd edge action, if counter value is a modulo of 180, push to cloud the JSON virtual resource, and empty it.
I think it might also be possible to use throttling option in the 2nd observation.
It should be also possible to set the first obs on the sensor/value resource if its period is set to 5 seconds.
Thanks for the tip, Nicolas! We did not think about the util counter for this application.
In practice, would it be necessary to then set the sensor’s period value equal to the /util/counter period?
Or does Datahub.read("/io/some-sensor/value", 0) poll the sensor value on-demand? If this is true, could the sensor’s period value be set to 0, and thus maybe saving on some power consumption?
The sensor’s period value does not need to be linked with the counter’s period. But obviously in your case it’s useless to set it to a smaller value than counter’s period one.
Datahub.read does not poll the sensor value on demand, it gets the latest value from the sensor, this value being refreshed according to the sensor period.