Open techsurrusr opened 2 years ago
That's actually a good idea. I have seen spikes in input values from my sensor, they are present in both the real sensor and also transferred to the virtual sensor. Setting a max anticipated value we could at least get the input error excluded from the virtual sensor. Those error values are always way off the charts, so it shouldn't be to hard to identify. But I don't think a relative change from previous value is a good thing since value can go from 0 to 1 and that would be an infinite change. I would say setting a max anticipated power (W) value as a parameter in the script the user could change it if I set it to far from usual draw on that sensor.
The spikes that I see are only from 433MHz sensors were I either get 1) ridiculous values based on radio interference (or something) and these values you could directly replace with value 0 and 2) then I have spikes which are with 'normal' values but still a massive spike for a single pulse reporting. I'm using the Wireless Pulse Counter (WPC3) which send the number of pulses based on time interval including accumulated total of pulses which is causing my spikes. So either a % based allowed deviation together with a max value of allowed deviation would do the trick.
Below image is an example of massive spike recorded by Domoticz:
And for more 'within range' but still far from correct and mostly based on that Domoticz was restarted and based on how the WPC sensors sends the data package it can typically look something like this:
Nice working script! Have you considered adding parameters for handling input errors from sensor based on that the actual value can deviate either X% or deviate max value from most recent value?