Mobile Web App with Screenshots (Updated)

[Vaughano]

@salbahra wrote:

@Oasiz37 and @Vaughano thank you for the detailed information! Your feedback was invaluable and I was able to hunt down and fix the specific bug. Turned out I wasn’t doing the decimal to binary conversion correctly. That has been fixed now. Please try the new push on Github and let me know if this fixes your problem.

Also, @Vaughano, has the timezone issues been resolved at this point?

Thanks!

Thanks Samer.

I have pulled the latest code but my timezone issue is still there. Basically it looks like the log file has correct local time from the machine, but when displayed in the app’s log page the timezone configured is being applied. Put more simply it seems the mobile webapp is assuming UTC time for its own logs, and adjusting according to timezone configured in the app (correct log behaviour is observed when the timezone offset is set to 0).

Perhaps this a feature, not a bug? A possible work around is to configure UTC timezone in the mobile webapp, and always set programmes to UTC time, but I’m not yet sure of the impact of this workaround on actual programmes sent to the interval webapp.

I will do more testing and report back.

Cheers
Vaughano

Edit: I should add that my local timezone is one of those weird ones with a half-hour offset (Australia/Adelaide +9.5). May be significant?

[Samer]

I’m typing this out using Siri so sorry for the mistakes but if you don’t mind let me know what time zone is configured in the mobile web config.php. Thanks!

Edit: Completely irrelevant but looking back Siri did a decent job here, haha!

[Vaughano]

@salbahra wrote:

I’m typing this out using Siri so sorry for the mistakes but if you don’t mind let me know what time zone is configured in the mobile web config.php. Thanks!

Thanks Samer, here it is:

$webtitle = 'Sprinkler System';

$os_ip = '192.168.1.111:8080';

$os_pw = '';

date_default_timezone_set('Australia/Adelaide');

$timeViewWindow = '7 days';

$pass_file = '/var/www/OpenSprinkler-Controller/.htpasswd';

$cache_file = '/var/www/OpenSprinkler-Controller/.cache';

$log_file = '/var/www/OpenSprinkler-Controller/SprinklerChanges.txt';

$log_previous = '/var/www/OpenSprinkler-Controller/SprinklerPrevious.txt';

$force_ssl=0;

?>

[Samer]

That’s the problem. I made a change in the code to change the timezone to UTC. I also removed this option from the installer. The problem is people who had the old software still have the old timezone configuration. I made the situation worse by not defining UTC right into main.php but left it into config.php.

The line inside your config.php can be safely deleted after updating to the latest version (however you really don’t have to since I now define UTC inside main.php after importing the config):

date_default_timezone_set('Australia/Adelaide');

Anyways, pushed an update that should resolve the problem for everyone. The only problem left are your old log entries (inside /var/www/OpenSprinkler-Controller/SprinklerChanges.txt). You will have to dump them and start fresh.

The long-term sequele is all user’s logs will be in UTC and a timezone offset (set via the OpenSprinkler) is used to change the display. This works better for the main reason that user’s dont need to set two timezones (one on the OpenSprinkler and one in the web app).

Let me know if this helps!

[Vaughano]

Still not right I’m afraid. I removed the timezone setting from config.php and got the latest code.

I have the following:

1. Device time on the interval webapp is an hour past the time on the Pi. Not your problem with respect to the mobile webapp, but possibly significant to my scenario. This time would be correct in our summer!

2. Entry in SprinklerChanges.txt is :

10000000--2013-06-19 13:51:01

00000000--2013-06-19 13:52:01

3. Time reported in mobile webapp log is 11:22PM. As before, when I set timezone setting to 0 the log reads correctly.

Thanks for your efforts!

[Samer]

Now I suspect the time is off on the server running the PHP code. Can you run commands from the terminal? If so run the following:

date

If not make a file named test.php that contains the following and open it:

echo date(DATE_RSS)."n
";

date_default_timezone_set('UTC');

echo date(DATE_RSS);

?>

Just so I can try and understand the server’s situation. You could also do both in case they are different, etc.

The reason I suspect the time is off is because if your PHP is being told to use UTC time and is saving as 13:51 when in fact the UTC time now is 5:09 something is wrong.

