[Feature Request]: Detection sensor accumulate count between reports

[seagull9000]

Platform

other

Description

Some sensors may trigger a burst of activity that would not be friendly to the mesh. For example, a rain sensor may trigger rapidly during a torrential downpour The minimum reporting interval would mitigate this impact, but with the current functionality, valuable information would be lost.

Proposed enhancement:

1. Should have: Accumulate a count of sensor activations between reports. This could be a lifetime count (not reset after each report) so that missed reports will not compromise the integrity of the data (client application can just subtract current received from previous received).
2. Nice to have: Attribute a quantitative value for each activation. For example, for a rain gauge, the amount in millilitres per activation could be entered and accummulated as in 1.

The CLI/API could have a function to reset accummulated values to 0. This would provide flexibility so that client applications don't have to worry about starting values.

[garthvh]

There is already an interval for how frequently the message is sent out, this is how you reduce mesh traffic, it also no longer works on the default channel if you upgrade your firmware.

[seagull9000]

There is already an interval for how frequently the message is sent out, this is how you reduce mesh traffic, it also no longer works on the default channel if you upgrade your firmware.

Yes, thanks, but the issue is with the loss of data if multiple detections occur between the minimum interval. I tried to find the relevant protobuf to see if a count already exists, but not sure which it is.

The key point is that messages can be missed, so if the count is important, we can't rely on the client application to keep track of it if the message is lost.

[seagull9000]

Unless I have completely missed something here, the current functionality would mean that a repeating event could not be relied upon, so additional hardware would need to be implemented to keep track of the count.

So I don't understand why this is closed without discussion.

[fifieldt]

@seagull9000 - converted this to a discussion ... so discussion can continue :)

[GUVWAF]

I do see the value of a counter for the number of detections within the transmission interval.

[seagull9000]

The feature would support any measuring devices with pulsed output such as energy meters and flow meters, just to add a couple more to the use case.

If implementing a counter breaks the Detection Sensor module, then perhaps a new Event Counter module could be on the cards?

[GUVWAF]

The DetectionSensor module is intended to be a very simple module, using text messages. Parsing the text message with the counter is likely not desirable.
The RemoteHardware module is more advanced and probably more suited for things like this, but it's not so easy in use.
I'm not sure if yet another module is the way to go, but the DetectionSensor module should be kept simple.

[seagull9000]

I see what you mean.

What if we keep the DetectionSensor Module much the way it is, but add an internal counter that can be polled from the client application? That way protobufs and set up configuration won't need to change.

My thinking is that a GPIO detection occurs, a message is sent, as happens now, but increments a lifetime* counter. held on the node.
The client application is in control of polling the node for the counter value at its own interval.

The benefit of this approach is that missed messages will not result in unreliable/unusable data.

I'm not familiar enough to know what mechanism/message format should be used for polling, but an existing method would be preferred. We just need the count.

*If maintaining a counter between restarts / power cycles is impractical, then setting to zero on boot would be fine, I think. The application could test if the counter is less than the previous value and manage that accordingly. That may result in some edge cases where some data is lost, I don't think the aim should be to have absolutely perfect data - just meaningful data.

Thoughts?

[GUVWAF]

Polling would need its own protobuf message to indicate that you are specifically asking for a DetectionSensor counter report, and then the report itself should probably be its own protobuf message.

@thebentern what do you think about a general PROTO mode for the DetectionSensor module that allows for things like this? Then, instead of sending a text message upon detection or at the status update, it could be a dedicated protobuf message containing a better parsable status indicator and e.g. also this counter value?