Skip to content

derived device 'watering_sys': case study

Jump to bottom
Marco Sillano edited this page Apr 9, 2021 · 13 revisions

derived device 'watering_sys'

Time changes requirements and options, so even good designs become obsolete when new solutions are possible. This is the case of the Sonoff-watering (2018) project, my terrace irrigation timer. Points for improvement to achieve a safer and "greener" irrigation device:

  1. Remote control from any distance for emergencies.
  2. Weekly programming.
  3. Irrigation controlled by the weather.
  4. Fault tolerance.

terrace irrigation specifications

  1. The days of irrigation must be user chosen: this is a function of the local regulations, the year period, and the plant's exigencies.
  2. Another user value, roughly corresponding to the max volume (liters) of water in a week, controls the timer.
  3. The real irrigation volume will also be controlled by environmental variables (temperature, humidity, ...) from tuya sensors.
  4. Irrigation must be carried out at night, to reduce water evaporation, roots thermal shock, and the nuisance of leachate to the housemates of the floors below.
  5. The terrace irrigation nighttime is better if divided into many short periods (cycles) because a single long period does not favor the soil absorption and increases the leachate.
  6. A short ON period, during the day, at the time I am at the home, is useful for monitoring the status of the tubes (the tubes often come off and the nozzles clog).
  7. The project, also if targeted to my terrace watering exigencies, must be as 'general-purpose' as possible.

project

Between many options I chose:

  1. To use a smart_breaker as 'watering timer', because its 'circulate' mode simplifies the project and guarantees data memorization.
  2. A fuzzy logic algorithm takes into count all environment variables available (for now 'temperature' and 'humidity'). I choose a 'fuzzy' logic control because it is easy to customize and expand. The result is an 'adjust' factor (0...100%) updated once a day.
  3. All definitions required by the fuzzy engine are in a variable called fuzzyset in the PARAMETERS node. The fuzzy set can be tested and tuned using an offline application, "fuzzytool".
  4. The user defines the watering days and max. 3 intervals of time for the irrigation.
  5. In all irrigation intervals, the timer cycles between an 'ON' phase, with a fixed duration, and an 'OFF' phase, with variable duration calculated by the timer: this way we have a strong water control via pulse-duration modulation (PDM).
  6. Fault tolerance. The maximum cost of malfunctions is not the situation of lack of irrigation (only the value of the plants) but is the situation of too much water (it can cause significant damages to other apartments).
  7. Accident scenarios:
    • AC off: no irrigation and nothing to do, the solenoid valve works at 220 V. When the AC is restored, the timer resumes all data.
    • WiFi off: the 'watering timer' guarantees the data storage: the last cycle will be repeated every week.
    • tuyaDAEMON shut down: same as WIFI off.
    • broken water pipe: as we know it, we can set OFF the timer from anywhere.
    • watering timer stuck OFF: no irrigation.
    • watering timer stuck ON: the only solution is redundancy: a second emergency switch normally ON: as we know, we can turn the emergency switch OFF from anywhere (think the emergency switch as an insurance fee).
  8. I chose a second switch, as 'watering switch'('Smart_Switch01'), used to give power to the 'watering timer'. This solution allows:
    • to cut-off the irrigation in emergencies.
    • to suspend for some time the irrigation without de-programming the 'watering timer'.
  9. This watering system is a derived device tuyaDAEMON with a node-red user interface, because its features are not possible using only the "automation" by smartLife. I used in this project some OO tecniques.

derived device definitions

In any custom device, we can choose the DPs. Using the inheritance of some dp from the base devices, I defined the following criteria:

  • ON/OFF main control (for long periods and emergency), UI and TRIGGER
  • TOGGLE the current watering status, UI and TRIGGER

Dynamic control:

  • status of the 'watering timer' and the 'watering switch' (UI)
  • water/week, liters (0...1000) (UI)
  • days of the week (UI)
  • 'adjust' (0..100%) internally calculated by fuzzy logic control, once a day (e.g. at 19:30)
  • skip irrigation for frosts at night and rain, limits defined in PARAMETERS.

Day cycles definitions. We can have until 3 irrigation intervals per day (I use only 2: day and night):

  • start time HH:MM (UI)
  • end time HH:MM (UI)
  • on-time constant, defined in PARAMETERS, e.g. 6 min.
  • off-time variable, calculated by the fuzzy control ('adjust') to get the required PDM.
  • Irrigation is disabled if no days or intervals are chosen, or if the actual Tmin is too low or the RHmax too high.
  • To disable irrigation all the intervals are set as not "active" and the real values are stored in three 'store' variables.
  • All timing info, the 'store' vars, plus water/week and last 'adjust', are handled as a unique variable, 'circulate', in the 'watering timer'. This value is stored in non-volatile memory, so it can be recovered also after a power off or a node.red 'Deploy'.

The detailed definition of all DPs is on derived device 'watering_sys' definition.

watering system implementation

The 'watering system' device is equipped with a simple configuration interface (node-red) that can be used locally via WiFi from any smartphone. Some commands can be done by 'smartLife' via TRIGGER or directly to base devices.

  • note: By using a 'dynamic DNS', such as no-ip, you can get public access to your node-red server from anywhere. This can be risky, so you need to think carefully before starting this route.

  • Many nodes implement the UI elements.

  • Three function nodes handle the incoming request: one for the 'inheritance', one for the 'use', and the last for custom commands.

  • Some function nodes solve specific problems:

    • "status msg" generates status messages for the UI.
    • "timer button" and "main button" handle the appearance of the buttons on the UI.
    • "fuzzy" implements the irrigation controller, updating the data any 24h ('SET TIME' acts as the trigger).
    • "flow store data" saves UI data to a flow variable.
    • "process data" generates the compact structure 'circulate' from UI data and Fuzzy calculations.
    • Reset (RST) uses some nodes to set up the switches and restore the configuration.
    • Clear (CLR) initializes the graph.

PARAMETERS

In the 'parameter.watering' node we can found some values that influence the 'watering_sys' device and that can need some tuning:

  • "maxwater":1000, same as the max.range value in 'slide' node. Change both if required.
  • "litresminute":2.5, for the conversion time/volume. Adjust to the measured value in your system.
  • "ontime":5, minutes, cyclic watering ON time (the OFF time is calculated).
  • "OFFtemperature":4, if the minimum temperature is less than this value, no irrigation (risk of frost).
  • "OFFRH":90 if the maximum RH is more than this value, no irrigation (it's raining).

In the 'parameter.fuzzyset' are all information used by the fuzzy engine.

  • You can save it in a file (change path and name in the "save path" node).
  • You can test the saved file using the 'fuzzytool' web application.
  • Use 'notepad++' and the 'JSON Viewer' plugin to edit the fuzzy-set file in an easy way.

The time for run the fuzzy engine is defined in the 'SET TIME' timerswitch node.

required nodes

Install following nodes in palette:

  • node-red-contrib-config
  • node-red-contrib-timerswitch
  • node-red-dashboard
  • node-red-contrib-ui-led

fuzzytool

This tool shows the fuzzy-set and allows tests. Use it to fine-tune the fuzzy engine. It is easy to add or modify the weather factors used.

Unzip the file in the WEB server working dir (e.g. D:\xampp\htdocs\fuzzytool ).

devices

Watchdog02 (custom)

Clone this wiki locally