- This topic has 20 replies, 5 voices, and was last updated 9 years, 11 months ago by
.
-
Posts
-
Hi all,
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 “}” ;
{“nprogs”:3,”nboards”:1,”mnp”:14,”mnst”:4,”pnsize”:12,”pd”:[[3,127,0,[1140,0,0,0],[0,0,30,0,0,1800,0,0],”S_Daily”],[11,127,0,[1140,0,0,0],[0,0,0,1200,0,0,0,0],”S_EvenDays”],[3,1,0,[0,0,0,0],[1,0,0,0,0,0,0,0],”Test”]
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 🙂
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.
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.
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-Hi Ray,
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.
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.
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.
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).
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?
Cheers
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!
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!
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.
Cheers
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.
Images attached… hopefully!
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!
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!
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.