- This topic has 14 replies, 7 voices, and was last updated 7 years, 6 months ago by
.
-
Posts
-
Hello,
currrently the OS updater only updates my OS 2.3 DC to 2.1.6 (2) but because of some improvements in logging I want to update to the next 2.1.6 (3) or maybe 2.1.7
I know the 2.1.6 (3) is in the current master on github and also the 2.1.7 branch exists.
Is it possible to implement a section inside the updater to select other branches?
Or maybe something like beta section?Thanks
BR
AndreasThe updater already allows you to select which major version you want (i.e. 2.1.5, 2.1.6 etc.) However, it doesn’t allow you to select minor version (i.e. 2.1.6(1) or 2.1.6(2)). We generally always put the latest minor revision in the updater repository so that when upgrading you will always get the latest version.
2.1.6(3) is actually a small mistake by me because it should have been 2.1.7 — I committed it to the master branch and realized that it should have been in a separate branch. In any case, all changes in 2.1.6 have been inherited by 2.1.7, so it’s not a big issue.
I am hoping to get 2.1.7 released as soon as possible but got distracted as I decided to finish a new version of OpenSprinkler Bee (this is for latching solenoid valves) first. Some of the main changes in firmware 2.1.7 (including impelmented and planned ones) are
– allowing full second-level precision of programmed water time
– supporting for GPIO and HTTP stations for OS 2.3 AC/DC
– supporting using an external switch to trigger program run
– supporting pushingbox (which provides email and push notifications)
– making the firmware compilable under the latest version of Arduino (1.6.9)
– misc. bug fixing, and better handling of flow sensor
– possibly (not implemented yet) supporting pausing a programOn the “better handling of flow sensor” What can we expect? Flow readings are inaccurate to say the least right now and I haven’t figure out how to display gpm it always reverts back to lpm even after changing the settings.
Can you be more specific about ‘Flow readings are inaccurate to say the least’? Is it due to the difference in units (since you said the unit changes didn’t stick), or what’s your evidence of the inaccuracy? Which flow sensor do you use? How much do you think the inaccuracy is?
Rey or Samer,
Can you confirm that the problem with the water percentage being set to 0% and never being reset has been fixed and also that the weather check happens more frequently and before a station starts even if you have say a lights on running already. I am running my own firmware with a single line changed that I had presented to Ray quite some time ago. I was under the impression it was going to be changed but I wanted to confirm this before I look to update my controllers.
Thanks,
I thin the watering percentage suck at 0% has been fixed. It was caused by a combination of 1) some weather stations are reporting invalid data for precipitation; 2) a bug in the weather script that didn’t handle the invalid data properly.
The firmware queues a weather request every hour, and updates watering percentage accordingly. The reason I say ‘queues’ is that if a program is currently running (i.e. program busy), it will NOT check weather immediately:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/main.cpp#L663
but will wait till the program has finished and then check. This is done to avoid confusion if in the middle of a program run the watering percentage changes. If you would rather want it to update even if a program is running, you can simply remove the “|| os.status.program_busy” part in the condition above.I agree with Ray. I was experiencing this problem, but I am no longer.
Bill
P.S. California has relaxed most of the rules. Many cities have relaxed their rules to match or in some cases left a few in place.
Ray,
I appreciate that, but the weather check should still commence more frequent and regardless if a program is running and here is why.
I use the last station on my controllers to run area lights from dusk to dawn. I usually run my irrigation programs during the night. So if my lights come on at 6PM and do not shut off until the following morning at 7 AM, there will be no weather calls for that period of time. So PLEASE, PLEASE fix this in the mainstream firmware. Also, I would prefer that we either have the option in the firmware to set the weather check increments either before a program starts or by being able to set the time, 5 minutes, 10 minutes, 20 minutes etc.
If you recall we had sent email correspondence back and fourth on the specific line in the code I changed to do the weather check regardless if a program was running. I changed that and its been working great. Please, change this otherwise using the controller to run dusk to dawn lawn lights and control irrigation valves will not work together. I am sure you can see this.
Thanks,
Ed
One last thing, yes CA has eased up currently on the water restrictions, how ever, water restrictions WILL BE BACK, so we should not discount this so the firmware, programming should keep this in mind.
Thanks,
Ed
@dun4cheap: ok, you raised a good point which I didn’t think about: that is, you use OpenSprinkler to switch lights, which can last the entire night. Since this program does not use weather, it should not prevent weather checking from being performed. So sure, this will be fixed in firmware 2.1.7.
Actually I just remembered why this check was done in the first place — because the weather checking returns time zone information together, I was trying to avoid the situation where a program is running and suddenly the time zone changed (because of Daylight Saving Time for example), and that would cause the actual program runtime to change. Of course this is a very rare situation, but this is what led to the decision of preventing weather checking during program run.
My state, Massachusetts, is now in drought. I heard some towns have banned watering using sprinklers all together (only hand watering is allowed…)
- You must be logged in to reply to this topic.