- This topic is empty.
-
Posts
-
Still learning the system so bear with me a bit:
I set up my first programs (opensprinkler V2.03) yesterday and realized ALL stations within a program must run at the same duration. This is a primary feature of most other controllers. In my srea, Houston Texas, we are heavily wooded (shade) as well as basically in northern Cancun….it gets really hot. In a most lawns here small or large it is very common to need to need to have different station times in in a group of stations that from a Home-owner standpoint should be in the same program…e.g. Front Lawn, Rear Flower Beds, etc.It seems a solution is to potentially have as many programs as one has stations …..each station can have a unique time. I have 38 stations and will need to alter time potentially on about half, 12 are beds (bubblers) and 26 are lawn….with about half needing slight changes in run-time from one another.
Are there any plans to provide per station run-time within a single program?
Thanks!
-Q
These features are planned for OpenSprinkler however I want to let you know a unique time is not needed currently.
You can specify the same start time and the controller will manage them all for you based on your concurrent or sequential setting.
@blandq wrote:
Still learning the system so bear with me a bit:
……… and realized ALL stations within a program must run at the same duration. This is a primary feature of most other ……..-Q
Likely the runtime duration constraint is a legacy from mechanical timing. I had a career employee in a very good sprinkler company tell me that the rain sensor worked by interrupting the neutral wire on the valve circuit. We were talking about microprocessor control at the time. So a lot of these companies are still in 1970. They are not in a business that has been forced to change to the same extent of many industries.
It makes sense that Ray first made the core functionality consistent with the way systems are traditionally operated. It also makes sense to rethink what works best, while still maintaining a well controlled and consistent system.
From a system design perspective it debatable what functionality belongs in the firmware, and what logic should be in a separate processes: Such as a web server, “the cloud”, or a home automation system. While variable timings belongs in the firmware, many advanced functions perhaps belong on something like the Raspberry Pi web server.
So is it true that the interval program requires that all stations in the same program have the same watering duration? And the current way to vary the length of the watering time (i.e. duration) is to create a different program for each station that requires a unique duration setting?
Assuming this is correct and that we prefer sequential station watering, would we just then specify the same start time for each program and let them run through the sequence for each unique duration.
In our case, we have less than 8 stations but each does require a different watering duration.
I’ve just received my OpenSprinker PI and was up practically all night exploring. (It’s hard to believe I missed the above, if my queries are correct). Anyhow, I’m going to be pretty busy working on other software (for my day job) for the next several weeks, but I can’t wait to take a look at the OpenSprinkler code.
Mark
@baataboom First, welcome to OpenSprinkler!
You are correct that currently programs only support one duration time that is used by all stations selected for that program. As you mentioned, you can make multiple programs with the same start time and the controller will manage all stations if sequential mode is turned on. There are plans to accommodate per station duration for programs however this is still pending completion.
I’m new to the forum Opensprinkler.
I bought about a year ago a Opensprinkler IP to connect to my raspberry PI. I installed the system just today, before I had time.
I am the owner of a Garden Center in Genoa, Italy.
Unfortunately I am impressed by the problem of duration equal for all stations.Please add this function, otherwise it becomes difficult for me to manage the system.
Greetings!
You mean all station at once for an identical time? If so you just need to deactivate the sequential check box in the device options.
Sent from my iPhone using Tapatalk
As someone who had high hopes for OpenSprinkler when I purchased it several months ago, I remain quite disappointed with the limitations of programming in general. I too have 30+ zones. I have been forced to implement a complex array of 25+ programs and have to track them in a spreadsheet so as to make sure I do not have any overlap and risk programs not running.
I have created several, sometimes very detailed posts, explaining the challenges with OS programming and made many recommendations for solutions that align with what I believe would be a best-in-breed combination of a microprocessor based controller with features common to commercial controllers. These recommendations have been greeted with responses from Ray, which I certainly appreciate, stating these new features are “planned”.
But at this point, I have two remaining questions:
1. When will the new programming features be deployed?
2. How can I help OS evolve into a device that not only matches the programming capabilities of other controllers, but surpasses them? Hopefully my previous posts are helpful, but I am willing to help more.Thank you,
Mike@mb42: I understand your disappoinement and I apologize for not making enough stride along the improvements you suggested. In my own defense, please understand that as a single-person open-source business, I don’t have the kind of resources that big commercial companies have, in terms of technical development and support. OpenSprinkler started as a DIY open-source project, for educational purpose, and for giving users the flexiblity of customizing the code if they want. Overtime, it has evolved into something a lot bigger than I thought when I started, and I think it remains the lowest-cost web-connected sprinkler controller on the market. As an open-source project, it relies on community contributions to improve it. If you have an improvement in mind and have the programming skills, I would very much appreciate you to contribute to the project. So far I am pretty much the only person working on the firmware code. I have a day-time job and I work on the hobby business in my spare time. I don’t want to be the single point of bottleneck, so if you have programming skills, you have all the source code availble, please consider making changes to the code. Frankly this is the state of the situation, and I very much appreciate your understanding.
To answer your questions:
1. When will the new programming features be deployed?
A lot of the new features, including per-station water time within a single program, are being integrated into the next firmware update numbered 2.1.0. The unified UI, available from the just released 2.0.8, allows Samer and I to work together to roll out 2.1.0.
2. How can I help OS evolve into a device that not only matches the programming capabilities of other controllers, but surpasses them? Hopefully my previous posts are helpful, but I am willing to help more.
See what I said above.
@mb42: by the way, in case you didn’t notice, some of your suggestions have already been integrated:
viewtopic.php?f=8&t=700&p=4433#p4650
for example: changing terms to clarify the meaning of them, adding nagivation links, these have all been integrated since firmware 2.0.7.Sounds exciting! 🙂 I most look forward to being able disable sequential for just a program, rather than for the entire system. I haven’t tried looking at the code yet because getting up to speed with any new project is the hardest part. I haven’t done anything with Ardino (sp?) so I am not aware of the learning curve. I have done lots of simple coding as a sys admin, but not much serious coding. If either of you have a few moments to give the the overview, I might be able to help.
- You must be logged in to reply to this topic.