Interested in slowing down iDigi data samples

Suppose your sensor produces a “new” sample every hour, but the actual value rarely changes. If so, then you might not want to pay the cellular charges to update iDigi hourly.

It would be cheaper to follow a logic which says “Upload the data at least once per day, or if any value changes by at least 1.0 units, but never upload new data faster than once per 59 minutes.”

I created a simple “filter_device” which does this. It creates a “mirror” device with selected channels. It “subscribes” to those channels and suppresses new samples unless selected criteria are meet.

There is a readme in the ZIP file. Please give it a try and offer feedback. [Thanks, Lynn]

Great device Lynn - works perfectly where I’m using it. Only thing to watch out for if using it for battery monitoring as there are some name/logic differences in the device drivers.
For example Massa uses “battery”, watchport “low_battery”, aio “battery_OK” etc.

Thanks for the feedback & that it’s useful - I like to do useful things :slight_smile:

The difference in names is a philosophical debate within the iDigi developers. Some people like “standards and rules”, which risks iDigi development morphing into Windows MFC complexity - others like the do your own things.

So I guess a second use for the “filter_device” would be to normalize the names. It wouldn’t take too much work to invert a logical condition, so that you could create a “battery_low” channel for all products. You could even add an AND/OR/NOT functions to the process list, supplementing the existing above/below functions.