[Samer]

Ray got this bug fixed and it will be released in 2.1.4.

Thanks for the information!

[Samer]

Daylight Savings Time is supported through the weather lookup and makes sense that it is also incorrect. The weather query also retrieves the day’s sunrise and sunset which explains why those are also incorrect.

We had one user on the forums who had an issue with the controller not reading weather reply when a firewall was installed between the device and the Internet. I think we might have found the firmware issue related to this and resolved in 2.1.4 which should be released very soon.

Is there anyway to disable the firewall just to test?

[Samer]

This is very cool, I love how organized everything ends up.

Thanks for sharing!

[Samer]

Does the device show the correct timezone? This is part of the reply from the weather service. Also, the sunrise and sunset times under the forecast page (clicking the weather icon on the home page) will show the controller’s sunrise and sunset times for the current weather (future days are calculated in the app).

Are you using a static IP on the device? If so, what is your gateway IP? Do you have any firewall appliances possibly filtering OpenSprinkler weather requests?

Just some thoughts to try and troubleshoot, thanks.

[Samer]

This is very well written and if you don’t mind I would like to help incorporate it into the main code. The documentation alone is worth it (and apologize for the minimal documentation in our code).

In regard to the logging of ET data, I am sure we can incorporate that into the firmware and offload the ET calculation to the weather service. The runtime calculation (using log data) would be calculated on the firmware side.

Also, feel free to submit pull requests to the repo as we are happy to review and merge changes like these.

Thanks!

[Samer]

No, nothing was changed.

[Samer]

We’re working to isolate this issue as we are also experiencing this in our testing.

[Samer]

Can you attach a screenshot please?

[Samer]

Brian,

Sorry I thought you were on OSPi, apologizes. The new firmware should be released soon so if you want you could wait or maybe Ray can provide some assistance with compiling.

[Samer]

Brian,

I found the issue regarding images not loading (weather and ajax loader). It was CloudFlare enabling “Hotlink Protection”. This has been removed and now the images are loading as expected. Let me know if you are seeing the same thing.

Thanks!

[Samer]

This has been added to the upcoming firmware and will be released in 2.1.4. Ray will be announcing it soon.

Thanks

[Samer]

Okay, I looked into this and the issue is related to the Weather Underground API call made from the app. It uses http:// instead of https:// therefore the browser is denying it since the remainder of the site is SSL encrypted.

The fix has been posted to the code: https://github.com/OpenSprinkler/OpenSprinkler-App/commit/20958d726a79c7173d490ae8acea0ef3bfba4d80 and will be released in the next app update (1.4.2) which should be out by the end of the week.

Thank you for the report!

[Samer]

So, everything works except the weather diagnostics popup?

[Samer]

Lighthttpd is fine. My point is that the proxy works. I don’t know which router you have so I can’t know which software you can install but again it doesn’t matter which httpd you are using, I am just saying Apache since that is what I have experience with.

[Samer]

Sorry I don’t quite understand however I will say I use this every single day. My personal setup uses Apache proxy and it works even better than directly accessing the controller remotely since Apache is a much more capable web server than the Arduino based server.

So yes, this works fine on my setup. I recommended making a new site instead of changing a current one to use SSL, if you are using the app.

[Samer]

The Weather Diagnostic popup does not talk to OpenSprinkler but rather polls Weather Underground. Therefore, this is an unrelated issue and suggests something else entirely.

Which app are you using?

This is considered an advanced topic and not something we have a guide for and is left for the user who is capable of performing such a task. Don’t get me wrong, I don’t think this is ideal and we are working on a solution to avoid port forwarding and having to use SSL proxies to ensure security.

Also, I have never used lighthttp so sending me the config really won’t help much.

[Samer]

OpenSprinkler does not support SSL out of the box however the app supports SSL and Basic Auth if you use a reverse proxy. We don’t have an official guide as the setup can be quite variable based on the setup at home.

Basically, if you want to securely open access to OpenSprinkler: you need to have a web server installed such as Apache and proxy pass the path to the OpenSprinkler from there.

[Samer]

Thank you for the detailed information and solution! I completely overlooked this aspect of the caching issue and have already merged the fix into the main code base.

Would you mind updating your code (git pull) and rebuilding to see if the cache issue is resolved?

I will likely go ahead and add the Pragma: no-cache to the request in the app/UI as well since older firmware’s will still have this issue.

Thank you!

[Samer]

Hi Brian,

I specifically timestamp each request I make to the controller to avoid caching issues however Chrome has been caching some requests according to some users. I will re-examine this however I doubt I can do more than what I already am to prevent caching.

I opened the URL you provided and I got no error. Furthermore, when I load the app using the browser method, I don’t see the error in the console. If you open that URL yourself, do you see the icon or instead get an error?

Thanks!

Update: I am able to replicate this issue on some networks/devices and therefore am hunting down the issue. It appears to lie with CloudFlare, our CDN, since the server is never even seeing the request for those files much less giving out a 403 error.

[Samer]

The reason for this is because your device doesn’t have GPS and the app can use GPS to help you find a nearby weather station. I thought I fixed this in 1.4.1 but clearly it didn’t work. I am going to look into this and get back to you.

Can you try to install the app from here (you will need to enable 3rd party vendor): https://build.phonegap.com/apps/1373249/share

Thanks

[Samer]

The program preview works for every day of the week and not just the current day. As a result, it has to calculate it’s own sunrise and sunset time for each day it is rendering. Therefore, the times might vary for programs using sunrise or sunset due to the source of the data.

Basically, the controller get’s the sunrise/sunset data every day from the OpenSprinkler weather service whereas the program preview on the app is calculating the sunrise and sunset within the app without requesting this data.

I do try to minimize this difference by comparing the current controller’s sunrise compared to the calculated sunrise and use that difference as an offset. This brings the predicted times fairly close and 5 minutes is a bit surprising for the current day. Therefore, I will take another look at this to make sure it is accurate however I hope this explains the discrepancy.

Just to make sure, when using a specific start time, this 5 minute delay does not occur?

[Samer]

This is documented in the user manual: http://rayshobby.net/docs/ospi14_manual.pdf

[Samer]

Oh, okay I understand now. Yes, it give a password invalid error on prior firmwares.

[Samer]

This is actually something that has been happening with the demo we host: http://demo.opensprinkler.com. In order to keep the process running I had to wrap it in a small script:

#!/bin/bash
while ! ./OS-Demo/OpenSprinkler
do
  sleep 1
  echo "Restarting program..."
done

This isn’t ideal and I will talk to Ray to figure out why this is occurring.

[Samer]

So, firmware prior to 2.1.3 did not correctly store 32 character strings (the length of an MD5 hash) and therefore was not really supported.

[Author]

Posts