IndyMike

Chuck, Thanks for being patient with me. I see now that you were saying exactly that. I get a mental block when I see the reference to the "AC-RF2". I keep thinking powerline interface rather than software plug-in. I'd love to say that I'm normally not this thick, but then my Family would begin lining up to disagree...

Rich, Your DS10a's shouldn't be a problem (not that much activity). Whether your MS will present a problem depends on their activity level. I had four sensors in my Kitchen/dinette and they would overwhelm the powerline at times. On a different tack, I just downloaded Bob's latest Beta of the Homeseer ISY plug-in. According to the documentation, you should have two way communication with the ISY. Would it be possible to trigger off the security sensor and launch a Insteon command via the plug-in?

Chuck, No worries! You're simply trying to help a fellow ISY user which is commendable. You're experience with Homeseer makes you far better suited than I. IM

Rich, I'm way out of date on Homeseer. I demoed it years ago before the ISY was available. From what I remember, you can set up an event that triggers off the RF receive and transmits a standard X10 command via the powerline. There's a nice Hometoys article on how the V572RF32 performs it's mapping - Article Link: V572RF32 I haven't had problems with my X10 coexisting with Insteon but I've taken precautions not to allow motion sensors to access the powerline (i.e. I don't use a RR501 or similar transceiver anymore). Unfortunately the X10 motion sensors will transmit every time they sense motion. In a high activity area this can add up to a lot of powerline activity. From the standpoint of powerline activity, interfacing the W800 directly to the ISY would be far superior. My comments regarding your using Homeseer were intended to give you an idea of how the system would work before spending your hard earned cash.

Hello Chuck, I'm sorry, but I don't believe the X10 Security devices transmit at 433MHz. As you noted the carrier frequency for the USA is 310MHz. This includes the security devices. Both the WGL W800RF32 and the X10 CM15a (which can receive Security transmissions) operate at 310MHz. The issue here is that the X10 security devices use X10 extended code protocol and there are not a lot of receivers that understand it. Furthermore, the Smarthome powerline interfaces cannot decode or transmit X10 extended code protocols. Smarthome uses an older form of the X10 standard that does not include extended codes. If you want to "inform" the ISY of incoming security traffic from the W800, the straight forward method would be to mimic the V572RF32 - Use Homeseer to map the security data to a standard X10 address and transmit a standard X10 on/off to the ISY via the powerline.

Rich, From the screenshot that you provided earlier, Homeseer is monitoring both X10 RF and Insteon communications. Don't you already have a Powerlinc connected to the PC? If so, can't Homeseer be configured to relay the X10 RF communications through the Powerlinc? This wouldn't give you the stand alone configuration you desire, but it would allow you to play with the ISY X10 interface. IM

RichTJ99, You had asked for opinions on the V572a. Well, it's pretty much the Cadillac of the transceiver lineup, but you probably already know that since you use the W800. Other options include: 1) X10 TM751: Can receive on one house code (16 Unit codes). Decent range, built in relay (loud). Unfortunately, this device does not have a powerline receiver. It hears RF, and then transmits on the powerline. Without a transceiver, the device can't sample the powerline for existing activity before it transmits (it's known for stepping on other transmissions). Cost:$6 on ebay 2) X10 RR501: Similar to the TM751 only this unit has a powerline receiver and therefore doesn't step on other transmissions (Collision avoidance). Physically large, good range, built in relay (loud). Cost: $8 on ebay. 3) Leviton HCPRF: Can receive all house codes (similar to the V572). Decent range, built in outlet control (quiet), X10 2-way device (can be polled for status), physically small, includes collision avoidance. Device includes Levitons' Intellisense AGC (very nice and reliable). Cost: $39 on Smarthome. 4) WGL V572RF32: Similar to the V572, but this device can receive 32 bit RF security codes and translate them to a standard X10 house/unit code. Used with DS10a/MS10a RF security devices. Cost ~$100 HNUSA. That's pretty much the waterfront. You can start simple (RR501) and gain experience with integrating your X10 with the ISY or go all out with the V572. A few additional words on the "collision avoidance" feature - This feature allows devices to test the powerline for an existing X10 transmission prior to starting it's own transmission. I do not know if they can recognize an Insteon transmission as valid data. It's very possible that X10 devices will see Insteon traffic as noise and the collision avoidance will be inoperative. That said, I have a number of X10 motion activated switches and flood lamps and have not seen a degradation in my Insteon communications. IM

