Moving Average Node returns NaN after some time

General
1

Hello, I want to plot soil moisture published on MQTT on a graph, which works well in Node Red. Unfortunately the sensor values seem to jump a round a bit in a short timeframe so I wanted actually use the moving average 100 values and think the Moving Average Node is the right Node to do this.
This works fine after deployment but no matter what I do after some time (sometimes hours) the Graph of the unfiltered (top Graph) values keeps plotting but the moving average node seems to always deliver NaN.

Is this a bug in the Node or what am I doing wrong ?

image
image1426×651 50.6 KB

2

Alas I fear it needs a bit more debugging.

Put a debug node on the output of the tripple node.

I suspect somehow it is sometimes not putting out a number payload.

3

First of all, I think you need to track-down why you are getting NaN - as this indicates a non-number.

I'd start-off by putting a 'debug' node on the MQTT-In node and see what sort of data is there.
You could also use Mqtt-Explorer to "sniff" what is happening.

Note: You could set the 'Output' of the MQTT-In node to 'auto-detect' and then remove your 'json' node.
mqtt-in
If you are getting spurious readings/values, you could apply a test or filter like... "if the current reading is 10% or 20% different to the last reading ignore it, otherwise pass it". This obviously depends on how often you take a reading and how much the value could normally change between readings.

If you can share your Node-RED flow I'm sure people will take a look and suggest other things to try.

4

Thanks for the replies. Debug is a bit tricky as mentioend this sometime only happens after hours and the unfilterted Graph seems to be processing fine - it might be more robust though

Would someting like that work inside the Tripple node , i.e. if a non-Number comes in from MQTT stop processing the message ?

if (typeof msg.payload === 'number')
{
msg.payload = msg.payload*10/3
msg.topic = "Bodenfeuchte";
return msg
}

5

The latter part looks good - I'm guessing.

(German)? Or a brand name?

Alas the debug (no matter where you put it) is a thing that is not nice but alas sometimes needs to be done.

Another way to do it - which will need a bit more work - is to LOG the data.

So you get the input - either at the MQTT output of at the tripple output and send it to a file.

Then after a day or so, you look at the data.

Or, you add code so when you get an error, you are notified and you look at the log file at that point.

6

I think it's the data being sent by the Shelly Plus soil moisture sensor.

Gut feel is the voltage goes out of expected range and the Shelly box gives an error when the reading is duff...

Personally I would check the data straight off the sensor (i.e. before it even gets to the MQTT server) but that may not be possible here - in this case I would check for a valid range and reject anything out of spec ASAP in the flow (e.g. after the MQQT collection or JSON conversion). These values can be logged to a file and warning issued if you get too many of them per day or in a row - both signs of a sensor going faulty or needing a clean.

(Living here in a hard water area kills capacitive and resistive sensors very quickly)

7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.