IndyMike

Hi Illusion, You're absolutely correct about commercial applications. Power companies penalize "big users" with poor power factors (causes problems for their distribution systems). It's interesting that the dual band LL's are showing better power factors. There may be "incentives" for oem's to improve power factors on small devices as well. Most older CFL's exhibited horrible power factors. I was surprised that this was allowed. Obviously a "green" trade that was made at the time. My recent dimmable CFL's are showing PF's of ~ .9 so things are improving.

Hello Ergodic and Illusion, The current measurements that you've observed appear in line with what I've seen in the past. The good news is, you're not being charged for this. This is because the devices are drawing power "out of phase" - it's referred to as apparent power. Your utility company only charges you for the "real" component (in phase portion) of this power consumption. In order to perform this measurement you need a device with power-factor correction. It measures both the current and voltage (or current and phase) to compute the real component of the power. Wiki: Power Factor As an example, I have a lamplinc plugged into my UPM energy meter. Current consumption is 80 ma. Corrected power consumption is 1 W. This device is drawing current nearly 90 degrees out of phase from the voltage waveform. Here's a list of devices that Dave Houston baselined some years ago. Dave improved the accuracy of his meter through long term tests: http://davehouston.net/x10-power.htm

Thanks for elaborating. I did not realize the Insteon signal was more complex and therefore more vulnerable to noise. Makes more sense as to why I have some reliability issues. Hello Intellihome, Insteon signaling is more complex, but I would not say that it is more vulnerable to noise. Quite the contrary, much of the complexity comes from embedded CRC codes (for error checking) and the command/response/retry functions in the protocol. I believe the complexity that UpstateMike was refferring to was the actual programming of devices. This is complex and lengthy. The same protocol/error detection is used, but since the programming can take minutes and you are effectively writing to many units, there is a greater chance that it will be upset. Nothing like this existed in the X10 world. I also use X10 units alonside my Insteon hardware. Since you appear to be having problems with Insteon units in the same location as your old X10 hardware check for common mode problems: 1) Location of your PLM - If different than your X10 controller, it may be near a noise/absorber 2) Phase coupling - The Accespoints are wonderful little devices that are absolutely required for RF coupling (motion sensors and remotelincs). When used for phase coupling, remember that they can also be affected by local noise/absorbers. For this reason I prefer the X10 method of using a passive coupler at the panel. 3) Presence of V.35 Switchlincs - Michel has indicated that these can cause intermittent failures. IM

Hi Mitch, I have a number of the V.2C SWL relay units. I haven't had a problem with these, nor do I remember problems with this firmware revision being reported. They are older units, but that does not mean they shouldn't perform well in your system. I'm beginning to understand your log below, and I believe you're making progress. You appear to be using the event viewer in mode 1. Please switch to mode 2 or 3 for additional information. In your log above you turned on devices 1,2 and 3 manually from the ISY GUI. When you use the GUI to turn on a specific device the ISY uses "Direct communication mode" which requires a response from the device. When you turned on device 4 it did not respond to the ISY and you received the "unable to communicate with xx device". This may have been due to one or more of the following: 1) Turning on devices 1 - 3 created noise on the powerline and prevented device 4 from responding. 2) Turning on device 4 generated noise (additive) preventing a response. The following shows the typical command/response from the ISY to a device when using mode 3 in the event viewer. I really believe this has to do with your loads generating noise. Since you can reproduce the effect from the GUI, try turning off all four devices, then activate only unit 4. Hopefully you can narrow things down to a particular load (CFL). Be careful with your conclusions. All CFLs generate some noise. The noise could be additive. IM

Sorry, Saw the following post after I had replied. This may actually make sense if you are turning on noisy loads with your KPL (CFLs). Please try the scene test again with all of the KPL scenes off. If you get good results, you might try turning on certain loads and rerunning the scene test to get a feel for the noise environment.

Not exactly the night and day results that I had hoped for. I would have liked to have seen a significant difference between the on and off conditions. We might have been able to attribute the difference to the CFL's generating noise. Are these results typical for other scenes or is this a problem area? Are all of these SWL on one circuit, or spread across multiple?

Mitch, Thank you for the replies. I am not proficient with the Climate module (I don't have the module) but understood this to be network based. As such, I would not expect it to cause Insteon communication problems as you described previously. I will, however, defer to the ISY masters in this regard. The log that you posted indicates that the ISY is receiving the communication from you SWL when turned on. The remaining ST entries are, I believe, the ISY predicting the status of the scene based on the communication. In other words, there is only one communication and the ISY is showing the status that "should" be attained in the scene. Please try the following tests using the ISY diagnostic "scene test". You can find the scene test under the menu item Tools\diagnostics\scene test. There's a description of the test here: Scene Test 1)Try the scene test on your Porch scene with all of the devices off. Hopefully everything will pass. 2)Turn your devices on using your SWL "mini scene" and retry the scene test. If we've both lead clean lives, you'll get some failures here. I'm mostly depending on you here since my life can't be construed as clean. 3)Turn the devices off, then back on via your KPL. Retry the scene test again. Please report by your results. Hopefully we can come up with an explanation to fit the data. IM

