Forum Replies Created
-
Posts
-
You said ‘the updater does not run’. What operating system do you use? Do you have Java installed? If not, please go to http://www.java.com, download and install Java. Thanks.
Thanks for sharing. The flow sensor part is particularly interesting. Will be taking a look at your code shortly. Thanks.
I have the same version of OSX. After googling the error message, it looks like you may have a folder permission issue. The updater needs to grab osFirmware_info.txt and write it into the folder where the program is (this part is taken from the code you wrote), and you may want to check whether the program folder has write access.
I can’t reproduce it. The only thing I can think of that would relate to ‘Permission issues’ would be if you were running the program in Linux and encountered USB permission issue. But it shouldn’t happen in Mac. What OSX version do you have?
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’.
@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.
@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.
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.
OSPi uses a 74HC595 shift register to generate 8 outputs. The shift register take 4 GPIO pins. It’s implemented this way so you can easily cascade additional shift registers to produce more outputs without using more GPIO pins (and that’s how the expansion boards work).
If you want to use 8 GPIO pins to directly drive relay board, you can use Rich Zimmerman’s sprinklers_pi program, which supports this option.
@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.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 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.
Look, the firmware does its own independent checking, so if you throw 65 minutes to it it’s just going to round it to 60 minutes because it has no way of representing 65 minutes; and if your throw 120 minutes to it it will convert it to 2 hours. It always does its best to represent whatever value you pass in. I agree with you that the firmware functionality should not be dependent on the UI to do error checking for it.
What I meant is that if the firmware cannot represent 65 minutes, why letting the UI leave this as an option? I think it’s not ideal for users to set 65 only to find out it’s rounded to 60. So what I am saying is that if the UI can do it, why not?
How that time value is stored is all inside the function and should have no bearing on the UI.
Sure, as I said before this is fine; but if we are to adopt the “value + unit” option , then the UI can be changed to match that right?
@iDoug: the user has no way of selecting 1 hour and 30 minutes, because there are only one input value box, and one dropdown list to select unit.
Another question: since ‘seconds’ is not very common, do people care about the accuracy of 1 second, or would 5 seconds suffice?
No, the UI won’t be affected much, because the conversion back and forth is done on the firmware side. The UI can send any value to the firmware, and it’s up to the firmware to decide how to store it; similarly, when the firmware sends value to the UI it gives the UI the decoded value. [edit: yes if we are going with the value + unit approach, it will involve a UI change]
The simplest approach is to let user input any time they want, and it’s the firmware’s job to quantize the value as necessary. But this may cause some confusion (like they may be surprised that 3 minutes and 10 seconds get rounded to 3 minutes). So the better approach is for the UI to match the firmware: for example, the user can put in any number in the ‘second’ box, but as soon as the ‘minutes’ box has a non-zero number, the ‘second’ box is disabled to reflect the fact that beyond 1 minute the accuracy become minutes.
@iDoug: here is another version based on your proposal: the first 2 bits represent units (second? minute? hour? day?) and the remaining 6 bits represent value. This will waste some values (like 24 hours and 1 day is the same), but simplifies the conversion.
@iDoug: you are right that the actual running time is in granularity of seconds so water percentage can be applied without losing accuracy. The 1 byte restriction is mainly for efficient storage (’cause the microcontroller has limited EEPROM size). Because water time per station takes up most of the program settings, if we can fit it in 1 byte instead of 2, that can provide almost twice as many programs, which is desirable for people with a lot of stations.
Is it important to cover run time longer than, say 8 hours? I mean, if you need to run it that long, you can always break it into two programs that run one after another right?
@TechFan: the number of times a program runs doesn’t matter (that’s stored in another variable), what I wanted to know is the water time within a single program run. So in your case , you have one example of 15 minutes, and another of 3 hours. (and just saw that you said you don’t need granularity of seconds, thanks).
@donc, my suggestion is to try a different browser (Chrome or Firefox would be my recommendation). At least this will help us find out if it’s a browser related issue. I can’t test IE9 right now because my XP says it can’t upgrade to IE9 and my Win8 says it can’t downgrade to IE9…
The board provides 5V to Pi, however, the shift register and ADC are powered from the 3.3V pin from Pi, because all Pi pins are only 3.3V tolerable. The other reason is that often these embedded Linux boards (especially BBB) requires external components to be powered strictly after the processor is powered, so using the 3.3V power derived from Pi (instead of 5V from OSPi) ensures this property.
Too bad you’ve decided to discontinue the original UI; in my experience, it was 10x better, even when used with my phone, not just desktop. Is there any way (SD card?) to keep the old UI around?
I understand your concern, but consider that:
1. The original UI is based on static html pages, which are very much outdated and do not offer dynamic page updates;
2. The original UI requires duplicate program code to output basically the same information as JSON — this takes away valuable resources that can be used to implement new features.
3. The original UI and mobile UI are inconsistent and it’s becoming too much overhead to maintain two different UIs. It’s much easier to maintain just the mobile one which can be used across all platforms.The reason the new UI is slow is partly due to the fact that it needs to be compatible with all OpenSprinkler firmwares, including OSPi software. But Samer has been working to address this issue by making use of browser caching, so that UI may take longer on first load but from then on it’s much snappier.
You asked about keeping the old UI around: this unfortunately is not possible from 2.0.9, due to reason 2 I mentioned above. Thanks.
