Forum Replies Created
-
Posts
-
I suppose it depends on whether we want to aggregate the precipitation ourselves or find an API that provides a rainfall report at both the 24 hour and 7 day level. Might be more realistic to do it ourselves, but we’d need make use of local storage to store the data.
Edit: yeah, the parsing will be easy. Just need to find the data.
I suppose it depends on whether we want to aggregate the precipitation ourselves or find an API that provides a rainfall report at both the 24 hour and 7 day level. Might be more realistic to do it ourselves, but we’d need make use of local storage to store the data.
nice job finding that. I had been looking around for a good example and gave up. I think this would be a great UI for it, but first we’d have to find a service that provides that kind of data. I’ll have to look through the Yahoo API to see if we can get rain accumulation, etc. Forecast is no problem.
So let’s say we got the data. I guess we could just set it up so that the script ran once per day and either did or did not set a 24 hour delay depending on the conditions. Is that what you’re thinking?
Awesome. Just pulled the code and it appears to be working (it’s not raining so it’s a bit difficult to test).
Two things:
1) The max rain delay should be a bit longer, perhaps 3 or 4 days.
2) it would be really cool if the rain delay events could be logged. Not sure how difficult that would be though.I was tracking the code that you checked in in preparation for changing the ui to allow for delay settings and I wonder whether it may be overkill (at least initially) to allow custom delay settings per individual condition code. Most users, I suspect, will want to say: “when it’s raining, set a delay for X hours”. They won’t care to specify hours for each code. Perhaps we ought to just identify which codes signify rain and then apply a single user-set delay when they come up.
@salbahra I was going to mention this anyway, but your response to @context gave me the perfect transition. With respect to deleting the config.php file (which I have done a few times now), you get the added benefit of having the watcher script installed into the crontab multiple times (as in, there will be multiple rows to execute the watcher script). I’d recommend checking for the line’s presence in the $output string before adding a new one.
Looks good. Can’t wait to see it in the app. Does the file_get_contents do proper url encoding? I could see that line running into problems if locations contain commas and spaces.
Also, I’m not a huge fan of hitting the woeid database every time you wish to obtain weather data. Is there a way to cache the woeid and continue to use it so long as the location option hasn’t changed since the last time? For one thing, Yahoo is a little bit more restrictive on their placefinder API than they are with their weather API. Also, the woeid queries can actually take some time (I ran the query using “Disneyworld” and it took several seconds to return).
Edit: looks like we’re cross-talking and you’re already considering the same issue.
Edit 2: Also, I completely agree that 1 minute is too frequent for weather checks. An hour is probably fine. I really only had it running every five minutes so I could test it out more easily.
Sounds great. Let me know if you need any help with the integration.
As for the frequency, I have it running more frequently because it only checks *current* conditions so if we’re only getting the weather once per day, we could easily miss the thunderstom that rolls in and soaks the ground. We could look into looking at future forecasts, but I’m not sure what kind of rules we’d want to apply over them. I had been looking for a while for an online data source that could be queried to obtain rainfall accumulation data (e.g., inches of precipitation in the last x days) but couldn’t find one.
salbahra: I uploaded a bash script to obtain the woeid from Yahoo. it can be found here:
https://github.com/andrewshilliday/OpenSprinkler-WebRainDelay/blob/master/get_woeid.sh
Pass in an argument with the string that you want to search for. For example:
> ./get_woeid.sh "Washington, DC"
2514815 Washington, DC
> ./get_woeid.sh "12345"
12762240 Schenectady, NY 12345
> ./get_woeid.sh "Disneyworld"
23686031 Walt Disney World Resort
> ./get_woeid.sh "Beijing"
2151330 Beijing
It will return the woeid and the name of the matched location. They’re separated by a tab, so you can pipe it to cut -f 1 to get just the woeid.
I wouldn’t recommend calling this every time you want to query the weather. Rather, I would run it once to obtain the weoid and somehow save that along with the user-specified location. Yahoo limits the number of times this part of their API can be accessed.
salbahra: There isn’t anything preventing that and in fact, the overwriting of existing delays was intentional. The idea was that as long as it’s still raining, we might as well push the rain delay out to whatever it’s set for that condition. So if I have it to set a rain delay of 48hrs on rain, then because the script is constantly overwriting the delay setting, the timer won’t start until it stops raining.
Now that I write it down, however, I am realizing that there could be a problem with that approach: If you have condition A set to delay for 48hrs and condition B set to delay for 24, and A hits first but then the weather changes to B, the delay will be changed to 24 hours even though you might still want it at 48 because that original condition did occur.
Perhaps it should be set to only overwrite the rain delay if the new delay is higher than the existing one. What do you think?
As for integrating into your application. By all means. I will also look into writing a script to resolve the WOEID, if it’s not too complicated.
Thanks. I’ve updated and it seems to work correctly (I’m not yet confirmed that the program is executed, but I’m no longer seeing the same error when I try to update a program on the python app that was set to 1439 minutes from the mobile app.
While I’m at it, I’ve got one more bug for you (this one is borderline minutia):
On an iPhone, if I try to change either the “operation” or “manual mode” toggle switch by swiping to the right (rather than just pushing with my finger) it has the slightly annoying habit of taking me into the settings page (as if I swiped to the right elsewhere on the page). In my opinion, you could just do away with the “swipe to get to the settings” feature all together, as there is a button in the top-left corner that works just as well, but that’s just my two sense.Also: since you were looking for feedback, I really like screenshot you posed for the preview screen. Will there be a way to jump to a day or would I have to scroll forward and backward?
Very cool app. I’ve got it running on my raspberry pi and everything runs like a charm.
One bug that I noticed: when creating or modifying a program, the interval slider has a maximum value that seems to be too high for the backend opensprinkler program (at least the one running on the RPi). If you select the maximum value, it respnds as if everything is behaving correctly (and in fact, the program even shows up in the schedule), but it does not seem to actually execute when the time comes. I notice that if I use the same value (24 hours, 00 minutes) on the python-based interval program it displays an error and doesn’t allow me to save. On the mobile app, it does let me save, but the interval silently ignores the offending program. I suppose one could mark this up as a bug in both the mobile and the python program, since the python program ought to correctly validate the programs it’s receiving from the mobile app but it’s probably a ridiculously easy fix on the mobile app side.
Sorry if the bug detail is confusing. I can clarify if you don’t understand. Basically, however, the maximum needs to be set down to 23 hours and 59 minutes (I think), instead of a full 24 hours.
