You would most likely use
with
and setup your automation’s when you have those devices setup in your instance.
For BOM its via:
You would most likely use
with
and setup your automation’s when you have those devices setup in your instance.
For BOM its via:
Thanks mate, yeah got em all setup and working.
I’m looking for a smart automation to trigger based off all the data between the ecowitt and the BOM forecast etc. For example if no rain is forecasted, temp is high, and soil moisture below certain %.
Setup the triggers in the automation at the top and edit the ID then use choose for the actions and inside of that use trigger by with an and with another trigger by then setup the action.
i.e this is for my nuc volume control but this is how I setup my automations for easier trigger and action groupings:
The and will be under that trigger by and you have that extra trigger by to pick from or use a device not in the when list.
i.e with an and condition:
I posted my code in an irrigation thread on here a while back. It’s probably a bit outdated now but it is there and would give you a good guide. It uses BOM data to decide if it needs to water or not, only on allowed watering days etc.
This should have some code you can use. Built for Australia, I use a Netatmo rain gauge but could easily be reconfigured for BOM.
Features:
This one also looks pretty good for a base to work with
They sent me one of those as a warranty replacement for a failed version 1 which was itself a warranty replacement of another version 1 of their smart switch which died. It’s working fine but I’ve not had it operating long enough (1 month so far) to test reliability.
Yes it is large form factor so it will prevent anything being plugged in next to it.
I use the zwave aeotec ones for plug ins.
I’ve added a patch for ZHA to support Mercator Ikuu 5-gang and 6-gang light switches here: Support for 5 and 6 gang Mercator Ikuu tuya switches by danielp370 · Pull Request #3218 · zigpy/zha-device-handlers · GitHub
Until it merges, easiest way to use it is to add it as a local quirk. The other light switches (1-4 gang) seem ok.
Check out GitHub - petergridge/Irrigation-V5: Irrigation custom component for Home Assistant
I wrote these to handle WA’s watering restrictions and collect and use weather data. It doesn’t use BOM weather but i have an integration to open weather map that allows some flexible calculations to affect the volume of water. OWM sources the data from the BOM I believe.
I tried this get Open Weather map but was not playing the game. I have got my dashboard running how I want now, has rain delay and date picker etc. All automation run from Node Red. Feel free to grab any of it, if it is useful. Does an actual volume based reading on local rain gauge.
A few versions ahead of what was posted above now.
Thanks for the recommendations guys, I’ll check them out. In the meantime, I created a helper 'rain chance max for the next 2 days" and using that. Really basic I know haha
alias: Garden Bed Irrigation
description: ""
trigger:
- platform: time
at: "09:00:00"
condition:
- condition: or
conditions:
- condition: template
value_template: >
{{ states.sensor.campbelltown_temp_max_0.state | int >= 30 and
states.sensor.soil_moisture_green_garden.state | int <= 30 }}
- condition: template
value_template: >-
{{ states.sensor.soil_moisture_green_garden.state | int <= 20 and
states.sensor.rain_chance_forecast_2_days.state | int <= 60 }}
action:
- service: rainbird.start_irrigation
metadata: {}
data:
duration: 10
target:
entity_id: switch.rainbird_gardenbeds
mode: single
I like it, I did not think to utilise the rain chance sensor in my Node Red Flow. I like the logic you have applied here including the temperature.
If you want to vary your irrigation duration based on the forecast temperature, you might want to try something like the below too.
I can’t rely on soil moisture measurements, so aside from some conditions (don’t irrigate if there’s been sufficient rain in the past few days (or it’s forecast), don’t irrigate in cold weather etc) I instead vary on a logarithmic scale based on termpature.
The HA sensor itself (configuration.yaml) looks like this:
- sensor:
- name: "Irrigation multiplier"
state: '{{ float(log(states.sensor.bomforecast_temp_max_0.state, 28) ** 6) |round(2) }}'
Where:
{{ float(log(28, 28) ** 6) |round(2) }}
Then my irrigation action calls the duration with the multiplier applied:
action:
- service: esphome.irrigation_ab75a5_irrigation_ab75a5_run_back
data:
zone1: "{{ (120 * float(states.sensor.irrigation_multiplier.state)) |round }}"
zone2: "{{ (900 * float(states.sensor.irrigation_multiplier.state)) |round }}"
zone3: "{{ (900 * float(states.sensor.irrigation_multiplier.state)) |round }}"
zone4: "{{ (600 * float(states.sensor.irrigation_multiplier.state)) |round }}"
etc etc etc...
Thanks for sharing the code on the multiplier, I might be able to use that logic with something else. Have you tried any soil moisture meters?
I’ve messed around with the resistive ones (they corrode really easily) and the capacitive ones (which seem better, albeit more expensive).
The issue for me is the sheer size of area I’m irrigating and the number of sensors I’d need to get a representative sample/average. My irrigation controllers are also quite a distance from the solenoids and the irrigated areas, so getting sensor readings over such distances is problematic.
These are fairly cheap and have been working for me but you are right the costs do go up quickly if you need a heap. I am just planning on 3 for each garden bed in 3 different areas of the yard, 1500m2. Between 9 sensors in 3 different areas I think I should be able to get a good representative sample.
So far they seem to be working well.
* Zigbee Model TS0601.
A bit similar in the RF category…
I’ve was meaning to try them for some time but wound up with another solution.
RF is good for distance and I suspect you could build a ESPHome reciever that could control stuff too.
AU$22.59 | 1 pcs of misol spare part (wireless soil moisture sensor), WH0291S-TR
https://a.aliexpress.com/_mMHn6JE
I don’t know. I don’t think so.
I suspect they only “listen” for RF when put in learning mode. And then I don’t know how you’d parse out the data from the signal anyway with that.
I use one of these for listening and sending RF (DIY ESPHome build)