IndyMike

CPUJohn, The light% does appear to work for my site (KSBN - northern Indiana). This is the local airport which is a NWS/NOAA site. I will say that I believe that the data is "calculated" based on the time of day and reported cloud conditions. Neither the NWS, NOAA, or WeatherUnderground report light% for this site. I have other PWS sites that report actual solar radiation - they are far less granular and indicate rapid transients with passing clouds. Using a different site may resolve the issue (it can work). Understand that a different site may not be the best for local climate data. My use of KSBN is purely for data collection as it is 15 miles away. Today KSBN has received .21" of rain where I have 0". Balancing climate needs for irrigation against light% needs for scheduling may prove to be difficult. IM

Unless something has changed, light% is not used in the ET calculation. Daytime sun exposure is based on your lat/lon and month/day.

I've been seeing similar things with my local airport station (official WBS/NOAA station). Seem's to be linked to the HAM "rain in the past 6 hours" which can roll into the next day. The following is a comparison of Weather Underground reports VS HAM (ISY). The second and third tables are HAM reports from 7-14 and 7-15. The discrepancy between Weatherunderground and HAM seems to be due to a HAM rollover of 0.46" from the previous day. No explanation for the discrepancy on 7-14

Hello Waketech, The amount of water "deducted" from the irrigation required depends on the values you specified for "absorption factor" and "water applied per irrigation" In the expample below I specified 80% for absorption and .42" for water applied. When I execute the "irrigation complete" command, the ISY subtracts 0.336" (.42" X 0. from the irrigation required value.

johnnyt, That's the point I was trying to get you to. I guess I misunderstood what you were trying to accomplish. I thought you had link table mis-matches and were trying to correct using I1 messages. In my experience, I2 is actually more reliable in reading/writing the link tables. You are writing the tables 8x faster and are therefor less likely to have problems with transient noise (motors starting, etc). If you are trying to eliminate the multiple responses, I agree that disabling the dual band devices is a good approach. I do not see any doublet/triplet responses in my system. I have very few (3) dual band devices installed and have a hardwired coupler at the PLM. No clue if this has anything to do with my NOT seeing multiple responses. Other than slowing down the read process, I'm not sure that the duplicates harm anything.

Hello Johnnyt, Your V.36 KPL and IOLinc are being read in standard message mode (I1). Both of these devices are extended message capable (I2). You apparently have your ISY set to "Automatic" message mode where it selects what it believes is the most compatible mode (I1 or I2). This is what UDI recommends. You can "force" I2 communication by going to Link Management/advanced options and selecting "device reported" mode. The ISY should then use extended messaging (I2) during your link table reads. I have been using this since I2 came out - but it is not the recommended mode. This will speed the link table reads by 8X. It may not be compatible with your Icon switches (won't do any harm). The newer Icons have a smaller link table and may generate an error "Unexpected Response (i.e. DB range): ignored" when read using I2. Switching back to automatic mode will resolve this.

Mike, We have two different problems here: 1) CTRSH is transmitting temperature reliably - it is not resetting during the day. The problem is that it does not transmit rain data. It provides "N/A" in the rain data field. 2) I think you have uncovered a bug in the handling of the "N/A" response. The ISY is expecting numeric data and can't convert the text provided. As a result, I believe it is using the last valid data it received (From KAUN?). If you switch to KAUN (currently at 0.05") and switch back to CTRSH the KAUN value will be retained. Could you try switching to FRKSH? It does provide rain data and is currently registering 0.02 inches. On the subject of a wireless moisture sensor - I purchased a Toro Xtra Smart Soil Sensor last year http://www.amazon.com/Toro-53812-Smart-Moisture-Sensor/dp/B007J0M93U The sensor uses soil conductivity to "estimate" the water content. It uses two 4"(??) metal probes to measure the conductivity. In my mind, the probes should be at least 6". Battery powered, it transmits RF to a base unit and has decent range (I have it roughly 150' from the base). The base is basically a programmable switch that can be used to "inhibit" your irrigation system. I had the switch connected to a IOlinc so I could log it's activity and compare it with the ISY ET calculations (I used the ISY to control my system). I can't give you a good or bad review on the unit. We had so much rain last year, I rarely had to run my irrigation system. I did get the impression that the unit's probes would sometimes become "isolated" from the soil causing low readings. I don't have definitive data on this, and it could be due to my very sandy soil. Unfortunately, winter came quick and hard this year. I barely got my sprinkler system blown out before the first storm. The transmitter is still in the back yard buried under several feet of snow. If it survives, I'll give it some points for durability.