Edit: Sorry this is taking a bit to work out, I am new to truly understanding timezones in programming and really only have my two computers which are both in central to experiment with. With that said they work fine which is what’s making it hard to grasp the problem. Thanks!

Edit 2: Using the OSPi code I just ran a run-once program and this is what I see:

01000000--2013-06-19 05:22:01

My web app displays:

Wed, 6/19/2013 12:22 AM Running Now

The interval program has a timezone set of -05:00 (central time but adjusted for daylights saving time)

[Vaughano]

Yes, my server times on the Pi are all over the place! Here are the results:

pi@raspberrypi:~$ date

Wed Jun 19 15:07:21 CST 2013



pi@raspberrypi:~$ php /var/www/OpenSprinkler-Controller/test.php; echo

Wed, 19 Jun 2013 14:37:27 +0900


Wed, 19 Jun 2013 05:37:27 +0000

pi@raspberrypi:~$

[JBinkley]

I’m just checking in on this after a couple of days heads down on work issues and it looks like you have made tremendous progress. I’m looking forward to the weekend when I can upgrade to your latest.

One thought came to mind when I saw you mentioned that only have a couple computers for testing. You can get a nearly free t1.micro instance of Debian (or many other distros) from Amazon Web Services (AWS). The micro instances are charged at $0.02/hr, but I think Amazon has a promotion where new accounts get 750 free micro hours/month. The way AWS works, you only pay for compute time when the instances are running and then a very small amount for storage while the machines are stopped.

Thanks again for the great work you have done on this!

[Samer]

@Vaughano wrote:

Yes, my server times on the Pi are all over the place! Here are the results:

pi@raspberrypi:~$ date

Wed Jun 19 15:07:21 CST 2013



pi@raspberrypi:~$ php /var/www/OpenSprinkler-Controller/test.php; echo

Wed, 19 Jun 2013 14:37:27 +0900


Wed, 19 Jun 2013 05:37:27 +0000

pi@raspberrypi:~$

That is the problem! So, your RPi has the wrong timezone set. It is using CST for some reason. PHP is using GMT+9 by default but because the RPi time is off its not able to make the proper calculations. Regardless, this needs to be fixed for my web app to work correctly.

First start with this in the terminal:

sudo dpkg-reconfigure tzdata

Follow the prompts and set the correct timezone. After this, re run those commands and tell me if they are lined up correctly with your local time, specifically the “date” command. If they are, check the web app against a new run.

[Samer]

@JBinkley Thank you for the suggestion! I could launch a few more VMs off my hypervisors but I am hoping it wouldn’t be needed. I have had some wonderful feedback of this running on routers and some NAS appliances so at this point I think the code is getting pretty stable and no VM I make will be unique enough to test a new environment. I am really depending on the odd situations I cannot predict from everyone here!

Hope the weekend update goes well!

Edit: I do actually own a Raspberry Pi just not an OpenSprinkler for it. I might try and hook it up to the network and test the OSPi directly on it instead of through a Linux VM and see if I can troubleshoot issues quicker/easier that way. Probably attempt that tomorrow since where it is located now it has no internet access.

[Vaughano]

@salbhara, I updated the timezone as suggested, though I believe it was already correct (Australia/Adelaide timezone is known as Central Standard Time locally here in Australia).

Results are now:

pi@raspberrypi:~$ date

Wed Jun 19 15:24:46 CST 2013

PHP Output (via apache this time, not cmd line to catch php.ini change)

Wed, 19 Jun 2013 15:28:01 +0930

Wed, 19 Jun 2013 05:58:01 +0000

Edit: Sanity check on linux date

pi@raspberrypi:~$ date

Wed Jun 19 15:32:01 CST 2013

pi@raspberrypi:~$ date -u

Wed Jun 19 06:02:12 UTC 2013

pi@raspberrypi:~$

[Samer]

Thank you so much, I am an idiot! I added UTC to the main.php but forgot to push it to watcher.php. I just pushed that change now. Hopefully, that is what we needed!

