Forum Replies Created
-
Posts
-
The program structure can be found in the program.h and program.cpp files. You may need to edit portions of Opensprinkler.cpp, program.cpp, server.h, server.cpp, and main.cpp to add new features and set or modify them using the device buttons or json web interface. There is a lot to look at but the best way to go about adding a feature is to trace another existing feature through the program.
Also if you are adding to the size of any of the structures be sure to allocate enough space for it in the nvram. You can find a decent table of its format in the defines file. You will want to write down your current programs as once you change the layout of the memory you will not be able to import your old programs.Good luck it can be really rewarding to add a feature and see it working in the real world. Make sure to fork the project on github and post your changes there as it can be useful to others to see what you have done. It also makes it easier for someone to help with an issue to see the full scope of your changes.
The way the firmware works it will always use the MAX number of stations and extension boards. If you set a bit on a board that does not exist it will still schedule and “run” that station. So your hardware only has 40 physical stations available, but your device allows as many as 48. So the sbits field you are seeing is correct.
You are also correct in your assumption that station 12 has its bit set, and should be running.Hopefully that explains what you are seeing,and clears up any worries you may have had about your setup. Just remember the firmware will always work with the maximum stations and extension boards that your particular device is capable of working with. This is done to keep the memory cleaned up and not have to rewrite all of it to adjust for future hardware changes.
Warning the user about no flow conditions is not inherently tied to the ET function. This would have the same result in a set it and forget type setup as well. However, the OS firmware does have the ability to send messages out when certain alarm conditions are met. If you wish to have an SMS message sent with High, Low or No flow conditions this can be done and is still included in the base firmware. The ET calculation has nothing to do with this function, and has neither removed nor changed its abilities. The one side effect is should the water somehow run longer or less than needed it will adjust in the following days hopefully negating the issue.
As always checking for proper function of the system is still the responsibility of the end user. As myself or any other programmer can not be present to correct physical faults in your personal system. Hopefully that explains things a bit. Please don’t take anything as me being rude but some problems rely on an owner fixing them. If you would like for me to add a “master” valve as a protection to the actual valves running, that is something that could probably be done. Just note that the ET function is not a fail-safe for physical fault or destruction of your system.When I started making the firmware changes for calculating and using ET the base firmware was quite different than it is now. Some of the “visuals” are left over artifacts that had no bearing on the final outcome of watering based on ET. Let me try to explain the crazy complicated process of watering asked on ET and hopefully it will answer a couple of questions and wonderings, as I like to call them.
ET is basically plant sweat for all intents and purposes. Like people the plants/grass will sweat out water based on the environmental conditions to help maintain a livable temperature. Some water is also lost in chemical reactions while the plant makes the food it need to survive and grow. All ET calculations are based on 100% simply because we are calculating total water lost. The percentage is an artifact of the older system. Here’s what I did in a nutshell to adapt watering requirements.
First get the current conditions and calculate how much we have lost so far today. Then take a quick look at how we did yesterday, and sum up the 2 days worth of data. This gives us ET. Now we need to know what the future looks like. If it’s going to rain a ton tomorrow and we don’t need much water today, we can wait. However, if it’s super hot and dry, with a tiny chance of rain in 3 days, let’s give her all we’ve got. So it is like balancing a checkbook and paying bills. We know our balance, and what bills are coming up, so we can make subtle adjustments and get everything paid without going in the hole, or over watering.
The data used is dependant upon the data available, if ET is sent by WU it will be used first. If not we need to calculate it on our own. Things already looked at are, leaf wetness, humidity, solar radiation, temperature, precipitation, wind, air and soil saturation. The soil type and plant height have to be user provided as WU won’t know that. If a piece if information is missing, like solar radiation often is, we use the next best calculation based in things we can acquire. For instance cloud cover, latitude, and time of day. Using those bits we can get to within less than 1% of actual by calculation. If some of that is missing we go to the next best thing using averages based on recent days. This continues for 7 iterations or until we have what we need, each level down introduces some error, but can still be 30% better than just setting for 10 min and calling it watered even at the lowest level of accuracy.
Next up we see how much time it takes to water the amount we figure the plants need. This is straight forward so no need for detailing the process.
Then after we know how long we need to water to balance out the requirements calculated, we do a quick sanity check to make sure watering is effective, wind speed must be less than 7kph, temp above freezing, and not currently raining. If everything checks out it waters. Then the process starts over. What will happen on screen is a number showing how much water in mm of precipitation is needed. Negative means we over watered, and positive is needed. When it gets over 5mm needed it will water, anything less and it will hold off.
This keeps the plants at their drought protective state. Essentially the grass and plants will be trained to save water by closing pores, growing at cooler times of day, and sending roots deeper into the ground.I’ve used this for 2 seasons now and biggest change was about 40% reduction in water use compared to the old 10 min twice a day method. Next I noticed the grass was much healthier, I guess it doesn’t like drowning any more than not being watered. Finally I had to mow less because the grass was staying short and densely packed together. I live in a part of Colorado that sees some crazy weather, and never watered when it was raining, and only saw over watering twice, by about 4mm due to a crazy thunderstorm.
So tldr: ET is just a required amount of water, there is no percentage. The sprinklers will only water what is needed and reasonable.
Any information provided by WU is used first, if it isn’t enough to get an ET value it will be calculated, or even approximated if very little info is available.
Accuracy is quite high using the Penmann-Monteith method so it is used first. If it can’t be used, then the Hargreaves method is used. After that statistical data is used as a last effort. The data is available online so I won’t bother with the mile long maths problems.The project fork I posted on github is usable and functional, but may be a touch rough around the edges. She ain’t pretty but she knows what she’s doin’.
If you have any other questions let me know, I’ll try to answer.
Side Note: WU provides different amounts and types of data based upon device. For instance the iDev app gives indoor temps and videos. The Android app does not, but has 10 days of history vs 7 the iDev app gets. I have petitioned WU, weather.com, and the weather company to provide all relevant ET data for Opensprinkler. They are currently adding more points to the API for Opensprinkler.
Due to the change in time resolution and memory constraints of hardware version 2.1 only 8 programs can exist at one time. If you have the latest hardware (2.3) you can have up to 14 programs I believe.
About 5 months ago I released a working version of the OS that would calculate ET and adjust watering times accordingly. The ET is calculated using data from WU weather data (the primary script is hosted on my server), this way no one has to work out every reporting method for ET. The method also uses an hourly calculation so it will adjust for real world conditions that vary from predicted. It also adjusts for predicted values so that it will withhold water if rain is predicted in the near future. Having used it all of the 2016 watering season I had great results with only 2 days of over watering amounting to a total ‘waste’ of about 25 gallons of water, compared to the near 500 gallons saved versus the previous year (adjusted for vastly differing weather patterns–I averaged and subtracted deviations of outliers). The entire program is available on my fork of opensprinklers main github if you wish to use it as a starting point. I don’t support it anymore as it seems interest in the product is high, but interest in integration to the primary firmware is low, essentially I do not have the time to support the project as it takes away too much time from my job.
Most of the firmware matches the 2.1.6 version of the firmware and as it sits is compatible with all devices. Please be aware of the use of code from other authors as I did not start from scratch. You can see the information HERE.
Samer I have the same issue. I hosted them on my server online for the ET version. I can go to ui.veuphoria.com and it works, but visiting the IP address of the OS, or using the app just returns, the black page. I was certain I had caused the issue so I didn’t mention it, but I don’t get errors at all. Just a blank black page.
The same result can be achieved on your version by opening the ui using the IP address, and then pressing the back button after logging in. It will go to the blank black page without going to whatever was in the browser history, and then no navigation buttons will work in the browser. I’m not a web developer so I was not able to fix the problem, and no errors are thrown so I don’t even know where to start.If you havent tried doing so, enter the pws name without “pws.”
The firmware will convert your location to latitude, and longitude. So if all else fails, go to WU, navigate until you are showing the weather using your pws. Then look at the location there, it will show the lat and long coordinates. Enter those as your location, and as long as your pws is up and running it will use it. If for some reason your station goes offline, it will use the nearest available.
Another thing to take in to consideration, some of the weather data is cached and averaged, the averaging process may not use weighting for the data, which could skew the final result a small amount. Weather is read every hour and the cached data is reset at midnight. If you continue to have no luck, you could look at the api documents and enter your location manually.
I hope that helps a bit,
ShawnSolar radiation will always be the most difficult data to acquire. Firstly, the equipment to measure it correctly and accurately is expensive. You can pick up cheaper units that will swing wildly throughout the day, and may end up providing useless data. The other way to get the data is mathematical deviations from a normal, or mean/average. You can use a small solar panel with a good specification and decay rate for watts/meter over time. Then infer solar radiation using charge rate.
The solar panel, or photovoltaic cell method is what most home based weather stations use. So you will only receive data as good as their calculation. I say do that part yourself, then you can tailor the calculations and assumptions to your specific needs. As far as working out the solar radiation, most of the methods are available online, and I encourage you to research which would provide exactly what you are looking for. Once you’ve found what you want to use I will be more than happy to help you with the calculations.
The biggest piece of advice I have is really think about how accurate you need to be. Remember, keep it simple, you’ll have much less headache, and an easier to use product. Grass is quite forgiving, it didn’t always have people around to help it grow 😀 Mine probably hates me because I’m always testing on it.
I honestly think you have gone much more into detail than I ever worried about. A lot of people will never understand the magic part of the code in the little box, they just want it to water, and keep things alive. You have done quite a bit of work and it shows, keep it up, I look forward to seeing what you are able to achieve.
Hey ppbecchi,
Firstly thanks for your interest, a lot of the script was written before I knew a lot about the OS firmware, so it may take a bit of work to use it. Secondly, a quick physics joke to help explain my background…there are a million ways to skin a cat, but a physicist will be stuck trying to prove the cat exists. Schrodinger’s cat reference, I will explain in a second. Anyway on to your questions…
1) Data availability, ground solar radiation can be derived quite accurately, if you know location (specifically latitude), day of year, time (or longitude), and the exact amount of solar radiation lost by atmospheric scattering. The first 3 parts are easy and exact, the 4th is the joke reference. I could spend days pouring over data and never get to solve the problem, or I could make some assumptions and get a “good enough result.” So what I did was use a solar radiation meter, and some historical data, then using the 2 determined, for the sprinklers, I didn’t need to be perfect. With the method I used, I could get results withing, an few thousandths of a mm. Unless you were watering on a medium sized country wide scale you wouldn’t over or under water by enough to matter. Since a better method doesn’t exist for most I decided “good enough.” As a heads up the script will use ground solar radiation data if available.
2) Satisfaction of variables…seasonal change is exactly what Penman and Monteith set out to account for. Their calculation uses all the appropriate data to figure water loss by plants within a normal growing set of points (ie above freezing, a certain amount of light, and wind not strong enough to remove the plant being observed). Next, vegetation type, for sprinklers I reduced the data set to above and below 4 inches, trees once greater than sapling are essentially self sustaining. All grasses, under 4 inches use or lose about the same amount of water. Most leafy shrubs, flowers and grasses above 4 inches do the same. Again I had to pick a solvable problem that would satisfy the majority of cases. If a plant/grass is not getting enough or too much water the base times can be adjusted to account for this. I used this point after a lot of research into calculated constants. Above an below this mark, there is so little change it would never be noticed, in a standard residential watering system. Soil drainage and absorption, was a bit trickier. I tried so many different runs at this problem my head still hurts a year later thinking about it. For this the end user has to adjust the number of cycles, and base times. Otherwise the program will not fit on the controller, there are simply too many scenarios to include them all. I hope you understand. The coverage area is the responsibility of the end user, as there is simply no way for me to know this. It can be calculated with area divided by flow rate, or a quick measurement of precipitation from the sprinklers.
3) Local or personal data is baked in to the script, just point to your data uploaded to WU, or have your weather station output a json similar to the WU setup and it will work. I can not possibly be asked how to do this for everyone’s individual setup, as I would spend a lifetime helping everyone with every station while I remained unpaid for my services. You will find yourself in the same scenario if you choose to explore this route with your setup.In conclusion, I made reasonable and educated assumptions where it would satisfy the majority of cases. And I excluded the notion of satisfying every individual setup, for the sake of my sanity. Essentially my script works well for myself and most cases, it will not work perfectly for every outlier. The beauty of open-source is exactly this, if you don’t like it or it didn’t work for you, observe, learn, correct and improve it. Then give your time back to those you drew information from.
Hope that helps,
ShawnHave you tried resetting the pi, or at least the sprinkler portion of it? If you have…you may need to run a manual program today if you need water. I think I forgot to point the pi version to the right script for weather :(. I’ll get it fixed, but I can’t do it while at work.
Sorry for making a tester out of you, but I don’t have a pi. First, try emailing me your location. Just so I can make sure everything is behaving properly with the script. Or go to WU, put in the location you want to use, and then copy the GPS coordinates to the location on the OS. You should see a change with the first weather call.
Second is checking to see if the program has ET checked, as well as use weather. Both are needed.
My address is Shawn +at+ veuphoria $dot$ com.
Do you use the CA restriction? Make sure you have evapotranspiration, selected as you weather option, no others will work, unless you change the script option /su back to weather.open sprinkler.com.
You can try making a manual call to weather.veuphoria.com/Weather3.py?key=yourWUkey&loc=yourlocation it will send a string back to your browser. It looks like code but is just the results for et0 and et1 and a couple other things all mashed together.
You should see the et update after the first weather check. It will also force update at midnight. If something doesn’t update let me know.
Well alright, I changed it to a ternary operator, name isn’t really all that important. The important part is it should work for you now, sorry it took me so long to respond initially.
Let me know if something doesn’t work for you, I’ll do my best to help…I don’t have a OSPi so please be patient. I don’t forsee other issues, but then again I didn’t know that would be a problem.
Okay you must be doing a build for ospi, I had no idea the basic math (min and max) functions were not available to the pi?! Let me do a bit of research and I’ll get back to you later today or tomorrow. Probably just need to do something simple like add an include for some math library, or change min() to math.min()…
If anyone has ospi experience your help here would be appreciated.Well seems like the fix for this issue was as simple as reducing the Ethernet buffer from 700 to 512, and 1500 to 1024, it seems as though the library allocated memory for as many as 4 connections at a time. On seemingly random occasions it would allocate for 2 connections when reading logs and was in the middle of something else. When it did this it would crash the MCU.
So without modifications to anything but the ether_buffer_size it works fine now, even when I have it write hundreds of logs a day.
Hope that helps, it does require a reflash but only one line in defines has to be changed.
It does indeed appear to be Dutch, if you are able to provide an appropriate German translation it is something that can be fixed pretty quickly, by requesting the change to the localization. It would be a help to the entire community using OS and the German language.
If the vpn is allowing access to the OS for other functions and does not happen to have a ‘really small’ data restriction placed on it (something not common in a standard setup) then you do not have a vpn problem. It sounds as though you have the same issue others are having in the firmware.
I have been working on the issue and converted the log write functions to use sprintf instead of the current method of appending. It seems to fix the issue. A bit more testing and I should know what kind of success it provides. It seems as though the current logs are somehow overrunning any buffered space provided for them. Essentially using to much ram during the read or write processes, and causing the MCU to reset.
Look into a free or cheap dynamic DNS service. DynDNS, freeDNS, no-ip, are just a few of the ones available and compatible with most ISP’s.
That would probably be the best way to go without having to go through the trouble of setting up and maintaining a webserver of your own.
A quick Google Search will give you quite a few more options including open-source versions of the services.
You could also set a cronjob or python script to send your external IP to an email account. Where at the very least you could retrieve the info if you find it has changed since you last used it.
Well good news that part is good as I suspected it should be if everything was coming on while plugged in to a power supply.
Next would be to track down why it won’t let you update properly, and what down the line electrically is possibly not working.
You could try testing to see if a voltage can be read at the pins for each valve. Plug the unit in and start a test program, then check between com on the pin for the station currently running. Should be about 24VAC, or 12VDC depending on version. I think you may get 0 running that test which means I would have to defer to Ray.I believe the inability to update the firmware and not firing the valves is directly related, but I’m uncertain as to why.
***If you do not have the case on when plugged in to power, please be sure to isolate the bottom side of the board. If you short the connections there is no telling what could be damaged.***
Right next to the battery labelled “F1” if you have a multimeter or voltmeter, test across the 2 solder pads, that is the fuse. It should read 0V or very close to 0, if it is 1 or higher you have a blown fuse.
Alright, I have the same thing happening again right now, here’s what is visibly happening.
I request logs as normal, and the ui sits there with the spinning circle which has brief pauses every second or so. This will continue for about 1min before it times out and says there was an error and to refresh. On the OS itself as soon as I make the request to see logs it will reboot, and continues to reboot until the request for logs has timed out.
I can request /jl for the same time period and I get the same result, however, using /jl with hist=0 returns correctly. I started expanding the time frame out and when I reached hist=3, it immediately reboot and returned an empty dataset []. Prior to today it was able to return 22 days (the full log history) without error, so I don’t think it is a memory issue. The 22 days is inclusive of the skipped day this previously occurred.I’ll leave it in this condition, so that you can request any tests you’d like to have performed. It is not currently writing any new logs, which is of little concern, as the unit is performing all other functions correctly.
With a couple sets of eyeballs put together, maybe we can figure this out. I don’t have much in the way of test equipment, but will do anything I can to help. If you want I could send the unit to you, but that would have to wait till the end of the season as currently I do not have a backup.
I am using HW2.1 with the ET firmware available on github, please note this problem was exactly the same with version 2.1.6. So that may help narrow down where in the firmware a problem exists, as the changed areas do not alter the outcome.
Thanks in advance,
ShawnMake sure the fuse on the main board didn’t blow, check your power supply to make sure it is working correctly and outputting the correct voltage. Then check the connection at each wire running to the valves. Are they seated fully and tight?
It sounds as if you have an electrical issue so running through everything one more time, checking connections and proper placement is going to be your best bet. If you didn’t touch the unit while is was not being used, fuses and power supply are more than likely the issue.
If you just recently updated to the most recent firmware it may have corrupted, so you may look at retrying the update.William can you post the name of the option you found on your modem, it may be helpful to others with similar problems.
The reply is indeed empty, when calling /jl. I couldn’t find a cause for it in the firmware, other than it may be some sort of overflow, when writing to or reading from the SD card. The odd part is a power off reset causes it to respond properly. As stated before it was only happening on data from the 4th days worth of logs. If no log is written for a couple days in the middle it still has the issue on the 4th day of logs when they are written. For example:
log1,log2,skip,skip,skip,log3,problem
Reset,
Log1,log2,log3,skip,log5Hopefully you can nail down a cause, because I’m truly stumped by this one.
If you have not already generated a new key, the one you have provided does NOT work. Publicly posting the key may result is restriction of your service. Please go to your user page, and generate a new key, then be sure to copy it properly to your OS. You can test your key on the WU site to make sure it is working, just use one of their examples with your key substituted in.
Hope that helps