Sorry Illusion, I hadn't seen your last post indicating you were using night only operation. I am a bit curious about the excessive number of dusk/dawn indications you're getting. I just looked at my log for the motion sensors - 4 sensors are averaging 10 reports a day (1 on/1 off per sensor) over the past month. I looked at the dusk reporting on the sensors some time ago. It turns out the dusk reporting period varies with the sensor motion timeout. Said differently, if your sensor is programmed to send an off command 2 minutes after motion has ceased, the dusk/dawn period will be 2 minutes + 3 minutes 30 seconds. By setting the dusk/dawn sense period wider than the motion timeout the sensor avoids being fooled by local lighting that may have turned on when the motion was sensed. From your description, your sensors are behaving very differently than mine. IM

Illusion, The ISY gives you the ability to set the darkness sensitivity (options tab at the bottom of the device window). This is typically set at 35%. Presumably, adjusting to 0 would reduce the number of reports the 2420 gives (don't know if it would actually disable the feature).

Sorry folks, but the above appears to have been a waste of time. I had intended to put an older battery in one of the 2420's to monitor the decay and note when the low battery/looping kicked in. The battery I chose measured 6.8V in circuit. This produced a number of differences from the power supply test posted above. 1) The 2420m diagnosed the 6.8V battery as "low" by indicating two led flashes during activity. It did this with two of my detectors. 2) The sensor did not enter the "looping mode" as it did when I operated from the power supply. 3) The sensor did not communicate the low battery status to the ISY. In contrast, when operating from the power supply the 2420 would run down to ~ 4.25V before flagging a low battery. I imagine there is a significant difference in the source impedance of my power supply VS the 9V battery. Since the battery impedance will increase as the cells discharge, it's not an easy thing to simulate. The 2420 is apparently keying off this and flagging the battery as low. Back to the drawing board...

Update (6/27/09): the following tests were conducted using a linear power supply input to the 2420m. I have found that they do not represent operation with a 9V battery source. Refer to the following post for 9V source information. Manged to dig out my power supply and find some time to play. Setup: Two 2420M motion sensors, V1.1 Timeout: 0.5 Minutes Led Brightness: 100 Darkness Sensitivity: 35 Notes: 1)The motion sensors have a fair amount of storage capacity. When changing voltages, it's necessary to wait around a minute for the internal voltages to settle out. 2)Per the manual, the sensors will "double flash" then led when the battery is low. The good news - Both of my units worked flawlessly over a voltage range of 4.5 to 9V. This include linking and setting options. The results: 1) At around 4.25 volts, both units would begin to indicate a low voltage condition with a double flash. This double flash repeats at intervals equivalent to the timeout period. What I did not expect, was that the sensor also sends out on/off communications during this period. With my units programmed for a 0.5 minute timeout, the sensor would indicate on for 30 seconds, cycle off for ~ 1 second and then back on. For anyone who has had their lights cycle on/off repeatedly when linked to a 2420m, this is the culprit - the low battery indication. Really not good. Neither of my units communicated the "low battery indication" at this point. 2) Between 4 Volts and 3.25 volts we have somewhat of a race condition. Communication with the Accesspoint is beginning to degrade (comm errors popping up). Below 3.25 volts communication was off line. Out of 10 trials, I received one low battery communication during this section. 3) Reducing the supply voltage to 3 volts will latch the low battery communication flag in the sensor (not the ISY). Unfortunately, the sensor can't communicate this fact back to the ISY since the communication went off line at 3.25 volts. 4) Increasing the Voltage back to 5 Volts allows the sensor to communicate the "low battery indication" back to the ISY. This works 100% of the time. 5) Increasing the Voltage back to 9 Volts does not reset the low voltage indication. The unit will continue to double flash until the supply is cycled. The supply must be off for around a minute to allow the unit to discharge completely. 6) After power cycling to clear the low battery fault, the sensor does not communicate a "healthy battery" indication to the ISY. The only way that I have found to clear the "low battery ON" indication in the ISY is to delete the sensor and add it back in. We really could use a query or at least a manual override here. Well, that's it in a nutshell. For right now, I'm trying to figure a way to program around the potential "cycling light phenomena". If this were to happen in my better half's kitchen, I'm not sure I would survive the aftermath. IM

