- This topic is empty.
-
Posts
-
I am completely lost by your logic:
I disagree with the firmware not allowing 65 minutes.
Every single option we talked about here has non-representable values. For example, none of them can represent 1 minutes and 4 seconds. They are all going to round that to 1 minute. That’s a design choice: if you only have 256 possible values (which is what a byte can do), how can you possibly represent everything? Even if you have 2 bytes, there are always values you cannot represent. As long as you have limited number of bytes, there are always values you can’t represent!
What happens when a coder wants to expand the log functions to allow for a display of 90 days or months or years?
Why does it have to do with logging? We are talking about the ‘water time’ of a station, not every single number in the system. Plus, in what cases do you want to run one station for 90 days? If that’s a rare case, then by design choice we rule it out.
Every coder is going to understand that “water time” is different from “time” or “datetime”?
Every coder is going to know how to convert “water time” to/from “time” or “datetime”, and be able to do the math?
No user will ever want more than 63 units?
If so, you have a winning solution.It appears I am way out of my element. In the few open source projects that I have contributed, no one has ever exposed their own data types. This sounds like to much dependence on other people. I am still of the belief, if the function for storing the time accepted a standard time data type, none of this would be an issue.
@iDoug wrote:
Every coder is going to understand that “water time” is different from “time” or “datetime”?
Every coder is going to know how to convert “water time” to/from “time” or “datetime”, and be able to do the math?First of all, using datetime (timestamp) makes no sense for a duration field. I am not sure what you mean about converting a duration to datetime.
Are you suggesting we give users a start date and end date for each station?
The proposed solution depends on people understanding the value so answering your question, yes, they cannot just use it assuming it represents a value such as seconds.
@iDoug wrote:
No user will ever want more than 63 units?
The point of this thread is to weed out what user’s need in terms of water time.
@iDoug wrote:
I am still of the belief, if the function for storing the time accepted a standard time data type, none of this would be an issue.
Although I understand what you are saying here this is deceiving to the end user. If we just accept and send a duration value from the UI side without trying to understand what the firmware is doing then you will run into situations where the user’s set value is not valid, such as 1 hour and 30 minutes (since the controller is rounding to the highest selected unit).
Also, the idea is to save space not use more. We are discussing fitting the watering time per station to one byte to allow more programs on the controller, especially for a user with many stations.
Microcontrollers have limited resources, like program data size, non-volatile memory size. The resource limitations stipulate that you cannot have just any number of stations you want. Do you ever wonder why it’s so much more expensive to get a 24-station sprinkler controller vs. a 6 station one?
Every coder is going to understand that “water time” is different from “time” or “datetime”?
Of course they have to: water time is ‘duration’, is the time between opening and closing the station; datetime is a time stamp and has nothing to do with ‘duration’. It won’t work if they do not understand the difference between the two.
Every coder is going to know how to convert “water time” to/from “time” or “datetime”, and be able to do the math?
As I said, the firmware can accept any input value, and converts it to its internal representation. Similarly it outputs value in a standard format. The math is done on the firmware side and is transparent to the user. But it’s important to understand that that the firmware has limited storage to represent the values, so it’s not possible to represent all values.
Even datetime has a limit: it’s usually represented by 4 bytes, which for practical purposes is sufficiently large. But of course it has a limit. When you reach the year 2200 you will see that coders have to understand the reason current datetime is insufficient.
no one has ever exposed their own data types. This sounds like to much dependence on other people.
All that I wanted to know from this survey is how accurate people need their water time to be. If they don’t need it to be accurate as seconds, why wasting the limited resources representing the seconds? This determines the best way to make use of the limited resources. I don’t think there is anything wrong asking this question.
I give up. Do whatever way you want.
I need a minimum of a 1 minute and a maximum of 1 day duration for the next 15 years.
@iDoug wrote:
I give up. Do whatever way you want.
I need a minimum of a 1 minute and a maximum of 1 day duration for the next 15 years.
That is accounted for in option 3 that Ray suggested.
Also, this won’t be used for the logging output. The controller will still log with a granularity of a single second and report exact usage.
Update: Actually he has a maximum of 7 hours right now. Are you saying you need a station open for 1 whole day? If so, the interval option is available to re-run the program as often as needed to accomplish the end watering goal.
Update: Actually he has a maximum of 7 hours right now. Are you saying you need a station open for 1 whole day? If so, the interval option is available to re-run the program as often as needed to accomplish the end watering goal.
Then this will not work for me. It is to complicated to use.
Ray, I am not sure what all is changing to accomplish this, but will it still be possible to set programs to run all stations for equal times like they are now? Or will these enhancements you are making replace the current options and require us to reconfigure our current jobs?
I know that I have some stations that I can’t run at the same time as each other (whole lawn zones and I have some stations I need to run at the same time as others (individual garden beds). Because sequential is either on/off per controller, it is hard to accomplish this goal without creating many schedules and manually making sure these tasks don’t overlap. I am hoping these enhancements you are working on will allow me to set this on a per schedule level. . .then I can have one schedule for lawn zones, which will run sequentially, and another schedule for all the garden zones to run at the same time.
Thanks again!
Everything being done here is to accomplish per-station watering time.
If you want, you can set every station to use the same time, of course.
This thread is simply to discuss options of reducing the storage requirement of the watering time. In order to accomplish this successfully, we need to assess the needs of the users.
The reasoning behind this is simple: right now we have a single value per program representing the watering time for all stations but to add per-station watering we need to have a value for each station. If people have 400 stations (exaggerated to make a point) for example, then one program alone will exhaust the EEPROM capacity.
The end result of all of this will be: added feature of per-station watering inside programs. The tradeoff of reducing from 2 bytes to 1 byte for watering time is the granularity (or the maximum watering time if you stay with seconds).
Right now, the current maximum is 18 hours (@iDoug, it doesn’t even do a full day as it is right now). The proposed change limits the maximum to 7 hours and changes the granularity to the highest unit used.
Hope this makes sense!
@TechFan, the main planned changes in firmware 2.1.0 are:
1. Each station can have a different water time within a program
2. Weather-based adjustment of water time (see my description here: viewtopic.php?f=8&t=891)
3. Each station can be individually enabled / disabled (disabled stations will not run and will not show up on the UI)There will be other minor changes too but the above three are the main one.
In your case, 1 will definitely help keeping the number of programs down. You mentioned running two sets of stations in parallel, while the stations within each set run sequentially. That will not be supported until we introduce the concept of ‘serial groups’. It’s briefly explain here:
viewtopic.php?f=8&t=401&p=2659&hilit=attribute#p2659
basically each station can be assigned to a serial group; stations that belong to the same serial group will be serialized, while stations in different groups are allowed to run in parallel. This will allow you to run two sets of sequential stations in parallel. Because this involves quite a lot of changes, we are not planning to implement this for 2.1.0 yet.@ray wrote:
Another question: since ‘seconds’ is not very common, do people care about the accuracy of 1 second, or would 5 seconds suffice?
Consider the use of a station for watering small pots or nurseries: overwatering behind the corner.
Or a clayey soil ( = slow infiltration rates) with slopes (= fast rill/surface erosion): the slopes will be underwatered; the end of the slopes overwatered, even in reduced state (= too much water = no oxygen).I think that 5 seconds is a sufficient granularity. A greater value could be too much..
I went crazy in adjusting drippers with an old programmer whose granularity was 1 minute.
Consider also the existent humidity of soil which can alter the infiltration rate as the irrigation proceed.
I think that a fine granularity is mandatory; and on the plus side of this project.A second thought.
Five seconds would still allow the use of a 1-2 sec delay in master/pump, but then the granularity would be reduced to 4 o 3 seconds.
Practically, I cannot see any diffrence between the actual granularity of 1 or the new one of 5 seconds.
Would people need longer delays in pump/master ?Then this will not work for me. It is to complicated to use.
‘Complicated’ is a subjective matter. To me it’s not complicated at all, in fact, it provides flexibility to break up a long water session into multiple small sessions, like the ‘cycle and soak’ feature on some sprinkler controllers. For example, to water for one full day, you can set a station to run for 1 hour, repeat every hour, for 23 times, this covers your 1 day of water time. If you want the soil to rest a minute between two continuous sessions, you can set a station to run for 59 minutes, repeat every hour, for 23 times.
Let me re-state that the only data that we are talking about to ‘fit in 1 byte’ is the ‘per-station water time stored in EEPROM‘, in other words, the ‘programmed station water time’. Everything else, including the program’s repeat count, cycle time, and ALL run-time variables (which exist in RAM) are of full precision. The actual run-time of a station is the programmed water time adjusted by water percentage, weather, station delay time etc, and is of full precision.
@ottorino: after realizing that we can use cycle and repeat to cover long water time, I am leaning towards going back to option 3 in the first post, which provides steps of 1 second up to 1 minute. So there won’t be steps of 5 seconds any more.
In my case, the 3 hours you would allow works for that I need now. . .it does seem to make things more complicated for things over 196 minutes. Being forced to do cycles to accomplish a desired water time over 3 hours doesn’t seem like the most user-friendly choice. Like I said, at this point, I won’t run into problems, but just my observation.
@TechFan: you definitely have a point. But let me justify it by saying that at least for now there is strong incentive to break up long water time to smaller sessions, because of a limitation in the scheduling algorithm. Specifically, if in the middle of a program-run the controller restarted (say, due to power down), it will not resume the program even if it hasn’t finished the program yet. This is because the algorithm only starts a program if the current time matches the program’s start time or any of the repeat times. Say, if a program starts at 8:00am, and the controller subsequently powers down and comes back at 8:01, it won’t resume the program because it’s already one minute past the start time. So if the program is supposed to water for 6 hours, this will lose almost the entire 6 hours. On the other hand, if you set the program to water for 1 hour and repeat 6 times, it will at most lose 1 hour, because at 9:00am the program will start again. Hope this makes sense.
@ray wrote:
Hope this makes sense.
This make a lot o sense. At least to me.
I know this topic is about saving memory, but …wouldn’t be possible to log such a potentially very dangerous event ?
Or is it already logged as partial watering time ?@ray wrote:
Hope this makes sense.
Yes. I have no problem understanding the logic and in some ways the benefits, but maybe that should be handled by the firmware, not the user. In my perspective, the user should be able to say I want it to run 6 hours. . .and it runs 6 hours. . .even if the firmware is restarting the cycle every 3 hours. I just don’t think the user should need to program around the limitation. I understand this is about conserving memory usage, I am just speaking up for keeping the complexity out of the user’s world.
@ottorino: Yes, I agree, it would be nice to log and alert about such things as failures, but not sure if that is feasible. Ideally, I would like to be able to automatically ship my logs to another device for long term access and storage (OS(nonPI) doesn’t allow accessing more than week at a time).Where is the ‘Like’ button…
I second that the controller must do whatever to accomplish the users request. Running 6 x 1H sessions to get to the users 1 x 6H schedule sounds like the best ‘User’ option. For a Techie looking at the logs it might look confusing so perhaps some added logging information should also be considered to tie the six watering sectors to one UI scheduled time.
Yes. I have no problem understanding the logic and in some ways the benefits, but maybe that should be handled by the firmware, not the user.
The discussion stepped from the current limitation that the controller will not resume program runs when it restarts. I think the only real solution to solve the problem is to write all run-time variables to non-volatile memory. That way, if the controller restarted in the middle of a program run, it can retrieve the data necessary to reconstruct the run. This is possible by utilizing the SD card to store these data in the future. That’s why I said ‘for now there is strong incentive to break up long water time to smaller sessions’.
I’ve just finished building my OpenSprinkler system, but my previous controller provided per-minute granularity and (I think) 2-digit range (00-99). For my specific use, 6-80 minutes in one-minute increments would suffice, so options 1 or 3 would work, 2 would not.
Regarding the recently-discussed issue of units on the per-station times, what about setting the units at the zone level as opposed to the program level? (from what I can tell, the previous discussion has been centered on including this information at the program level).
That way, users have the flexibility of selecting hours/minutes/seconds for each zone, but you can represent the actual durations in the programs themselves in a single byte (0-255 of the selected unit). Note that the “units” could certainly follow the options mentioned in the first post (and not necessarily just H/M/S).
For irrigation purposes; seconds are relatively irrelevant. Using minutes makes far more sense to me.
Hopefully the change to individual station timing will permit simplification of the programming process. (Especially for those of us in drought zones with heavy restrictions on watering dates and times.) In the San Antonio, Texas area; we can only water one day a week from Midnight to 8:00 AM and again from 8 PM to midnight. I have a wide variety of zones (Drip irrigation, Grass, Vegetable Beds, shrubbery, Fruit Trees, etc) all with different timing needs. The current method of creating different programs for each type (timing) and stringing them together can be quite frustrating; especially if you want to make seasonal adjustments. Since you have to state the exact time that each program starts; you can’t easily string multiple programs one after another without leaving time gaps to account for a seasonal percentage increases in normal watering levels. This in turn makes it extremely difficult to fully water everything within my allowed 12 hours per week. (32 Zones) . The new approach sounds like an excellent enhancement. Thanks for your ongoing enhancements to the system.
@bwulfe wrote:
For irrigation purposes; seconds are relatively irrelevant. Using minutes makes far more sense to me.
Hopefully the change to individual station timing will permit simplification of the programming process. (Especially for those of us in drought zones with heavy restrictions on watering dates and times.) In the San Antonio, Texas area; we can only water one day a week from Midnight to 8:00 AM and again from 8 PM to midnight. I have a wide variety of zones (Drip irrigation, Grass, Vegetable Beds, shrubbery, Fruit Trees, etc) all with different timing needs. The current method of creating different programs for each type (timing) and stringing them together can be quite frustrating; especially if you want to make seasonal adjustments. Since you have to state the exact time that each program starts; you can’t easily string multiple programs one after another without leaving time gaps to account for a seasonal percentage increases in normal watering levels. This in turn makes it extremely difficult to fully water everything within my allowed 12 hours per week. (32 Zones) . The new approach sounds like an excellent enhancement. Thanks for your ongoing enhancements to the system.
Thats what i thought too. i have all my programs start at the same time, and the software will string them together.
- You must be logged in to reply to this topic.