IndyMike

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

Neil and Gary, The Scope is a USB interfaced DS2200 from USB instruments. These are no longer available, but they do have a new version (DSM12) for around $200. I use a ACT Scope-Test2 adapter to knock down the AC line voltage to manageable levels and separate out the Insteon/X10 transmission. These are also no longer available (maybe Ebay) but there are plans available from Uncle Phil Kingery (ACT Guru). I word of caution if you do use an adapter (or build one) - the coax shield is connected to the neutral line. This can be a problem if you have a device that is drawing current and raising the neutral level. Always treat the shield as if it was hot and use an isolated (no chassis ground) oscilloscope. I use the DS2000 with a laptop to be safe. As far as the Insteon sensitivity levels are concerned - I can believe 10mv in a lab environment. In a normal home environment noise would swamp out a 10mv signal. I believe the minimum "acceptable" X10 level is considered to be 100mv. IM

Gary, I've actually had good luck with the Sylvania, although I do not have any of the 23W. I do have 8-15W Sylvania in my upstairs hall controlled by SWL relay - no problems. My bathroom use 8-9watt (light bars) bulbs again controlled by a relay SWL. Is it possible that you have a poor connection on the circuit feeding the CFL's? Does this happen whenever the CFL's are on, or only during warmup? IM

Neil, The "Optimal" location for the PLM is at the main panel. This is provides a solid neutral connection and a "point" for all signals to fan out. I can't honestly say what affect the 60' will have on the signal. It depends on distributed inductance/capacitance of the cabling and the type of loads you have on the panel. My gut tells me this should be no problem. I had promised a plot of the passive coupling using I2 signals. The signals in the above: 1) First communication - 11 packet I2 transmission from the PLM 2) 2nd communication - response from Accesspoint (opposite phase) through the signal coupler. 3) 3rd communication - PLM repeat 4) 4th communication - Accesspoint repeat. Now you may have noticed that the "coupled" signal is only ~ 0.7V P-P. This was a worst case test. I have only two I2 devices (PLM and Accesspoint) coupling across the phases. The PLM is at my main panel. The Accesspoint is 2 floors up at the opposite end of the house. Also, keep in mind that my coupler is designed for X10. It's giving up some level since it's not tuned to the Insteon 130Khz.

Hello Gary and Neil, Sorry for barging in, but you've hit on one of my favorite topics. I agree that a passive Insteon coupler at the panel can be a huge asset and I also believe it saves 1 hop in coupling the phases. I use a 4616H X10 coupler at the panel for my legacy X10 components. While not optimal for Insteon, I can run the entire house (4500 sq Ft/3 levels) reliably with no Accesspoints installed. Whether you can do the same depends on the type of loads installed and how far your 1st devices are from the coupled panel. Over the past couple of weeks I've been playing with I2 signal distribution. I was using 1 I2 ApplianceLinc and checking signal propagation throughout the house. I have no other I2 capable devices (Accesspoints were removed) so the I2 signal was not being repeated. Without the repeat feature of the Insteon protocol, the configuration winds up being similar to my X10 system. I found that I could reliably communicate, program, and query the I2 device anywhere in the home with only the passive coupler installed. I then pulled most of my filters (except the one on the Toshiba laptop) and still had good communication and 100% scene test response. My loads include PC's (6), A/V systems (3), CFL's (25), and the normal number of wall warts for phone chargers, modems, switches, etc. I disconnected only my Hafler amplifier (black hole for PLC) and filtered only the Toshiba laptop. The point of the above is that Insteon can be made reliable even in extreme cases without throwing a 6-pack of Accesspoints at the installation. I tend to treat Accesspoints as nothing more than a Rf to PLC signal bridge. If they are used to "cover up" a signal problem on a circuit, that problem is likely to come back and bite you (noisy devices/signal absorbers can move). A few words on using CFL's. While standard CFL's are noise producers, they tend to induce spikes near the peak of the AC sine wave. Since Insteon and X10 communication occurs at the zero crossing it is resistant to this noise. I say resistant because I have seen documented evidence (lab environment) where multiple CFL's can combine to produce "beat" frequencies that do affect zero crossings. As Gary noted, dimmable CFL's (dimmer friendly) can be worse than the standard version. When operated at max level the dimmable CFL's inject noise similar to their standard brothers. As the input to the CFL is cut (triac output from the dimmer) the spike injected by the CFL grows up to 2X. I've seen 20V P-P spiked injected by a 8W dimmable CFL. This spike did not prevent Insteon communication because it occurred at the waveform peak. It did lock up the Lamplinc dimmer that I was using to control the lamp (direct noise injection). I'll try to post some plots of the CFL noise injection and Insteon phase coupling when I get a chance. IM

