Is there any need to reset a bucket in the new version after running an irrigation?
Regarding aggregates: if I use min/max for temperature sensor instead of HADailySensor, will this work same way?
Also pyETO have optional min, max humidity arguments for more precision. May be it worth to implement them too?
That event is to tell you when to start irrigating so all your zones can run before the sun rises. It doesnāt do anything, itās an event, not an automation. You can use the event to trigger an automation that runs each zone for the duration in the sensor.
I believe I responded to this, but yes. Same as before. This component doesnāt control your valves (never did, maybe some day) so you are responsible for resetting the bucket.
Please add a request on github for the min /max humidity. And yes, you could just apply those aggregates instead of using HADailySensor. That should be the same thing, approximately.
Until now I tried to use this event for starting an automation. But it got never fired. Now Iām on beta 16 and as I understood it should be fired now.
yes, it should be fired at: time_of_sunrise - total_duration_of_all_automatic_and_manual_zones. if itās not, please open an issue on GitHub
To control valves I use use irrigation unlimited which is paired with smart irrigation. to me this is a winning pair
1 Like
i have looked at that as well, but havenāt set it up yet. Can you share your config that explains how you tie these together? I am thinking maybe ship Smart Irrigation with a couple of blueprints, and would like to include irrigation unlimited as well.
1 Like
Ok Iāll do that. Iām currently quite busy, Iāll try for next week
Hi,
I use irrigation Unlimited together with smart irrigation in the following way :
-
Smart irrigation calculates the required irrigation time of a zone (in my case: sensor.rasen_gesamt) at 23:00h every evening
-
This time is transferred to Irrigation Unlimited by using the service āirrigation_unlimited.adjust_timeā. In Irrigation Unlimited I have defined a sequence (id 1)
HA Automation
alias: "Rasen gesamt - Smart irrigation - Zeit adjustment "
description: Adjust watering times based on smart irrigation calculations
trigger:
- platform: time
at: "23:30:00"
condition:
- condition: and
conditions:
- "{{ states('sensor.rasen_gesamt') | float(-1) >= 0 }}"
action:
- service: irrigation_unlimited.adjust_time
data:
actual: "{{ timedelta(seconds=states('sensor.rasen_gesamt') | int(0)) }}"
entity_id: binary_sensor.irrigation_unlimited_c1_m
sequence_id: 1
mode: single
- After irrigation in the morning the reset of the bucket is necessary. Also done service āsmart_irrigation.reset_all_bucketsā
HA Automation:
alias: Smart Irrigation reset bucket_Rasen
description: Resets the Smart Irrigation bucket after watering
trigger:
- platform: state
entity_id:
- binary_sensor.irrigation_unlimited_c1_m
from: "on"
to: "off"
condition:
- condition: numeric_state
above: "0"
entity_id: sensor.rasen_gesamt
action:
- service: smart_irrigation.reset_all_buckets
data: {}
I have not found out how to use service āsmart_irrigation.reset_bucketā to reset single zone buckets. Maybe you can give me a hint?
Kind regards
Daniel
1 Like
My code to reset a bucket
- id: 21cb9d35-de90-42e7-bc1a-6d3399f73423
alias: Smart Irrigation reset bucket
description: Resets the Smart Irrigation bucket after watering
trigger:
- platform: state
entity_id:
- switch.566
from: "on"
to: "off"
condition:
- condition: numeric_state
above: '0'
entity_id: sensor.smart_irrigation_id7_daily_adjusted_run_time
action:
- service: smart_irrigation.smart_irrigation_id7_reset_bucket
You have a service for each instance of ha smart irrigation you created. (Iām still using the production version, not the current beta one). In Developer tools/Service, type reset in service, it should be listed
1 Like
can I ask you to edit your post and format the code as preformatted text for readability (wrap it in three backticks?
To explain how to reset a bucket on a zone:
service: smart_irrigation.reset_bucket
data: {}
target:
entity_id: sensor.deck_plants_ambient
2 Likes
Hi Jeroen,
- Can we have a wind-sensor height as input, so the conversion is done automatically?
- Thanks for adding the ET to the debug info, but it is not possible to graph this value during the day / debug it. The old āhourly runtimeā was a nice feature. Can we get something like that back? Maybe add the ET to the attribute so that it can be template into a separate sensor for those we want that?
- The old integration calculated the hourly runtime and at 23:00 it transferred that into the daily_runtime. Of course, the bucket needed to be manually reset by the user after irrigation. Now it seems that the daily runtime calculation also needs to be done by the user. Can you make this default behavior, possibly with a configurable time? I like to avoid automations when not required.
- Thanks for adding the explanation of āupdateā and ācalculateā, but I donāt understand why these need to be separate? āUpdating is updating weather data from OWM/Sensorsā, What is happening behind the scenes, is it forced polling of OWM? For local sensors this should not be needed, or can you force a read of the local weather station?
- When setting up the integration, the description of the checkbox for OWM mentions sensors, but maybe you can add the explanation that OWM can also be used for the wx forecast? I initially disabled it since I have a wx station, but it seems it can be used for forecasts as well.
- However, I donāt understand how that works. Since the user is left with starting irrigation and resetting the bucket, how does PyETO deal with the forecast? I would think it would only be used to delay the start of irrigation, but that is left to the user, right?
- Am I right that when a user has an ET sensor all other sensors are not needed anymore, since they are only used to calculate ETO? If so, when selecting the radio box for ET, all other sensors should disappear?
- After re-downloading a new version the side-bar panel shows the new version number while the integration odes not yet. Can you delay the display of that new version until the restart has been done?
- You asked somewhere if the HADailySensor should be integrated into this integration. I personally would prefer that, 2 less sensors to set up.
Sorry for all the questions, hoping to help make great documentation as well.
Thanks again for all your efforts!
I am going to number the items you had in your comments so itās easier to track the conversation.
- What do you envision here? Right now, itās documented (for v1) that you need to provide wind speed at 2 meters. Are you thinking there should be a separate sensor the height of the wind sensor or is it a property of the wind sensor that you can provide somehow? Curious to your thoughts!
- I moved away from hourly runtime because it was confusingā¦ butā¦ if you have auto update / auto calc set to every hour wonāt you get the same result? the sensor value should update and you would have your chartā¦ of course then the issue is that weāre not doing the āhourlyā to ādailyā conversion anywhereā¦ hmm, stuff to think about. I am not a fan of bringing back hourly runtime vs daily runtime though.
- Not sure what you mean with āDaily runtime calculation also needs to be done by the userā - this is exactly what the auto-calc is for. There is no concept of hourly run time any more.
- Updating is updating weather data from sensors only, not from OWM. Calc just takes whatever is there, adds current OWM if needed / configured and calcs with that. I separated it to reduce calls to OWM and provide maximum flexibility. Both updating and calculating can be scheduled. Updating would force read the sensor values at that time, or multiple times a day if you want, which is the same behavior as our v1 but then more flexible.
- yeah, I need to clarify that, good point. Let me add a bug so I can track that..
- the idea of using a forecast is: letās say it was a sunny day and you collected info about how great it was. Now you calculate at 23:00 but irrigate just before next sunrise. Letās say the weather turns awful after 23:00 and itās raining cats and dogs the whole next day. In the V1 your irrigation would run while itās raining and you would be wondering why (or anyone else in the household would). With the forecast you can actually take the forecast into account and avoid having this unnecessary irrigation going. This was a top feature request for the V1.
- Yes, but no. the ET sensor is not used in the PyETO module or in the Static for that matter. Only the Passthrough module actually looks at the ET sensor. By having a mapping that defines more than just the ET sensor you can use the same mapping for both teh Passthrough or PyETO module.
- not sure what you mean with āwhile the integration odes not yetā. Typo? Can you explain?
- You really actually donāt need HADailySensor anymore, right? Just use the max/min aggregate on your temperature sensor and the behavior is the same. Let me know if this doesnāt make sense.
Thanks for all your questions, you raise some great points. Alsoā¦ Iād like to invite you and anyone else to consider helping me document all of this. I welcome PRs (pull requests on GitHub) for documentation (and code if you are so inclined). If anyone is willing to help we get this done faster. Right now documentation is lacking / nonexistent for v2 because I am solving bugs, but if anyone wants to get started on it, feel free!
I cloned the wiki locally and made a first adaptation for 2.0. Now I shy away from just execute a āpushā. How should I do it?
Basic git. You will not be able push to my repo. You make a fork, clone that, make your changes, push there. Once you are ready, make a PR. That is how it works for readme and code. For the wiki, Iād assume the same would apply.
For the README.md I will do it in a view seconds, for wiki its not possible to fork.
hmmā¦ maybe add markdown pages for wiki pages youād like to add? not sure how else to do it 
In my fork I added a wiki with all needed pages.
Youāll find it here https://github.com/gatonero/HAsmartirrigation/wiki
From there you can clone it 