OpenSprinkler Forums Hardware Questions OpenSprinkler Pi (OSPi) Bug in weather_level_adj.py plugin

  • This topic has 7 replies, 3 voices, and was last updated 7 years ago by Ian.
Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #34601

    Ian
    Participant

    I signed up for a free Wunderground account so I could try out this plugin. This account has a limit of 500 enquiries per day which should be plenty. However I got some messages saying that I had exceeded this and instead of cancelling my account, they would use one of my “raindrops”.  This has happened a couple of times so I am at the limit, and thought I should try to fix the problem.

    I found that Wunderground is returning “–” instead of “00” in precip_today_metric and when the plugin tries to convert it to a floating point number, there is an exception. So I have tested for this, and also at the same time checked for ‘–‘ being returned for other values requested at the same time.

    So I installed a temporary fix as follows.

    In the function today_info(), just before the last statement which starts

    result = {
    ‘temp_c’: float(day_info[‘temp_c’]),
    etc etc

     

    insert the following lines

    ###  IW patch to stop crash  when trying to convert ‘–‘ to float

    if (day_info[‘temp_c’] == ‘–‘ )  :
    day_info[‘temp_c’] = ’00’
    if (day_info[‘precip_today_metric’] == ‘–‘ )  :
    day_info[‘precip_today_metric’] = ’00’
    if (day_info[‘wind_kph’] == ‘–‘ )  :
    day_info[‘wind_kph’] = ’00’
    if (day_info[‘relative_humidity’] == ‘–‘ )  :
    day_info[‘relative_humidity’] = ’00’

    ### end patch
    This stops the exception, and the plugin works again.

    There are still some questions to be asked.

    – is ‘–‘ the only possible value returned that could have this result?

    – is ’00’ an appropriate default value for wind_kph,relative_humidity, and temp.

    There is another issue however. When this exception is caught in the main run() routine, it prints the err string (which is misleading as the line numbers quoted do not make sense), and then sleeps for 60 seconds before trying again. The retry gets the same error and so it continues all day and night. I changed the self_.sleep(60) to self_.sleep(1800) to ensure my Wunderground account does not get deactivated. This is short term, and probably what should happen is that it should try every 60 seconds for say 10 times, then hourly etc.

    Regards

    Ian

     

     

    No

     

     

    #34749

    ShawnHarte
    Participant

    You could just use any variant of a safe float/int function for example:

    
    def safe_float(s,d):
    
      try:
    
        return float(s)
    
      except:
    
        return d

     

    Then just replace any instance of float in your script with safe_float(data, defaultfloat value)

     

     

     

    #34764

    Ian
    Participant

    Thanks Shawn. That’s a much better way to handle it!

    I think it is still worthwhile changing the self_sleep(60) to self_sleep(1800).

    Ian

     

    #34775

    ShawnHarte
    Participant

    I’ve found that checking data on weather underground more often than once every 15mins does little to add useful information for calculating watering schedule modifications. Even a single check just prior to a scheduled watering event is often enough, given returned data is valid and useful.
    If weather data is used as a rain sensor of sorts, then simply factoring in forecast, and current co editions to that single check, will reduce accidental watering during rain events to a negligible level.
    My suggestion would then be the definition of acceptable defaults for the correction of odd data loss and on demand requests for data used to adjust schedules, or display current/ forecast information. I highly doubt a computer of any sort cares what the weather was like 15mins ago if you yourself have no interest in using the information.
    Outside of the meteorological fields high resolution historical weather information is geewiz at best in most cases. It’s good practice to constantly refine programs toward the average, and then handle the outliers.

    #34776

    Ian
    Participant

    Shawn

    To clarify. The plugin normally retrieves Wunderground data as part of a main loop which executes on an hourly basis.  The main loop however is in a Try: Except: structure and it is in the Except: condition that the self_sleep(60) statement occurs. Perhaps the author assumed that any error would be in the call to retrieve the data, and that retrying every 60 seconds would soon fix the problem? However the Except: catches all errors, and this particular one (the float problem) would not resolve itself until it rained next!

    It would be possible to improve the error checking, but I doubt there is a lot of point. Changing this particular self_sleep(60) to self_sleep(1800) ensures that you don’t exceed your Wunderground limits for retrievals in the event of as yet unanticipated errors. Your safe_float suggestion fixes the problem I encountered in an elegant manner.

    Regards

    Ian

     

    #34777

    ShawnHarte
    Participant

    I see what is happening now, except: is a catch all, if you would like to only extend the sleep when certain errors happen, use the applicable exception for example:

    try:
      //some code you hope works
    except (TypeError, ValueError):
      //increased sleep time
    except:
      //something else happened leave sleep time alone and do whatever you do for errors 
    

    A list of all exceptions can be found in the python documentation, if you simply want to ignore errors use except: pass
    I think simply handling certain errors appropriately would do wonders for you and would be quite simple to implement. Python has a ton of code built in for handling problems, seems to be designed for writing code assuming everything will work, then just quickly deal with whatever goes wrong. Easier to ask forgiveness than permission, type programming.

    #34867

    mrabe
    Participant

    I am seeing the same issues, lots of “string to float” errors, and now wunderground warnings. I’m a little confused on how an hourly weather check could make over 500 API calls in 24 hours.

    If your fix still working? Where exactly would I insert those lines?

    #34871

    Ian
    Participant

    I have attached my version of weather_level_adj.py  – if you place this in the plugins directory in place of the version that is already there, and make sure the new version is executable, then you will solve the problem.

    Due to the restrictions on attaching files in this forum I have had to rename weather_level_adj.py to weather_level_adj.txt   You will have to rename it back to weather_level_adj.py after you download it.

    This version works but a better (more elegant and complete) solution has been proposed by ShawnHarte in this thread. Feel free to implement that instead if you wish.

    The reason it calls wunderground so many times is that the error routine retries every 60 seconds. I have changed this in this version to every 1800 seconds to avoid the problem.

    Regards

    Ian

Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.

OpenSprinkler Forums Hardware Questions OpenSprinkler Pi (OSPi) Bug in weather_level_adj.py plugin