Alf, If I understand correctly, your second home currently has X10 installed with no couplers or repeaters and it functions OK. If that is the case, you either have all of your X10 units on the same phase or you have a good couple through your transformer (rare but it happens). In this instance you should be able to simply install the ISY-99/PLM (I prefer installation at the panel) and go. If you do run into signal problems down the road, a coupler installed at the panel will help. Here's a link to coupler information that Jeff Volp put together: Passive Couplers. The passive coupler is compatible with Insteon and will help with these signals as well even though it's not perfectly "tuned" to the Insteon 130Khz (I use one in my panel). Since you are planning on adding Insteon down the road, you may find that your signals degrade as your Insteon installation grows. Since each Insteon unit is a 2-way (receiver/transmitter) they also absorb communication. Insteon gets around this by having each unit repeat the Insteon transmission thereby "re-boosting" the level. Unfortunately, they do not boost X10 transmissions. I'm not sure if the 2300 series X10 units are transmit/receive units. If they are, and you perform a 1:1 swap with Insteon, you're unlikely to see any additional loading. If loading does become a problem, you can replace the passive coupler with an active repeater. Jeff Volp makes a XTB-IIR which can pound out really impressive X10 levels. From what I've seen, it's the best device out there for X10 Amplification: XTB-IIR Again, this device is Insteon compatible. I would not recommend a BoosterLinc (even the Insteon Blessed version). I've had a few and they work well enough for X10 but get confused and destroy Insteon communication. Take it slow, IM

oberkc, The query response below is an example of extended messaging. The ApplianceLinc reference was a mis-type on my part. I meant Accesspoint. I've checked my accesspoints (V1.0) and they do repeat the extended message commands. Loose connections can certainly contribute to signal loss, particularly if you have a signal absorber on the downstream side.

oberkc, A few observations - 1) Your new Lamplincs utilize Insteon Extended messaging for programming and queries (evidenced in your previous log posts). Extended messages may not be repeated (amplified) by your other Insteon units making the programming sequence more susceptible to noise/absorption. Your difficulty adding these devices to scenes is further evidence of this programming problem. 2) These devices use standard Insteon commands for on/off and scene activation. The fact that you are having difficulty with these functions implies that the programming was incorrect (corrupted by noise/absorption as Michel stated). 3) While the Insteon Filters do a good job of isolating/blocking noise from most devices, others require different "low pass" filters. Please try plugging one of your Lamplincs directly into the PLM and perform a factory reset/restore. This should ensure that the programming is correct. Move the device back to it's original location and (hopefully) verify proper scene operation. If the above works, you can try a variation with the second Lamplinc (if you're game). Unplug all of your possible noise/absorption offenders on the circuit. Install a Accesspoint on the circuit. Perform a factory Reset/Restore. If this programming functions properly you should be able to plug your devices back in and still have scene functionality. If the above works, it's a temporary solution. Until, you track down the possible noise/absorption source (or boost your signal level) you will have difficulties each time you attempt to modify the programming of these devices. Let us know how things are progressing, IM

