Using PLEG for Rate of Change Calculations

Hi All,

Does anyone have an example of how to do a ‘rate of change’ calculation in PLEG - specifically something like:

If Humidity increases by more than 5% in a 5 minute period.

To do this you’d presumably need a way to keep some previous values, the time they were sampled and compare them to the most recent value and calculate the difference.

The “optimum” way, from a signal processing point of view, is to use a Kalman filter. This is a recursive algorithm, so only requires minimal storage. If you’re happy to save a block of data, then simply a least-squares fit may suffice. There is also a recursive implementation of that. Simply differen in two measurements is unequivocally the worst way to do this.

It may be overkill, but if you want to avoid false-alarms, you need to do it properly. Performance will depend on how noisy the sensor is, your sampling rate, and the dynamics of the system you are modelling - normally a single exponential response model is sufficient.

Implementation is almost trivial, it is the details of sensor, noise, and system, which takes a little thought and understanding. Humidity is a notoriously hard measurement and ‘cheap’ sensors have poor characteristics.

Input Parameter
HumiditySensor - Your Sensor Value

Input Schedule
Periodic - ON: interval, every 5 minutes, off interval 1 second

DeltaValue HumidityValue > LastValue ? (HumiditySensor - LastValue) : (LastValue - HumidityValue)
BigChange Periodic and (DeltaValue > (HumiditySensor * 5 / 100))
LastValue Periodic ? HumidityValue : LastValyue

Thanks Gents!

@akbooer - refer attachment with graph, the yellow plot is my humidity and the red is the light level (indicating primarily when the heat lamps are on and we’re having a shower). So the spikes in humidity bounded by the red columns are what I’m trying to detect. 2 showers had this morning.

@RTS - I haven’t tried your code yet. But will give it a go and report back. Hopefully it’ll pick up the spikes - worse case scenario my extractor fan will go off half cocked. :slight_smile:

Are you able to post or PM the raw data? Then I could give it a go so that you could see the results.

Are you able to post or PM the raw data? Then I could give it a go so that you could see the results.[/quote]

Hi Akbooer - data in the CSV attached, added another day on top of that chart so there’s another event to test against.

Values are Humidity, Light, Temperature. Humidity is what I’m focussing on.


So here’s a plot of the data and the estimated rate of change from a Kalman filter. The implementation is currently in Matlab, but translation to Lua is straight-forward. There is one free parameter which is related to the ratio of the measurement noise and the humidity variance, but you can think of think of this as a sort of response time.

You’d call the filter estimator once per new humidity variable and it would return the best estimate of humidity and rate of change.

Nice theoretical analysis.

Now from an electrical engineers practical perspective …
This profile very nearly matches a HIGH PASS FILTER … the simplest to implement is a Differentiator (which the PLEG code I sent is an example of) where the sample interval is sufficiently long.

Most battery devices do not have a high report rate for things like humidity, and as a result if the reported value had any significant noise component the raw value would be useless … so I do not think this is a problem.

As an Engineer, often the simple solution is good enough.

I wouldn’t argue with any of that, although I might add that the Kalman filter also maintains a variance estimate of the state vector, which can be very useful in understanding what threshold level to choose to yield an acceptably low false alarm rate. Hardly an issue for an extractor fan, though.

You guys are great. I can practically hear my IQ raising when I read your posts.

That Kalman filter looks spot on - but I guess it can’t be distilled down to a few PLEG conditions? :slight_smile: A plugin that takes an input and lets you set parameters with trigger events that could be used in a scene/PLEG would be awesome - or I guess the LUA code could be used in PLEG itself?

I tried RTS’s Differentiator code, using a Period of 3 minutes (humidity sensor has 60 second updates) and it’s been pretty solid on picking up activity in the shower after it’s been on for 5 minutes. Is it fair to say that improving the detection speed would be a matter of more frequent sensor updates and smaller sample period?

Also it then repeats the alerts as the humidity continues to rise - this isn’t really an issue in my scenario, but if it’s easy to filter out further triggers that might be handy.

For the readers at home, here’s the PLEG I’ve got set up so far (note that PLEG will spit out a compare to nil error until the humidity changes value).

HumiditySensor Bathroom (Humidity)[940] CurrentLevel[urn:micasaverde-com:serviceId:HumiditySensor1]

sBath1_Humidity_Sample Interval 00:03:00 None Interval 00:00:01 None

DeltaValue HumiditySensor > LastValue ? ( HumiditySensor - LastValue) : (LastValue - HumiditySensor )
BigChange sBath1_Humidity_Sample and (DeltaValue > ( HumiditySensor * 5 / 100))
LastValue sBath1_Humidity_Sample ? HumiditySensor : LastValue


I have a follow up question on this - I’m using the same mechanism on some power meters which are watching each of my 3 phases.

What I’m doing is looking for a 1000W increase inside 60 seconds across all 3 phases. Which means the aircon is now on. The PLEG logic as it stands detects both increases and decreases. It looks like the Deltavalue condition above is effectively ABS function?

What would be the syntax if I wanted to separately detect an increase and a decrease?


Using your Humidity Example:

LargeIncrease (HumiditySensor > LastValue) and BigChange
LargeDecrease (HumiditySensor < LastValue) and BigChange

These would go BEFORE you update LastValue and AFTER you compute BigChange