- This topic has 14 replies, 3 voices, and was last updated 8 years, 2 months ago by
.
-
Posts
-
I got the new app update today and it’s great. The new sunset to sunrise station duration is a really nice feature to have. I was wondering if you also have plans to add support for a station to stop at a particular time off the day. For example, I have backyard lights that I want to turn on sunset and turn off at 11:00pm. I don’t need them on all night and it would save electricity. Currently I have the duration time maxed out at 4 hours, but when its winter and the sun sets at 5, the lights will go out at 9. I hope this can get added.
Thanks!
This is on our todo list, however, I am not sure when this will get implemented, primarily because introducing the concept of ‘end time’ would incur some significant changes to the program’s data structure and the UI. I will keep thinking about what’s the easiest way to handle this.
Thanks for your response. If I may, here is a suggestion how to implement this without completely reorganizing the programs data structure:
When a user clicks on the duration setting for a station, add a section for selecting the end time below the sunrise and sunset area. The duration well be greyed out when the user starts entering info about end time. When submitted, the program calculates the duration based on when the station will start and the selected end time (I’m assuming this is how the current sunset to sunrise option works). This duration can then be saved in a similar manner as if the user selected the duration explicitly. This duration will have to be recalculated once every day as the sunrise and sunset times will change, but I’m assuming this must already occur for the sunrise to sunset option to work.
I can see not wanting to go this route as the pop-up duration screen might get a little busy, but I’d be curious to know your thoughts on this method. Thanks!
This will be fine if the program has only one station to run. But what if the user selects multiple stations, and they are all sequential, then it’s not clear to me how the controller should execute this program. For example, if you set station 1 to end at 5pm and station 2 to end at 6pm, does it mean station 1 will run first, and station 2 then runs till 6pm? Since both stations are sequential, they shouldn’t overlap. We need a clear definition of what it means when you have multiple stations in a program and each has a specified end time.
Sorry for the long post, I had a lot of ideas. Not sure if they are helpful but here goes…
I see how that could get tricky with multiple overlapping stations that are sequential. I think the solution, at least part of it, would have to rely on some level of user common sense. Your example, for example, doesn’t seem to make any practical sense to me. I don’t see why anyone would set up two programs this way. But at the same time you want a clean and straightforward user interface where there is as little room for user error as possible.
All of my sprinkler stations are sequential except for my two backyard light stations. Maybe you could restrict the end time feature to non-sequential stations only? Theoretically, if you want a particular station to end at the same time every day, then you have a specific time in mind when you want that station to stop. Therefore, the sequential option wouldn’t make much sense. So the end time option would have to be enabled only for non-sequential stations, or take precedence over the sequential option.
I think the same thing can be said about weather adjustments. I’m not at all concerned with weather adjusting the duration of my backyard lights. They need to turn on at sunset and off at 11:00pm every night. Any program with a specific end time should also not be concerned with weather adjustments as it just doesn’t make sense. Similar to above, the end time could take precedence over the weather adjustment.
The way I now see this playing out in the UI is something like this:
Below the Start Time on the Add Program page, a new option for End Time is available but not selected. If a user selects this option and enters an end time, the Use Weather Adjustment is disabled. The user can then select which stations for this program to apply to via checkboxes, not a station specific duration (kinda like how the old firmware worked). The only stations available to check would be those that are non-sequential (alternatively, this program could take precedence and disregard the sequential option for a particular station if checked).Right, I agree with you that end time should probably only be applicable to parallel stations. So if we enforce this constraint, it should solve the issue of ‘clearly define what happens when multiple stations use end time’.
If a station is set to use ‘end time’ I think it’s natural to ignore weather adjustment since it has a defined end time and not defined duration.
I’ve discussed with Samer about this and we came up with one solution, which is to allow station’s run-time to be set as ’till xxx’ (e.g. till 11pm). At the moment the station run-time already supports two special ones: ‘sunset to sunrise’ and ‘sunrise to sunset’. Extending this to support ’till xxx’ would require some more storage, but we are already planning to expand the storage for station run-time anyways (in order to fully support granularity of seconds), so this can be planned together. Timeline wise, maybe in a month?
Not yet. This has been an extremely busy semester (I teach at a university), and Samer is extremely busy too. I may have to wait till spring break to get any significant work done 🙁
Unfortunately not. This, and also the ‘pause program/station’ feature, will have to wait till the next release, after 2.1.7.
- You must be logged in to reply to this topic.