Edit: I also remember why I left UTC in config.php now 😛 So I only define it once. But this way is better in the long run, if it works.

Edit 2: To summarize for anyone reading this. The timezone problem was fixed a while back however anyone who was using my program before the timezone fix got hit with a new problem. This program applied timezone offset calculation while still using local timezone (because the config.php was not updated). Earlier I decided to move the timezone declaration out of config.php (since it is no longer user configurable) and move it into main.php. I decided to put it after requiring config.php that way I overrode the user setting (effectively moving everyone over to the new format). However, I forgot to update the watcher.php which runs every minute and this was still using the local time to update the log files. This has now been fixed. Anyone with problems at this point is advised to update to the latest version and delete the old log entries.

If any further issues persist please let me know!

[Vaughano]

Fixed!

Log file now contains UTC time, and mobile webapp view shows time adjusted according to timezone configured in both apps.

Thanks very much for your efforts! I will keep testing…

Edit: I am still having issues with times, and programmes not triggering, but I am almost certain that this is in the OSPi interval webapp, which seems to have some hard-coded daylight saving conversions and other time calcs I can’t yet follow.

Edit2: There was an element of user error here. I wasn’t setting the ‘interval’ parameter in the programme, which meant it was never triggered. I now see watering programmes being triggered in the interval webapp, and I see voltage where I expect it from the OSPi output. Woohoo!

However, I don’t see any update to the station status in the mobile webapp unless I trigger it manually. Programmes being triggered by schedule do not update the station status in the mobile webapp.

[Samer]

@Vaughano Fantastic! Glad it’s finally working!

In regards to the required interval setting I have also experienced this problem with setting interval to 0 and really wish it worked differently. This is true not only on the OSPi but the OpenSprinkler as well. You will notice the program preview, fortunately, also accounts for this requirement.

In regards to the station status during programs this is a bug on the OSPi that I discovered the other day but blamed my odd setup. But after you have pointed it out I am certain this is an actual bug. I will let Dan know (maker of the OSPi interval program) and we will see what happens from there.

Edit: I have also noticed the OSPi interval program won’t fire master stations in program or manual mode even with them set, but again I haven’t said anything thinking it might be my setup.

[Vaughano]

@salbahra wrote:

@Vaughano Fantastic! Glad it’s finally working!

In regards to the station status during programs this is a bug on the OSPi that I discovered the other day but blamed by odd setup. But after you have pointed it out I am certain this is an actual bug. I will let Dan know (maker of the OSPi interval program) and we will see what happens from there.

Yes, I have confirmed that http://192.168.1.111:8080/sn0 returns 00000000 when in fact there is a station on. In this particular case, station 2 is on, but http://192.168.1.111:8080/sn2 also returns 0, so it seems the underlying data structure is not being populated correctly when a station is triggered. I have some time tonight to dig deeper, so I may be able to fix it and provide a patch for the interval webapp.

[guylior]

@salbahra wrote:

Are you using the OSPi version of the OpenSprinkler? If so, the sequence option doesn’t exist and this is what’s throwing the warnings. From my understanding you can safely ignore them because the app will still function fine (notices shouldn’t be displayed to you, if they are your using a very old version of PHP or need to change your php.ini to hide notices).

This is what you need to change in your php.ini to hide the errors:

error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR

display_errors = Off

Source: http://stackoverflow.com/questions/10160859/turn-php-error-reporting-off-in-xampp

As the discussion on Stack Overflow suggests, bugs should be fixed not suppressed however in this case I am expecting something to be reported and unfortunately it isn’t supported yet. I could write some code to handle that properly but I am hoping it will be fixed on the OSPi side soon and find it redundant to add checking for this particular event.

The very first error you pasted from the View/Change program screen I am not sure about (because your version at this point differs from the latest on Github) however I venture to guess a station is not named or something weird like that. If you could update to latest code and run again let me know.

I installed the latest version, disabled the warnings and it works great. thanks.
is it possible to compile this into an android apps?

Thanks
Guy

[Ray]

