Greenhouses automation botnet. Need your advice.

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
Post Reply
navy
Posts: 15
Joined: Sat May 04, 2019 6:37 am

Greenhouses automation botnet. Need your advice.

Post by navy » Mon May 20, 2019 9:56 am

Hi guys!
I need your opinion about my project's architecture.
We have a greenhouse complex with 4 greenhouses and 1 seedling lab.
For now there no automation in greenhouses and some automation in seedling lab with sonoff 4ch pro.

I am planning now how to build a greenhouse automation system on esp32 and esp8266 boards and micropython on it.

My conception.
- 2 categories of boards:
"Data senders" boards and "Action boards".
Several esp8266 with bme280 and ds18b20 always send data thru MQTT.
Each agregate in greenhoues has own action board. It will power-up water pump, open doors, starts vents and etc.

- Cluster with 2 rapberry pies will act as MQTT server, task server and Graphana host.
One Pi is a master and second Pi is a slave. Hot backuping for fast change if master will physically broken for a some reason.
On RPI will be touchpad screen and app on Kivy framework to full control a system.
Touchscreen https://www.aliexpress.com/item/5-5inch ... 46179.html
We can use touch interface in front of RPI or we can do a remote connect by VNC to control system outside a greenhouse.

- There a 100% wifi coverage in each greenhouse and 100mbit ethernet connection between routers an RPI. All ESP will have stable powering.

My general idea is to develop a task generating system at server and task scheduling system at ESPs.

Explanation.

We have 4 greenhouse and we will grow a 4 types of flowers. Our bio engeneer develops a grow plan for each flower culture.
Water schedule, temperature mode, nutrient mixing in water and etc.
Growing duration is about 4 month. So, we just generate day-by-day schedule for each "Action boards".

Every day each action boards knocks to a server and get bundle of tasks for today.

For example ESP with ID 57575 tell server:

Code: Select all

[{"get_tasks": 57575}]
Server answers:

Code: Select all

[{
    "task_id"   : 1,
    "mcu_id"    : 57575,
    "light1"    : "on",
    "time"      : "8:00"
    },
    {"task_id"  : 2,
    "mcu_id"    : 57575,
    "light1"    : "off",
    "time"      : "18:00"
    },
    {"task_id"  : 3,
    "mcu_id"    : 57575,
    "pump2"     : "on",
    "time"      : "13:57"
}] 
All tasks starts in multithread mode. After task is done, ESP reports on server.

Architecture is very similar to famous botnet systems (Zeus, SpyEye and etc.)

All logics and decision making will act on server side, ESP just simple do everyday routine.
All ESP IDs we comment on server panel and can see detailed statistics about connection and task progress.

Data senders boards just send sensor data to MQTT.
But for action boards i plan to write a socket server to delivery tasks instantly.

Please give me any feedback about my vision, aspecial about "socket server with json" VS MQTT protocol"

Image

WRR
Posts: 7
Joined: Wed Jan 09, 2019 8:33 pm

Re: Greenhouses automation botnet. Need your advice.

Post by WRR » Mon May 20, 2019 3:20 pm

Very cool! Autonomous or semi-autonomous gardening and farming is a really exciting application of embedded devices.

Good idea to use a Pi as a hub - you might also want to add a sort of 'heartbeat' notification to each ESP board so you can be quickly alerted if/when a node fails.

Also, for environmental monitoring, keep in mind that ESP32 and ESP8266 modules heat up a fair bit when their radios are on. Putting your sensors on the same board as the module or inside of a small enclosure with it can set your temperature readings off by a few degrees.

I don't have enough experience to give you any better advice, but hopefully people with more experience in agricultural applications can chime in. It looks like a nice idea and setup, good luck!
Remember, the "S" in "IoT" stands for "Security".

kevinkk525
Posts: 510
Joined: Sat Feb 03, 2018 7:02 pm

Re: Greenhouses automation botnet. Need your advice.

Post by kevinkk525 » Mon May 20, 2019 3:39 pm

This is a very interesting project!
I'm currently building a small Greenhouse on my balcony... Got almost all libraries ready for it.

Why not send the current task by mqtt instead of all daily tasks? I see no need for a separate socket server (but could point you to a library pythoncoder and I created). You can just use mqtt and let a server application send the current task to the appropriate device.

For example:
I use homeassistant for automation and to have an overview of all my devices/components. Each of my ESPs uses my pysmartnode framework (which is almost supporting homeassistant mqtt discovery) and all the connected components are configured for each ESP. ESPs are simply sensors (sending sensor readings) and actors (switching a pump on and off) but don't do anything on their own (except sending sensor readings) and don't follow any logic. They just wait until they get the command over mqtt to switch the pump.
This way the whole logic stays in homeassistant and can be changed instantly. You could even use different caldav calendars to control different devices (e.g. a pump calendar. homeassistant will switch the pump on whenever an appointment is scheduled), haven't used that component yet though. Just an idea.
Kevin Köck
Micropython Smarthome Firmware: https://github.com/kevinkk525/pysmartnode

User avatar
pythoncoder
Posts: 3659
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Greenhouses automation botnet. Need your advice.

Post by pythoncoder » Mon May 20, 2019 5:43 pm

@navy I would recommend using uasyncio rather than threading for reasons you'll find here - follow link to tutorial.

I agree with Kevin (@kevinkk525) that it's worth considering MQTT to communicate with the ESP's. Yours is exactly the kind of application which IBM developed MQTT to address.

One issue to consider is where the intelligence in the system is located. The MQTT approach, along with your original approach, assumes a fair amount of code on each node. An alternative approach which Kevin and I developed is described here which minimises the code on each node. Kevin's framework builds on this (he is best placed to provide details).

Another issue with high reliability applications is the handling of WiFi dropouts. These do occur and the official MQTT libraries do not cope well with them, especially with qos > 0. The solutions Kevin and I have developed involved considerable effort in ensuring recovery from such events. This document discusses the general issues. Essential reading if you plan to develop your own socket code.

If you go the MQTT route, I suggest you look at my resilent MQTT driver which also aims to overcome these issues.

Note that the above solutions all use uasyncio for concurrency.
Peter Hinch

Post Reply