You will also need to have the ability to prevent deep sleep while you debug it and do any OTA update.
Automated plant watering
Looks like most of the work has been done in the link above.
Fine point. So the wakeup button is also a debugging button now. It makes the thing connect to wifi as the first thing and also wait an extra 5 mins or so before going to sleep again. For longer duration debugging, the wait can be increased first.
Looks like this:
(edit: yes I know. You cant connect to wifi and then wakeup after. But I suppose you get the idea anyway)
Strange, this is the exact same link I used to order mine…
Just wondering, why should it wait 5 minutes if “Was button wake up signal” is true? Why can it not just go into long sleep straigh away. Maybe there is a good reason, I just don’t know? pls let me know 
It’s because we want to wait for an OTA update. In that update you can extend the 5 mins so you can work with the code, debug etc. If you don’t have the wait, chances are you can’t make it with an update before the ESP is sleeping again.
1 Like
mqtt:
broker: 192.168.1.7
username: Redacted
password: Redacted
birth_message:
topic: solarplantwatering/birthdisable
payload: disable
will_message:
topic: solarplantwatering/willdisable
payload: disable
discovery: true
discovery_retain: true
on_message:
- topic: solarplantwatering/ota_mode
payload: 'ON'
then:
- logger.log: 'OTA Mode ON - Deep sleep DISABLED'
- deep_sleep.prevent: deep_sleep_1
- topic: solarplantwatering/sleepearly
payload: 'ON'
then:
- deep_sleep.enter: deep_sleep_1
#I have set a default run duration and sleep duration in case seomthing fails
deep_sleep:
id: deep_sleep_1
run_duration: 60s
sleep_duration: 30min
I do it all with MQTT . I can send a message from homeassistant fast to turn off deep sleep for OTA and for when I want the pumps to work.
- id: '1650105153163'
alias: Solar_watering_ota-ON
description: ''
trigger:
- platform: state
entity_id: input_boolean.solar_watering_ota
from: 'off'
to: 'on'
condition: []
action:
- service: mqtt.publish
data:
topic: solarplantwatering/ota_mode
payload: 'ON'
qos: '1'
retain: true
- service: mqtt.publish
data:
topic: solarplantwatering/sleepearly
payload: 'OFF'
qos: '1'
retain: true
mode: single
------------
- id: '1650105638216'
alias: Solar_watering_ota_OFF
description: ''
trigger:
- platform: state
entity_id: input_boolean.solar_watering_ota
from: 'on'
to: 'off'
condition: []
action:
- service: mqtt.publish
data:
topic: solarplantwatering/ota_mode
payload: 'OFF'
qos: '1'
retain: true
- service: mqtt.publish
data:
topic: solarplantwatering/sleepearly
payload: 'ON'
qos: '1'
# I have this set to true below but I think it should be false
retain: true
mode: single
This is 2 automations I use to turn on/off the OTA mode (really just deep sleep disable). I suppose I could just turn these into scripts as I have to set up an input boolean to connect these two automations to be a switch on/off. I can turn the OTA mode on at any time and the next time the esp comes out of sleep it doesn’t go back into deep sleep until I turn off the switch. This way no need to wait 5 mins to see if I want to do OTA. I use this a lot as I do a lot of tinkering with it. The sleepearly is sent when homeassistant gets the battery reading and can save seconds off being awake.
1 Like
Okay. But the device we are using right now doesn’t support MQTT. If we’re to use that we would have to switch board (and redisign the PCB to fit the new board).
Yes it does. What makes you think mqtt wouldn’t work?
I just got myself an update on youtube. I thought MQTT was like Zigbee but just a different standard, but it is not. It’s just a different way of using wifi.
Does ESPHome also make each client a broker so that the networks reach is extended with each device added? That would make our pot usable in the garden as well. I could even have some nice flowers in my garage 
I don’t think ESPhome has mesh yet.
The longer the esp is awake the quicker it drains the 18650. WIFI is a big drain on the cell. The sooner you can connect , do the job and go back to sleep the better.
Static IP is quicker than DHCP. Fast connect can help but I don’t use it as I have more than one router using the same SSID and it would sometimes connect to the weakest signal not the
closest and strongest.
I set the output power as low as possible. You can see below Where I have set my output to 13dBM and the router still receives at -45dBm (you can go as low as 8dBm. Experiment.). This saves 80mW over the default 20dBm output.
# Enable logging. Leave it in DEBUG until get it up and running but switch it to INFO later to save resources and leave the ESP more stable.
logger:
level: INFO
ota:
password: "Redacted"
wifi:
ssid: "Redacted"
password: "Redacted"
manual_ip:
static_ip: 192.168.1.81
gateway: 192.168.1.1
subnet: 255.255.255.0
dns1: 192.168.1.1
dns2: 8.8.8.8
output_power: 13dB
fast_connect: on
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Solarplantwatering"
password: "Redacted"
ap_timeout: 15min
1 Like
Okay. Sounds like you get to be this projects connection&communications chief officer (or you can make an even fancier title if you like)
On that note, should we try to formalize the who-does-what? Would making issues in Git work for you?
Putting everything in github would be good. A BOM, a wiring diagram. I was thinking of dping the wiring diagram tomorrow.
I have little experience with Github but I’m sure I could work it out.
Yes having a schematic would help to know which pins are being used. In the code I’m just putting in the pins I used. I don’t have your hardware. I don’t have any sort of water sensor.
I have 3 switches. A software reset switch as I don’t have external switch and 2 motor switches. I have set the motor switch to not run for more than 400s.
In the initial stages sometimes I couldn’t turn the pump off and it would pump out 20L before I got to it. I pump to 4 pots which have drainage holes.
60 seconds might be better for an individual pot. When you run the pump you will need to measure how much water it pumps in a given time. The normal watering time is controlled by MQTT via a script. Easier to adjust a script in HA than reflash the ESP. I am working on setting the water time on a slider bar on the frontend.
switch:
- platform: restart
name: "solarplantingwatering Restart"
# delay of 400000ms is a failsafe if mqtt fails to shut pump off
- platform: gpio
pin: 14
id: relay1
inverted: false
name: "Plant watering1"
icon: "mdi:watering-can"
#turn_on_action:
on_turn_on:
- delay: 400000ms
- switch.turn_off: relay1
My project will operate almost the same way. This is useful for me, I’ll probably mirror a lot of the logic.
I’ve tidied up and dropped some of my WIP ESPHome config here. Maybe some of it is reusable.
The main bits I’ve been working on is getting the deep sleep working how I want. It’s my first deep sleep project.
I went with the API rather than MQTT. I asked the question about which is better in 2022 and despite what you see online, one of the ESPHome devs suggest API is good as long as your mdns is working well.
1 Like
I have been trying to decipher the schematic on the thingiverse page Smart, Self-watering Plant Pot Planter "Flaura" by Martin_McMaker - Thingiverse
The damn thing is hard to read. I will hopefully produce a scribbled pen and ink some time soonish. I am also endeavouring to use easyeda, but it is a learning curve.
I’ve added the flowchart I made previously to Git as well as a small todo-list.
I’m still working on some experiments regarding tightness (though nowhere nearly as fast as I’d like to) and I think @nickrout is working on documenting the PCB.
That means the rest of the coding is up for grabs. I think the next big chunk that would be nice to get sorted is getting the moisture sensor to work reliably. Anyone who’d like to get that bit working?
Was looking at the problem with water level sensor and think it might be less destructive to the electrodes if you made them capacitance touch sensor rather than binary sensors that eventually destroy the end of the leads.
esp32_touch:
setup_mode: true
sleep_duration: 436 milliseconds
binary_sensor:
- platform: esp32_touch
name: "ESP32 Touch Pad GPIO27"
pin: GPIO27
threshold: 1100
This was just a test but it could detect the water. I used aluminium foil to cover the tip of the lead. The setup mode is just to work out the threshold in my example. If you leave one lead in as ground it apparently makes it better. Might be able to just use one lead in a plastic cover that works by parasitic capacitance that can measure depth so little risk of electrode breakdown. I think most of the pins already chosen for depth sensor are able to be used as capacitance touch.
