Hi, not sure if this is a stupid question but I need some help in setting up:
hi, iāve set up OWM paid account and I get its sensors populated with values, but in Smart irrigation I see OWM selector in strikethru font and of course i cannot use it
Owm takes time to activate the key. They tell you to wait 4 hours.
You enter the key in the setup or config of smart Irrigation. No need to have OWM integration. You can also keep the OWM integration and use the sensors provided by it as sensors in smart Irrigation.
Give it time. OWM tell ls you to wait four hours.
I created yesterday and the key was active after a couple of hours. in HA I can see the values getting updated every hour.
The problem is Smart irrigation seems to not recognize OWM
Two options: specify the OWM key in the setup of smart Irrigation. Orā¦ If you have a owm integration already, which it sounds like since you have values in HAā¦ Use the sensors option in smart Irrigation.
Also, read the docs.
1 Like
I have been struggling since this new version to get things running. The old one was very smooth, new version is issue after issue.
Latest issue I notice sprinker isnāt running for many days. I think oh it just needs more in the bucket.
Turns out is is stuck and not calculating bucket since October 27th!
Source: custom_components/smart_irrigation/__init__.py:413
Integration: Smart Irrigation (documentation, issues)
First occurred: October 29, 2023 at 1:41:57 AM (104 occurrences)
Last logged: 4:41:57 PM
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/config/custom_components/smart_irrigation/__init__.py", line 384, in _async_update_all
weatherdata = await self.merge_weatherdata_and_sensor_values(weatherdata, static_values)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/smart_irrigation/__init__.py", line 413, in merge_weatherdata_and_sensor_values
_LOGGER.debug("merge_weatherdata_and_sensor_values, overriding {} value {} from OWM with {} from sensors".format(key,retval[key],val))
~~~~~~^^^^^
KeyError: 'Evapotranspiration'
and
Logger: custom_components.smart_irrigation
Source: custom_components/smart_irrigation/init.py:558
Integration: Smart Irrigation (documentation, issues)
First occurred: October 29, 2023 at 11:00:02 PM (18 occurrences)
Last logged: 2:27:43 PM
- Calculate for zone Lawn failed: no data available.
- Calculate for zone Landscape failed: no data available.
sorry for the issues. It looks like there is no weather data available for calculating, are you updating the weatherdata? Can you share screenshots and / or a diagnostic file (see Github issue instructions). In V2 we have split the two steps: V1 updated and calculated in one step (just once a day) but to get more flexibility and resolve issues with this approach we now have a calculate and an update step. You update the weatherdata X number of times a day and then calculate the duration based on the collected weatherdata.
The error says Evapotranspirationā¦
I have these options:
Source: None Sensor Static value
I set it to static value, there is no option to put the monthly values so I average out all the months.
I do have openweathermap. I do have a valid API key and the setup screen accepts it (it is V2.5, if that matters, If I select V3 the setup process rejects it).
However I do not see how to define the location it pulls from OpenWeatherMap.
I think I got past that hurdle. I had signed up for One Call API 3.0 (under the same login) with openweathermap and now the setup process lets me use V3
It really should not fail this way if there is API issue, and the setup shouldnāt say itās OK if it isnāt. Or at least the error should say like Response 500 from OpenWeathermap, server said āAPI Key is not validā. Something you can read without having to debug all the code.
I still have no idea what is going on because I do calculate all zones manually, yet the run time does not increase from the last value. Yes I refresh the page to be sure.
Actually it is showing negative value for the bucket! This is impossible because there is very little rain logged, in the past two weeks is 0.4 one day and 0.02 another.
None of this happened with the old version.
Honestly I have no idea what is going on. Your description is very confusing. Please open an issue on github and provide diag file. We do that for a reason. Did you read the readme / watch the videos?
Youāre telling me itās confusing!
How come when I hit calculate all zones the duration does not change? And how is the bucket value negative? I assume that means there is excess rain.
Here is my latest debug
{
"home_assistant": {
"installation_type": "Home Assistant OS",
"version": "2023.11.1",
"dev": false,
"hassio": true,
"virtualenv": false,
"python_version": "3.11.6",
"docker": true,
"arch": "x86_64",
"timezone": "America/New_York",
"os_name": "Linux",
"os_version": "6.1.59",
"supervisor": "2023.10.1",
"host_os": "Home Assistant OS 11.1",
"docker_version": "24.0.6",
"chassis": "vm",
"run_as_root": true
},
"custom_components": {
"smart_irrigation": {
"version": "v2023.9.3",
"requirements": []
},
"irrigation_unlimited": {
"version": "2023.9.0",
"requirements": [
"crontab"
]
},
"alexa_media": {
"version": "4.7.9",
"requirements": [
"alexapy==1.27.8",
"packaging>=20.3",
"wrapt>=1.14.0"
]
},
"winix": {
"version": "1.1.5",
"requirements": [
"winix==0.2.1"
]
},
"adaptive_lighting": {
"version": "1.19.0",
"requirements": [
"ulid-transform"
]
},
"hacs": {
"version": "1.33.0",
"requirements": [
"aiogithubapi>=22.10.1"
]
},
"smartthinq_sensors": {
"version": "0.35.2",
"requirements": [
"pycountry>=20.7.3",
"xmltodict>=0.12.0",
"charset_normalizer>=2.0.0"
]
}
},
"integration_manifest": {
"domain": "smart_irrigation",
"name": "Smart Irrigation",
"codeowners": [
"@jeroenterheerdt"
],
"config_flow": true,
"dependencies": [
"http",
"panel_custom"
],
"documentation": "https://github.com/jeroenterheerdt/HASmartIrrigation",
"iot_class": "local_push",
"issue_tracker": "https://github.com/jeroenterheerdt/HASmartIrrigation/issues",
"requirements": [],
"version": "v2023.9.3",
"is_built_in": false
},
"data": {
"config": {
"entry_id": "284ca9d34a73073f30647797d91b4b61",
"version": 1,
"domain": "smart_irrigation",
"title": "Smart Irrigation",
"data": {
"owm_api_key": "XXXXXXXX",
"owm_api_version": "2.5",
"use_owm": true,
"name": "Smart Irrigation"
},
"options": {
"owm_api_key": "XXXXXXXXXXX",
"owm_api_version": "3.0",
"use_owm": true
},
"pref_disable_new_entities": false,
"pref_disable_polling": false,
"source": "user",
"unique_id": "Smart Irrigation",
"disabled_by": null
},
"storage": {
"config": {
"calctime": "23:00",
"units": "imperial",
"use_owm": true,
"autocalcenabled": true,
"autoupdateenabled": true,
"autoupdateschedule": "hours",
"autoupdatedelay": "0",
"autoupdateinterval": "2",
"autoclearenabled": true,
"cleardatatime": "23:59",
"starteventfiredtoday": true
},
"zones": [
{
"id": 0,
"name": "Lawn",
"size": 60.0,
"throughput": 0.65,
"state": "automatic",
"bucket": -7.022135653213333,
"old_bucket": -6.999322362022459,
"delta": -0.022813291190873525,
"duration": 1023,
"module": 0,
"multiplier": 1.0,
"explanation": "Note: this explanation uses '.' as decimal separator and shows rounded values. Module returned Evapotranspiration deficiency of -0.0. Bucket was -7.0.<br/>maximum bucket size is 1.5.New bucket value is [old_bucket]+[delta]=-7.0+-0.0=-7.0.<br/>Since bucket < 0, irrigation is necessary.<br/>To calculate the exact duration, the following steps were taken:<br/><li>The precipitation rate is defined as [throughput]*60/[size]=0.65*60/60.0=26.5</li><li>The duration is calculated as abs([bucket])/[precipitation_rate]*3600=7.0/26.5*3600=954</li><li>Now, the multiplier is applied. The multiplier is 1.0, hence the duration is 954</li><li>Then, the maximum duration is applied. The maximum duration is 4140.0, <li>Finally, the lead time is applied. The lead time is 69.0, hence the final duration is 1023</li></ol>",
"mapping": 0,
"lead_time": 69.0,
"maximum_duration": 4140.0,
"maximum_bucket": 1.5,
"last_calculated": "2023-11-06T23:00:00.922477"
},
{
"id": 1,
"name": "Landscape",
"size": 30.0,
"throughput": 0.65,
"state": "automatic",
"bucket": -7.022135653213333,
"old_bucket": -6.999322362022459,
"delta": -0.022813291190873525,
"duration": 537,
"module": 0,
"multiplier": 1.0,
"explanation": "Note: this explanation uses '.' as decimal separator and shows rounded values. Module returned Evapotranspiration deficiency of -0.0. Bucket was -7.0.<br/>maximum bucket size is 1.5.New bucket value is [old_bucket]+[delta]=-7.0+-0.0=-7.0.<br/>Since bucket < 0, irrigation is necessary.<br/>To calculate the exact duration, the following steps were taken:<br/><li>The precipitation rate is defined as [throughput]*60/[size]=0.65*60/30.0=53.0</li><li>The duration is calculated as abs([bucket])/[precipitation_rate]*3600=7.0/53.0*3600=477</li><li>Now, the multiplier is applied. The multiplier is 1.0, hence the duration is 477</li><li>Then, the maximum duration is applied. The maximum duration is 1900.0, <li>Finally, the lead time is applied. The lead time is 60.0, hence the final duration is 537</li></ol>",
"mapping": 0,
"lead_time": 60.0,
"maximum_duration": 1900.0,
"maximum_bucket": 1.5,
"last_calculated": "2023-11-06T23:00:01.265839"
}
],
"modules": [
{
"id": 0,
"name": "PyETO",
"description": "Calculate duration based on the FAO56 calculation from the PyETO library.",
"config": {
"coastal": true,
"forecast_days": "4"
},
"schema": [
{
"type": "boolean",
"name": "coastal",
"optional": true,
"default": false
},
{
"type": "select",
"options": [
[
"1",
"EstimateFromTemp"
],
[
"2",
"EstimateFromSunHours"
],
[
"3",
"DontEstimate"
]
],
"name": "solrad_behavior",
"required": true,
"default": "1"
},
{
"type": "integer",
"name": "forecast_days",
"required": true,
"default": 0
}
]
},
{
"id": 1,
"name": "Static",
"description": "'Dummy' module with a static configurable delta.",
"config": null,
"schema": [
{
"type": "float",
"name": "delta",
"required": true,
"default": 0
}
]
},
{
"id": 3,
"name": "Passthrough",
"description": "Passthrough module that returns the value of an Evapotranspiration sensor as delta.",
"config": {},
"schema": []
}
],
"mappings": [
{
"id": 0,
"name": "Default sensor group",
"mappings": {
"Dewpoint": {
"source": "owm",
"sensorentity": "",
"unit": ""
},
"Evapotranspiration": {
"source": "none",
"sensorentity": "",
"unit": "",
"static_value": "0.156"
},
"Humidity": {
"source": "owm",
"sensorentity": "",
"unit": ""
},
"Precipitation": {
"source": "sensor",
"sensorentity": "sensor.gw1100b_v2_1_8_daily_rain_rate",
"unit": ""
},
"Pressure": {
"source": "owm",
"sensorentity": "",
"unit": ""
},
"Solar Radiation": {
"source": "none",
"sensorentity": "",
"unit": ""
},
"Temperature": {
"source": "owm",
"sensorentity": "",
"unit": ""
},
"Windspeed": {
"source": "owm",
"sensorentity": "",
"unit": ""
}
},
"data": [],
"data_last_updated": "2023-11-06T22:16:38.990249"
}
]
}
}
}
No. Negative means more water was removed from the soil than was added with rain. Again. Did you read the readme?
You set the evapotranspiration value to a static value. So of course there is no calculation happening and the values will be of compared to any weather. Why did you set the et value to a static value? Did you read anything about how to use this integration?
Now it is set to none, do you not see it in the debug above where it says
Evapotranspiration": {
"source": "none",
Yes the static_value is still apparently saved in the config, but when you select none in the UI the static value input goes away. I am sorry I am not a programmer, but the documentation is not very clear. I was using the old version without an issue and tried to carry over the settings.
If the bucket is -7 why is it not calculating the correct run time to replenish the loss? Why does the run time stay the same after I select the option to calculate all zones?
This might be related to what I reported on October 3rd:
I am getting unexpected and very strange values with v2. I follow the migration steps from the wiki.
In my v1 I had the following values, I had calculated them out based on ETO forum.
"number_of_sprinklers": 1.0,
"flow": 0.55,
"area": 60.0,
"coastal": true,
Per the wiki I multiply 1.0 x 0.55 = 0.55 and enter this for Throughput (gal/minute).
Then I enter the value 60.0 in Size (sq ft)
I enter the value -2.0 for the bucket. I click on update & then Calculate and reload the page to see the new values.
This results in a duration of 985 and a new bucket -5.7! The duration is way too short for a -5.7 or even a -2.0 bucket. Where does this massive change in bucket even come from? With V1 and the above settings I would see about 985 run time for just around a -0.15 or -0.20 bucket.
However now I was running 0.65 instead of 0.55 just trying to get this working the way it was with V1. How can I manually calculate the run time from bucket for V1 and V2 to see what is the issue?
just be safe go into source group configuration and remove the static value for ET there.
itās not easy to reproduce between V1 and V2. V2 is absolutely more correct. Letās separate some things though:
- updating collects weather data, so after you updated / calculated your bucket was decreased by 3.7 (-2.0 ā -5.7). This is reasonable depending on the weather pattern. Was it a hot, dry day or did you get rain? Keep in mind that you pressing āupdateā just takes collects the weather data once to calculate on, so it might be extrapolating. Also, depending on when your last weatherdata was collected this will multiply the bucket to adjust for the time elapsed.
- the second item youāre mentioning is that the bucket value + duration combination does not match up to your expectations. I believe you are saying itās too short? Letās do the math here, but you can also see it in the UI. In fact, this is from your diagnostic file:
"Note: this explanation uses '.' as decimal separator and shows rounded values. Module returned Evapotranspiration deficiency of -0.0. Bucket was -7.0.<br/>maximum bucket size is 1.5.New bucket value is [old_bucket]+[delta]=-7.0+-0.0=-7.0.<br/>Since bucket < 0, irrigation is necessary.<br/>To calculate the exact duration, the following steps were taken:<br/><li>The precipitation rate is defined as [throughput]*60/[size]=0.65*60/60.0=26.5</li><li>The duration is calculated as abs([bucket])/[precipitation_rate]*3600=7.0/26.5*3600=954</li><li>Now, the multiplier is applied. The multiplier is 1.0, hence the duration is 954</li><li>Then, the maximum duration is applied. The maximum duration is 4140.0, <li>Finally, the lead time is applied. The lead time is 69.0, hence the final duration is 1023</li></ol>",
so it appears you have set your throughput to 0.65 (not to 0.55, but ok). so your precipitation rate is indeed (0.65*60)/60 which should have been 0.65. Not sure why it is 26.5?
That is probably a bug in the explanation output. I will investigate that.
If we set it to 0.65 just for this experiment then the duration is abs(bucket)/precipitation_rate*3600 = 7/0.65*3600 = 45818 seconds which is more than 12 hours which seems very long to me. Are you sure your config makes sense?
Would that duration be more in line with what you expected? Really? That would be very long. Anyway, the duration youāre seeing is 985 apparently which is 16 minutes, which is way more in the ballpark of what I would expect.
All in all, I am trying to say I think the V2 is doing the right thing here. Do you really water your lawn for hours??