Hello to_lighter, When you issue the "Set Scene "Main floor Font Motion-50%" you are modifying the status of your condition "Main Entrance door posts". This causes all of the program conditions to be re-evaluated. Your "Main Entrance door posts" status is still true but you not longer have a "Control" event from the motion sensor. The conditions will therefor evaluate to "false" and the program terminates. You can get around this by moving the status check into a conditional folder and placing your current program in that folder. When the status condition for your door posts is true the folder will be enabled. By doing this you can modify the status of the door posts without creating an event that causes the program to be re-evaluated. To be honest, I haven't messed with conditional folders in over a year. I generated the following to make sure this would work. This is based on the various examples of the programming Maestro "Rand": Qualified Folder Folder Conditions for 'Lamplinc' Add conditions to limit when programs in this folder are allowed to run. If Status 'Icon Lamplinc V1.0 07.AE.1D.1' is not Off Then Allow the programs in this folder to run. Program within the Qualified Folder If Control 'KPL Table' is switched On And Control 'KPL Table' is not switched Off Then Wait 1 minute Set Scene 'Lamplinc 50%' On Wait 1 minute Set Scene 'Lamplinc 50%' Off Else - No Actions - (To add one, press 'Action')

cslee, I noticed the same delay the very first time I linked the Triggerlinc to a lamplinc (manual link, no ISY or PLM involved). The delay was in the Triggerlinc itself. I could see the Triggerlinc LED flash to indicate that it saw the magnet status change but it would take 2-3 seconds for it to communicate with my Accesspoint. After a factory reset/re-link the device has responded almost instantly. I have not been able to reproduce the delay since that initial linking. IM

Hello Darrell, It's encouraging that the beta units provided low-battery triggers. I can't imagine Smarthome back-peddling on an advertised feature. I guess it's time to find my old variable DC supply and run some tests. Thanks for the reply, IM

Hello Joe, Sorry to have raised concern. I should have provided some more detail on the "high activity". On and average the weekday (3 kids at home), my kitchen sensor trips an average of 120 times (on/off) a day. If it's a rainy day I've seen as many as 250 trips. After my first battery died I realized that the ISY folks gave us the ability to decrease the LED drive. I changed the LED brightness on one unit to "0". It's on it's second battery whereas the other units are on their third. To early to tell, but I hoping for a significant battery improvement on my "test unit". I replaced two Hawkeyes with the 2420M's. The Hawkeyes would last roughly 6 months in the same location.

Hello forum members, I'm wondering if anyone has had success getting low battery events from their 2420M motion sensors? I currently have 4 Rev 1.1 sensors (ISY lists them as V.00) installed in "high activity" areas. As a result, I've gone through multiple batteries on each unit over the past 4 months. I've never seen a low battery trigger from any of the units. Typically, the sensors will become intermittent and begin generating communication faults. Soon afterward they go off line. I'm a bit tired of watching the logfile in an effort to predict when the next battery will fail (hate coming home and seeing 12 - 75 watt cans burning away). If someone out there has had success, I'd sure appreciate a firmware rev/model rev. On a positive note, when the batteries are "up" the motion sensing and day/night detection on these units has been flawless. I've been using the day/night status to qualify programs and I haven't seen it miss yet. Thanks, IM

