December 15, 2014 at 5:26 pm #35012
I recently purchased a pre assembled opensprinkler (hardware 2.2 firmware 2.1.1 app 1.2.6) and have been having a problem setting it up.
I currently have four stations and two programs running successfully but when I add a third program to opensprinkler the UI become unresponsive, the UI login screen loads but just returns back to the login screen on correct password, an incorrect password returns an incorrect password error. The device screen and buttons still work fine in this state, and the first two programs still seem to run. Android apps fail to access the UI.
When the UI fails, all the JSON / API replies are fine appart from “/jp?pw=opendoor” which returns data with out the end “}” ;
The browser still waits for data to be returned but eventually gives up. Once I use the API to delete the third program I can login fine and the android apps work again.
If I hit “save new program” quickly twice it saves the program twice, and I end up with four programs in total and opensprinkler, JSON / API and the UI all work fine.
I have done several resets and started the setup from scratch and as soon as I add the third program the UI fails. Even if I add the third program several days later, opensprinkler will work fine up until that point.
Has anyone else experienced this or does my opensprinkler have issues?
Thanks in advance 🙂December 15, 2014 at 6:31 pm #35013
I can confirm the issue. This seems to be happening on firmware 2.1.0 as well, which is quite surprising because so far I can only think of one user who raised a question that’s related.
To summarize the issue: when the number of programs is a multiple of 3, the /jp command returns a string that’s incomplete (missing the ending ]} characters). I am pretty sure this has to do with the firmware sending out one packet per 3 programs. I am digging into it right away and will report soon. Thanks for reporting it and sorry about the trouble.December 15, 2014 at 8:03 pm #35014
A quick update: I found a fix to the issue. The source of the issue is not clear but is definitely odd — it seems to me like a compiler bug. The line of code that outputs the ]} ending characters is being ignored when the number of programs is a multiple of 3. This might be due to a glitch in the compiler optimization. A strong evidence is that when I turned on serial debugging code, the issue is immediately gone. Another evidence is that the issue happens on OpenSprinkler hardware 2.1 and 2.2, but not on 2.0 — all three use the same code, but have different microcontroller frequencies, so the generated code is different.
In any case, the fix is to add some dummy lines (e.g. delay(1)) after the line of code that outputs ]}, and my guess is that it causes the compiler to optimize the code in different way thus avoiding the issue.
Another issue with firmware 2.1.1 as you probably have noticed is that it’s not correctly handling the SPACE character in the program name (I noticed that you used underscore in place of SPACE). So we will be releasing firmware 2.1.2 shortly to address these two bugs. Thanks.December 16, 2014 at 12:45 am #35016
Firmware 2.1.2 has been released, which fixes the above two issues: 1) /jp returns incomplete data when the number of programs is a multiple of 3; 2) incorrect handling of the SPACE character in program name. 1) is likely due to a compiler bug, and I am surprised that it wasn’t brought up earlier.
Anyways, thanks for reporting the issue. If you have never upgraded firmware before you can check the instructions here:
https://opensprinkler.freshdesk.com/solution/categories/5000022938/folders/5000099521/articles/5000381694-update-opensprinkler-firmware-with-downloads-December 16, 2014 at 5:45 pm #35027
Wow thanks for the very quick fix on this, was not expecting it to be fixed so quickly!
I have updated and can confirm it has been fixed, also the space issue has been fixed thanks also.December 20, 2014 at 10:11 am #35038
Thanks. We try to be as quick as we can to fix major bugs. I appreciate you reporting the bug — your detailed description helped me find the cause of the bug.December 24, 2014 at 2:22 am #35058
I have been using two programs on my Opensprinkler (f/w ver 2.1.1) without trouble since I assembled my DIY kit and put it in use about a month ago. However, when I added a third program today it seemed to trigger the same problem described here.
When attempting to save a 3rd program, it would become duplicated (might be another bug) adding a 3rd and 4th program, but when I went back and deleted the 4th duplicate program I started having trouble not being able to login anymore… I know the updated firmware should now correct this problem and I will update it again soon, but I temporarily corrected this issue by deleting the third program via entering the following in a web browser address bar “http://os-ip/dp?pw=opendoor&pid=2” . This is explained in the “Firmware 2.1.1 API Document” in section 13.
I am reporting my experience with this trouble so that the software can be refined as needed to be improved / more trouble free and also help others that may encounter the same trouble. So far I enjoy using the product and plan to soon connect it to my garage door opener as a way to remotely control it in addition controlling a koi pond fish feeder, an air line valve feeding a skimmer air stone (keep floating pellets out of the skimmer), and a Multi-cyclone MC50 waste water purge valve that are currently being controlled via individual timers and relays. As you can tell, I plan to use it for much more than just controlling my sprinkler system and look forward getting these things mentioned working with it.December 24, 2014 at 10:15 am #35063
OK, thanks for the tip. Another work-around, if for any reason you can’t upgrade the firmware right away, is to disable the 3rd (or 4th, since it’s duplicate) program. That way there are 4 programs, but one of them will not run (disabled).January 4, 2015 at 1:32 am #35130
I’ve updated the firmware and so far so good.
ThanksJanuary 21, 2015 at 10:08 pm #35280
Nice to know that this issue has been addressed since the problem occurred to me when I was away interstate with no way to rectify it until I came home some 4 days later. The issue that I saw was a little bit different in that creating a 3rd program while copying an existing one actually caused multiple copies to be created before I lost access. The upshot was that unfortunately my garden was very wet when I came home.
Anyway, the reason for my post is that I experienced the same issue a few times last night prior to having read this forum and each time I had to reset and restore the config. What I find now is that despite the fact that there has been no rain in the last 24 hours, the table view shows 3 entries for my rain sensor yesterday each for a runtime of 49709 days 14 hours and some minutes. One entry at 00:47:29 (AEDT), one at 00:50:04 and one at 01:01:56. Times not associated with my reset (unless they are for the default timezone). All other table data appears to be correct. The upshot is that the graph does not display correctly if I include yesterday’s date. Is there any way to remove these erroneous entries from the log without clearing the log altogether?
CheersJanuary 22, 2015 at 3:18 pm #35284
Just a further point on this. It seems to me that even if I can’t remove the offending entries from the log, it would be acceptable that if when I uncheck rain sensor or rain delay from the chart, the chart would redraw without the issue. I’m not really sure why it doesn’t behave that way to be honest. While I was looking at the chart view, it also occurred to me that it seems a little annoying that disabled stations are included in the graph. I realise that there may be some occasions where this is desirable so I don’t know if they should be removed from the graph automatically just because they are disabled but I would have thought that at least they should be unchecked by default or alternatively, and probably preferably, it would be nice to provide an option in the station config to exclude a chosen station from appearing anywhere in the interface other than “edit stations”. No biggie, just a suggestion!January 22, 2015 at 9:03 pm #35286
Thank you Phil for your feedback! The zones showing disabled stations is something other users have echoed and honestly an oversight on my end when incorporating the ability to disable stations. I am fixing this in the next release.
In regard to the rain delay not updating on toggle, is this in regard to scale? I am testing this out on my end and the graph is in fact updating/refreshing when toggling the station. I know this is was a bug previously so just to make sure, are you on the latest current: 1.2.7 (1.2.6 for iOS, still pending app store testing)?
For deleting specific log entries this isn’t possible without removing the SD card and editing the file yourself however Ray does have the option to delete a specific day instead of the entire log history. I will see if I can incorporate that into the app.
Thanks again!January 22, 2015 at 10:10 pm #35288
Firstly, thanks for the quick response. I’m pleased to hear that you will be incorporating a fix disabled stations in the next release. Note that I am connecting via the web using Firefox and IE so the app is not especially relevant although the iPhone app behaves the same way. In the screenshot below I have unchecked rain sensor and rain delay and you can see that all of the chart points are at the far left.
The next screenshot shows what happens when I exclude the date with the offending entries.
Here is the offending data:
Although it’s not ideal, deleting the offending day would be an acceptable fix if it’s possible.
Thanks once again for your help.
P.S. Obviously copy and paste doesn’t work for pictures. I would be happy to insert them if I knew how or alternatively I could email them if you can give me an email address.January 22, 2015 at 10:18 pm #35290
Images attached… hopefully!
Attachments:January 22, 2015 at 10:19 pm #35295
Attachments:January 22, 2015 at 10:21 pm #35297
OK. It looks like I managed to upload the images. I hope they explain the issue a bit better.January 22, 2015 at 11:17 pm #35305
Wow, that is quite odd. I guess that isn’t a situation that one would “normally” run into (49,000+ day run) but I guess it shouldn’t completely mess up the date range when plotting the graph.
I will see what I can do about something like this but to help do you mind emailing me the log export to [email protected].
Thank you!January 23, 2015 at 1:18 pm #35316
Thanks Samer, exported log is on its way.
CheersJanuary 24, 2015 at 1:35 pm #35335
Okay, thank you Phil for all the detail. I have identified the issue which was a miscalculation of the bounds of the graph. Before, the max was calculated as the start time + duration time. This never made sense because the duration is visualized vertically meaning there is no reason to extend out the max bound.
I have since fixed that in this commit: https://github.com/salbahra/Sprinklers/commit/157afd8f057aeaf54ea21b6405813c8a36d0d036. I will have this released in the next app update (~1 week).
This should fix all the graphical glitches you had showed me and allow unchecking of the “Rain Sensor” in the legend to rescale the graph and show the correct view.
In regard to deleting a specific day, I should have this functionality in there within the next update as well.
Thanks!January 24, 2015 at 2:03 pm #35336
Awesome work Samer. Thanks again for your work!January 30, 2015 at 12:21 pm #35425
Just another quick word of thanks Samer. I have seen the updated UI and been able to delete the offending days from the log. Everything is now looking as it should. I wonder if a future enhancement might allow you do delete individual entries from the log? Just a thought!
Interestingly, I found multiple days with the same rain sensor entries when I went through the log and had to delete about 4 separate days to clean it up.
- You must be logged in to reply to this topic.