- This topic has 20 replies, 7 voices, and was last updated 9 years ago by
.
-
Posts
-
The OpenSprinkler UI just got updated to 1.4.0 bringing some major changes outlined below.
Homepage redesign - Now provides a more informative home screen, which blends the previous current status and edit stations page with extended functionality such as manual station queuing. New menu button - Now available on all pages is the menu button, which provides the navigation that was the previous home screen. No need to revert back to home for each page change. For desktop users, a hot key has been added to this menu by pushing "M" (for menu). New notification system - Added right side panel, which shows new notifications and allows clearing of all notifications at once. Updated site manager – Now allows editing of basic authentication and SSL settings when behind a proxy. Also moved connect button to the title so connection requires one less tap. The same connect but also indicates whether the site is up (green) or down (red). Add Icelandic and Farsi languages Add warning when a importing configuration that will change network settings Add error message when logs fail to be retrieved Fix duration input allowing negative values when it shouldn't Fix preview bug causing stations to render twice when program starts at midnight Fix sorting of timeline on preview and logs page Fix log timeline incorrectly using end time as start time Removed graph representation of log data due to many inconsistencies in favor of timeline view Many minor bug fixesCurrently, the UI is only updated when navigating directly to your device by IP (eg. http://192.168.1.22). This allows us to react quickly to any bugs before pushing to the app stores which invariably take longer to publish fixes/updates.
If you are not seeing the new home page and wish to do so, just refresh your browser or empty your browser cache. If you encounter any issues please let us know so we can address them.
Thank you.
Gave me quite a shock when I just loaded my OpenSprinkler page! Anyway, I do like the new look, couple of questions:
– afer jumping to a few pages using the new menu, how do I get back to the new “home” screen? Couldn’t figure out how to do this.
– I understand the graph caused issues, but I did like to see the graph of % watering (I’m using the automatic option). Any chance of just getting this graphed?
– the mobile page on my Galaxy S5 shows a notification icon (woth a note for me to update firmware). I don’t see this on my desktop version (WIndows 7, Chrome).Basically minor issues…..
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.
Thank you Samer!
One minor blip. I have a daily garden program and an every third day lawn program. On the preview screen for today it predicts no watering.
this may be an artifact of the update. I’ll check tomorrow and see if it was a one time glitch.
Sean
@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!
I see the revised ui when accessing it via a browser.
How to you get the new ui within the android app?
@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.
Here ya go Samer:
{“programs”:{“nprogs”:2,”nboards”:3,”mnp”:13,”mnst”:4,”pnsize”:12,”pd”:[[67,127,0,[16444,-1,780,12348],[0,0,0,0,0,0,0,0,0,0,0,600,0,0,0,0,0,0,0,0,0,0,0,0],”Garden”],[51,1,3,[360,0,0,0],[1800,1800,1200,7200,1800,1200,2100,2100,1200,1200,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”Main”]]},”stations”:{“snames”:[“Rear S. Fence”,”Rear S. walk”,”Front S. Lawn”,”Back Yard Perim”,”Frnt Lwn Street”,”Frnt Lwn Rear”,”Rear Lawn E.”,”Rear Lawn Patio”,”Flower Beds Frnt”,”Rear Lawn N.”,”S11″,”Garden Drip”,”S13″,”S14″,”S15″,”S16″,”S17″,”S18″,”S19″,”S20″,”S21″,”S22″,”S23″,”S24″],”masop”:[255,255,255],”ignore_rain”:[0,0,0],”act_relay”:[255,11,0],”stn_dis”:[0,244,255],”rfstn”:[0,0,0],”stn_seq”:[255,247,255],”maxlen”:16},”options”:{“fwv”:213,”tz”:24,”ntp”:1,”dhcp”:0,”ip1″:192,”ip2″:168,”ip3″:3,”ip4″:76,”gw1″:192,”gw2″:168,”gw3″:3,”gw4″:1,”hp0″:144,”hp1″:31,”hwv”:64,”ext”:2,”sdt”:0,”mas”:0,”mton”:0,”mtof”:0,”urs”:0,”rso”:1,”wl”:0,”den”:1,”ipas”:0,”devid”:0,”con”:110,”lit”:100,”dim”:15,”rlp”:0,”uwt”:1,”ntp1″:50,”ntp2″:97,”ntp3″:210,”ntp4″:169,”lg”:1,”reset”:0,”dexp”:-1,”mexp”:5},”status”:[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],”settings”:{“devt”:1426710750,”nbrd”:3,”en”:1,”rd”:0,”rs”:0,”rdst”:0,”loc”:”pws:KCOLOVEL23″,”wtkey”:”xxxxxxxxxxxxxxx”,”sunrise”:425,”sunset”:1151,”eip”:1204629141,”sbits”:[0,0,0,0],”ps”:[[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0]],”lrun”:[11,1,312,1426616053]}}
Looking at the logs, it appears that the daily watering did not take place today.
it is predicted for tomorrow, though.
Is there a url to input a past date and location to check the Zimmerman calculation?
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%.
When I can view it in the early morning, the weather diag always says Current % Watering = 0%. I assumed that was because i can only look at it before sunup most days.
In the Log/Table view, there is no entry for 3/18 or 3/19. in the Timeline view, the last two days show no watering.
I have disabled weather check on the daily program to see if that allows it to run.
BTW, it has not rained or snowed here in over 3 weeks.
Got home early today so I could check it out while the sun is still up , if that makes a difference.
The daily program that I disabled Weather Adjustment watered for the first time since the update rolled out. I think the problem is the Zimmerman weather adjustment.
the sun is up, it is 70 degrees and it has not rained since 3/4/15. On that day we got 0.1 in. I jus ran the weather diagnostic and it tells me that Current % watering = 0%. does this mean that it still thinks zero water is needed? Is that why watering stopped for weather enabled programs?
Just made the following changes:
- Wiped and reloaded the 2.1.3 firmware.
- ran apt-get update and apt-get upgrade.
- re-enabled Weather Adjustment on the daily program.
- Changed the local weather station setting from the personal weather station where it was pointing to the local airport.
Weather diagnostic still says “Current % watering = 0%”
We’ll see if it waters tomorrow.
Samer: I have a flow sensor on the OS logging data. I’d like to add it to the existing log file so one entry would have the last run program, last run station, last run duration, and average GPM for that station. When I have it add the 4th field, the GUI and web access ignores the entire line. Could you please consider either displaying the 4th field as GPM (floating point) or at least make it so that it doesn’t ignore the logfile if a 4th field is in there? Or would you prefer the gallons per minute be logged in a different manner?
FYI allowing the logfile to have a couple more fields and display those in the GUI would make custom logging/mods easier for others also in case someone wants to log other items rather than just GPM for each station run (along with the standard data).
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!
I thought the GUI/App would not like the additional data but it ends up I was putting the data in the wrong order (epoch time spot instead of after it). So now that I placed it after it here is what it looks like, and seems to work on the HTTP GET for the log as well as the GUI/API seems to work and just ignore the extra GPM data. With the HTTP GET it passes all the data including the additional GPM info (see below partial data from the HTTP GET):
[99,4,10,1426886894, 8.23]
The 8.23 is the GPM measured.
If you think this will interfere in the future we can move it outside of this standard logfile. I tried creating a new logfile but then had to create utilities to get the data, etc and then moved it back to the existing logfile . So ideally if we can keep it in the same logfile to avoid duplication of data/functions I’d probably prefer that.
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.
@Robert, glad to see that you are making use of the current system to log flow rate. Here is how the log data is formatted: each entry records the [program_index, station_index, duration, time_stamp]. When program_index is non-zero, this is a normal log record storing a standard sprinkler event. When program_index is 0, this is a special log record, and the station_index becomes the name of the event. The currently supported events are defined here:
https://github.com/OpenSprinkler/OpenSprinklerGen2/blob/master/main.cpp#L736
there are rain sensor, rain delay, and water level events. In the future we can add an additional event such as “fl” (flow), and duration would become the numerical value of the flow measurement.The good news is that sunday I was able to generate a report using HTTP GET and show how many GPM each station is and how many total gallons, from the existing logfile. However when I ran the script again today to get the logfile from this morning’s run, it only displayed about 1/2 and only sometimes, other times it never returned anything. Perhaps the added field is causing some instability?
Attached is log 16516 which is sunday, and looks good along with my perl script report called “sunday report ok.txt” that just takes the logfile and formats it. In 16516 you can see the last field which is GPM.
Log file 16518.txt and “tuesday report cut off.txt”. You can see 16518.txt has all the data in there, but the HTTP GET at the top of the tuesday report stops early so my formatted script output also stops early.
The modification to add flow sensor data is pretty easy, just the ISR and of course adding the one additional field when it writes the data to the logfile. I can provide the code for that if you like.
The Min GPM is out of the entire report for that valve (over up to however many days the report was generated for) what the min value was, and the MAX GPM is the maximum GPM observed over the entire report run time for that valve. Last GPM is the last GPM measured on that valve, helpful to see if the underflow/overflow condition still exists. Might add a low threshold and upper threshold for the script to flag zones that are too wide – where last GPM is outside a set range. Also plan on calculating cost per month based on # of days in the report and scaling it with the tot gallons for each zone.
The actual #.txt logfiles I took out the SDHC card and read it on the computer which showed they look right even though the OS isn’t returning all the data.
Yes, I would be happy to integrate your code to future firmwares. You can attach the code here, or contact me directly at [email protected]. Thanks.
- You must be logged in to reply to this topic.