Hello frustratednon-geek, As a first guess, try relocating the PLM back to it's original outlet. The move may have placed a noise source/signal absorber between the PLM and the load panel. This could easily explain the problems you are seeing. In regard to the IP address change, if you have DHCP enabled on your router, the ISY/PLM move may have resulted in the router assigning a new address when the ISY came back online.

Joe, By using the "run else path" at the end of your program you can force the program to false when it completes. As a result, the status will only be true when it is actually executing. Program Test IF A, or B or C Then set A Set B Set C Run Program Test (Else Path) Else --No actions end

Ken, Your changes below sound "meaningful". Please keep us posted on whether or not this holds up. Not to be a PITA but... It sounds like you're on you way to verifying that there is a noise source/absorber on the original circuit. You're currently bypassing this by plugging into another circuit with the extension cord, but the "problem device" is still there. In order to prevent future problems, I would rather see you track that "problem device" down and kill it.

This is probably OK as long as the hot and neutral are wire nutted in the box. If the circuit is "daisy chained" (4 push in connections at the back of the outlet) I would suggest rewiring. I don't believe this is code - the outlet is designed to provide current to it's output terminals, not be a current "link" in a circuit. Unfortunately, just because device A can talk with device B it doesn't mean that the reverse is true. The reason is that noise sources propagate differently depending on their frequency. A noise source close to device B might prevent it from hearing device A. Device A can hear device B because the noise is attenuated by the length of the powerline and the other devices connected. Assuming that you linked the device using the ISY, the ISY is part of the scene. If you press a button on a KPL or SWL and it can communicate with the ISY, the lamp with flash an error. That's a good start. Try reversing the connection and run the PLM on the extension cord. You may have something else on the circuit that is preventing the signal from making it back to your load panel. From one of your earlier posts - You tried plugging a Accesspoint into the PLM and had mixed results. Assuming that you had a noise source/absorber between the PLM and your load panel, here's the scenario. 1) The noise/absorber prevents the PLM from reliably communicating back to the panel. Let's call this Phase A. 2) Plugging the accesspoint into the PLM establishes communication to the second accesspoint on the opposite phase (Phase . 3) Phase A still has marginal signal at the panel since the noise/absorber is still between the PLM and the panel. For the above to work properly you would require a third accesspoint to "jump" over the noise/absorber and re-establish levels on phase A. Personally, I would much rather kill that problem device (I use only 1 Access point in a 4500 sq foot house). You also mentioned that your X10 system appears to be functioning reliably. I have a feeling that your X10 transmitter is in a different location than your PLM. If you were to move the PLM to the same location you may find communications are stellar. Hang in there, you are making progress. Keep in mind these things tend to make complete sense after you've found the problem. IM

Hello CJ, To answer your question below - Yes, I have an ISY-26 that simply works every time. I also have an advantage - I originally ran the house on X10 (still have 20+ devices) and got things where they were 90%+ reliable. With the ISY installed, Insteon is near 100% (nothing is 100%). One observation - your system sounds like it is reliable until you attempt to make programming changes to a device. You also have problems running programs. Both of these sound like communication issues between the PLM and your devices. Have a look at the placement of your PLM: 1) Is it on a GFI or Arc-fault circuit? I have some GFI outlets in my home that attenuate X10/Insteon by a factor of 20. 2) Do you have a noise source/attenuator on the circuit between the PLM and your breaker panel? You indicated that you have a number of filterlincs, but it only takes one device (in the wrong location) to cause a problem. If you haven't already, you can try placing a Accesspoint near the PLM. If this works, I would still investigate the circuit to see what is interfering with the signal. IM