Unfortunately, the backyard stations appear to be offline as well. Weatherbug is in the process of migrating them to the cloud: http://www.wxforum.net/index.php?topic=21904.0

Hi Tim, I started monitoring KMYV after I saw your post. The Airports have been going haywire just after 16:00 your time daily. Today was no exception. The temperatures and rainfall on all three of the following stations reset at 16:15 your time. I actually checked ~ 15 NOAA stations from San Diego to Seattle. All of them reset after 16:00. I'm 2,100 miles away in Indiana. My Airport station (KSBN) is due to go down at 19:54 tonight (assuming the pattern is consistent).

Hello Mike, I've been monitoring 3 airports and 2 schools in your area. The feeds from the schools (CTRSH in particular) look good. The airport data is too screwed up to even comment on. High and low temps are being reset multiple times during the day. Using these values to calculate ET will be totally nonsensical. I've also monitored stations in my own area. Same result - the school feeds look good while the airports are totally out to lunch (one actually reverses it's time feed). I do not know when when this started. I was using my airport feed at times over the summer and this was not occurring. I captured the following data using an Excel program to call the Weatherbug API. It was totally independent of the ISY. Data from Weatherunderground shows the Airport sites as reliable. Good feed: 1) Low temperature hits a minimum and maintains until the midnight reset. 2) High temperature hits a maximum and maintains until the midnight reset. Bad Feed 1) Low temperature reset at 16:00 2) High and low temp track current temperature from 16:00 to midnight. 3) Midnight data captured by the ISY: High temp = Low Temp; Average temp is actually > High temp.

Mike, Weatherbug appears to be having problems with data from the Airport stations. The feeds from the local Schools and backyard stations (still verifying) appears good. Please try switching to a School in your area. I'll post some data this weekend.

ELA, I happened to be going through the HL2 release notes today. Revision 2.9.94 (released 5/3/2013) has the following note: • Increase "smarthops" hop count on retries Like you, I have theories on what this might include. Zero evidence to back up any theory.

I don not know what is causing the dropouts, but they appear to be occurring at a specific time. For the last 3 days Weatherbug has been dropping the KAUN precipitation to 0 around 16:00 Pacific Time. The same KAUN feed on Weatherunderground is intact.

Nope - I was. The times are my local times (Indiana-East). Somehow I made myself believe that the 20:12 reset was due to the midnight reset. Not even close. Weatherunderground data from the same station shows rain continued through midnight. Sorry, no good explanations from my end.

mbrossart, Glad you found your way through the Weatherbug setup. One additional request: Please increase to polling interval to 300 seconds (or greater). Using a 1 second poll results in a lot of needless communication and could be interpreted as a attempt to overload the Weatherbug server. I normally use a minimum of 10 minutes (600 seconds) for my polling interval. Many National Weather Sites (NWS) like airports only send updates at 30 or 60 minutes.

The rain didn't get reset - Weatherbug switched to another station that hadn't received any rain. When Weatherbug switched back to station KAUN the rain tabulation continued normally (no loss of data after it returned). As I explained, I do not know what causes Weatherbug to switch stations. I can say that when I use a local "backyard station", it does not switch.

Mike, Glad to hear there's no shaking going on there. I have relatives, friends, and co-workers spread all along the fault lines. I use the network module to log data to the ISY whenever there is a change in the weatherbug data. This comes in extremely handy for back-checking when things don't seem correct. The file itself is a comma separated text file (.csv) that I download directly to Excel.

Tim and Mike, I switched my ISY to log data from KUAN. A partial listing of the log is shown below. The yellow items are "anomalies": 1) Low temperature - should never increase during a given day 2) Light: Station suddenly began transmitting light data (more on this below). 3) Rain today: should never decrease during a given day. 4) Elevation - obviously should not change unless KAUN suddenly became mobile. Did I miss an earthquake in your area? The issue is Weatherbug switching stations in an attempt to provide a continuous data stream. I do not know the conditions that cause the switch. I suspect the station at 130' elevation is McClellen AFB in Sacramento. In short, I do not know how to prevent this other than finding a "very reliable station". Reliable is very misleading in this sense. The local airports in my area are not reliable in a Weatherbug sense. I believe they get overloaded with requests at some points and cause wetherbug to re-vector to an available station. I wound up switching to a backyard station a mile up the road. It's not NWS certified, but weatherbug has not switched away from this station in over 8 months. Note - times shown below are Eastern. Subtract 3 hours for your local time

