- This topic has 17 replies, 12 voices, and was last updated 9 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,
martin
- You must be logged in to reply to this topic.