IndyMike

Hi Mitch, As usual, there's no "one size fits all" answer here. Purely from a communication standpoint, it's best to have the PLM as close to the main panel and the signal bridge as possible. I've had the configuration you're describing since I built the home in '2000: 1) Triple gang box fed by 12-3 from 15A 240V breaker. 2) 120V duplex outlet on left (Phase A: XTB-R installed) 3) 240V phase coupler center (SH 4816H X10 Coupler) 4) 120V duplex outlet on right (Phase B: PLM installed). I installed the above prior to completing the house. It complies with local and NEC code and was inspected during construction. Now for the rub - Many panels are in unfinished areas of the home (basement, garage, etc). Code requires the use if GFCI outlets in these areas. These GFCI outlets have a habit of attenuating both X10 and Insteon signals. You do not want to plug the brains of your system (PLM) into an outlet that may attenuate it's output signal. Let us know whether your panel is in an unfinished area and, if so, whether there are any finished areas nearby (wire distance) for the PLM.

There was a problem with "early" revisions of the KPL regarding X10 All on/All off commands. If a single secondary button were programmed with an X10 address ("A1" for instance), all of the buttons (including the load) would activate in response to a HouseCode A "All on" command. I am not sure whether an Insteon Scene would be initiated in response to the above. IM

gfridland, You've already developed a well thought out plan. Assuming that this isn't a program that is getting tripped up, I don't have a lot to add. Since an entire scene is executing, there should be a controller somewhere. As oberkc indicated, check for log file events in that time frame. I have seen local line "events" fool devices into triggering on. I have a cheap strip fluorescent in our walk-in closet that periodically triggers a leviton bath fan timer (non-communicating). If the same thing were to happen with one of your Insteon devices (and it was a controller) it could communicate a local on command and trigger the scene. Even if a device were "fooled" in this manner, the "control on" event should be logged. IM

Hello Paul, You were very close. The "Time IS" condition is generally used for one time on off events. You can use it with an "and" statement, but both conditions must be true at exactly the same time. Try the following modification: IF X10 'C1/On (3)' is Received And X10 'C1/Off' is not Received And From Sunset to To XX:XX:XX Then Set Porch Light On Else Set Porch Light Off In the above, the C1 signal will trigger the "then" statement between the prescribed times. After the time has expired (or if a C1 Off is received) the light will be turned off (else statement executed). IM Edit - sorry, I missed that fact that you wanted to "latch" the C1 ON command for execution during the time window. See Marks post that follows (good catch Mark).

Hello Harold, If I were to give one piece of advice on the use of dimmable CFLs, it would be to proceed cautiously. As others have indicated, you will not get anywhere near the incandescent dimming range with a CFL. I've tested a number of manufacturers and have found most of their claims to be optomistic. Noise injected into the powerline tends to increase as a CFL is dimmed. One of the brands that I tested injected 22V spikes into the Line at low dim levels. The noise also tends to "crowd" the zero crossing where the Insteon transmissions occur. This results in "loss of control" of the Insteon dimmer connected to the CFL. I've been using Neptune dimmable CFL's in my outdoor fixture for around a year now. These were the least objectionable of the brands that I had tested (lowest noise). I currently have the lamps set to dim to 40% after 10:00 PM. This is the lowest level that I can attain reliably without inducing communication problems with the Insteon dimmer. Actual reduction in the lamp output is, I would guess, on the order of 20% (hardly noticeable). Before investing a lot of money, I would strongly suggest that you "test drive" some lamps in a less noticeable location.

Hi Brian, As I indicated, I thought I'd take the easy way out an let SH do the wiring for me. I figured I give forum members the benefit. The connections to the pwb actually look pretty good. Better than I could do given my current eyesight (even with a 10X loop). They even cleaned the flux off the pwb. I didn't put up pictures of the "working sidie" of the pwb. A total of two small IC's and surface mount passives. It's amazing what you can do with house chips these days. As a side note - I walked out into the garage this afternoon and found a box delivered by ups. My timer system unlocks the door for 15 minutes when my better half is due home. If she's late, she has to use the keypad (and she was late today). Either my UPS guy is very good, or very lucky. Either way, I have half a mind to give him a call (all my friends will attest to the fact that I have half a mind). IM

