Michel Kohanim Posted March 15, 2013 Share Posted March 15, 2013 Hi Mike, Reset cannot be called except through programs. Do you happen to have any programs that call Reset? With kind regards, Michel Link to comment
JMC Posted March 22, 2013 Share Posted March 22, 2013 No programs use the Irrigation - Reset Variables command. I've checked all programs several times. Incidentally, last night at about 11:50PM Eto was 0.1033, Irrigation Requirement was 0 and Water Deficit Yesterday was -0.7647. At about 8:30AM this morning Eto was 0.1499, Irrigation Requirement was 0.1499 and Water Deficit Yesterday was 0.1499. I checked the log for the overnight period and saw nothing out of the ordinary. Needless to say that reset threw my irrigation schedule out the window for the next several days. mike Link to comment
JMC Posted March 25, 2013 Share Posted March 25, 2013 Following up on my Friday Mar 22 post: To compensate for the loss of rainfall data I ran the Irrigation - Cycle Complete command with my usage set at 0.25". That should have set Irrigation Required at -0.1001 0.1499 - 0.25). The next morning all three values were equal at 0.1388 as though the carryover value of Irrigation Requirement was 0 instead of -0.1001. I am using 3.3.10 and I don't remember this happening with either 3.3.6 or 3.3.8. However, that could be because it didn't rain during the time either of those two versions were installed. mike Link to comment
Michel Kohanim Posted March 25, 2013 Share Posted March 25, 2013 Hi Mike, Something is not making sense here since I cannot at all reproduce this issue. Are you sure you are consistently getting WB data? Can you please look at your Tools | Error Log and look for -14xxx errors for domains related to weatherbug? With kind regards, Michel Link to comment
JMC Posted March 25, 2013 Share Posted March 25, 2013 Hi Michel, There are many entries with 140000 and a few with 140002. Here is the most recent 24 hours: System -140000 datafeed.weatherbug.com Sun 2013/03/24 03:11:42 AM System -170001 [TCP-Conn] -1/-140002, CLI-WBug Sun 2013/03/24 11:59:40 AM System -140000 datafeed.weatherbug.com Sun 2013/03/24 12:56:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 01:02:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 01:48:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 01:53:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 02:19:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 03:48:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 04:19:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 04:24:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 04:31:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 04:32:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 04:50:39 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 05:05:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 05:08:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 05:10:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 05:20:39 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 05:21:39 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 05:22:39 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 05:25:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 05:32:39 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 05:36:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 05:41:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 05:45:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 05:46:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 05:49:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 05:52:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 05:54:41 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 05:58:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 06:03:45 PM System -140005 CLI-WBug Sun 2013/03/24 06:04:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 06:12:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 06:15:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 06:20:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 06:21:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 06:23:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 06:24:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 06:26:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 06:31:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 06:33:40 PM System -170001 [TCP-Conn] -1/-140002, CLI-WBug Sun 2013/03/24 06:37:39 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 06:45:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 07:02:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 07:22:39 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 07:35:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 07:50:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 08:00:39 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 08:01:39 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 08:14:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 08:15:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 09:21:40 PM System -140000 datafeed.weatherbug.com Sun 2013/03/24 11:49:33 PM System -140000 datafeed.weatherbug.com Mon 2013/03/25 12:11:32 AM System -140005 CLI-WBug Mon 2013/03/25 12:39:33 AM System -140000 datafeed.weatherbug.com Mon 2013/03/25 03:00:33 AM System -140000 datafeed.weatherbug.com Mon 2013/03/25 03:48:33 AM System -170001 [TCP-Conn] -1/-140002, CLI-WBug Mon 2013/03/25 06:35:32 AM System -170001 [TCP-Conn] -1/-140002, CLI-WBug Mon 2013/03/25 07:04:34 AM System -140000 datafeed.weatherbug.com Mon 2013/03/25 07:34:33 AM System -140000 datafeed.weatherbug.com Mon 2013/03/25 07:40:33 AM System -140000 datafeed.weatherbug.com Mon 2013/03/25 07:55:32 AM System -140000 datafeed.weatherbug.com Mon 2013/03/25 08:05:35 AM System -170001 [TCP-Conn] -1/-140002, CLI-WBug Mon 2013/03/25 08:25:33 AM System -140000 datafeed.weatherbug.com Incidentally, Since all values were non-zero yesterday, today's values are exactly what I would expect: Eto = 0.1584 Irrigation Requirement = 0.2973 Water Deficit Yesterday = 0.1584. I'm going to give the system .5" of water today, which should take the Irrigation Requirement negative. We'll see what tomorrow's values look like. mike Link to comment
Michel Kohanim Posted March 25, 2013 Share Posted March 25, 2013 Hi Mike, Those errors explain everything. ISY is not being updated with information from WB consistently. So, the first thing I would do is to figure out why ISY has such problems getting out to the Internet. Things to check: if you have static IP address, please change it to DHCP and see whether or not there are any improvements. If your ISY is connected to the router through a switch, try connecting it directly to the router. With kind regards, Michel Link to comment
JMC Posted March 26, 2013 Share Posted March 26, 2013 First, the ISY is using DHCP to get it its IP. It is connecting to the router via a switch and traffic across that switch can be heavy at times with up to 5 HD video streams present at any one time. However, all other devices appear to be accessing the internet normally. I'll check to see what it will take to make a direct connection to the router. While the ISY does appear to be getting data updates from WB. Temp, humidity, wind and rain data all appear to be consistent with existing weather conditions. Eto at 0.1547 this morning is consistent with what I would expect given our current weather. Water Deficit Yesterday is also 0.1547 and that is consistent with there having been zero rainfall. I gave the system 0.5" of water yesterday as I said I would. Using yesterday's Irrigation Requirement of 0.2973 my hand calculation shows that today's Irrigation Requirement should be 0.2973 - 0.5 + 0.1547 = -.0314. However, today's Irrigation Requirement is being shown as 0.1547, just as though yesterday's negative value had been discarded. mike Link to comment
LeeG Posted March 26, 2013 Share Posted March 26, 2013 JMC Michel indicated in another topic he would be gone until Thursday. A few pages back was it not established that "You cannot have a negative number for the amount of water" so a calculation that drives Irrigation Requirement to a negative value would not exist. The "0.2973 - 0.5" results in a negative number for Irrigation Requirement which would seem to reset it to 0. To that add "+ 0.1547" and the Irrigation Requirement would be 0.1547. Obviously I don't have access to the internal code used to calculate the value so this may be junk science requiring Michel's return to clarify. Link to comment
JMC Posted March 26, 2013 Share Posted March 26, 2013 Follow up: I have a spare Cat 5 connection between the garage where the ISY is and the room where I keep the router so the direct connect was a simple matter. I'll check the error log later today and see what is there. mike Link to comment
JMC Posted March 26, 2013 Share Posted March 26, 2013 Lee, My understanding is that while Irrigation Requirement will not display a value less than zero, the actual value is stored for calculations. If that were not true then the amount of any rainfall or water application which exceeds the existing Irrigation Requirement would be lost. For example, this time of year in my area the typical Eto is less than 0.25" per day but rainfall exceeding 2" in one day is not uncommon. Those two would result in an Irrigation Requirement of -1.75" and if that value were not retained for future day's calculations, irrigation could be called for only a day following the heavy rainfall. The same would apply following a very heavy application of water. If that is the case then the value of the irrigation module is decreased significantly. mike Link to comment
LeeG Posted March 26, 2013 Share Posted March 26, 2013 Had not considered an Irrigation Requirement value would be held internally that did not match the displayed value. Link to comment
Michel Kohanim Posted March 28, 2013 Share Posted March 28, 2013 Hi Mike, Actually LeeG is 100% correct: the value can never be negative not even internally. If negative, it's immediately set back to zero. With kind regards, Michel Link to comment
JMC Posted March 29, 2013 Share Posted March 29, 2013 That being the case the value of the irrigation module is diminished to the point where it doesn't make any sense to even use it. For example: Take a starting condition where Eto = 0.1 Irrigation Requirement = 0.1 Water Deficit Yesterday = -1.9 (2: of rainfall) On the following day Irrigation Requirement will be 0. Using Et0 = .4 with no further rain the day after that will have an Irrigation Requirement = .4 which will probably trigger the irrigation system to apply more water less than 48 hours after a 2" rain, wasting a lot of water and risking damage to the plants being irrigated. If, however, a negative value is permitted for Irrigation Requirement then if Eto remains at about 0.4 it will be the 5th day following the rain before the irrigation system will apply more water, and that is about the actual need. mike Link to comment
Michel Kohanim Posted March 29, 2013 Share Posted March 29, 2013 Hi Mike, Here's the code and I let you decide whether or not it meets your requirements: waterDeficitYesterday = etoYesterday-(rainToday*absorptionFactor); irrigationRequirement += waterDeficitYesterday; if (irrigationRequirement irrigationRequirement = 0.00; I am not at all certain that a negative irrigation requirement makes any sense. In all cases: 1. You have networking issues that have to be resolved 2. If this module does not meet your requirements, we'd be delighted to deactivate it and give you a full refund With kind regards, Michel Link to comment
JMC Posted March 29, 2013 Share Posted March 29, 2013 A negative Irrigation Requirement is important for the module to eliminate the effect of a very heavy rainfall, which will take many days during which no irrigation is wanted. By resetting Irrigation Requirement to 0 when it is negative effectively discards previous days rainfall and allows irrigation to be called for long before it is actually needed. I can work around the problem in my programs by simply avoiding the Irrigation - Cycle Complete statement until Irrigation Requirement reaches 12" or so. Then there won't be any danger of having rainfall data discarded and is what I will probably do. On the networking issue: Can you provide me with the full meanings of the -140000 and -100 error codes? mike Link to comment
G W Posted March 29, 2013 Share Posted March 29, 2013 'Ang about. It seems to me that Irrigation Requirement is calculated everyday, so it's not the Irrigation Requirement that needs to be saved. It's the values needed to calculate that number. The important value is etoYesterday. So, how is etoYesterday calculated AND how and where is it stored? Link to comment
Michel Kohanim Posted March 29, 2013 Share Posted March 29, 2013 Mike, 12 inches of rain yesterday does not equal to 12 inches of water UNLESS your absorption factor is 100%. Here's the link to the list of errors: http://wiki.universal-devices.com/index ... r_Messages The main problem seems to be that ISY has a hard time getting out to the Internet. Gary, etoYesterday is calculated based on Evapotranspiration Algorithm developed by UN. With kind regards, Michel Link to comment
JMC Posted March 30, 2013 Share Posted March 30, 2013 12 inches of rain yesterday may not equal 12 inches of water but it is much closer than 0. In any event I can resolve the issue by simply inserting an offset into the Irrigation Requirement value and then accounting for it in my programs. I noticed that one of my error messages, -100 is not in the list you referenced. As far as the DNS problem (-140000) I can only offer that at any given time there could be 5 to 8 different devices on my network accessing the internet and none of the others reports any problem. Incidentally, I did move the ISY to a direct connect to the router instead of through the switch as before. It didn't seem to make any difference. Link to comment
IndyMike Posted March 30, 2013 Share Posted March 30, 2013 ARRRGH - 3 hours into a post and I just watched it vanish. Lesson (re-)learned: write post local and copy/paste to the forum! Here's the short version: I assisted Michel in checking out the ETo calculation. I believe it's accurate within +/- 7% over a month. It will vary more per day but we're talking about errors on the order of 0.05 inches. The calculation relies on elevation high/low temperature, and averages of current temp, wind speed, and dewpoint. This is a classic example of Garbage in = Garbage out. 1) If you have a unreliable WB connection, your averages will be incorrect. If the "gaps" in data are large enough, the errors can be significant. 2) If you have a very unreliable WB connection, your Min/Max temperatures and rainfall may be incorrect. This will lead to large errors. 3) You need to pick a RELIABLE WB station. Temperatures are typically very reliable. Windspeed and dewpoint are placement/maintenance sensitive. Reliability is more important than proximity. You can compensate for offsets (constant differences) between your local location and the WB station. Nothing can compensate for poor station placement or maintenance issues. 4) NWS stations (airports) are typically well maintained. Unfortunately, they do not normally report rain data and report wind speed at a higher elevation. While not good candidates for WB data, they are a good source for assessing whether your local WB site is giving accurate wind/dewpoint data. 5) WB has a nasty habit of "automatically switching stations" if your selected station is having reporting problems. This isn't a big deal in Indiana where the elevation changes 200' over the course of miles. Out West, where little things like Mountains come into the equation, a station change could move you from a valley to Pikes Peak. I don't have a good solution for this problem - other than selecting a RELIABLE station. I did not address the issue of Irrigation Required or retention of negative values. In hindsight, I can see where this would be required for rain events that far exceed the typical ETo. Unfortunately, I don't believe that it's as simple as retaining a negative irrigation required variable: 1) The soil absorption factor is a linear approximation that is applied over a "normal" range of rainfall. 2) Soils are not linear - after hitting saturation, 100% of the rainfall will result in run-off. Short of running a percolation test (required in my area with septic systems), I do not know how to quantify soil absorption/saturation. Asking users to run a percolation test would seem to be a bit extreme. If anyone has access to data that could be used to characterize regional soil characteristics, please chime in. IM Link to comment
Michel Kohanim Posted March 31, 2013 Share Posted March 31, 2013 Hi IM, Thanks so very much for your thorough response. Indeed quite appreciated. JMC, I am not sure what to say about DNS errors. All I can say is that if you have Cisco/Linksys, Juniper, or any flavor of DD-WRT, please reboot your router and see if that helps. If not, you might want to configure ISY with a static IP address and then use either of the following DNSs: 8.8.4.4 8.8.8.8 With kind regards, Michel Link to comment
JMC Posted March 31, 2013 Share Posted March 31, 2013 IndyMike, The station I use (KAUN) is a NWS airport station that started reporting rainfall data about a year ago. So far the reported rainfall has been tracking actual conditions very well. I'm really reluctant to change from it because of one of the factors you mentioned, elevation. I'm at least 1,000' higher than any nearby station except KAUN, which is about 400' higher than where I am. I'm not concerned with the ETo calculation, I'm totally ignorant in that area. The discarding of rainfall data that should (in my mind) drive Irrigation Requirement negative is a problem though. I've checked the soil with a soil moisture tester numerous times and following a heavy rain the system wants to start irrigation again in a day or so while the soil moisture is still off-scale (mud). I've inserted an offset into my programs by not calling for irrigation until Irrigation Requirement exceeds 10.3". That should allow the system to delay restarting irrigation too soon. I'll be using the soil moisture test regularly and make adjustments accordingly. Michel, my router is a Motorola combination cable modem/router in a single device. the ISY now connects directly to it without going through the switch. I've rebooted it twice in the last couple of days with no change. We'll see what the offset in my programs does. mike Link to comment
arw01 Posted March 31, 2013 Share Posted March 31, 2013 Just a wild eyed stab in the dark here. I had two of those Motorola units and when I went to a voice over ip with the carrier got a Arris unit. I had trouble with all three dropping connections, needing to be reset etc. Not exactly your problem, however, even after THREE techs had come out over the last couple of years, it took the fourth one to figure out the connection to the box on their side has been loose since day one! Donkeys that were there before never checked obviously. The last fellow even felt the strength was a bit low with that fix (technically in their acceptable range) and climbed the pole. The squirrells had been chewing the cable for some time, so we gave me a new drop. ALL my issues went away. Now the only issue I have is the router/modem does not dole out DHCP if the devices are not on or connected with some window of time. E.g. if friend brings an ipod over and wants to use internet on the wifi, I have to reset the router to get it to let them connect. It is kinda a pain when the wife's phone is off and I do a reset for something, have to run around and bring all the wireless devices online first, then reset. But the moral of the story, is do not discount the improbable when chasing this stuff down. See if you can ping your ISY when you have troubles. Link to comment
IndyMike Posted March 31, 2013 Share Posted March 31, 2013 IndyMike, The station I use (KAUN) is a NWS airport station that started reporting rainfall data about a year ago. So far the reported rainfall has been tracking actual conditions very well. I'm really reluctant to change from it because of one of the factors you mentioned, elevation. I'm at least 1,000' higher than any nearby station except KAUN, which is about 400' higher than where I am. I'm not concerned with the ETo calculation, I'm totally ignorant in that area. The discarding of rainfall data that should (in my mind) drive Irrigation Requirement negative is a problem though. I've checked the soil with a soil moisture tester numerous times and following a heavy rain the system wants to start irrigation again in a day or so while the soil moisture is still off-scale (mud). I've inserted an offset into my programs by not calling for irrigation until Irrigation Requirement exceeds 10.3". That should allow the system to delay restarting irrigation too soon. I'll be using the soil moisture test regularly and make adjustments accordingly. Michel, my router is a Motorola combination cable modem/router in a single device. the ISY now connects directly to it without going through the switch. I've rebooted it twice in the last couple of days with no change. We'll see what the offset in my programs does. mike Mike, I found your station and downloaded the observations for the month of March. I do agree that there should be some method of retaining the rainfall information. Note that your NWS site appears to report at 30 minute intervals. Based on your error log, you are requesting data from weatherbug at a much faster rate (not sure what that is). I believe I remember one of the UDI team posting that over-polling weatherbug sites could be interpreted as a Denial Of Service attack and could result in errors. Regardless, you should be able to back your polling way down - it's not buying you anything. I am currently monitoring the NWS station at 10 minute intervals as a test. I'll let you know if I encounter errors. The 1st chart below shows the ISY calculated ETo and Irrigation required (both as calculated and with retention of rainfall). You've had two rather significant rainfalls (on 3/6 and 3/20) and are in the process of getting more rain today. Sorry for the crappy weather. The second chart predicts Irrigation based on: 1) 100% Soil absorption 2) 0.5" water applied per cycle 3) Both current calculated Irrigation Requirement and Irrigation requirement with Rainfall retention (negative values). As shown, the current ISY calculation (not retaining negative Irrigation) would have resulted in 5 cycles of your irrigation system. If the ISY had retained the negative values, the system would have cycled 3 times (one inch less water applied). With all of the above said, I still do not understand your numbers: 1) You stated that you've applied a 10.5" water offset to keep your system from cycling. I don't understand this - your total calculated Irrigation requirement for March should not have exceeded 1.2". Is it possible that you are using metric values (mm)? 2) I'm having problems understanding why your system would cycle every day or so. Please post back your settings: 1) Irrigation Region 2) Soil absorption (100%, 90%, etc) 3) Water applied/cycle 4) Allowable depletion 5) What you are actually watering (Grass, flower beds, etc). IM Link to comment
JMC Posted March 31, 2013 Share Posted March 31, 2013 IndyMike, Hopefully the KUAN in your charts is a type, my station is KAUN. Thanks very much for the polling interval info, my system was polling on 60 second intervals and I reset it to 1800 seconds (30 minutes). Hopefully that will help the DNS issue. I'm using the following settings: Irrigation Region: Best Guess Absorption Factor/Soil Type: 83%/Loam Sand Water Applied per Irrigation Cycle: 0.25" Allowable Depletion: 0.0208" (calculated by ISY) Grass is being watered. I know the soil type is wrong but it seems to work best for me. My actual soil type is 6-8" of highly absorbent top soil on top of lava cap. I set the small amount of water applied because it is about the maximum I can apply before runoff. The offset I mentioned was an error, the actual offset is 7" and it is purely arbitrary. My irrigation program looks at 7" the same way it looks at 0" without the offset. Basically I'm trying to achieve the performance pattern in your 2nd (ISY Calculated Irrigation) chart's red line and avoid the green line. It appears to me that the offset will do the trick but time will tell. The early morning program looks for Irrigation Requirement > 7.45" and applies 0.25" of water if the condition is satisfied. The evening program looks for Irrigation Requirement > 7.3" and applies another 0.25" of water if the condition is satisfied. This arrangement allows up to 0.5" of water to be applied in a 24 hour period and also avoid the runoff problem associated with the lava cap if the 0.5" were applied at one time. mike Link to comment
IndyMike Posted April 1, 2013 Share Posted April 1, 2013 Hello Mike, The station name was a typo. I'm monitoring KAUN. I've updated the charts based on your settings. I know the soil type is wrong but it seems to work best for me. My actual soil type is 6-8" of highly absorbent top soil on top of lava cap. I set the small amount of water applied because it is about the maximum I can apply before runoff. I have to admit that your soil structure has me a bit mystified. I have no idea what a "lava cap" is. "Highly absorbent" and "runoff" don't normally go together unless you are applying water at a very high rate. From your description, this sounds like soil that is 100% absorbent but quickly hits a saturation limit. I don't know how to model that - yet. Questions: 1) What type sprinkler heads are you using (spray, rotors, etc)? 2) Have you measured the application rate? Observations: 1) If you are able to saturate your soil with the sprinkler system, the same will be happening (probably to a greater extent) when your receiving your 1" of rainfall. 2) The above being the case, retaining the full value of 1" "rain today" is completely incorrect. Most of this would be lost to runoff after the soil becomes saturated. The offset I mentioned was an error, the actual offset is 7" and it is purely arbitrary. My irrigation program looks at 7" the same way it looks at 0" without the offset. Basically I'm trying to achieve the performance pattern in your 2nd (ISY Calculated Irrigation) chart's red line and avoid the green line. It appears to me that the offset will do the trick but time will tell. The early morning program looks for Irrigation Requirement > 7.45" and applies 0.25" of water if the condition is satisfied. The evening program looks for Irrigation Requirement > 7.3" and applies another 0.25" of water if the condition is satisfied. This arrangement allows up to 0.5" of water to be applied in a 24 hour period and also avoid the runoff problem associated with the lava cap if the 0.5" were applied at one time. I still do not understand the 7" offset. If I add the total ETo for the month of march (disregarding rain) I get about 3". In other words, your system should never have approached the 7" offset. If this number is correct, something is very wrong. I have my ISY set to monitor your KAUN site using the numbers you posted. If you could collect numbers over the next few days we can compare to see if you are somehow getting corrupted data. The easiest way to pull your data is to use the REST interface via your browser: 192.168.XXX.XXX/rest/climate. Save the XML file and we can compare notes. IM Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.