[Samer]

As I mentioned earlier, and you confirmed with your feedback, the controller is not communicating with the Internet correctly. Furthermore, I noticed you have another forum post open about intermittent connectivity issues with your OpenSprinkler. I believe the two are related and the connectivity issue is causing your device not to update its weather level.

Also, the weather diagnostics is showing the live data from Weather Underground, not the control. The watering level is the only variable in out popup that’s actually from the controller. The numbers are what the weather script gets (weather.opensprinkler.com) which is why they are showed there but the actual device watering level is shown since that’s what’s important. Maybe I will add an “expected” value so the difference is more apparent.

Lastly, yes the “scale” value is the end water level result, which is 0% as you expect.

[Samer]

Hi Luca,

The rain sensor works by delaying the controller using it’s own analog method and the delay is a function of the drying speed of the material used inside the rain sensor. Basically, they are supposed to dictate the “how long to stay off after rain”.

The app can start a rain delay manually, using “Change Rain Delay” from the main menu however this is unrelated to the rain sensor you have installed.

Thanks,
Samer

[Samer]

I think for the OSPi this can certainly be done however for the Arduino, resources are quite limited and could be used for other things. Maybe Ray can comment more about the Arduino being able to do this.

[Samer]

The most likely culprit is the controller not successfully retrieving data from the weather service. To quickly test if the controller is having an issue, try a different location and see if the value updates within a few seconds.

Also, the end point the controller is reaching out to is: http://weather.opensprinkler.com/weather1.py (1 means Zimmerman method to the controller). It takes the location in as ‘loc’ and the API key as ‘key’, as GET parameters. For more information on the code you can refer to Github: https://github.com/OpenSprinkler/Weather-Adjustment

The reason I am telling you about the end point is for you to test against it. If you see the correct scale on the endpoint but wrong on the OpenSprinkler, then it’s failing to communicate. If it’s wrong on the weather service then it’s a problem in our calculation. This way we can have better data to trace down the issue.

Thank you

[Samer]

If your weather station can integrate with Weather Underground, you can reference it for use with the weather adjustments.

In regard to the adjustment method, we are working on adding ET based adjustment and hope to have this soon.

[Samer]

Oh okay now I understand the problem. The best way to test this is to schedule a temporary program that starts 1 minute ahead of the current time. This should test the rain sensor in the fashion you described.

[Samer]

I think a more suitable test would be to pour water on the rain sensor. Otherwise, you are not testing a normal part of the software loop (triggering a rain sensor by bypassing the hardware doesn’t test much and is similar to triggering a rain delay).

You can also change the state of rain sensor (normally open to normally closed).

[Samer]

Hi,

The fix does not depend on the firmware version and all versions have received this fix (no need to reflash).

So answering your questions:

1) Yes it is correct with 2.1.2.

2) If you upgrade to 2.1.3, everything will work without any patching needed.

Thanks.

[Samer]

It does make sense to keep the flow data with each run since that’s what we would be associating it with: duration and frequency.

And as you discovered it shouldn’t interfere with the current methods (extra data). We can absolutely continue this path assuming Ray can implement your methods regarding the flow data.

[Samer]

I am very open to allow GPM data within the app. Another user suggested a station specific popup showing its detail. I think for backwards compatibility we can put this data in another file on the SD and pull it when available like the watering level log is handled. This way they can be polled separately.

I ripped out the old graphing library as it gave me many issues and made the timeline default. I am looking for a new graphing library and plan to have a candidate soon to replace it and reincorporate graphs that are responsive. Once that is completed we can easily plot flow data as well.

Thanks!

[Samer]

Sean,

I have imported your configuration and begun examining the issue. Just for reference, the previous app also reported no watering for today so this isn’t a new issue.

In regard to previous days, you can goto the table log data and see the average watering level for that day (an average of each reply for that day).

Update: By the way, is your water level 0%? Because the current day takes into account the current watering level and if it’s 0% the preview will show no runs whereas any other day will show the set durations. Based on your current export, it looks like the water level is in fact 0%.

[Samer]

This can certainly be a possibility. Is this a statewide restriction? Can you provide any official information on this (in case it has information such as amount of rainfall to count for restriction, etc.)?

Since the weather adjustment script knows the location, it can check the rain status of the past two days from the data it already has and adjust the watering percentage to 0%. This would be applied regardless of the weather method being used (currently only Zimmerman).

Just FYI, the weather script is also open source and available here: https://github.com/opensprinkler/weather-adjustment. If anyone wants to fork the code, apply the above method, and pull request then I would be happy to review it and make it available.

[Samer]

Hi Randy,

