- This topic has 20 replies, 4 voices, and was last updated 8 years, 11 months ago by
.
-
Posts
-
Ok I have been spending much more time monitoring my devices since I have noticed problems with the weather pulling, watering percentages and now that I have them controlling area lights I have discovered another serious problem. I think we can get it ironed out but I wanted to make you guys aware and see what we can do.
My area lights come on from dusk to dawn and I run them 7 days a week and on the last station of my devices. I have noticed when the device initiates the program it looks like it does a weather call 1 hour before. The light station has weather/rain off and is not set for sequential. The program initiates and runs fine. However I noticed that once the lights are running no additional weather calls are made.
So we had rain this weekend, my controllers stayed at 100% watering and ran my sprinklers. It did not pull a new weather call until after all the programs were done. During this time, I tried to pull weather by clicking the weather diagnosis button, but it would not pull an update. So I have been testing this through the weekend and I was able to reproduce it.
This information is being provided for information only and to help make this product even better. So please do not take it negatively.
1. So the device needs to be able to pull weather calls while programs are running. (I don’t think this is happening.)
2. When you press the Weather Diagnosis button, this should force the device to call for a weather update. (Is this the case, because I did not see this, especially when a program was running.)
3. How often is the weather call happening? (Maybe this info can be displayed in the diagnosis click. (Maybe this should be a settings as well.)
4. Does the device make a call for a weather update just before a program starts?
5. Is there a possible cache problem?Afterwards my controllers went to 0% and I suspect it will remain at 0% until I manually reset it. (This problem has already been reported and is being looked in to.)
Let me know if there is anything I can test, or information I can supply.
Ed
The weather updates do no occur while a program is running because the Arduino can only run a single task at a time. Therefore, if the weather update is delayed due to network congestion the controller might not correctly start or stop a station at the precise time. For this reason, we opted to not update during watering.
In your situation, using it for both lighting and watering, you will run into the issue you are describing. Furthermore, we don’t have a hook to force update the weather from within the app, this only occurs every hour when no program is running.
Hope that clarifies what you are seeing. As far as mitigating it we will have to do some research and discuss with Ray the best way to alleviate this in the mean time.
Thanks!
Update: To address your other questions, the controller updates every hour when no program is running and that is its only update schedule.
Samer,
Thanks for responding quickly. The information you have supplied confirms what I was seeing. I am sure we can figure something out.
Let me correct Samer’s reply: the firmware technically can update weather data while running a program — this actually has nothing to do with the controller running single-task at a time, because it can alternate between tasks giving the illusion it’s doing multiple tasks at the same time.
I made the conscious decision to not update while a programming is running for two reasons: for one, currently the weather call returns time zone data and weather data in one packet, if the time zone changes (though this is a very small probability event), it can mess up the total run-time (imagine a program is running while the clock suddenly changes); for the other, if the watering percentage changes while a program is running, it can cause confusion (for example, if the percentage changes to 0, should the currently running program be terminated or not?) Also, most controller that use weather data do not update more than once every day. The fact that we are updating every hour is already much more frequent than usually done.
It’s very easy to change this. In the firmware code, the following line:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/main.cpp#L663
just remove the “|| os.status.program_busy” part. If you don’t want to compile the firmware yourself, we can send you a compiled firmware and you can upload it to your controller.To answer your other question: the weather call is by default updated once every hour
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/main.cpp#L54If you have a long running non-sequential station (i.e. lighting), one work-around is to break it up into multiple shorter runs. For example, you can utilize the program’s ‘repeating start time’ feature to break a long session, say 18 hours, into 6 sessions of 3 hours each. This way, at the end of each session it gives the firmware a chance to perform weather call.
Ray,
Thanks for the additional information. First, this device is your baby and I think you already realize that it is not like other controllers on the market. It has potential to be greater. It is already better, but greater is what I see.
Now I will be putting some more thought to this, but off the cuff, at minimal in my opinion it should be doing a weather call just before the start of each program regardless if a program is already running. California restrictions would say yes, if it starts raining while watering then the program should be aborted immediately and the water delay should be applied. As for the water percentage with other methods, then I believe that this adjustment would apply to a program before it starts, or applied at the next startup.
As for the TZ change possibility, in any of your tests have you seen this actually happen? If so, maybe there can be a check and balance (error trap) to determine a bad return.
I am not beyond compiling a custom firmware, but I would prefer working with you and Samer directly to make OS an even better or more finished product. I don’t have a problem helping run tests, running test fw etc.
I would also like to see the weather diagnostic button fixed to force a weather call if possible regardless if a program is running or not.
Your suggestion of breaking the lights in to 6 sessions, I suspect that this would mean a possible interruption in lights each time which is not really realistic solution. Maybe you can convince me otherwise.
One last thing, has there been any headway with fixing the 0% watering after a rain delay has expired in CA mode only? I have been having to reset my controllers manually.
Thanks,
Ed
I am actually curious how California is enforcing the watering restriction. In theory it’s just a threshold, but in practice, there must be a central source of weather data somewhere. Otherwise, different locations (and different weather stations for the same location) will report different rain amount, so when talking about the amount of rain, what is the actual point of reference?
Also, since rain accumulates over time, there is the question of whether the program can continue if at the time of starting the rain hasn’t reached the threshold yet, or whether the program must be terminated along the way if the accumulated rain reached the threshold.
The time zone change only happens with day light saving time, so it really only occurs twice a year.
I don’t think breaking the lights into 6 sessions would cause interruptions. If it does, it’s less than a second so in practice you won’t notice it.
I haven’t had time to look into the 0% watering after rain delay issue. This may be due to a bug in the weather script. Just to make sure I understand the condition: is this by using manual rain delay, or the auto rain delay?
Ed may have tried Rain delay in auto. I have only tried it in manual. I can report that is stays on 0% on that setting. We have had so little rain, it is hard to test various conditions and settings.
Regarding enforcement, on peons like myself there is no enforcement except for random warnings. The value of the fine would to be worth the bother. In Ed’s case with 68 acres or so under management, he might be no be so lucky.
As far as how the cities might develop an enforceable reference point, I don’t know and I doubt they do either. It probably would turn into one of those guilty until proven innocent things. That’s one of the really cool things about opensprinkler: the log.
I began replying and for seem reason i lost it. Very frustrating.
William is right, water you typical lawn is not an issue. When you multiply that in a very public area (69 Acres) it does not bode well have lawns being watered while it is raining especially when we have the tools to do so. As for how CA is enforcing this, well every resident and neighbor along with the city are the ones to police it. The residents here have access to an app for their phones that make it simple to report it with pictures included. The city then follows up with a letter, and then you can in turn get more information. Now we have not seen fines, nor have we had excessive warnings but it is possible. I have a good crew and we monitor the area pretty well. The City is also reasonable as they know leaks happen and they are happy to know that you are on top of it.
It is our due diligence to make every effort to not abuse, so if I can prevent my smart controllers from coming on when its raining I would like to do that. However, when its not raining I need them to function. So I have been monitoring them heavily because we have had enough rain lately to test it.
So to answer your question about the rain delay, I am using the Auto Rain Delay with the rain restrictions. I have set it up for 48 hours. I don’t know what the water percentage drops to 0% because or water restrictions in CA is time based. 5 Minutes for shrubb heads and no limit for Rotor Heads and I am only allowed to water on Monday and Fridays. In any event upon rain, the water delay does kick in as expected, the water percentage drops to 0%. (Not sure why it changes at all) bt after the rain delay expires it remains at 0%.
Now currently I have 4 controllers deployed and I purchased 4 more a couple of weeks ago. Then I came across the weather not pulling a couple of weeks ago when a program was running and also the 0% watering bug. I have download the source code from github and also the Arduino 1.06 software so I could try and make some of my own modifications however, it will not verify and compile with the info and instructions available on github. I am receiving quite a few errors. So maybe you could give me some guidance. I am a little concerned that its been 2 weeks and you have not been able to look at the script and fix it yet. I know that we are right on top of the holidays, but our lawns are suffering as it is. Maybe you could correct this issue soon.
I am very interested in at least removing the weather not checking every hour when a program is running as well. But like I said, I cannot get the code to verify and compile. I do think though the main code should have this corrected. I believe the 2 rare possible problems with the TZ issue is much smaller than the potential of it raining an hour before my sprinklers turn on and my lights are already on. I have no real interested in creating 6 programs to turn my lights off to allow this. Then multiply that by a potential of 45 controllers in the future. Just does not make any real sense.
Anyhow I look forward to your feedback and help.
Thanks,
Ed
So I found additional information on the website with regards to compiling. https://opensprinkler.freshdesk.com/support/solutions/articles/5000165132-how-to-compile-opensprinkler-firmware . I had already download the sdfat.h but I followed the older information located here and was able to get to compile. So I will create a firmware removing the don’t check the weather if a program is running as you pointed out in one of your earlier posts. If you could check the script and fix the bug with the 0% watering problem then we will be golden for now.
We are expecting rain this week so I will will be able to trouble shoot if your able to get the script fixed if that is indeed where the problem is.
Thanks,
Ed
Ray,
I have removed the code that you suggested “|| os.status.program_busy” and compiled the FW. Can you send me info as to the best method to update the FW on the controller. I will be looking to install it on one of my 2.2 hardware devices. So I compiled it for this hardware.
Please let me know, I hope to do this tomorrow sometime.
Thanks,
Ed
Hi Ed, sorry about my delayed response. I am currently traveling in China and it has been a pain to access gmail and lots of websites without a reliable VPN.
I assume you have been able to compile the firmware code. I actually typically use arduino-make in conjunction with an Arduino 1.0.6 installation. arduino-make allows you to compile the code without launching the Arduino IDE which is often more convenient. Also, it compiles the code into the local directory as opposed to into a temporary folder that’s difficult to find. The Github repository also contains a Makefile which is directly usable with arduino-make (you do however need to open that Makefile and change directories to match your installation).
Anyways, to upload a firmware, if you have Arduino IDE installed (assuming this is how you compiled the firmware). You can go to menu Tools -> Board, select your corresponding OpenSprinkler version. Then Tools -> Port, select the serial port (typically there is one obvious option). Then click on the Upload button.
If you prefer to upload in command line (without Arduino IDE) you can do so using avrdude:
avrdude -c arduino -p m1284p -P COM? -b 115200 -U flash:w:xxx.hex
In Windows, the COM? is the COM port associated with the device (the same as in Arduino IDE, and you can also go to Window’s Device Manager to find out). In Linux and Mac, the serial port shows up as a device under /dev/tty???, for example, in Linux it may be /dev/ttyUSB0, and you can do ‘ls /dev/tty*’ to find out). xxx.hex is the name of the compiled firmware. -p m1284p indicates it’s ATmega1284p microcontroller (assuming OS 2.3). If you have OS 2.2, change it to m644p.
Ray,
I was able to update the firmware through the Arduino IDE. The command line would not work for me. I kept getting the following error:
avrdude -c arduino -p m1284p -P 4 -b 115200 -U flash:w:FW23-216C.hex
avrdude: can’t open config file “”: Invalid argument
avrdude: error reading system wide configuration file “”I would like to get this working but it appears the upload worked. The change appears to have fixed the not updating the weather when a program is running. I will update another controller and test. The 0% water level is still a problem which hopefully can be corrected soon.
Thanks,
Ed
Ray,
So I have made a few more modifications to the 2.16 FW. I changed it to check the weather every 15 minutes whether there is a program running or not. I also located the portion of the code that is settings the watering level. I know you said earlier that the problem may be in the script, however, I think it would be best to control that from the code and not the script. So once I retrain myself a little more on the code I will add to the if condition below to detect the uwt settings. If manual or California Restrictions are selected then it should not change the water percentage at all. Similiar != os.options[OPTION_WATER_ . This of course is found in the weather call procedure. However, I have not found the proper option for the uwt values yet.
if (v>=0 && v<=250 && v != os.options[OPTION_WATER_PERCENTAGE]) {
// only save if the value has changed
os.options[OPTION_WATER_PERCENTAGE] = v;
os.options_save();
}
}Ray,
Here is what I am going to change the weather call setting to. While I am not well versed in C and I don’t know of a way to compile this and debug it without just uploading hopefully it will work. The 130 represent the valua of uwt when California Settings are selected and I I set it for auto rain delay. I know the represent bits and I am sure this can be implemented for both manual and auto. However this will fulfill my needs for now. Hopefully when you get back from China we can look to implement this in to the main code to fix the bug.
As for the weather calls, I am now receiving them every 15 minutes even if a program is running. I may change this in the future, just figured I would try it out. We are expecting rain wed night so hopefully this will test out.
if (v>=0 && v<=250 && v != os.options[OPTION_WATER_PERCENTAGE] && os.options[OPTION_USE_WEATHER]<>130) {
// only save if the value has changed
os.options[OPTION_WATER_PERCENTAGE] = v;
os.options_save();
}
}@dun4cheap: the “avrdude: can’t open config file “”: Invalid argument” error you encountered is because it can’t find avrdude.conf. This depends on how you installed avrdude. If you installed it as a standalone program, it should have set the path to avrdude.conf automatically. On the other hand, if you are just running the avrdude program that’s included in Arduino’s installation folder, it can’t find the config file automatically. You will need to provide the path to avrdude.conf by using the -C parameter (following by the path of the config file, which exists in Arduino’s installation folder somewhere).
@dun4cheap: OK, I understand the changes you are making to the code. One quick question: is <> in ‘os.options[OPTION_USE_WEATHER]<>130′ a valid operator? I’ve never seen this. I think what you intend to use is != (not equal to), isn’t it?
Ray,
You are correct. The visual basic and basic context is <>, but the c context is !=. I compiled and uploaded the firmware last week with the != context. It seems to be working but I am waiting for a rain fall to see if it works. It is spritzing right now but not measurable enough to show measurable precipitation. The 15 minute weather calls seem to be running smooth as well.
Ed,
Do your changes include the a fix for the “California Restrictions, watering stays at 0%” problem?
Bill
William,
Yes it does. I have been testing since last week. However we have not had any rain. It has remained at 100%. I may change the location on one of my controllers to a location that is raining to see if it works. But looking over the code, it should work. That portion of the code is what ray was commenting on. Basically i added the check to see if auto rain delay was selected and california restrictions was selected then do not adjust the watering percentage.
The other change I made was to check the weather every 15 minutes regardless if a program was running or not.
Ed
So I changed my weather location to Washington where it was currently raining. The rain delay kicked in, the watering percentage remained at 100% and while my lights remained on. So it appears to have fixed the 0 watering percentage and my sprinklers did not turn on because of the rain delay.
OK, thanks for reporting. That’s very valuable information to know and will definitely help debugging. I took a look at the weather script:
https://github.com/OpenSprinkler/OpenSprinkler-Weather/blob/master/routes/weather.js#L422
and it’s indeed setting watering percentage to 0 if there is a rain condition (regardless of whether the weather adjustment method is set to Auto Rain Delay or not). This is probably related as it’s the only place I can think of that would affect watering percentage when rain condition is detected. However, in theory as the rain condition expires the watering percentage should recover to whatever it should be (and not forced to 0). So we will dig deeper to find out what’s causing watering percentage to get stuck at 0.
- You must be logged in to reply to this topic.