Flexible support for different weather algorithms

[eyal]

Hello,

It’s obvious, from dicussions on this forum and my own (short) experience, that there’s a lot of room for improving weather supprot in OpenSprinkler. Although I’m not familiar with Arduino and C++, I looked at the code and scripts to understand how weather suopport works, and I think that with a few relatively simple changes, weather support can be much better.

1. Allow host name of weather script URL to be IP address. Currently the host name must be a name. As far as I can tell this is because the code on the device first performs a DNS lookup, and only if the lookup succeeds it proceeds to call the URL. This may seem like a small issue, but those who want to run their own weather scripds, may need to use an IP address of a host on the home LAN.

2. Include the script name in the URL. Currently the code appends weather?.py to URL, however those who want to host their own scripts may wish to use PHP or JavaScripts or some other scripting language.

3. Pass adjustment method as GET parameter. Currently each adjustment method has a number (probably the order in the UI), and the number is appended to the script name (eg. weather1.py or weather2.py). I suggest that the name of the method, or a shortend name (eg. zim=Zimmerman, ard=Auto Rain Delay), be passed as a GET parameter “uwt”.

4. Add several “Custom” adjustment methods. Currently there are Zimmerman and Auto Rain Delay, each with its fixed set of parameters, and both supported by the public OpenSprinkler script. Custom methods are for those who want to host their own scripts.

5. Add user defined parameters to “Custom” methods. To make the custom methods truly useful, they should also have some parameters attached. I suggest to provide a list of name-value pairs (eg. Elevation:700). The number of pairs can be fixed, I guess about 10 should be more than enough for all practical purposes (the parameters are stored in a file on the microSD card, so there’s no issue with size).

6. Document the expected input and output of the script. I could not find any documentation of the script’s calling convention and expected return values. I found some clues in forum posts, looked at the code, and used some TCP tools to see how excatly the device calls the script.

Example of what I want to achieve:

I need to manage several OpenSprinkler setups (my own, my parents and friends). I want to adjust watering time based on last 24 hours data, current conditions, and 24 hour forecast. But I also need to account for elevation and the slope of the yard (ie. south facing slope needs more water, north facing needs less). I use PHP as I have some experience with it.

I want to configure the OpenSprinklers I manage to call this weather script URL:
http://mydomain.com/weather.php?loc=xxxxxxxxxxxxxx&key=yyyyyyyyyyyy&fwv=zzz&uwt=custom1&wto="elevation":700,"slope":south

With such infrastructure in place, it should be easy to create different scripts for different purposes. I expect that with time some really good solutions will be developed, and those can be adopted as standard built-in adjustment methods.

Regards,

Eyal.

[Ray]

1) Allow host name of weather script URL to be IP address: my understanding is that DNS lookup works fine if the domain name is an IP address. I will check this later but I think it is the case.

2) Include the script name in the URL: you are right, at the moment if you want to change the weather?.py part you will have to modify the firmware. However, note that it’s usually possible to set up your server side to customize the endpoint. In fact, the OpenSprinkler weather script is currently written in node.js, and it uses redirect to define the endpoint of a url. This way, the server still accepts weather?.py but will map it to the appropriate server function call.

3) Pass adjustment method as GET parameter: sure this is possible. We just opted to be backward compatible with previous firmware versions. This can be changed in the future.

4) Add several “Custom” adjustment methods: the firmware is already set up to accommodate up to 255 (1 byte) weather algorithms. So you can easily define weather2.py or weather3.py and so on. But showing the names of these properly requires modifying the app/UI. In the meantime, you can use direct HTTP GET command to change the uwt parameter value, thus allowing it to use more weather scripts.

5) Add user defined parameters to “Custom” methods: this should be easy to do and in fact is already in place, as there is already a wtopts.txt (weather options.txt) stored on the SD card that tracks the weather options (for Zimmerman method, it’s the weight of each weather factor; for auto rain delay, it’s the rain delay time).

6) Document the expected input and output of the script: I agree this needs to be added. At the moment, if someone has a question about the weather script output, we typically ask them to try the weather script directly in a browser:
http://weather.opensprinkler.com/weather1.py?loc=xxx&key=xxx
where the first xxx is the location and second xxx is the WUnderground API key. From the output it’s relatively easy to figure out what parameters are returned, the most important one being the scale (i.e. watering percentage).

A lot of the awkwardness with the weather call are due to backward compatibility — since we don’t want to change the weather script and break the previous firmwares and old hardware, we chose to keep some of the old design decisions. This will be improved over time as we focus more on the current hardware versions — OpenSprinkler 2.3 AC/DC (and OSPi).

[Author]

Posts