teterb, The ISY/PLM cannot receive X10 RF. You will need to retain your X10 transceiver(s) (TM751, RR501, etc) to translate the X10 to the powerline. Once on the powerline, the ISY/PLM can receive and react through programs. Here's a brief description of the X10 module. It allows you to name your X10 devices and include them in the device tree. If you don't have the module, you can still write programs using X10 House/Unit codes. Without module: If X10 A1 On if Received Then Send X10 A5/On With module: A1 = Palmpad A5 = lamp If Status Palmpad is On Then Set Lamp on http://wiki.universal-devices.com/index.php?title=ISY-99i_Series_INSTEON:Enhanced_A10/X10 You can order the modules within the ISY administrative console once it is installed.

I bit of perspective is in order. I have a security switch on the door and an inductive sensor for deadbolt confirmation. With the Morning lock, I would only lock the door xx minutes after is was closed. If the door remained open for over yy minutes, the ELK would being making announcements. If it was open for over ZZ minutes, the ISY would begin sending Email notifications. Since the Schlage has no knowledge whether the door is open/closed, it will throw the bolt after 30 seconds in either case. I envision dinged woodwork etc, or a better half with mail/paper/etc and no free hands trying to punch in a code. Trying to explain why a lock that costs $80 more has less functionality (for now) is not a conversation that I'm looking forward to. My best bet is to explain things to my daughter and use her as an intermediary. If anyone reading this says "chicken$#!t" - I agree. Just looking to maintain the family harmony.

Thanks for the reply Gary, I do plan to use the re-lock feature until I get the Zwave network up and running. The 30 second re-lock does cause a problem - my better half goes out that door each morning to retrieve her paper. No way she can make the trip in under 30 seconds. Approval factor will take a dive until I can lock via Zwave.

After 4 years of faithful service, my Morning Industries lock has finally begun to give up. As noted above, the lock was installed on my garage entry which serves as the primary entry into the house. I would estimate that this lock was activated at least 20 times a day. It did not miss a beat (monitored by my ELK system) and functioned for over a year on a set of batteries. It's final undoing was likely due to an snow dam that occurred last winter during our 120+" of snowfall. I didn't catch the water that was overflowing the gutters and draining into the door. The icing sprung the door and took out the threshold - I had to replace the door, but re-used the lock until this past week. Diss-assembly revealed that the gear drive is worn and loosing time. Obvious signs of water intrusion - likely from my snow dam event. In short, I don't think this was the locks fault. Plan to replace with a Schlage BE469 deadbolt so I can have key compatibility with my other locks. Hope it does as well.

Mike, That is what I believe I am seeing in my ISY weather logs. Sorry - I had you mixed up with someone else and thought you were in Arizona. Don't understand why your "rain today" is resetting at 10:00 PM and mine appears to be resetting at 11:00 PM.

Tim, Thank you for confirming the calculations. I was sweating that one a bit...

Tim, The data below was pulled from WeatherUnderground. It shows what I believe the ISY should be calculating for the Month of November. The ISY should display one of the ETc values depending on which Kc you have selected. I have no way of telling whether the Weathbug feed from KBAB is operating properly. All I can say is that the WeatherUnderground data looks OK.