Hello All, Wasn't quite sure where to post this, but thought it could be handy for some of the forum DIYers. I've been evaluating one of the Morning Industries RF deadbolts (QF-01P) for use in various locations throughout my home. The unit provides both keypad and RF (rolling code) lock/un-lock functions. For my applications, I was interested in interfacing the RF remote to my ELK/ISY system for automatic locking. My family members appear to have a genetic deficiency that renders them incapable of locking doors. The deadbolt itself appears to be of decent quality and construction as does the quality of the exterior plating. The exterior keypad also has a nice feel with good tactile feedback on the buttons (not mushy). The indoor assembly is rather large, but it does contain the motor drive and 4 AA batteries. I've installed the unit on what is arguably the nastiest, most used door in the house - our garage entry. Installation on the door was straightforward requiring only minor modification of the jamb plate to prevent binding. I should point out that this is a steel door with magnetic seals. Doors that use compression seals would likely pose a problem with binding. Extensive modification of the jamb plate to prevent binding would leave the seals open. The garage itself is unheated, but normally does not get below 20F during winter. So far this winter we've experienced our share of single digit weather and the lock has not skipped a beat. I was a bit concerned that the motor drive might stick in subzero whether. So far so good. After a 3 month test drive of this unit, I decided to spring for the second half (on sale of course) - the RF interface. SH offers a IOLinc kit that interfaces 2 IOLincs to a Morning Industry RF remote. In this configuration, one of the IOLincs provides power (5V) and the unlock function (momentary contact) and the second provides the lock function (momentary). My real reason for purchasing the Kit was to determine the wiring interface at the Keyfob. While I'm only planning on using the lock function, I was able to rationalize the kit by using the IOLincs for other applications. That basically gave me the keyfob and wiring for free (yep - I'm lazy). So, that brings us to the entire point of this post - the wiring interface to the keyfob: Note that in the photo above, the white wire is labeled "blue/white" in the SH diagram and performs the momentary lock function. The black ground wire (difficult to see) connects to the middle terminal of the lower switch (right side). With the Keyfob interfaced to the IOLinc, range to my deadbolt is impressive (over 30' and through the garage wall). I've been using this to automatically lock the garage door based on an ISY schedule (haven't interfaced to the Elk yet). So far, the unit has been operating reliably and has coexisted with all the family members. I should not that my UPS man is not overly pleased - he's accustomed to the garage being unlocked.

Hello Paul, Preset Dim levels are covered in this thread: http://forum.universal-devices.com/viewtopic.php?t=1168 I believe that marksanctuary has also added this to the Wiki (too lazy to look at the moment). As Brian indicated, SmartHome Insteon and older Smarthome X10 units use "preset Dim" commands. X10 brand, Leviton, and ACT units use simple bright/dim or extended code direct dim commands (the PLM cannot transmit the extended code). Clear as mud, right? Give us an idea of what hardware (units) you are working with and what you're trying to accomplish. Chances are a Forum member has been there already.

Michel, Am I to understand that Smarthome is working on implementing S/N measurement in the Insteon devices themselves?? Than would truly be a boon to the Insteon community. Do you know if this would be implemented in individual modules or just the PLM? IM

Curious, Just returned home from a road trip to find the ISY time 1 hour off (re-synch worked properly). In going through the log, I found the same time warp to 1941. The other curious item is that the ISY was performing exactly the same task on it's trip to 1941 and back. The F5 status is a response to an X10 Poll of my outside flood lamps. It's a program that runs every 15 minutes during daylight hours. The "A Extended Code" is a transmission from my CM15a to my Leviton Dimmers. The program is triggered by a X10 motion sensor, and executes a direct dim command to the Leviton switch. While the F5 status response is a synchronous event controlled by the ISY, the "A extended code" is very definitely a asynchronous event completely outside the ISY's control. Coincidence that these events happen to line up with the time warp? My automatic re-synch is set for 24 hours.

Darrell, Don't be sorry. My comment was in no way aimed at you. On the contrary, the discomfort was entirely of my own making. After convincing myself that this was an undocumented feature, I launched into the before mentioned test sequence to define the conditions under which the battery function worked. All that, when the feature was plainly stated on the web page. What a dope.

OK, now I'm miffed. I did buy into this as an "undocumented feature". There isn't a word about it in the quick start guide, and there is no full users manual that I can find (including the Wiki). I have to admit, I normally gloss over the web page as I've found it to be a great source is misinformation in the past (load ratings and such). What a SAP I was. Thank you for arming me with the correct information. I can see another conversation when the next battery goes down. IM

Illusion, Previously you were not getting low battery warnings - Correct? If so, were you using standard alkaline batteries previously? This could be a case where the discharge characteristics of the lithium batteries allow the low battery announcement to function properly (battery source resistance).

Darrell, Thank you for confirming. It's good to know that my experiences aren't due to that little black cloud that continually hangs overhead. When I spoke to Smarthome about this, they indicated that the "documented" battery low indication was the "double flash" of the led. Sure enough, my units double flash when the battery is getting low. The battery low communication to the ISY is apparently issued sometime much later (and typically after the communications have broken down). I'm currently running a comparison test between two of my sensors. One is programmed for full led brightness with the other programmed to 0%. Both are located in the same high traffic area (kitchen). I'll try to report back when they begin to develop problems. Thanks again, IM

Hi Illusion, The timeout period for the Dusk/Dawn was arrived at through experimentation. I was using my "drawer test" to activate motion and plunge the sensor into light/darkness. Most of these tests were performed with a 0.5 minute motion timeout and a 35% darkness sensitivity. I went back though my notes and found that the timeout period that I had documented was actually 3min 40sec (not the 3:30 that I had posted). Last night I played a bit more with the darkness sensitivity and the motion timeout period. Here's a summary of what I've seen: 1) NO Motion: If the light level changes state (no motion present) the sensor will delay around 3min 30 sec prior to changing the output state. This appears to be independent of the dusk sensitivity setting. This measurement was made by switching a 4 bulb T-40 fluorescent fixture on/off over the sensor. I did see a fair amount of variability in this time (3:05 to 3:50 with the same settings). I attribute this to the implementation of the photo cell/light calculation of the sensor. 2) Motion: The sensor will not change the state of the dusk/dawn output within the motion timeout. If motion is sensed and the light level is changed, the sensor will only change the dusk setting 3:40 after the motion off is issued. This timing was very consistent and was not affected by the dusk sensitivity. 3) Motion re-trigger (within timeout): If motion is sensed within the motion timeout period, the timeout is simply extended (i.e. motion off command is issued at the specified timeout period after the last motion). Since the dusk/dawn is only issued 3:40 after the motion off command is sent, this will be delayed as well. 4) Motion re-trigger (outside motion timeout, before dusk timeout): Since the sensor will not issue the dusk/dawn output while the motion output is active, re triggering motion again delays the dusk/dawn output. 5) Light re-trigger (light cycling within the 3:30 second timeout): Still playing with this one. I initially saw a lot of variability which may again be due to my light source and the photocell. The jumpers in all of the above were in their default position. I believe you mentioned that you were using the "dusk only" mode. I have not tested that configuration. IM

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...