Hello Mitch, In a word - NO. You are not violating anything by having four controllers within a scene. Please answer the following: 1) What type of load is attached to each of the four switches? 2) Is your relay unit a V.35? 3) Do any of your fixtures have photo-electric cells (light sensors)? 4) Rand's question from above - do you see a lot of Insteon communication when you activate the "Porch Light" You can view Insteon activity addressed to the ISY/PLM in the event viewer (Rand linked to instructions above). Another method to get a feel for total activity is to watch the led on a lamplinc or Accesspoint. For a four unit scene, flashing of the led for over a couple seconds would be excessive. The reason for questions above are we are trying to separate electrical noise from communication/programming problems.

Hello Mitch, From your description, I can't see that you have violated any rules with your "scene within a scene". I have numerous examples of this in my home, including a whole house scene that encompasses most of my devices. I'm hoping that you may be using a dimmable CFL in one of your Switchlincs (porch light perhaps). If so, it's possible that the scene on level or ramp rate is different than your KPL scene. Dimmable CFL's like to be turned on quickly and at full brightness. After they have stabilized (temperature and frequency) you can dim them down (30% in my experience). They will generate more noise in the dimmed condition. Check your ramp and level setting between the two scenes and at the device itself. If you don't find any differences (or aren't using dimmable CFL's) please post back and describe your scene devices and loads. IM

Hello Steve, To the best of my knowledge, scenes that are initiated by the ISY are predictive. In other words, the ISY "assumes" that the devices have responded properly and does not issue "cleanup" commands to verify the status of the receivers. This normally works well and dramatically increases the system speed. I'm not sure whether your "backup" program is any different. I believe the ISY treats devices in programs in the same "predictive" form and assumes that they have responded properly (I'm trusting the ISY experts to set me straight if I'm incorrect here). If the above is true (?), then devices that did not respond to the initial scene command should have a the same problem with the "backup program". So why does the backup work? By turning on devices you are changing the impedance of your wiring (communication system). Simply turning on a 60 watt bulb can dramatically change the noise/signal level on a length of wiring (branch circuit). In your case, you may have a situation where a "noisy" device is preventing device "B" from hearing the ISY. If you turn on device "A", a load is added to the circuit and device "B" can now hear the ISY. The opposite is also a possibility - turning on a "noisy" device on a circuit may prevent others from hearing communications. To diagnose this, try the following : 1) Scene test with all the "scene" devices off (this should produce the same 2 failures on your problem devices). 2) Scene test with all the "scene" device on (I'm hoping this will show 100% - not sure, because this is a tough test). If test 2) works, you could try issuing a second scene "on" command within your program (quick fix). If item 2) doesn't work, we'll need a bit more info including a description of the types of loads that you're activating and whether they are on common circuits. Disclaimer - V.35 devices have been reported to have problems with scenes. I have very little experience with V.35 units. If some of these devices installed, please indicate that and consult the ISY experts. IM Edit - After reading the above, it gives the impression that the Insteon communications are "fragile". That is not at all the case. I would characterize my home as average size (4500 sq. ft.) with some above average problem devices. The devices include a Grunfos variable speed well pump (documented problem for UPB), six PC's/servers (signal absorbers), 30+ cfl's, 3 a/v systems (soon to be 4). I am currently using 1 filter (Toshiba laptop), and 1 accesspoint (hardwired X10 coupler at the panel).

Sorry Brian, Although I quoted you, the comments were intended for others. I know you are a knowledgeable X10 and Volp follower as well. Didn't mean to imply otherwise.

Sounds like you're in business. Please let us know how things perform for you. The 240V PLM is a great idea for signal integrity, but it might not have much of a market. There aren't a lot of people that have a 240V plug near a lan connection. Adding an outlet near the panel is an expense that many people would not want to incur. The additional components and 240V ratings would also drive up the price. The closest item that I've seen to a true 240V amplifier are the line of X10 repeaters (X10, ACT, XTB). The XTB-II is unique in that it boosts X10 levels to ~20Vp-p. While the increased signal level is great for X10 (1 way communication) simply boosting the PLM output won't work Insteon (2-way). While an increase output level from the PLM would help with scenes, the responding devices would need to be boosted as well ($$$ again). I'm sure someone has done a cost/benefit analysis here... Given the repeating nature of Insteon, this shouldn't be required for most installations. The current work around is to use the passive coupler (with listeners/repeater in range) or the Accesspoints. I'm a big proponent of the passive coupler. Exactly correct. Jeff Volp (the XTB developer) worked to specifically ensure that the XTB line of devices would co-exist with Insteon. As mentioned above the XTB-IIR is a 240V device that wires near the panel and provides ~20Vp-p X10 on both phases. Jeff provided me with a XTB-R (120V plug in) that I baselined at 32Vp-p on my system. Since the device is 120V (single phase) a passive coupler is required. To my knowledge, this is the only plug-in X10 booster that is compatible with Insteon (the boosterlinc is not - I have data to prove it). If you can't tell, I'm a fan of the Jeff Volp devices as well... IM

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