[Samer]

Ah okay sorry about that! Now I understand the issue.

The other version you are seeing is in fact correct but it’s the build number. This happens to look like the version but it’s not. Code: https://github.com/OpenSprinkler/OpenSprinkler-App/blob/master/config.xml#L43

[Samer]

That last update didn’t address this issue. There is another one (1.8.2) that does.

For future coorelation, please use the version displayed in the about page.

[Samer]

I am preparing an app which downgrades the webview back to UIWebView. This will be available as 1.8.2 shortly. I believe the issues are all due to the webview change made in 1.7.9.

[Samer]

I am preparing an app which downgrades the webview back to UIWebView. This will be available as 1.8.2 shortly.

[Samer]

In testing this morning I was able to reproduce the issue on firmware 2.1.7 on a v2.0 device. I don’t think it’s tied to the hardware or firmware at all but rather a fault of the iOS app specifically (as we suspected). However, after installing another version the app started working. I even deleted everything and re-downloaded from the app store and it works now.

I asked Ray to also test with his iPhone and it works for him and his colleague as well.

I am sure you tried this but if you force kill the app and restart it, does that have any bearing on the outcome?

I am still trying to pin this down and just looking for information, thanks!

[Samer]

NTP based time syncing and weather based adjustments are the only two network dependent items. Hosting the UI or using one of our provided apps should allow you function without an Internet connection.

[Samer]

No problem! It was a fun read up for myself: https://github.com/ftlabs/fastclick/issues (quite a few related issues).

I fear though the switch to WKWebView is what is causing your issue along with a few other customers. I admit I test mostly against the demo so I overlooked this issue. I will try to pin this down and will hopefully have a resolution soon.

[Samer]

I understand where you are seeing the version now but I am generally referring to the version listed in the about page. Thanks for pointing out this detail though.

The fact that the app communicates with the cloud server tells us the issue is limited to the insecure connections. Let me do some more debugging and I will get back to you.

Thank you for the detail!

[Samer]

Thank you for the information. In regard to the crashing, we have solved that issue in 1.7.9. That version is currently in the app store. Could you please update your 1.7.4 version to the latest version and try again?

To be clear about the recent iOS crashing: The app was not crashing per se but clicks stop being registered. The app was still running and updating as shown by running timers etc. This was a bug introduced by Apple in iOS 11.3 and persists in iOS 11.4. The latest iOS 12 beta shows it to be fixed. The bug is a negative timestamp being sent with events when the app is running in the background (eg. lock screen). This bug alone is not an issue but we use Fastclick to remove the 300ms delay in UIWebView (we have now switched to WKWebView in 1.7.9). We now use a newer build of Fastclick which has this bug resolved (uses new Date().getTime() instead of the passed in timestamp).

[Samer]

Can you add the demo to the iOS app?

IP: demo.opensprinkler.com
PW: opendoor

[Samer]

Are you using a reverse proxy with SSL? Which version of OpenSprinkler are you using?

[Samer]

This update has been pushed out as version 1.8.1. It should be available in the next few days on the App Store.

Thank you again for letting us know!

[Samer]

Yes I can reproduce this on iOS. Thanks for pointing this out.

It’s due to the WKWebView being used now as opposed to the UIWebView. I’ll get a fix for this ASAP.

Fixed in https://github.com/OpenSprinkler/OpenSprinkler-App/commit/c9f980b69aa4cbf811001feff220e34e902f5b17 (will be out this week)

Samer

[Samer]

@Sebastian I would suggest performing the following steps:

git checkout master
git pull
sudo ./build.sh ospi
sudo /etc/init.d/OpenSprinkler.sh restart

See if that helps your issue. A restart after the following steps if the issue persist might help.

Let us know what you find.

Thanks!

[Samer]

Version 1.7.9 is now available in the store. Please let us know if it resolves the issue.

Thanks!

[Samer]

The cloud option does not backup the configuration of the devices unfortunately. It only syncs your device login (IP, port, password, images, etc) across instances of the app.

Once you log into the device the first time, you can check if you can import a configuration. Your app might have a local copy saved if you exported it before.

Otherwise not sure what else can be done other than to manually restore the configuration by hand.

[Samer]

Just to update everyone, from my testing the fix works and is now in review as version 1.7.9. Hopefully this will address the issue however please let me know if anyone continues having the issue after updating.

Thank you for your patience!

[Samer]

@Pat I am looking into DarkSky now and the API seems very easy to use and the data seems very rich. The perfect alternative it looks like as OpenWeatherMaps is missing historical data in the normal API and requires seperate billing and API call for historical data. There website clearly says do not direct customers to generate their own keys, each company should use one key.

Their pricing seems very reasonable so I think I will discuss this with Ray and hopefully get this solution setup. This will stabilize the scale values currently being seen with OpenWeatherMaps as the source.

[Samer]

Awesome glad you found that out. I will update once I have more information regarding the OWM fluctuations.

[Samer]

Regarding the OpenWeatherMap water level being very dynamic, I am looking into that now. Hopefully will have a solution soon (which should be a server change).

The OWM key is managed and paid for by us (OpenSprinkler). This is to avoid users having to register with a new site and retrieve a key for personal use. Instead we believe the cost will be reasonable for us to manage and maintain it. This will also allow us to be more responsive as API’s change, etc.

[Samer]

@Jemba Okay I identified your issue specifically. If you look at the reply from WUnderground, your daily summary data is empty. This is resulting in a lack of data showing the resulting summary:

{ icon: 'partlycloudy',
  timezone: '+0200',
  sunrise: 342,
  sunset: 1294,
  maxTemp: NaN,
  minTemp: NaN,
  temp: 78,
  humidity: NaN,
  precip: 0,
  solar: 1,
  wind: NaN,
  elevation: 400 }

Noticed all the NaN values which means it’s missing. This is causing the scale not to be calculated. If this changed recently maybe WUnderground is now omitting this data?

[Samer]

Okay found the issue: It’s due to FastClick library using incorrect values for the timestamps. Here is more detail:

https://github.com/ftlabs/fastclick/issues/549

I am trying out a fix now, if it works we will push this out ASAP.

Thanks!

[Samer]

Also can you provide me the exact location you are passing?

[Samer]

I noticed your WUnderground URL has a misspelling for the word yesterday. Is this what was sent to WUnderground. I ask because I just noticed you are missing the history section of the reply. If the URL is correct (not like it is typed here) then the lack of history is causing the scale to remain at 100. Otherwise we need to further investigate.

[Samer]

The data above looks correct. The only other request I have then is to try the following link again replacing your API_KEY and LOCATION:

http://weather.opensprinkler.com/1?key=API_KEY&loc=LOCATION

Let me know what scale is shown please.

Thanks!

[Author]

Posts