-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Daily bucket calculation is not correct when using a solar radiation sensor #363
Comments
Taking a look at the diagnostic file myself, I see that the temperature sensor in all of my sensor groups does not have a temperature unit in the file - but I can confirm that they are all set to C in the GUI. |
and I turned on debug logging for the integration and here are the logs for smart_irrigation. Hope this is helpful.
|
the unit is not interesting - it is set automatically to Celcius if not set to anything else. I am not seeing the blocking call issues on my side, but I will try to resolve it. |
the warning is not stopping the integration from working - I don't see what is not working here. Are you not getting any other errors? |
No errors. Nothing to indicate it is not working. Watering stopped (bucket not updating) in early April. No idea why. Nothing changed at my end. I might setup a HA test environment and see if I can reproduce. Anything else I can do to see what is going on with the bucket calculation? |
@jeroenterheerdt - I have setup a new test environment (another docker container) so my test and prod are on the exact same baseline HA config. In my test environment I have added only my weather station and smart irrigation and I have created the setup exactly the same as in prod. So I will monitor over the next few days to see if the bucket calcs are the same on both - they should be. FYI - I did notice something a bit strange when setting up new. The default sensor group has config for max and min temp but any new sensor group does not have these. So I think that might be a little bug. I created new sensor groups and then deleted the default in both prod and test so both setups are identical. |
there should not be a default sensor group at all.. |
But there was a default sensor group for me with a clean install of the integration on a clean/new HA setup. Today I see that my test setup is having the same issue as prod. bucket value of -0.3 from a full day (with precipitation set at 0 so rain is not taken into consideration). I will keep monitoring and update you. |
The only thing I can think of is that in early April I fixed a pretty big bug in which the solrad wasn't converted before storing it. That has indeed reduced values tremendously, but is now correct (unless I have inadvertently introduced new bugs). So take a look at the values in the storage file and compare them with what your sensors provide. Do some calculations to check what is in the storage file is correct. I don't see the issue, but I might be missing something. Default sensor group I will look at. |
Looking at the data in the diagnostic file, solrad is definitely converted to a much smaller number but I am not sure what conversion is happening. Can you explain what W/m2 is being converted to for the calculation? I have attached a new diagnostic file with a fair amount of weather data config_entry-smart_irrigation-7f7127f4c22a04d1cbd475295c54538c (1).json |
So I have been monitoring prod and test for 3-4 days now and I get exactly the same results on both with around -1mm added to the bucket a day. This translates to about 10secs of watering in the front garden and 30secs in the back garden per day. When this was all working correctly, it was around 3mins watering in the front and 10mins at the back per day. So I do think something is wrong with how solrad is being handled. |
thanks for your efforts so far. I have pulled up the code and added a wiki page about the units in the diag / storage file: https://github.com/jeroenterheerdt/HAsmartirrigation/wiki/reading-the-diagnostic-and-storage-file-(v2). Can I ask you with this in hand to do the comparison to see if you can spot any issues? Is the data indeed converted properly at storage from your input sensors? I don't see issues on my end, but I am also kind of blind to my own code by now. The solrad value is expected to be way smaller in the storage file than what your input would be in W/m2 as it's stored in MJ/day/m2. 1 watt is equal to 0.0036 megajoules per hour. Since there are 24 hours in a day, you would multiply 0.0036 MJ/h by 24 hours to find the megajoules per day. I think that is what is happening, but I might have made a mistake here. |
Sure thing. I’ll take a look at all the info over the next few days and let you know if I find anything. |
@jeroenterheerdt - Have done some research and I agree with your maths for the conversion from W/m2 to MJ/day/m2. I see in the integration the conversion factor of 0.0864 (0.0036 x 24) is applied. I have been looking at my sensor data and I can see that the W/m2 is being converted using the 0.0864 factor into the data file. So everything looks good at this point. I assume the integration is using the pyETO API - pyeto.fao56_penman_monteith to calculate evapotranspiration for each data point and then adds up these up to calculate the total. I am not clever enough to understand more than this... The only idea I have is that I have the coastal boolean set to true as I live right on the coast. However as I am using a sensor to provide solrad directly there is no need to have this flag set as it should not be needed. I'm thinking maybe that somehow this coastal flag is forcing the integration to calculate solrad rather than use the sensor data. So I will switch off the coastal boolean and see if that changes anything. It would be good to see the dataset that is being passed into the API and how these are then added up to provide a total ETo. |
The other thought I have is that my watering is way lower than it should be - but it is calculating something. I think it could be out by a factor of around 24. This is making me think that maybe the API needs the solrad for the day or there is something happening where the integration is not adding all the data together, |
I will add extra debugging statements around the calls to pyeto and the aggregation of data. I will create a beta build so we can hone in on this. |
Thanks. Much appreciated and let me know what I can do to help once you have the debug beta ready |
ok, here we go. Install https://github.com/jeroenterheerdt/HAsmartirrigation/releases/tag/v2024.5.1. You can do this through HACS assuming you have "show beta versions" on. Also, in your config, enable debug logging for custom_components.smart_irrigation:
Your log will be flooded, so keep an eye on it. There will be lots of data to parse through when calculating but hopefully it will help to find any issues. |
Thanks. I have this all setup in prod and test so will do a 'calc all zones' manually later today in test and let prod run automatically tonight at 11pm. Will update you over the weekend. Thanks for all your help with this. Hope we find the bug (if there is one)... |
can I suggest to first test with a calculation per zone so you don't get too buried in messages? :) |
please pull the new version of 5.1: https://github.com/jeroenterheerdt/HAsmartirrigation/releases/tag/v2024.5.1 |
I think I have found a possible clue... There is a function that aggregates data (apply_aggregates_to_mapping_data) before being pushed into the pyeto API. This looks like it uses an average for all elements and uses a multiplier that I think works out the proportion of a day included in the data. The issue with this approach is that solrad needs to be added together not the average. See below the solrad being used is 1.36 (this is an average of night time solrad plus a early morning data where solrad is above zero but increasing fast. So I think all that potentially is needed is to update the function so that solrad is added not the average. This will make a big difference I think.
|
I have found something else - but not sure if it is relevant I see a number of solrad calculations that are taking place in pyETO: calculate_et_for_day - not sure if any of these are being used in the final eto calculation but... In my setup I have a solrad sensor so there is no need to do any calculations to estimate solrad. Just need to pass in the correct (aggregated) solrad data into the model. I hope this is helpful info for you
|
Well, yes. We have the timestamps of each sensor update and now that we're calculating as soon as the sensor updates, we have a timestamp for the delta. I don't store it currently but it's there. But the point is that pyeto assumes the info it gets is for 24 hours. So it will return a Et based on the sensor values passed in for every sensor update. Hence, we need to handle that otherwise the bucket grows way to fast. So my thinking is: take the diff between the current time and the last time the sensor was updated. Calculate what fraction of an hour that is (used to be not a fraction really, but now with continuous updates it most likely is) and then divide that by 24 since there are 24 hours in a day. That number is then used to multiply the Et value pyeto returns which is for 24 hours as I said above. Writing this out I think it makes sense, but curious to your thoughts. |
I see. Yes this makes sense in terms of working out the ETo for the day and then dividing this into the fraction of the day that the data relates to. So overall I think it makes sense. What do you mean by doing calculations 'as soon as the sensors update'? Should you not just do the calculation based on sensor data every x minutes? For my setup I am getting almost real-time data from my weather station but calculating ETo more than every 10mins is probably overkill. |
Just looking at my logs on prod (not test) and I see this. Prod is also running latest beta of smart irrigation
|
You wanted to continuous update duration and bucket, right? For that we need to calculate ET values continously. |
Interesting. If there is no rain does your weatherstation report unknown when there is no precipitation? |
No but this is the one weather sensor that I use a cloud based integration rather than local data for. So perhaps this is a one off error due to the cloud based sensor not being available at the time. I will monitor. |
Just a quick update that I am no longer getting any bucket updates at all so something in the latest beta has stopped calculations. I turned on debug logs and have included some of these log entries (way too much to share the whole lot). |
Hello @jeroenterheerdt - Hope all is well. Just checking in with you on this. I know you are busy and this is not really urgent so no pressure :-) I have switched my watering to my original 'dumb' smart watering system and it is doing fine. haha |
Sorry busy with family emergency. What do you mean 'dumb'? |
Oh no - hope all OK with family stuff. Before I started using smart irrigation I wrote my own system (dumb - compared to smart irrigation) that uses weather and rain to control the watering using different schedules and watering time. It has four scenarios:
It works well and I used ETo (when working) to help me tune watering durations for the above scenarios. I call it dumb but it is quite smart TBH :-) |
Hi all, just went through all the messages. I believe if you want to convert from loose watt/s measurements to a total you have to use a Riemann sum integral. I believe each measurement was always converted to MJ/M2/day when stored by this integration. The only proper thing you can do is average this out... unless a Riemann sum integral is used as this incorporates the time factor as well. If i would now select 'sum' the integration sums all the calculated MJ/M2/day and this explains the gigantic bucket values you saw. |
Thank you @wauswaus. Very nice of you to join this discussion :-) I think you might be onto something with this line of thinking based on the prod version of the integration. It was massively underestimating watering duration - but not sure if Riemann sum integral would resolve things. The current beta integration is doing almost real-time calculations but it is not working (yet) for my setup. So need to wait for the dev @jeroenterheerdt to comment when he has time. |
I also use have a radiation sensor (in w/m2) and with the latest production version I don't have any big issues. I do let the integration update all the sensors every 5 minutes to get better granularity and have the radiation sensor set to average. In the meanwhile I made Riemann sum integral sensor and that thing is only counting up... so I also created a statistics sensor that gives me the difference between latest measurement of the Riemann sum and the one 24 hours ago. I'm monitoring if that goes well. If so i'll feed that sensor in the smart irrigation and will use the latest value for the calculations. |
I am also playing around with a Riemann sum integral sensor and also noticed the issue with it not resetting daily but this is easy to resolve with a stats sensor or utility meter helper. Interesting that you are getting good results with a 5 minute update period. Mine is default so every hour. Another thing to look at I think. Keep me posted. Keen to get this all working again by next spring/summer so I have a few months to work on it. |
ok, I created a Riemann sum integral sensor with as method 'left' and has as unit w/m2/d. That feeds in a statistics sensor with state_characteristic 'change' and max_age of 24h. That gives me a rolling amount of radiation of the last 24h. Now lets see what happens :) Based on all the messages in this issue I have the feeling that the instant calculation that is now in the beta version is also incorrect due to the fact the time factor is not properly incorporated. |
That's great progress. Can you explain a couple of things to me please?
|
thank you @wauswaus - I will update my setup to the same as this and see how the bucket calcs look over the next week or so. |
thanks both, I am back and will be working on the bugs in the latest beta. Also following the discussion on the reimann integral with interest, looks very promising. please let me know what you find! |
@jeroenterheerdt - welcome back. Hope all ok with the family stuff you have been dealing with. I have 2 integral sensors configured. One using one minute intervals as this is the frequency of the source sensor data. I setup another using a daily interval like @wauswaus Looking at the daily interval data, I think it looks too low/small to make a meaningful contribution to the ETO calc (so I will test both ways and report back. |
@jata1 unfortunately a close family member has passed away, that was the emergency. |
unfortunately these logs don't tell me what is going on. do you also see these #421 maybe? |
I don't see how you made 2 different ones. The integral is an ever increasing sensor so the only way is to also configure also a utility sensor which resets daily so you know the MW/m2/d. |
Hey, I started a discussion now that the feature is in experimental state in production. Can I ask you to move the discussion about how to process the solar radiation input there? Thanks! #437 |
What happened?
Everything working fine until early April 2024 - so likely when I updated to HA 2024.4.
Since then buckets are no longer updating so something is not working correctly.
My weather station data is all good and nothing has changed so I am not sure what is happening.
How to reproduce
Relevant log output
Which version are you running?
2024.5.2
Diagnostics file
Additional information
please find diagnostic file here. Happy to help with any further info and troubleshooting.
config_entry-smart_irrigation-7f7127f4c22a04d1cbd475295c54538c.json
The text was updated successfully, but these errors were encountered: