[Vaughano]

Would really like to get back to this, but my part time job has become full time coding, and I simply haven’t had the time (or inclination) to get back to it.

Just an FYI to anyone who was following.

Cheers
Vaughano

[Vaughano]

It will depend on your internet provider. For me, my IP address is shown when I log on to my members page with my provider. You may also be able to find this on the administration site on your router.

Some providers, particularly mobile internet, provide no public IP address at all.

Can you provide more detail on your specifics?

[Vaughano]

@salbahra wrote:

Thank you @JerryAllen for the compliments! There is a similiar project on going right now by @Vaughano available here: http://rayshobby.net/phpBB3/viewtopic.php?f=33&t=330. I would be more than happy to help just let me know after you glance over things what specifically you need to know.

Just on this, there has been little activity from me for a while due to other distractions, like work. But I expect to get back to it soon, and will certainly be checking that post if anyone has any questions, or ideas.

[Vaughano]

@eddiek2000 wrote:

Might have to give it a shot. Not happy about java, but is just me.

I don’t see any Java, eddiek2000. Looks to me like a Node.js Javascript app.

Javascript != Java. Samer’s popular mobile app is also largely Javascript.

[Vaughano]

No worries, I will keep you up to date with the progress here.

[Vaughano]

@salbahra wrote:

By the way, the get logs function has become clunky which is 100% my fault. I should make those hide/show into proper functions. So we don’t have to keep declaring things all over the place. I can do one of two things, I can push some changes to your Github branch timeline-logs or I can wait until you are done and it is merged with my line and make some changes.

I’m not sure there is a right or wrong approach here. You could make changes to your main branch, and I can pull these in to mine (I’m new to Git, but I’ve used CVS and SVN for years, and that’s what we’d do with those tools). That way I would be performing the merge on my branch, theoretically making the subsequent merge of my branch back to the main trunk easier.

Otherwise you or I could make the change on the timeline-logs branch and merge all the changes eventually back to the main trunk. My gut feeling is this would make for a more difficult merge later.

More of a Git/Github topic now but if I made changes to my copy now and later merged your changes, what would happen to my changes? Would they get overwritten?

As I said above, if you did that, I would take it on myself to merge forward those changes to my branch, so they would still be there when my branch is merged back to trunk (master branch in Git talk).
I’m still learning Git myself, but we’ll work it out.

Cheers
Vaughano

[Vaughano]

I’ve just pushed another bunch of changes to https://github.com/vaughano/OpenSprinkler-Controller/tree/timeline-logs. These changes fix some introduced bugs in the preview timeline (due to component name clashes), introduce a new action in main.php for looking up detailed log data (including water pressure, flow, air temps, whatever else we can think of), and changes in main.js.php to render the new detailed JSON on the timline component.

It is still serving static JSON for this data, but the infrastructure is there now to plug in an external web service that can produce it.

TODO:

• Allow configuration to enable/disable extra log details and/or timeline view in logs
• Allow configuration of water pressure thresholds for timeline bar colouring
• Allow configuration of external web service that will provide detailed logs (might branch the interval program to do this; still thinking this through)
• Plenty of other things I haven’t yet thought of!

Cheers
Vaughano

[Vaughano]

Thanks Samer.

Yeah, I was also thinking that the naming could be better. Not sure that this need be specific to showing water pressures though; people may prefer this visualization to the plotted graph even without the pressure readings. But timeline is a bit generic and could easily describe the plot under the ‘graph’ option.

Definitely the handling of water pressures needs to be a configurable option. I will get to this and using real log data soon. Thanks for the encouragement!

Cheers
Vaughano

[Vaughano]

I have a prototype log timeline pushed to https://github.com/vaughano/OpenSprinkler-Controller/tree/timeline-logs. This just renders some static (hard coded) data for 2nd September 2013, with associated average pressures on the lines after the relevant station.

Next step is to gather that data, from the interval program logs, and another web api to get pressure info for a given time range.

Cheers
Vaughan

Edit: Note that the colour of the bars indicates the strength of water pressure on that line. Strong colour – strong pressure; weak colour weak pressure.

[Vaughano]

Thanks Samer, I’ll have a look at the API for the timeline component.

Just by way of an update (and a written plan for my own benefit), I have dug through the code and here is my plan:

• add a radio button to the logs page for ‘Timeline’ option, in main.php
• add code in main.js.php; a function called get_logs() to retrieve and parse logs into timeline component JSON format (partially done, plugs some HTML in saying ‘not implemented’).
• add another function in main.js.php to perform the parsing of logs to this format, based on the existing get_preview() function. Perhaps call it get_logs_timeline()
• a server side handler for this function, that does the lookup to the interval webapp, and possibly another webapp that serves pressure sensor data, in a similar manner to the existing functions get_preview() and process_programs() in main.php.
• Slight changes in log JSON data for the Timeline widget to show average pressure on the coloured bars (like the way programme name is shown in preview).

Any thoughts on this? I will take a light-touch approach with existing code to make it easier to integrate back into yours. I have forked your code into my own repository at https://github.com/vaughano/OpenSprinkler-Controller, and will send you a pull request when I am happy with it.

Cheers
Vaughano

[Vaughano]

Thanks Samer.

I’m not too familiar with PHP, but I do have a software background in Java, so this info should be enough to get me going.

Cheers
Vaughano

[Vaughano]

Sounds fair. I’ll grab your latest code when I get a chance and try it out.

[Vaughano]

Thanks Dan,

I have no solutions unfortunately, only questions!
Thanks again for your efforts.

Cheers
Vaughano

[Vaughano]

Dan,

Once again, thanks very much for the work you have put in on this python/pi port of the interval program. Ray, yourself and Samer have provided a great platform to play with!

It might be good for us to look again at @aradke’s post at viewtopic.php?f=28&t=160&start=40#p1500 about timezones. I have removed timezone calculations myself to fix problems I was having, which I believe was a bug that has been fixed. However, my preference is still to allow the OS to keep the time, and the application to simply query the OS for it.

The only thing that I wonder is whether using the OS local time (daylight savings adjusted time) would cause any impacts when daylight saving time gets adjusted? Like a program failing to stop, potentially leaving a solenoid on?

Cheers
Vaughano

[Vaughano]

I did a little experiment with flow meter pulse counting, see viewtopic.php?f=22&t=125#p605 for some discussion and some C code.

[Vaughano]

Looks good, Samer!

This may fit nicely with my plans to superimpose flow data on top of valve actuation logs. I will definitely have a look at your code and see if I can reuse it.

Cheers
Vaughano

[Vaughano]

@salbahra wrote:

I am debating adding an updater to the watcher.php script so that updates from Github are automatically pulled. Is this something people would be interested in? I know some people might find this weird so curious as to how people would want this implemented, if at all. I think by adding a setting during install and in the configuration (ex. $auto_update = 1) then checking against it during watcher.php runs, as such:

if ($auto_update) `git pull`;

Of course, this requires your using git instead of downloading the zip/tar and extracting manually but it should serve it’s purpose just fine, I think.

Let me know what you guys think.

Edit: Also, shell exec would have to be allowed for this to work.

Samer, I think this auto-update would be ok, but I would default it to be off, and possibly hide it away in ‘advanced config’ or something with enough help information for people to diagnose problems with it. I personally wouldn’t use it unless it was detailed with respect to displaying versioning/release information, etc. At least show the snapshot date for the running code.

I reckon it could generate a lot of confusion if it went wrong for people, but if done well it would be useful. But it’s really a developer feature, and should be exposed to the user as such.

Keep up the good work! This webapp is proving very popular, as shown in this thread.

Cheers
Vaughano

[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

[Vaughano]

No worries Dan, thanks for your efforts!

I agree that removal is as good as making the daylight saving work, that’s what I did on my local version. If I manage a fix I will provide a patch, or push a branch back (after I learn how to use git…).

Cheers
Vaughano

[Vaughano]

Another bug I have found is to do with daylight saving. In my setup I was getting daylight saving corrections, even though it is winter here in Australia.

Looking at the ospi.py code, I see

 gv.lrun[3] = now-(time.timezone-(time.daylight*3600))

and

homepg += 'n'

I am no python programmer, so I looked up the time functions. It seems that time.daylight will return 1 in timezones that have daylight saving regardless of whether it is currently applied, so the above code segments will incorrectly adjust for daylight saving all year. More discussion on this gotcha at http://stackoverflow.com/questions/2881025/python-daylight-savings-time.

[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.

[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.

[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:~$

[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:~$

[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!

[Author]

Posts