Awesome!
1 Like
hey, just a user solving one problem at a time 
Well, the ART = W * BSI = ( |B| / ETpeak ) * ( ETpeak / PR * 3600 ) = |B| / PR * 3600 = ( ET - P ) / PR * 3600
So ART is not dependent on ETref. Obviously. I donât get why ETref is necessary since we only rely on ART.
ETpeak =max(ETref). So, still dependent. But yes, we only need the one max value. Version 2.0 will only ask for that
I understand that ETpeak = max(ETref) but in ART formula it is canceled out.
Well, I created two SW instances with different ETref say ETpeak = 4.2 for one and ETpeak 6.5 for another and have equally calculated ART for both.
I still donât understand why ETrefs are necessary. Anyway thank you for the work. Waiting for the version 2.0.
I am no expert on the formulas, I just got them from some paper. It looks like youâre right. I will do so experiments. Great timing with the 2.0 version! I am rewriting everything so this can easily be changed! Thanks!
Version 2.0 is now available in beta! Please install it and open issues for any problem you find. There are no docs yet and lots has changed. Most notably there is a panel now which allows you to configure zones, calculation modules and mappings (references to sources).
Iâve uninstalled the previous version and installed the v2023.8.0-beta9. Havenât had a chance to set everything up, but hereâs some initial feedback. A lot of this is just related to documentation which Iâm sure will be updated later.
Step 1/7 still references âUnique Name for the Instanceâ, but since thereâs only one instance allowed, perhaps this should read âUnique Name for your Integrationâ?
Step 1/7 shows a check mark below the field for naming your instance, and Iâm assuming this is for using your own ETo sensor? There is no text describing what that check box is for.
Step 3/7:Sources, is apparently requesting the OWM API key and needs some text to make that clear to any new users.
The Side Panel option for âAutomatic weather data updateâ defaults to 24 days. That sounds excessive and maybe it should default to 24 hours or less?
Iâm unclear about what the Zone Multiplier and Duration values are used for. In the previous version Maximum Duration defaulted to -1 (No Maximum). Or is this for Force Mode Duration?
What is the âForecast daysâ option on the PyETO Modules page used for?
For the Mappings, is there a best practices or description for whether to use Average, First, Last, Max, Min, etc when using your own weather station sensors? Iâm assuming most would use the average, but in the previous version I thought that Daily Rainfall was supposed to be a point in time value. I calculate my own daily min and max temps, so should that be set to âLastâ? Maybe include the text (default) on any settings where itâs appropriate?
Thanks for all your work on this!
Thanks for checking in and providing detailed feedback!
It looks like the second and third thing you talk about in the config flow / setup have to do with old versions still lingering. did you reboot HA before setting the beta up? There is nothing in the 2.0 code that should cause a âstep 1/7â to show, nor a checkmark without a label. âstep 3/7â is also gone. There are maximum 2 steps nowâŚ
Please reboot HA and set up the integration again and let me know if you are still seeing this.
Now back the other items:
- âUnique name for the instanceâ yes, that should be âfor the integrationâ.
- see above
- see above
- yes, that should be 1 days. Will be fixed in next beta
- Multiplier is a value you can use to change the duration with. If you set a multiplier to 2 any calculated duration will be multiplied by 2. If you set a multiplier of 0.5 any duration will be multiplied by that, i.e. divided by 2. This is a feature people wanted in V1.0 but I never got to work. If itâs not for you, just leave it at one. Now, Force Mode was a feature in V1.0 but is now replaced by you changing the state to Manual and entering a duration. This forces the irrigation to run every time itâs triggered for exactly that duration. This should for sure go into docs.
- Since OWM provides a forecast up to 14 days in some cases, you could conceivably want to take that into account when calculating a duration. This is to provide options for those that have complained about the integration only âlooking backâ. I.E., if it was a very dry day and you calculate at 11PM the integration might decide to irrigate. However, if you run your sprinklers the next morning, it might actually be a very rainy day so why irrigate. With forecast days you can decide not only to look at the current day but also any future days. Leave it at 0 if youâre not interested in it.
- Regarding aggregates: thatâs really up to you. I have received many conflicting requests, some wanted average, some wanted max, some wanted min, some wanted last. Iâd say, leave it at average for now, but of course if you have a rainfall sensor that is cumulative for the day, that should be set to last. Same for min and max temps. Are you using the HADailySensor integration for calculating min and max by any chance? I wrote that and I wonder if I should integrate that into here. Definitely some of this explanation should go into docs.
Thanks again and stay tuned for the next beta.
Thanks for the info.
I am using your HADailySensor for Min and Max. Iâd leave that as a separate integration for now. I did uninstall/reinstall (this time with a reboot in between, and Iâm no longer seeing those oddities with Step 1 and Step 3.
1 Like
Hi,
Thanks for this great integration. I am looking for a smart solution for irrigating my lawn since a while now. This is exactly what I was looking for.
I checked out beta 9 and found the similar bugs, that have been reported so far. But it worked in general.
Now I struggle with update to beta 11.
Both Update and completely new installation fail.
Is this a general problem or am I the only one who has problems?
Thanks a lot in advance.
Daniel
Dieser Fehler wurde von einer benutzerdefinierten Integration verursacht
Logger: homeassistant.config_entries
Source: custom_components/smart_irrigation/store.py:516
Integration: Smart Irrigation (documentation, issues)
First occurred: 14:24:07 (3 occurrences)
Last logged: 14:24:34
Error setting up entry Smart Irrigation for smart_irrigation
Traceback (most recent call last):
File â/usr/src/homeassistant/homeassistant/config_entries.pyâ, line 388, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File â/config/custom_components/smart_irrigation/init.pyâ, line 60, in async_setup_entry
store = await async_get_registry(hass)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File â/config/custom_components/smart_irrigation/store.pyâ, line 516, in async_get_registry
return cast(SmartIrrigationStorage, await task)
^^^^^^^^^^
voluptuous.error.MultipleInvalid: expected float for dictionary value @ data[âdeltaâ]
Not seen this before. Is this on a completely new install? Can you please open an issue on github so we can track this more easily?
I already restored my backup from yesterday. Now beta 12 could be installed and is running. I think something messed up with my installation.
Sorry.
no worries, thanks for testing!
Good morning,
During testing (overnight 
) found some more :
-
multiplier at zone is not calculated correctly
0,5 is used as 0.
-
Multiplier with dot (e.g. 0.5) can not be entered.
By the way : dot and comma are not used consistently.( The info calculation shows dots.) I didnât know, which is the preferred syntax. -
second zone is not calculating (where primary zone works with same Module, state and mapping)
-
when changing delta at the static module, the module gets duplicated with the same name.
-
unused modules (here static and pass-through) can not be deleted
One thing I couldnât find out. How can I reset the bucket of a single zone? Where is the state of the buckets stored? Couldnât find it in any attribute or entity.
Thanks and kind regards⌠I am looking for the next update. Great work!
How to trigger an automation with the new beta version?
Thanks for the feedback! Can I encourage you to add issues on github for these? The reason is it asks you to fill out certain things including uploading a diagnostics file which makes it possible for me to see if exactly what you have set up so I can replicate your exact configuration. Thanks. Also, any error messages from the log would be helpful (also that is being asked for in the issue template on github). Iâd like to keep this thread for discussion, not for bugs. Thanks
Like before there is a sensor that tells you how long to irrigate for, one per zone. Should be called âsensor.zone1â or so. Itâs value is the duration. From there itâs the same as before. Would you have preferred something else? I considered doing something else but wasnât sure what was best.
You could use SimpleScheduler for this.
Additionally you could write an automation which gets triggered by the scheduler so you can include conditions, like a soil moisture sensor, weather forecast etc.
@jeroenterheerdt I think the current implementation gives the most flexibility, the âdownsideâ being itâs not a turn-key integration.
Thinking about this, as in my request for the ET value going into the attributes (thanks for implementing!), to make it as beginner-friendly, maybe you can also put the time of last execution of each relevant service call into the attributes, and weather (pun intended) that was caused by an automation, manual trigger etc. I like components which are so self-explanatory that I donât need to RTFM. I do acknowledge this might be way out of scope though.
1 Like
There is still an event smart_irrigation_start. First I would like to use this instead of fiddeling with a new addon. But thanks for the hint.