Hello NewTech, The scene test feature (Tools/Diagnostic/Scene Test) is intended to be a "worst case" test of the cleanup responses after a scene is activated. There's a Wiki page on the subject here: Scene_Test When operating under "Direct Control" Insteon commands are sent to a device. The device is then required to respond with an acknowledge (or negative acknowledge). If the recipient does not respond to the command, the sender retries xx times. Scenes are a bit different. The sender sends out 1 command to activate the scene causing all of the recipients to go to their respective levels. The sender then issues a "cleanup command" to determine whether all of the devices responded properly. The Scene Test is designed to check this cleanup command/response. There are a number of limitations related to cleanup commands: 1) Both the command and response are limited to 1 Hop (1 rebroadcast). This may not be enough in some installations (direct and scene commands are 3 HOP). 2) Cleanup responses may be aborted due to other Insteon traffic on the powerline. 3) Some devices (Lamplincs with local control enabled) will not respond if no load is attached (or if the load is switched off). Note that the items above don't stop the scene from working. It's just that under certain circumstances a scene member may not respond. Since there are limitations to the device response after a scene, the ISY is forced to use a predictive status (the device is on because I just turned it on). Since your scene is intermittent, you may have better luck querying the devices or turning them on directly from the device GUI. This uses the direct protocol and will indicate any errors in the device response. Can you give us some more details on the devices and loads in your Great Room? In newer homes the lighting circuits are typically wired separate from the outlets. Devices having problems on a lighting circuit may indicate noise problems due to CFL's, Fan Motors, Low voltage lighting, etc. Devices having problems on outlet circuit could be due to signal absorption/noise from plug in devices (TV/Stereo/Computer). IM

Michel, Thank you for the reply. I hadn't thought of the switch itself transmitting an incorrect record. I can see how that would throw a wrench in the link table. Since not all users are experiencing problems, I'm making the rash assumption that this is influenced by the powerline environment. I had planned on trying some tests varying noise/signal absorption (therapy work). Your new tools in the event viewer will come in handy - I had been exporting the records to excel to compare the link lists and calculate "Hops remaining". Thank you very much for this addition. IM

dss, I believe the repeating problem was something that we theorized awhile back. Unfortunately the nature of forums is that information is often taken out of context, repeated, and misquoted and before long becomes fact. I've been searching and have not been able to locate where a SH or UDI representative has stated that I2 messages are not repeated by I1 devices. GregoryX quoted Steve Lee as saying that the I2 communication might be more sensitive to noise: http://www.forum.universal-devices.com/viewtopic.php?p=16776#16776. This is not at all the same as saying that I1 devices won't repeat I2 commands. Another questionable conclusion has been made regarding "corrupted" link tables and I2 CRC. From what I've seen, corrupted link tables are comprised of duplicate entries or entries for groups that are no longer reflected by the ISY. I haven't seen a post indicating "garbage" data in a link table (invalid format). If you look at the old I1 peek/poke method of programming you can see that the ISY was in total control of the process. Each of the 8 locations in the link table was individually peek/poked until the entry was completed. Each communication is sent with a max HOPs of 3 and retry logic is applied. In short, there is a lot of handshaking going on with a simple 8 byte programming sequence. If/when problems occurred the ISY could recognize them and recover. As I understand the I2 programming sequence, the switch is an active part of the programming. The entire 8 byte link record is written in one fell swoop. Note: the following is pure speculation. What I do not know is how the switch responds to a "completed" sequence. If the PLM/ISY for some reason can't hear the switch indicating a ""link record complete" transmission, it's possible the ISY will retry and thereby create a duplicate record. The ISY and switch are now out of synch. At present I don't have any devices that the ISY recognizes as I2 programmable (2 units on the way). If someone can provide the Hop count used during I2 programming acknowledge I'd be very interested. As of Version 2.6.14 UDI has given use the ability to easily monitor Max Hops and Hops remaining using Mode 3 in the Event Viewer. IM