fHelper on Node-Red

If using Node-Red to handle fHelper an algorithm to handle the alarm is needed.


Here a brief description of the algorithm implemented in Node-Red.
The server is controlling a LED on the client to notify the plant need to be watered.


The reading from the soil humidity sensor is quite erratic, even after reading it 10 times every 25 seconds and calculating the average, the variation remains quite high.
Because of this I estimated to consider the plant in need of water if the measurement from the sensor remains above 2500 for at least 30 readings, i.e. for about 12 minutes, will be probably increased to 72 (30 minutes) in the final version.
Every reading below 2500 will reset the counter.
And also the On signal to the LED is sent only once every 12 hours.
The LED can be turned OFF only from the UI manual control on the Node-Red website.
Here a high level logic flow.

On Node-Red is easy to use two functions.
One that receive the messages from MQTT about the humidity.
This function will increment a counter every time the reading received is above 2500 and reset the counter when the reading is below 2500.
This function will send out a message containing the counter.
The second function will receive the counter from the first one and it will implement the logic to send out the "on" message toward the LED when the received counter is above 30 (or 72 in the final stage).

The Node-Red flow is event driven, i.e. everything is based on the reception of the messages from MQTT.
Let see an example of the Node-Red visual blocks.

The graph need to be read from left to right.
The block Soil Humidity is the MQTT receiver topic for the Soil Humidity.
Every 25 seconds a MQTT message containing the humidity value (between 0 to 3500) is received.
The received value is passed to 5 blocks.
The msg_payload is just a debug block, it shows (if enabled) the humidity value.
The Gauge block shows on the UI the last received value of the humidity.
The CheckWater block contains the first part of the logic, the one that increment a counter.
The last tow blocks (Last 3 hours and Last 24 hours) create a graph of the received values.

The CheckWater block send out the counter value created.
This value is sent to two blocks.
Counter, a graph block, in order to see the counter value changes and the sendAlarm block.
The sendAlarm block contains the logic to send out the on command.
This is sent to 3 blocks :
- msg_payload
- LED status
- esp32/output
The first one is a debug block, just to show what the function sends out (or not sends out).
The second one shows on the UI the status of the LED (also manually controlled by the block LED on the left) and the last block sends the command to the MQTT output topic.
Basically allows to control a LED on the client.

This is the UI generated by the code :

Is possible to see the Gauge and the three graphs.
On the left the Activate block that shows the LED manual control and the LED status.

Lets take a quick look to the function CheckWater :

var count = context.get('count')||0;

if (msg.payload > 2500) {
    count = count + 1;
} else {
    count = 0;
}

// store the value back
context.set('count',count);

var counter = {payload: count};

return [counter];

We initialize a variable called count if not assigned (i.e. the first time the code runs).
If the received value (msg.payload) is above 2500 we increment the count variable, if not we force it to zero.
Then we save back the value on the context area and prepare a message (called counter) with the count value to be sent out when we return.
That's it, very easy and neat.

Just as update, I added a block to linearize the readings and simplify the testing.
I also add a button on the design control in order to reset the counters and an email output controlled by a test block and the sending message.

The idea is that the system detect the plant in need of water, will turn on the LED on the client, on the UI and will send an email to somebody to notify about the need of the plant.

This is the resulted graph on the UI showing about 24 hours activity.
Notice how unstable are the readings.

Some more adjustments are required to achieve a "dry plant" detection.