I applied Samer’s patch to Dan’s interval program (per forum post viewtopic.php?f=2&t=154&start=40#p781) and checked it in to GitHub.
https://github.com/rayshobby/opensprinkler/tree/master/OpenSprinkler%20Pi/software/demos/interval_program
So it’s less confusion to anyone who is new to this thread. Sorry about the delay.

[Samer]

Thank you Ray! I went ahead and updated my older post with the information you just posted. That should help notify users who are directly linked to the post.

[Samer]

@guylior I am glad it is working for you now!

At the moment the application is merely a website that acts as an application. If you just bookmark the link to your home screen it should act very similar to an actual app, if that makes sense.

Here are some instructions for pinning a web app to the home screen: https://www.mavenlink.com/community/blogs/785-add-to-home-screen-for-iphone-ios-and-android

[sco3tt]

Great job, this is a really nice front end for OpenSprinkler!

When configuring my install I noticed some weirdness about the password setup, and came up with a workaround for anyone else having similar trouble. For the record, I’m running an OpenSprinkler Pi with OpenSprinkler-Controller and the interval_program both hosted on the device itself. For this one I’m using lighttpd rather than apache to keep the footprint small (if that makes any difference).

The problem I found was that when I ran the initial setup and gave it a fairly complex password (> 8 characters with some special chars), it appeared to save everything okay but then would always give me an “Invalid login” when I tried to use the app. I deleted config.php (in order to get back to the setup page) and re-did the setup several times, always making sure I didn’t mistype the password, but had no luck with this until I tried a simpler password (“test”). That succeeded and allowed me in… so for some reason it looks like either the initial setup or the validation in main.php has a problem with more complex passwords, although I examined the code and can’t see any reason why this should be so.

A secondary issue was that the app doesn’t provide any way to configure access for more than one account. I wanted to send a link to a friend to show it off and convince him to buy an OpenSprinkler Pi, but did not want to give him my credentials, so I needed a way to create a separate account for him.

To work around both of these problems I decided to try apache’s htpasswd utility to manage the accounts outside the app instead (apt-get install apache2-utils if you don’t already have it).

Usage is pretty simple, just cd to wherever your .htpasswd file is (by default it’s in the app’s root directory) and you can add new users (or change the password of an existing user) with

sudo htpasswd -s .htpasswd YourUsernameHere

(It’ll prompt you for the new password. The -s switch tells it to use SHA for hashing, in keeping with what the OpenSprinkler-Controller app itself uses.)

However, that only solved one of the problems. Now I had a way to manage multiple accounts, but it broke the app’s login screen. I couldn’t even get in with my simple “test” password anymore.

I checked the .htpasswd file and saw that the Apache utility had stuffed a “{SHA}” prefix in front of the hashed password which the sprinkler app hadn’t used. So in order to make the sprinkler app understand Apache’s format I edited main.php and changed this line:

$test_pw=base64_encode(sha1($pass));

to this, so it would cope with the prefix:

$test_pw='{SHA}'.base64_encode(sha1($pass));

Unfortunately, this still didn’t solve the problem. I read that htpasswd does indeed base64 encode the SHA1 digest of the password, so I knew this code had to be correct unless Apache’s SHA1 implementation was different from php’s for some reason. It turns out that by default, php’s sha1() function defaults to outputting a 40-character hex number (which obviously doesn’t need to be base64’ed in order to be written to a text file), so I switched the code to use the raw bytes from the sha1 call instead (which do need encoding) by adding the optional “raw” parameter:

$test_pw='{SHA}'.base64_encode(sha1($pass,TRUE));

This resolved the problem — my friend and I are both able to log in with no issues, and now I can manage all access via htpasswd without having to go through the initial setup to change anything.

Speaking of which, if for any reason I need to delete my config.php file and go through the initial setup again, the install page needs to be changed to observe this format too. This line in install.php:

$r = fwrite($file,$_REQUEST["username"].":".base64_encode(sha1($_REQUEST["password"])));

just needs to be changed to

$r = fwrite($file,$_REQUEST["username"].":{SHA}".base64_encode(sha1($_REQUEST["password"],TRUE)));

and Apache-style passwords will be used during setup as well.

Good going, Samer! This is a really amazing piece of work, and I am impressed by your rapid responses in getting all the bugs worked out. (And Ray, if you’re feeling generous you should send this guy an OpenSprinkler Pi. I feel bad that he’s debugging Pi-specific issues by tracing through the interval code.)

[Samer]

@sco3tt Thank you for the elaborate workaround and sorry you had to go through that! Turns out I do a very stupid check on authentication, one that rejects anything non-alphanumeric. This check isn’t place when adding a new account. Also, although the authentication accepts multiple accounts your very right, I did not add an option to add multiple accounts. I was lazy and will absolutely add it to the to do list!

I will use your feedback to update the authentication scheme. I will also remove the silly alphanumeric restriction!

I am glad everything is working for you now!

By the way, I have a special version of my web app up now. It requires no install! All it needs is internet access to the OpenSprinkler by opening a port on your router. The app is hosted on rayshobby.net and saves the configuration in the browser’s local storage. Since the information is read off the local storage it has no messy authentication to deal with (none needed since all sensitive data is in your browser). Ray plans on blogging about it soon but for anyone eager to try it out it is available here: http://rayshobby.net/apps/sprinklers/ 😀

The one downside of the hosted web app is the lack of logging. Unfortunately, there is no way to poll data from the OpenSprinkler without saving the password on the server, which I want to avoid for security reasons. Also, I don’t want to poll the OpenSprinkler over the Internet as this would cause a bit of traffic/latency which some user’s can’t afford. However, everything else is the same.

I will maintain both copies of the web app since each one has a particular application depending on the user. So, this is not a replacement but rather another option for users who do not have a Raspberry Pi or another server to host the web application and are okay with the OpenSprinkler having a port forwarded on their router.

If you have any questions feel free to ask, and above all enjoy!

Huge thank you to Ray for hosting the web app!

Edit: I pushed an update on Github for the alphanumeric problem. Complex password should work fine now! Another update will follow to support adding/deleting users.

[Vaughano]

The one downside of the hosted web app is the lack of logging. Unfortunately, there is no way to poll data from the OpenSprinkler without saving the password on the server, which I want to avoid for security reasons. Also, I don’t want to poll the OpenSprinkler over the Internet as this would cause a bit of traffic/latency which some user’s can’t afford. However, everything else is the same.

On the topic of logging, I’m thinking that I’d prefer logging be performed in Dan’s python interval program. I believe that is a better source of truth since it is the application that actually controls the GPIO/OSPi. Logs can be be exposed via a web service to the mobile webapp, whether hosted or not.

This is a little more consistent with the way the rest of the mobile webapp behaves, as a front-end delegating backend application functionality.

Cheers
Vaughano

[wyone]

Well so far I am still working on getting the Ubuntu to work, so I cannot really use the information pasted here. I will get it though! lol Although I am now wondering if I should be using the server version instead of the desktop version. I am really a graphical person, so I prefer the GUI, but after reading, I am not sure it will do what I want to do with open sprinkler. hmmmm

I did try to look at the new program you posted above and I guess I need to spend some more time. I am not sure if it is fully functional yet, but I cannot get into my sprinkler control with it. Maybe I need to try to do that when I am more awake. lol

Anyway, I REALLY REALLY want to thank you all for all of your efforts to make this awesome program. I will be donating soon to your efforts!

Mitch

[Samer]

@Vaughano I agree with you however the limitation on the OpenSprinkler was memory. That has been resolved in hardware 2.0 and hopefully Ray can incorporate this feature now. Also, Dan has added this feature into the OSPi which is functional however my web app cannot use it yet and I am holding off until there is a compatible logging system in both versions.

@wyone The desktop version will work just as well as the server version! Use what is comfortable since it will help get you up and running quicker.

Also, the hosted web app might not be working because you need to use your routers WAN IP. To find this goto http://wimi.com. Another requirement is port forwarding the port used by the OpenSprinklet. For more information consult this guide: http://www.computerhope.com/issues/ch001201.htm

[Samer]

By the way, for anyone who has noticed, there are some graphical glitches on iOS and I have finally fixed all of them. I am still testing however expect a push by today!

[Author]

Posts