IndyMike

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

Depending on your location, many areas also specify foil backed foam panels between the garage and heated areas of the Home. I have this in my garage (Northern Indiana) and have powerline only in the garage as a result.

Hello swnewman, Glad to hear that the grass is doing well. With bermuda grass, you should be using a Kc of 0.6 (warm season grass). If you have the network module, you can periodically log data to the ISY in a comma delimited format (.CSV) that Excel can import. I've been logging data at 10 minute intervals (when I poll Weatherbug) for about 5 months now. File size is at 3 M. The notification file formats are located here: http://forum.universal-devices.com/viewtopic.php?f=25&t=10905&p=86231&hilit=network#p86231 Instructions for creating the output file are here (instructions are for an Elk file - use the formats in the link above): http://forum.universal-devices.com/viewtopic.php?f=51&t=11753&p=90748&hilit=network#p90821

Hello swnewman, First and foremost, you need to be running ISY V4.0.5. Earlier versions did have some issues with the date calculations. Beyond that, I've checked your weather site and your area. KHSV Weather Site: 1) Weatherbug appears to be reporting data accurately at this time. I have no way of determining if there were data losses in the past. 2) WeatherUnderground shows the site history from June to present. No indications of problems. Your Soil: 1) The soil map from UCdavis has your area listed as having "silt loam". That's as good as it gets for water retention: http://casoilresource.lawr.ucdavis.edu/soilweb_gmap/ 2) From the table below, your soil can hold 0.2 inches of water per inch of root depth. 3) If your grass has 6 inch root depth, your soil retention would be 1.2 inches of water. 4) The table recommends a maximum 50% depletion - you should irrigate when your ET exceeds 0.6". Field Capacity Table You have had a lot of rain this summer. I'm wondering if this hasn't changed your irrigation from what you would call "normal". The table below shows your historical Eto for your area. For irrigation, you need to compute Etc (crop evapotranspiration) for your specific plant type: [*:6hu1e1cs]Etc = Eto * Kc (where Kc is a crop coefficient). Use Kc = 0.8 for cool season grass and Kc=0.6 for warm season grass. [*:6hu1e1cs]For your hottest months you would normally get a Eto of .17" per day. Using a Kc of 0.8 would reduce this to 0.136" per day. [*:6hu1e1cs]From the field capacity table above we determined that you should water when you've depleted your soil water balance by 0.6". [*:6hu1e1cs]At a rate of 0.136" per day, you would need to irrigate every 4.4 days (about what you had figured). Local Data The plot below shows what I believe the ISY should be calculating based on actual data as reported by stations KHSV and KALMADIS16. As I mentioned above, you've had a lot of rain. [*:6hu1e1cs] The ISY calculated Eto for KHSV is running a bit higher than normal. I believe that this is because this station is reporting wind at the NOAA height of 10m rather than the NWS height of 2m. The station is reporting "average" windspeed of between 4 and 6 mph. That is very high and is causing the calculation to overstate Eto. [*:6hu1e1cs] The windspeed for that KALMADIS16 station (0 to .27 mph) is much more in-line and the calculated Eto is closer to historical values. [*:6hu1e1cs] The stations pretty much agree on the July rainfall (which was excessive), but differ on June and August. I don't have a good explanation for this other than topography in your area (you know this better than I). Even though the totals differ, the events occur on the same days. Running through the numbers, I believe the ISY should have scheduled irrigation between 3 and 4 times per month over that period. [*:6hu1e1cs] Answers to your questions: [*:6hu1e1cs]Eto is calculated at midnight. [*:6hu1e1cs]Rainfall is totaled at midnight and subtracted from the Irrigation required. [*:6hu1e1cs]Irrigation is subtracted from Irrigation required immediately when you execute the "irrigation complete" command Since both Eto and Rainfall are tabulated at midnight, it is possible for ET to be close to rainfall resulting in no change in the "irrigation required". It would be very odd for this to happen over a period of days. Based on the above data from stations nearby, I disagree that your lawn needs watering every three to four days. I'm basing this on many assumptions about your soil and grass, so I may be off. My questions: [*:6hu1e1cs]How does your grass look? Under watering can cause it to go dormant (not harmful). Over watering will kill grass - particularly with your humidity. [*:6hu1e1cs]What settings are you using in the irrigation panel (below)? [*:6hu1e1cs]Do you believe that the rainfall reported at either of the sites above is accurate for your area?

Backyard stations appear to be on line today (my area at least). I am still missing all but one of the local schools.

This seems to be a bit more than a simple loss of the backyard stations. Most of my local schools and businesses have disappeared as well. Currently, with a 40 mile radius, I have 2 NWS stations (airports) and 1 school showing up. Previously, there were at least 30 stations. Most of these were schools and businesses. For the time being, I would regard only the NWS stations as reliable.

Hello Jim, I have multiple programs that function properly as you have posted below. This should work. Today I tried constructing a program using dual band KPL's to see if there was an interaction. I could not come up with a configuration that would misbehave (the program always responded properly). From your post below, it appears that you actually deleted/re-installed your devices. That would eliminate the possibility of scene cleanup messages (i.e. the only responder was the PLM). My subject devices were older dual band KPL relays. They do not support "Group cleanup direct retries" as described by LeeG here: http://forum.universal-devices.com/viewtopic.php?p=89144#p89144 Your 2334 KPL's are very new. It is possible that they are sending additional communications to the PLM that are "re-triggering" your program to a false condition. I do not have any of these devices to test. As posted by Lee and ARW01: 1) Inspect the program summary tab. It is possible that the program is triggering true, then re-triggering false before the X10 command can be sent. 2) Please post a "level 3" event viewer log. I suspect that your 2334's are sending something that causes a re-trigger.

In addition to the above suggestions... If the triggering devices are Scene controllers, they will transmit device cleanup messages to the responders after the ON message. These cleanup message can interfere with the X10 transmission. If they are controllers, try a wait statement before your "X10 on " command. The duration of the wait may depend on the number of scene members.

LeeG has given you the most appropriate response - I agree with it. The motion sensor is a controller - the "control condition" is the most appropriate. I the ISY does not detect a control ON activity, it cannot (by definition) detect a status activity. Beyond that, the motion sensor is a two state device: 1) "Is on" = "Is not off" 2) "Is off" = "Is not on" 3) I don't think that "Is not responding" makes sense for a motion detector since it is a controller. The ISY only provides a response after it has already received a transmission from the motion sensor. Bottom line - use the example that Lee provided. Do not forget to provide both a subject and body in your email notification.