IndyMike

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.

Hi Mike, My logs are showing that as well: 1) 10:00 PM 0.5" rain. 2) 11:00 PM 0 rain. 3) 12:01 PM Irrigation required calculated for 0 rainfall. Still not sure whether this is the ISY or Weatherbug.

Hello Mike, Good catch. I just checked my ISY logs and my Rain_today value appears to be setting around 11:00 PM. This appears to have kicked in after the time change on Nov 3. Odd thing is - 1) You didn't change times in AZ. 2) I believe the ISY reports the Rain_today value directly as reported by Weatherbug. This may be a Weatherbug issue. If you are getting rain, and have the opportunity, could you check the actual Weatherbug site to see what it is reporting after 10 PM?

Hello Charles, Both PLM's and ISY's should be able to send and receive X10. There is no specific linking in the X10 protocol as there is in Insteon. If the signal is placed on the powerline, all receivers should be able to detect it, assuming there isn't absorption or noise. If ISY#1 does not have the X10 module installed, you will not be able to "name" X10 units or track their status. The ISY will still be able to detect and act on Raw X10 signals. You should be able to communicate between systems using X10. Check your "Event Viewer" to make sure you are not receiving X10 between the ISY's. If not, you likely have a powerline issue. I have multiple Insteon PLM's and X10 Controllers in my home. All can send/receive X10. That said, I do take great pain in keeping X10 off the powerline (mostly RF) because it is sooo SLOW. If there is a network module solution that would accomplish the same task, I would recommend that instead. Unfortunately, I'm network module "challenged" and can't offer a solution.

Hello zorax2, Before investing in a truckload of filterlincs, I would suggest focusing on the Scene Test itself. The Scene Test can be a powerful tool, but it can also be tripped up and give misleading results. Performing a scene test of 42 devices increases the likelihood that external communications will interfere and cause a scene test failure. What the scene test does: 1) ISY executes a Group "fast on" command for your selected scene. Unfortunately, the ISY will quickly reset the event viewer window (2 seconds) and overwrite this command. I managed to grab a screen capture of one of my smaller scene tests this morning. The first line below is the ISY instructing the PLM to issue a "Group fast on" to group x27. The 5th line is a question mark - I had no clue this was occurring. The ISY is issuing a second "Group fast on" command to group x30. In short, I think this in incorrect (i.e. I have an issue with this scene). 2) ISY executes a All link "fast off" command for the selected scene. The following is the all link command for my group 27 scene. Sun 09/22/2013 10:19:18 : [GRP-RX ] 02 61 27 13 00 06 3) The PLM interrogates all the scene responders. When complete, the PLM will respond with a "Clean up Report" of the results. A "06" in the last position indicates success. A "15" indicates that the polling was interrupted. Any activity will cause the PLM to abort the polling process (motion sensors, wired transmitters, X10 devices, programs, ELK commands). In short, the difficulty in successfully completing a scene test increases quickly for a large scene. I intentionally interrupted the Poll below by pressing the "ON" button of a KPL during the poll process. Sun 09/22/2013 10:28:19 : [std-Cleanup Ack] 19.46.CE-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Sun 09/22/2013 10:28:19 : [CLEAN-UP-RPT] 02 58 15 ----- SC BSMT Test Results ----- [Failed] BSMT Bed (14 78 3B 1) [Failed] BSMT Video Cans (17 F7 B6 1) [Failed] BSMT Fam Cans (1A 4F 19 1) [Failed] Master KPL G - BSMT (A E5 EC 7) [Failed] Christmas Tree (13 A 51 1) [Failed] BSMT KPL Game (F FF F1 1) [succeeded] Master Table KPL G - BSMT (19 46 CE 7) [Failed] BSMT Stair (1A 5D 6D 1) ----- SC BSMT Test Results ----- Sun 09/22/2013 10:28:25 : [iNST-TX-I1 ] 02 62 00 00 27 CF 13 00 Sun 09/22/2013 10:28:25 : [iNST-ACK ] 02 62 00.00.27 CF 13 00 06 LTOFFRR(00) How to make the Scene Test (more) reliable: [*:2cndqvnb]As the test indicates, you must disable programs. Any program that is initiated by a change in device status WILL interrupt the PLM polling. I've created a "conditional" folder with a variable for enabling/disabling programs. Set the variable, and the folder (and all programs) are off. [*:2cndqvnb]Pending updates to devices - If you have devices with pending updates (green arrow), the updates will initiate during the scene test (causing it to fail). Disable automatic updates or (better) resolve the pending updates. [*:2cndqvnb]Motion sensors, IOlincs, Devices with load sensing (etc.) are a problem. No good way to disable these. The network must be quiet during the test or the PLM will abort. [*:2cndqvnb]Use smaller, Logical scenes - less chance of interruption during the test. [*:2cndqvnb]Always watch the PLM status response. A 15 indicates that the PLM was interrupted. Sun 09/22/2013 10:28:19 : [CLEAN-UP-RPT] 02 58 15