- This topic has 21 replies, 13 voices, and was last updated 7 months, 2 weeks ago by
.
-
Posts
-
Hi!
I was wondering whether there is any way to set a specific order in which the stations are run within a program. The order seems to be set simply by the order the stations are plugged and configured. I want to have my own order. What do I do? Tried to change the names of the stations but oit does not do anything…HW 2.3, v2.1.7…,
Yes indeed, this seems to be a limitation. To be fair, regular dumb sprinkler timers have the same limitation. The only way to change it is to physically swap station wires around so that they are in the order you want.
Too bad. It would be a very good feature. I use solar power to water my garden and setting the order would allow to first water those areas that are in shadow in the morning or in the evening…
This is certainly doable in software, but it requires a pretty significant change to the user interface: at the minimum we have to provide a user interface that maps a logic zone to a physical zone and it may cause confusion to users who don’t need this feature. Would rather not having to do it unless if this is a common thing that many users need.
Well it certainly isn’t impossible to do. When I built my PC based controller software in Java and then the UI in HTML 5 and Javascript (with Jquery and JqueryUI), it was pretty straightforward to allow any station to go in any order, and even repeat stations within the same program. I just have an Add button that selects the controller and station to add to the program list. On a PC I also allow you to drag and drop program entries so that you can reorder stations that you’ve added.
The thing that isn’t easy to do on a Smartphone or any touchscreen device is dragging and dropping. But you can get around that by having move up and move down buttons at the side of the station name. Click the station up or down button and it moves up or down in the order.
*bump*
the ability to re-order stations/zones in a program would be a very much appreciated feature!!
The only issue with this is storage of the data. The controller can’t store this mapping so we are left with storing it in the app instance and syncing it with the cloud sync we currently have.
Is this the path we want to pursue here?
Hi Samer,
Without understanding the (technical) reasons why it is not possible to store zone ordering mapping in the controller itself, it would not be my personal preference to pursue the proposed path of storing such critical information in the cloud. I suspect that without a functioning internet connection the mapping could not be retrieved at the time of irrigation, messing up important dependencies that could even result in damaging a well pump in my case. Very undesirable situation.
My observation: zone reordering/mapping seems to be an advanced feature that may not be relevant to the majority of users. Though nice to have, from a developer viewpoint it does not seem to be need to have and should therefor only be implemented if reasonably easy to realize.
Perhaps something to keep in the back of the head for when a complete re-write of controller software is necessary (at some point in the -distant- future?) and implementation becomes feasible with storage in the device itself
I do plan to add new types of programs to the firmware which allow you to specify the zone ordering arbitrarily. This will largely follow how OSBee’s programs work, which has already been implemented in OSBee firmware. Basically each program consists of a number of program ‘entries’, where each entry is a set of any number of zones (could be a single zone or could be multiple simultaneous zones) and the associated run time. A program can have a maximum of, say 64 entries. This will allow you to run zones basically arbitrarily. Simplest speaking, each entry is a mini-program and an actual program is made of multiple of these entries. The reason this works well for OSBee is that it only supports 3 zones, so the user interface for such type of programs is easy to implement and looks fairly clean. On the other hand, OS supports up to 72 zones, so the user interface will look a lot more messy and that has been my hesitation. Also, as Samer said, with that many zones the storage becomes an issue that cannot be overlooked. In the past the programs have been stored in EEPROM on OS 2.3 (the size of which is only 4KB) and prior (and flash on OS 3.0). With the upcoming firmware 2.1.9, the programs on OS 2.3 will be stored on external SD card, so the storage will no longer be an issue. We are unlikely to get the program type changed in firmware 2.1.9, but it can be planned for 2.2.0.
Ray,
Would this allow someone to have set limits to how many simultaneous valves can run at once within the program?
For my use in greenhouses where we have baskets on dripper lines and below them plants irrigated with spinners, I need to run as many valves as I can without running out of flow (2″ water main….lots of pressure and flow). Main reason for the rush is much of this has to be done when no one is inside the houses or in the nursery yard, covered by sprinkler as well, so squeezing in 130ish zones in a handful of hours gets challenging.
A work around has been making many programs so that, for instance, only 4 spinner lines run at once, 6 programs are needed to do this. This becomes harder to manage as things get bigger with the need to constantly change timings (water demands always changing in greenhouse).
I would love to be able to create a program that allows you to state how many zones are allowed to run at once. So one program can manage my 48 spinners because it would only allow 4 to run at a time. I’d be able to compress how long it takes to irrigate everything and it would be done with a much smaller number of programs.
It’s not going to automatically create programs given the constraints of simultaneous valves. Instead, you can manually schedule multiple valves to run at the same time. As I said, each ‘program entry’ can include any set of zones (these will run at the same time). So if you want 4 zones to run at the same time, just choose the set of 4 you want, and create a program entry. Then for the next 4 zones you create another entry, and so on.
That sounds like what I’m looking for. Would all the program entries fall into the programs main parameters, such as the programs initial start time? So even if you have 64 program entries within a program, they cycle through from the initial start time until finished? You wouldn’t need to set start times for each set of programs entries?
That is vital for me because currently as I adjust zone durations within a program, say reducing the times, chunks of time can be created where nothing is being watered because the start time for the next program is set far enough out to avoid overlap (mostly help keep things clear when I block out the timings for all the programs). It’s quite a task to adjust all these details without making mistakes, and I have to make adjustments frequently. But I say this only because of the large number of zones I’m dealing with.
Thanks for your time!
I just installed my system with 24 stations. I would also like to have the ability to select the order that the stations run via software.
Is there a Merge Request or Issue on Github I could follow? I would also need the reordering (12 zones with OSPI) so that the (short running) sprinklers for the grass run prior to the (long running) vegetable / flower patches.
Guys,
Any update on this topic?? Really needed.
BTW, attached is a proposed approach on the enhancement
cheers,
martinSo, first off, I’m surprised this feature is still not present given this thread started so many years ago!
I’ve been looking for exactly this feature in a sprinkler controller, and it would seem to me to be an absolutely essential feature for anyone with more than two or three zones. I sure as heck don’t want to have to go to the machine and physically re-wire it just to change the order the zones are run. This is a problem for software, not screwdrivers!
All that said I did fairly quickly find a very simple, but highly limiting, and somewhat tedious, way to make this sort of work with the current firmware.
One simply designates one program for each zone. I.e. create as many programs as you have zones, and in each program give only one of the stations a run time (each with the same start time, e.g. 00:00, and each set to run at an interval of 1 day).
Now since it is relatively easy to arrange the programs in any order, voila, zones can now be run in non-sequential arbitrary order. (Why can’t zones be re-ordered the same way programs are?)
It’s still highly limiting to do it this way — one really needs support for ordering zones within any given program (and of course it must be all done in the firmware so that it’s reliable). If the code were plain C I might even be able to make it work myself, but I’m very reluctant to try to dive into C++ code.
Attached is an image of a program preview in the demo system of an example setup where zones are run in an arbitrary order.
Attachments:
Allowing arbitrary reordering of zones in a program would require substantial changes to the program data structures as well as the UI design. This is not something that’s easy to do at the moment, not because it’s technically difficult, but because it involves a lot of changes to the program data structure and UI, and making them backward compatible is hard.
But, some limited support for reordering is coming up in the next firmware, as I explained here:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/issues/232#issuecomment-2256420560
it’s not arbitrary reordering, but it give you a few options to run zones in forward or reverse order of zones indices, forward or reverse order of zone names, alternating (i.e. program’s first run in forward order, second run in reverse order etc.), and completely random ordering.If you have been looking for an arbitrary reordering of zones feature in a sprinkler controller, that means it’s not a common feature — on traditional sprinkler controllers, you just name a set of zones and the water time of each zone, and it waters them in the order of the station index. I haven’t seen a sprinkler controller that allows arbitrary reordering of zones.
Although the firmware code is written in C++, it mostly uses C only features.
In addition, you can always use a script to send command to OpenSprinkler to run zones in any way you want.
Ordering by zone names would be a great solution, since it is easy to add numeric prefixes to zone names. Thanks, Ray!
Thanks for your reply Ray!
While I think it would make the most sense to have arbitrary zone ordering per program, for my own needs I will be perfectly happy with ordering by zone name.
“001 front lawn”
“002 back lawn”
“003 side lawn”
etc.That’ll work just fine.
In my own use I don’t see much need to re-order in different programs — mostly I just omit certain zones in different programs, e.g. for mowing days.
While I appreciate that control via the network API would also allow arbitrary programs and ordering, my current thoughts are that I don’t want anything in the chain of control that doesn’t absolutely have to be there for regular operation. Maybe if there were native HomeKit integration I might risk it, but even there I’m happier having stand-alone embedded systems driving critical infrastructure than having to depend on my AppleTV to run the show.
The reason traditional sprinkler controllers don’t allow arbitrary ordering of zone is because their designers are hardware-first engineers concerned about getting costs as low as possible. I once turned down work on an embedded system that cost several thousand dollars per unit because they wouldn’t spend more than $0.25 on the microcontroller for it. Hardware designers also don’t think like software people at all — software is an annoying necessity to them for more modern low-cost hardware design, and besides they’ve traditionally relied on physical switches and knobs for input controls so programming different ordering would likely require more switches and knobs (or be even more convoluted than their existing horrendously ugly control interfaces), and so would require even more costly hardware. Also since traditional sprinkler controllers are not typically remotely controlled you have to go to the controller anyway to change a program, and so re-wiring is only a screwdriver away. I had some hopes for the high-end Hunter HCC systems with WiFi control, but I can’t get a firm answer from them, and if I were going to spend several thousands of dollars upgrading my system I need to know it’ll do exactly what I want and more well ahead of time, without needing internet access to their cloud! All the other so-called “smart” irrigation controllers are abominations that seem like they were designed 20 years ago.
As for the code, sorry I just don’t touch C++, no matter how few C++ features it purports to contain. I have over 40 years of C programming experience and I’m firmly in the anti-C++ camp.
For the record I’m wanting to replace an old Irritrol 24-zone and a Hydro-Rain 9-zone, with only one zone each unused, integrating them all into one controller. A little SoC board, like an RPi or BeagleBoard, with an add-on relay controller board, while highly flexible is far too ad-hoc for me, and I don’t want to do the software from scratch either, so something like OpenSprinkler is highly appealing, provided I can bend it to do things the way I want.
- You must be logged in to reply to this topic.