The OSPi Python program you installed is still in active development by Dan Kimberling. It has also received a lot of updates since 2.0.1 that likely resolve a lot of the bugs you are experiencing. With that said, the Unified firmware is the official firmware that is written by Ray for the Arduino and recently all other platforms. The Unified firmware has some advantages such as per station watering times in programs, integrated weather adjustments, etc. The Python program is more flexible and offers a plugin system for quick expansion.

The tight loop bug is not fixed yet on the master code however the suggested fix of adding usleep(10000) seems to work great and am sure Ray will update this in the next version. Therefore, if you want to avoid high CPU usage and don’t want to edit code, stick with the Python version (maybe update it) for now.

Thanks!

[Samer]

Hi, yes you should be able to wire two stations to the same terminal but do realize they will both turn on and off at the same time.

The forum search feature is visible on the forum root page: https://opensprinkler.com/forums/ (top, next to your user name). I understand how it could be useful to have that available on all forum pages and will look into that.

[Samer]

Okay, I believe this has been fixed. Please check your OpenSprinkler and see if the correct water level is being shown now.

Some detail: The script was resolving the weather station latitude and longitude to calculate sunrise / sunset times however later in the script the location gets swapped from whatever is provided to the latitude and longitude. This was done before PWS and ICAO locations were supported to allow a uniform query. Of course, this isn’t ideal when using a specific weather station and is also what caused the issue you are both seeing. I have since updated the script (code here: https://github.com/opensprinkler/weather-adjustment) to check if a PWS or ICAO is being used before just changing to latitude and longitude.

Thanks!

[Samer]

I can confirm there is an issue resolving the data on our end. Even though Weather Underground is returning the correct data, the script which OpenSprinkler uses to calculate watering level is not parsing the data correctly, it appears.

I am still investigating and once a solution is released I will post here to update.

Thank you

[Samer]

@gary, I will be releasing it very soon but wanted to release the browser update first since I can fix bugs instantly whereas the apps have a few hours to days delay. By Friday the apps should be released to the stores assuming no bugs prevent release.

So far, I think the update is being received well and don’t foresee any delays with the Android, iOS, etc being updated.

[Samer]

@craftgeek, some fixes where made to the preview algorithm to fix some reported bugs. I’m wondering if those changes adversely affected you.

Do you mind providing an export of your config? Be sure to remove any API key or other sensitive data and you can privately attach it here if you wish or email at [email protected].

Thanks!

[Samer]

The footer/status bar acts as a link back to home for the most part. Taping it returns you to home.

The graphing of water level data will come back in one form or another but it wasn’t fair leaving a broken implementation in the code. Once I identify a better library the support will likely return.

The notification icon only shows up if you have a notification. Is the desktop connecting to the same OpenSprinkler that needs a firmware update? If so, I would try refreshing a few times sounds like a cache issue, maybe.

[Samer]

Hi Gary,

Sorry for not replying to your first post earlier however it didn’t go unnoticed and in fact the fix was pushed to the code two days ago. Ray identified the problem and provided the solution regarding the preview duplicating the station. The app should be updated by the end of the week.

Thank you

[Samer]

This next update has quite a few changes so I want to be sure to test everything out before release. The good news is it brings a lot of new features and improved navigation along with a lot of bug fixes. I am hoping by the end of this week we will have the next version out.

Thanks!

[Samer]

Okay, I think I can offer some explanation. One, the graph view has a lot of bugs with the scale of the plot not showing some runs and other issues, so we are removing this in favor of timeline (now default) which helps compare to the program preview.

Second, the timeline and table view were both showing the end time as the start time causing both to be off. This has been fixed.

Lastly, the timeline view on the log page was sorting stations alphabetically which made reading the timeline quite difficult. I have since fixed this to sort by station order.

These changes have resulted in the timeline on log page matching the expected preview and the table view being accurate.

These changes will be found in the next app release.

Thanks for the report!

[Samer]

By the way, I deleted your configuration because it contained your weather underground API key.

[Samer]

Although the app is saying “An invalid API key has been detected” the reality is the error is being thrown because WUnderground is giving an error. The line of code specifically triggering the error you are seeing is below:

if (typeof data.response.error === “object”) {
showerror(_(“An invalid API key has been detected”));
return;
}

This means it WUnderground returns data with an error then the app stops processing the request and shows the message.

The reality is, this can be due to your API key having no more calls for that day or it could be the location is not valid. In order to debug this, I would navigate directly to WUnderground by using the below URL to discover the actual error:

http://api.wunderground.com/api/APIKEY/yesterday/conditions/q/LOCATION.json

Change the APIKEY to your WUnderground API key and LOCATION to the location you have provided in the location box on the options page. Once we have the actual error we can troubleshoot from there.

Thank you

[Samer]

Thank you for the images and detail. I have loaded your configuration and will begin to troubleshoot this. I will get back to you once I have found the problem.

Sorry for the trouble and thanks again!

[Author]

Posts