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).