Back around the Christmas time frame I changed the setup on our Family room RL. This is the "better halfs" device and it is used daily. Two days later the batteries were gone. Thinking that it was just their time, I replaced the batteries and returned the RL to the Boss lady. You guessed, within a few days the batteries were dead again (Boss not happy - can't turn on fireplace). When I looked over the scenes that I had linked to the RL I noticed that I had mistakenly linked into a kitchen scene that included another controller (3 way circuit). I normally only use one controller per scene. I corrected the kitchen scene link by linking to the scene where the RL was the only controller. That was 3 months ago and the batteries are still going strong. Not at all a scientific test, but I'm wondering if anyone else has noticed similar problems. IM

I'd call 1992 recent construction for electrical. You don't have arc-fault interrupters (that's probably a good thing) but other than that, you're close to current code. Our homes are similar in both size and layout. I'd imagine 200A service with the panel in the basement (possibly a tag on panel). I am not sure that I understand a "whole house" scene. Is this a scene that contains all the devices that I own? Once done, I assume I am looking for consistently bad actors via the scene test, which would in turn point to a bad circuits? Correct - Include everything except Remotlincs, Motion sensors, Controlincs (these can't be responders in a scene). Since the Scene test turns devices OFF, you're not risking waking the family in the early morning (when I tend to play with the system). What type of load do you have on your problem light? I've recently been testing noise injected by CFL's. I'm using both Neptune dimmable and Sylvania non-dimmable. The dimmable version appear significantly worse in terms of noise (not causing problems as yet). Does this light respond properly to the Scene test when ON? I understand completely about the yard work. I'm trying to finish my taxes this weekend so I can play catch-up outside. IM

Mike, The best way I can do this is with a sketch. In configuration 1, we have a receiver 100 feet from the panel with a noise source/absorber in the middle. In this configuration, the distributed Inductance/Capacitance is reducing the signal available from the panel. It's possible that the receiver won't be able to hear the communication due to the noise/absorption. 1) Panel ---------50ft--------Noise/absorber--------50ft----------receiver Adding a second receiver at the end of the line adds additional loading. If the first receiver can't hear the communication from the panel, chances are the second won't either (you've made matters worse). 2) Panel ---------50ft--------Noise/absorber--------50ft----------2xreceiver Adding a receiver midstream can help by repeating the panel communication. Since the line length is reduced it can "hear" the panel communication. 3) Panel ------50ft--------receiver/Noise/absorber--------50ft----------receiver Notes: 1)the above is a very simplistic example intended to show that it makes a difference where a noise source/absorber is on the circuit. 2) When looking at the circuit layout, you need to consider both communication directions. 3) My experience is that it takes more than just line length to sufficiently reduce the Insteon signal to the point where it can't be received. Different combinations of line length/noise/absorption/bad connections are required.

Hello oberkc, Trying to track down general system noise/absorption can be very frustrating when there doesn't appear to be a single offender. At times the offender is overlooked since it can be as innocuous as a cell phone charger. At other times it can be the "sum" of various offenders causing a problem. Prior to getting into the manner of troubleshooting, a few more questions: 1) How large is your home/how many levels? 2) When was the home constructed and (if older) has it been rewired? 3) You mentioned an X10 signal bridge. Is this a passive signal bridge or an active repeater? 4) How reliable are your X10 communications? 5) Do you have a boosterlinc or any boosterlinc enabled X10 switches in the system? If your X10 coupler is passive, it should help your Insteon signals cross the phase as well. If it's and active coupler, it may or may not help (many active couplers contain a tuned circuit for passive coupling as well). Prior to troubleshooting, please revisit the compare function - if a device isn't programmed properly it can't respond properly. For troubleshooting your system, I would recommend simplifying the configuration to get to a system that is repeatable. A system that isn't repeatable is extremely difficult to analyze. Assuming that your X10 coupler is passive: 1) If you haven't already, create a whole house scene that you can use for the scene test. 2) Remove all of your accesspoints (this is the simplification part). 3) Retry the scene test and try to isolate failures to specific circuits in your home. Note that Lamplincs may not respond if their load is disconnected or turned off. The gist of the above is the isolation of problem circuits that repeatably cause errors for your devices. Once a circuit is identified, try to locate problem devices or bad connections. If you have "spare" Lamplincs, these can be used as plug in repeaters on problem circuits. Note that for this to be effective you really need to understand how the circuit is physically wired (plugging a repeater in "upstream" of a problem area can help, downstream may actually make the problem worse). IM