Jump to content

IndyMike

Members
  • Posts

    1632
  • Joined

  • Last visited

Everything posted by IndyMike

  1. Hello Johnnyt, I do not believe the following is correct. I have the X10 module installed and I am using X10 "Status" in my programs. I use several programs to monitor the status of my X10 PR511 floodlamps and display the status on KPL's. I also run a polling program during the day to determine if the lamps have been inadvertently activated. In my experience, the ISY (with X10 addon) will: 1) Respond to X10 ON/OFF and Status Response transmissions when using the "Status" condition 2) Respond to an X10 ON/OFF transmission when using the "Control" condition. 3) Will track status and trigger properly when combining "Status" and "Time" conditions ( if Time = XX and Status = XX). Please note the difference in the Status/Control conditions above: A X10 Status Response will not trigger a "Control" condition. The following is the activity monitor trace for a X10 Status Request and Status Response for one of the PR511 flood lamps. The flood lamps have been added to the device tree using the X10 module. They are defined as X10 Generic devices (not A10). Status Request Activity Monitor Sat 09/15/2012 10:27:07 : [ X10] F1 Sat 09/15/2012 10:27:07 : [X10-RSP ] 02 63 96 00 06 Sat 09/15/2012 10:27:07 : [ X10] F1/Status Request (10) Sat 09/15/2012 10:27:08 : [X10-RSP ] 02 63 9F 80 06 Sat 09/15/2012 10:27:09 : [X10-RX ] 02 52 9E 80 Sat 09/15/2012 10:27:09 : [ X10] F1/Status = off (2) Sat 09/15/2012 10:27:09 : [X10-RX ] 02 52 9E 80 Sat 09/15/2012 10:27:09 : [ X10] F1/Status = off (2) Polling Program If From Sunrise + 1 minute To Sunset - 10 minutes (same day) And Time is Last Run Time for 'Flood Daytime Poll' + 15 minutes Then Send X10 'F1/Status Request (10)' Wait 9 seconds Send X10 'F3/Status Request (10)' Wait 9 seconds Send X10 'F5/Status Request (10)' Else - No Actions - (To add one, press 'Action') Status Program (Updates Keypads with Flood status) If Status 'Outdoor / Deck Flood' is On Or Status 'Outdoor / Deck Flood Comm' is On Or Status 'Outdoor / Drive Flood' is On Or Status 'Outdoor / Drive Flood Comm' is On Or Status 'Outdoor / Garage Flood' is On Or Status 'Outdoor / Garage Flood Comm' is On Then Set Scene 'Outdoor / SC Flood Status' On Else Set Scene 'Outdoor / SC Flood Status' Off Daytime Monitor Program - Monitor KPL Status buttons and Turn off floods after 1 mintue If From Sunrise To Sunset (same day) And ( Status '1st Floor / Fam Room / Fam KPL 1 - Wall / Fam KPL 7 - Floods' is On Or Status '1st Floor / Mud KPL 1 - Entry Garage / Mud KPL 6 - Floods' is On ) Then Wait 1 minute Run Program 'X10 Contol Floods Off' (Then Path) Else - No Actions - (To add one, press 'Action') If you are having difficulty, it's possible that your X10 modules are responding differently than I'm showing above. Please post back your module make/model and the activity monitor output for a status request transmission (you can also query the device from the ADMIN Tree). IM
  2. From memory (dangerous): The requested module will return a Status ON or Status OFF. This is a standard X10 response that is recognized by the ISY. I use the status request in a program to Poll my PR511 outdoor motion floods. If one of the floods returns a status of ON, a second program is activated to turn off the floods after a period of time (day/night dependent). I'm currently out of the country, but will try to post some activity logs when I get back. IM
  3. Hello dss, Not sure if you are looking for a deadbolt or a locking handset (you linked to both below). If you are looking for a deadbolt... Unless something has changed in the Schlage design, it will not throw the bolt to lock the door (no motor). The "lock feature" simply disengages the external lever so that the door cannot be unlocked without a code. The Kwickset model does include a motor, and does report lock/unlock status. Since you already have an Elk system, I was wondering if you would consider using a deadbolt separate sensor? I've been using the following inductive sensors to sense the position of my Morning lock for the past couple years. It takes a little woodworking to get them in the door frame, but they've been bulletproof. I've also embedded the sensors in my sliding door foot locks to confirm that they are locked. The sensors require 10 to 30 volt excitation - I use the 12 V Aux outputs from the ELK to power them. Integrating the sensor with the ISY/morninglinc became "fall off a log" easy when UDI incorporated the ELK module. The combination of the ELK and the ISY has been one of the great success stories with the boss lady. When I'm on the road she can see the lock status of the house and all of the 7 entry points by looking at one of the "Status" KPL's spread through the house. No need to run the stairs unless a door is unlocked. http://www.automationdirect.com/adc/Shopping/Catalog/Sensors_-z-_Encoders/Inductive_Proximity_Sensors_-z-_Proximity_Switches/Rectangular_(CR-z-DR-z-APS-z-LF40_Series)/12X27mm_(APS4_Series) Thought this might give you another option, IM
  4. Hello Lee, Your code from the 24th doesn't show a "wait" in the else statement (only the repeat). When I run this I get the same 60 second period. If a 1 second "wait" is inserted, the period increases to 120 seconds. I can confirm that the "Repeat" by itself is being scheduled. Other Insteon activity alters the timing as reported by Tim and Lou. It appears that both the repeat and wait are interruptable (program re-evaluates and re-enters). The use of the repeat, by itself, appears to have 1 second of overhead.
  5. Hello porscheguy, Your 2476 devices are showing V00 because you added them manually. At some point you should check them to make sure they are not V35 devices (know to cause problems). You could delete/re-enroll them using the "auto discover" option which will read the version from the device memory - that's just painful. The easy method is to read the device memory directly using the "Show device Links" command and address 0x0000 to 0x0000 as shown below. This is my 2476D - it's showing a firmware revision of 27 ( the 27.00.00 entry) and agrees with what the ISY is listing for the device. Aside from the above, I don't have much in the way of suggestions that you probably haven't heard already. Since your devices aren't responding, I'd try to determine if they were on the opposite phase from the PLM- it might indicate a noise or phase bridging problem. As far as your program is concerned, I'm a firm believer in the "don't fix what isn't broken" theory. Your program is time tested - mine is not. After seeing your program, it occurred to me that I was forcing the use of a variable where one wasn't needed. Your program could actually be made simpler than what I offered. Just in case you're curious - remembering that your program is already working (although it may not be working the way you thought it was). Your program Your program condensed Last - to copy a program, right click on the program name (in the program tree) and select "copy to clipboard" from the popup menu.
  6. Porscheguy, This isn't exactly what you were looking for, but it may suffice in the interim. The following appears to work when I tested with a disconnected KPL. It's an example of how we are not supposed to program - a "then" section that modifies the "If" conditions. Note that you must use a device direct command in the then section. A scene will not work since the ISY will not request an acknowledge for a scene. I used a short wait for test purposes. I would suggest using something a bit longer (30 seconds?) to allow any spurious noise (that may be affecting communication) to subside. Edit (additional notes): The variable is an integer type - it will not cause a trigger or event when it changes. Do not use a state variable as it will re-trigger the program each time it is incremented. Questions: 1) What devices are you having communication errors with (PLM Model/version, Insteon Model/version)? 2) Does the device controlling the pump actually turn off/on when commanded? Said differently, does the device respond to the command, but fail to communicate back to the ISY? Why do I ask the above - If you understand why the remote device is failing to communicate back to the ISY (spurious noise, etc) retries may be valid. If the problem is due to longer noise periods (TV's, refrigerators, well pumps, etc) a different approach is required. By changing the retry wait period in the above, you may be able to "bracket" the duration of the problem communication period. If the remote device is responding (on/off) but failing to communicate back to the ISY, there may be other workarounds.
  7. Hello Tekken, I recently received a 2487S as well. After reading your post, I wired it to an appliance cord - ever so slight buzzing with the relay on. No noise with the relay off. In order to hear the relay, I had to basically put my ear next to the switch. No way would I be able to hear it in when mounted in a box (but then I'm old). These do make a rather loud click when the relay switches. They are also rather DEEP. I didn't know that when I purchased them (rushed to get the 20% off). Smarthome does have a nice comparison of the standard depth vs these newer deep switches on their webpage. I just didn't read it. I may have to re-think where I'm putting these. A double or triple J-box will be tight.
  8. Michel and Lou, I was about to post back that I "sometimes" see the -1 log entry as well. After testing, I have to change that to "always". I had also wondered if this was associated with "differences" in some of my Icon switches. It is not. I've tested a SWL relay, SWL dimmer, and Icon relay. They all generate the -1 log error. Curiously, there is no indication of an error in the event monitor: Event Monitor Fri 12/09/2011 09:39:26 AM : [iNST-ACK ] 02 62 16.10.95 0F 30 FA 06 BEEP (FA) Fri 12/09/2011 09:39:27 AM : [iNST-SRX ] 02 50 16.10.95 13.22.F9 2B 30 FA BEEP (FA) Fri 12/09/2011 09:39:27 AM : [standard-Direct Ack][16.10.95-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 12/09/2011 09:39:28 AM : [iNST-ACK ] 02 62 16.10.95 0F 30 FA 06 BEEP (FA) Fri 12/09/2011 09:39:29 AM : [iNST-SRX ] 02 50 16.10.95 13.22.F9 2B 30 FA BEEP (FA) Fri 12/09/2011 09:39:29 AM : [standard-Direct Ack][16.10.95-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 12/09/2011 09:39:30 AM : [iNST-ACK ] 02 62 16.10.95 0F 30 FA 06 BEEP (FA) Fri 12/09/2011 09:39:31 AM : [iNST-SRX ] 02 50 16.10.95 13.22.F9 2B 30 FA BEEP (FA) Fri 12/09/2011 09:39:31 AM : [standard-Direct Ack][16.10.95-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Error Log 1st Floor / Mud Room Beep 250 Fri 2011/12/09 09:39:27 AM Program Log 1st Floor / Mud Room Beep 250 Fri 2011/12/09 09:39:27 AM Program -1 1st Floor / Mud Room Beep 250 Fri 2011/12/09 09:39:29 AM Program Log 1st Floor / Mud Room Beep 250 Fri 2011/12/09 09:39:29 AM Program -1 1st Floor / Mud Room Beep 250 Fri 2011/12/09 09:39:31 AM Program Log 1st Floor / Mud Room Beep 250 Fri 2011/12/09 09:39:31 AM Program -1
  9. Hello Frank, The proper Access Code is the "User Code(s)" as defined on page 14, section 2.3 of the Elk manual. If you use another code (ELKRP or Installer) or an incorrect code the ISY will still be able to "Monitor events" but will not be able to arm/disarm the system. User Code 1 (normally the Master) should always work. Other User codes (that you have defined), may not have privileges to arm/disarm the system depending on how you set them up. An easy way to check this is to activate the "ELK Console" from the ISY admin screen. If the ELK Console allows you access with the user code, and you are able to arm/disarm the system, the ISY should work with the same access code.
  10. IndyMike

    Query

    Lee and Oberkc, I'm sorry, but I must respectfully disagree - A scene can be queried and it will produce status updates for each device within the scene. The scene itself does not have a status. I use the following two programs to ensure that my outdoor lights are not inadvertently turned on during the day. The Outside Daytime program will trigger anytime the ISY recognizes that one of my outdoor lamps has been turned on. Program Outside Daytime If From Sunrise + 1 minute To Sunset - 10 minutes (same day) And ( Status 'Outdoor / Entry Deck' > Off Or Status '1st Floor / Mud KPL 1 - Entry Garage' > Off Or Status 'Outdoor / Entry Patio' > Off Or Status 'Outdoor / Entry Porch' > Off ) Then Wait 2 minutes Set Scene 'SC Ouside Night' Off Else - No Actions - (To add one, press 'Action') The Poll program is only necessary if the ISY "missed" an outdoor lamp being turned on. The query will interrogate each device in the scene. If there is a status change in one of the devices ( > off) the Outside Daytime program will trigger to turn off the scene. Program Outside Daytime Poll If From Sunrise + 1 minute To Sunset - 10 minutes (same day) And Time is Last Run Time for 'Outside Daytime Poll' + 30 minutes Then Set Scene 'SC Ouside Night' Query Else - No Actions - (To add one, press 'Action') The following is the Event Viewer output after running the Query program on the Scene. It shows each device in the scene being interrogated and responding with it's status. Tue 11/29/2011 04:14:30 PM : [iNST-ACK ] 02 62 0C.7A.38 0F 19 00 06 LTSREQ (LIGHT) Tue 11/29/2011 04:14:30 PM : [iNST-SRX ] 02 50 0C.7A.38 13.22.F9 2B 00 FF (FF) Tue 11/29/2011 04:14:30 PM : [standard-Direct Ack][0C.7A.38-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Tue 11/29/2011 04:14:30 PM : [iNST-ACK ] 02 62 03.42.48 0F 19 00 06 LTSREQ (LIGHT) Tue 11/29/2011 04:14:31 PM : [iNST-SRX ] 02 50 03.42.48 13.22.F9 2B 00 00 (00) Tue 11/29/2011 04:14:31 PM : [standard-Direct Ack][03.42.48-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Tue 11/29/2011 04:14:31 PM : [iNST-ACK ] 02 62 0C.77.D2 0F 19 00 06 LTSREQ (LIGHT) Tue 11/29/2011 04:14:31 PM : [iNST-SRX ] 02 50 0C.77.D2 13.22.F9 2B 00 00 (00) Tue 11/29/2011 04:14:31 PM : [standard-Direct Ack][0C.77.D2-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Tue 11/29/2011 04:14:31 PM : [iNST-ACK ] 02 62 09.8C.CD 0F 19 00 06 LTSREQ (LIGHT) Tue 11/29/2011 04:14:32 PM : [iNST-SRX ] 02 50 09.8C.CD 13.22.F9 2B 00 00 (00) Tue 11/29/2011 04:14:32 PM : [standard-Direct Ack][09.8C.CD-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Tue 11/29/2011 04:14:32 PM : [iNST-ACK ] 02 62 09.8C.CD 0F 19 01 06 LTSREQ (01) Tue 11/29/2011 04:14:32 PM : [iNST-SRX ] 02 50 09.8C.CD 13.22.F9 2B 00 D4 (D4) Tue 11/29/2011 04:14:32 PM : [standard-Direct Ack][09.8C.CD-->ISY/PLM Group=0] Max Hops=3, Hops Left=2
  11. Hello Michel, I was using the "right click" method as well. The problem only occurs after you use the "compare" function within the device links viewer. After using the compare, the ISY link viewer appears to hang - presents the same information for all devices.
  12. Michel, There appears to be a refresh problem with the ISY Link Table Viewer under 3.1.13: 1) Upon initial entry into the admin console everything works fine. Viewer correctly displays the ISY links for various devices. 2) Performing a device link table scan correctly shows device links. 3) Performing a compare correctly opens the ISY Link Viewer and compares links. 4) After step 3 (compare) the ISY Link Viewer will "stick" to whatever device was compared. All devices will appear to have the same links. Exiting/re-entering the admin console clears the problem. Not a huge deal - we have a work around. Hope you and the team managed to fit in some down time over the Holiday, IM
  13. Michel and UDI Team, Thank you for all the hard work. 3.1.13 Installed without issues. ELK Arm/Disarm, Exports, and Zone queries appear to be working nicely. I attempted to diagnose the problems reported by weunch and FRR regarding the ELK "connected" function and learned a couple of things - 1) Initially the program below indicated false. I assumed this was due to it not being triggered. 2) Fired up ELKRP2 and connected to the ELK. The program did not trigger. It was at this point that I realized that the ISY could still communicate with the ELK with ELKRP2 running. I didn't realize this was possible. Communication appears to be one-way. The ELK communicate state changes to the ISY, but ISY cannot Arm/Disarm the ELK. 3) Physically disconnected the ELK from the network. The ISY displayed a warning message in the top menu bar area and triggered the program. This appears to be automatic - the user does not need to manually query to determine the status. 4) Reconnecting to the Elk again triggered the program which now evaluated to True. If Elk System is Connected Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') I'm hoping that the source of the confusion is the fact that running ELKRP2 does not fully disconnect the ISY. IM
  14. jetjock, There is a device mapping problem with the ELK export in 3.1.12. Please see Lou's post here - http://forum.universal-devices.com/viewtopic.php?f=25&t=7342. I exported with 3.1.12 and had the same issues that Lou reported. I f you have already exported/imported to the elk, please revert to 3.1.10, export/import, and things should be back to normal.
  15. frustratednon-geek, Knowledgeable Fathers are a wonderful thing to have. I still consult my Father on electrical issues (he's in his mid 80's now). Spent 30 years in Aerospace and, as luck would have it, 10 years as Chief Engineer in a local Hospital. I have 30+ years in Aerospace, but I still listen and learn. I'm still a bit concerned about your fixture ratings - the switch must be rated for the fixture, not the installed bulbs. If your fixtures are rated for 60W bulbs, an 1800W switch is appropriate. If the fixture is rated for 90 or 100W bulbs you are at or over the switch rating. My chandeliers are rated for 6-100W bulbs (I have 60W installed). Even though my installed load is 360W, I use 1000W dimmers because that is what the fixture demands. Check yours to make sure. If the worst happens, you want to make sure that an insurance adjuster does not point to this switch.
  16. Frank, Have a look at the ELK firmware as well. I had similar symptoms prior to upgrading to the latest M1 and EXP firmware. I also had to upgrade the ELKRP software to R2 (to support the new firmware). After upgrading, I get the security bar and the ELK can communicate with the ISY. Reverse (ISY to ELK) is still a problem. Current ELK Config: M1G Firmware: 5.2.8 Bootware: 3.3.6 Hardware: 0.13 XEP Firmware:1.3.28 Bootware: 1.2.0 Hardware: 1.0 Symptoms: 1) Events generated by the Elk are recognized by the ISY. 2) The Elk does not recognize Insteon lighting events. 3) The ISY cannot arm/disarm the ELK.
  17. Hello frustratednon-geek, Since this is a commercial installation, please proceed carefully. The switch rating should be matched (exceed) to the maximum fixture load. The rated fixture load may well exceed the 60W bulbs that are currently installed. If you "trust" the original dimmer installation (1800W) do not install a device with a lower rating. If you are unsure about the installation, look up the max fixture rating or get out that ladder (that you don't yet have). I was not aware that SH was offering a 20A KPL. From the website, it lists a 1800W incandescent capacity. Again, please be careful and check the UL label on the back of the switch. I have switches that are rated differently from the information presented on the website/product manuals. An inspector will not care about websites or manuals - he will look at the UL label which indicates what the device was certified to.
  18. Hello gatchel, Thank you for the info. I'll give the code a try. I had assumed that since it was working in previous revisions, the ISY "remembered" the code.
  19. Michel, Caught your note regarding the ELK Firmware. After upgrading to 3.1.12, the ISY cannot communicate with my ELK (ELK addon module is not yet installed). I get looping retry errors in both the Event Monitor and the Error log: Event Monitor Thu 11/17/2011 07:34:51 PM : [Elk ] ELK-WAIT Waiting for retry 1 of 3 [0Bsd18002005C\r\n] Thu 11/17/2011 07:34:59 PM : [Elk ] ELK-WAIT Waiting for retry 2 of 3 [0Bsd18002005C\r\n] Thu 11/17/2011 07:35:08 PM : [Elk ] ELK-WAIT Waiting for retry 3 of 3 [0Bsd18002005C\r\n] Thu 11/17/2011 07:35:27 PM : [Elk ] ELK-WAIT Waiting for retry 1 of 3 [0Bsd18003005B\r\n] Thu 11/17/2011 07:35:35 PM : [Elk ] ELK-WAIT Waiting for retry 2 of 3 [0Bsd18003005B\r\n] Thu 11/17/2011 07:35:44 PM : [Elk ] ELK-WAIT Waiting for retry 3 of 3 [0Bsd18003005B\r\n] Error Log Thu 2011/11/17 07:33:16 PM System -170001 [Network] Established Thu 2011/11/17 07:34:28 PM System -170001 [uDSockets] HTTP:31 error:6 Thu 2011/11/17 07:34:32 PM System -170001 [uDSockets] HTTP:31 error:6 Thu 2011/11/17 07:34:37 PM System -170001 [uDSockets] HTTP:31 error:6 Thu 2011/11/17 07:34:41 PM System -170001 [uDSockets] HTTP:31 error:6 Thu 2011/11/17 07:34:46 PM System -170001 [uDSockets] HTTP:31 error:6 Thu 2011/11/17 07:34:50 PM System -170001 [uDSockets] HTTP:31 error:6 Reverting to 3.1.10 corrects the issue. My ELK firmware is at 5.1.20. Is the older firmware an issue even without the ELK Module Installed? I fully plan on purchasing the ELK module. Just trying to make sure I don't have a different problem. IM
  20. Hello Lou, I was all set to chime in and agree that paralleling the passive coupler and Line to Neutral outlets off the 240V dryer branch was a definite code violation. Now I'm not at all that sure. The above qualifies as a multiwire branch circuit and is covered by Article 210.4 of the NEC code. There appear to have been a number of revisions to this section in recent years. 1999 NEC Code, 210.4 Multiwire Branch Circuits. [*:30rmpb4w](A) General. Branch circuits recognized by this article shall be permitted as multiwire circuits. A multiwire circuit shall be permitted to be considered as multiple circuits. All conductors shall originate from the same panelboard or similar distribution equipment. FPN: A 3-phase, 4-wire, wye-connected power system used to supply power to nonlinear loads may necessitate that the power system design allow for the possibility of high harmonic neutral currents. [*:30rmpb4w]( Devices or Equipment. Where a multiwire branch circuit supplies more than one device or equipment on the same yoke, a means shall be provided to disconnect simultaneously all ungrounded conductors supplying those devices or equipment at the point where the branch circuit originates. [*:30rmpb4w]© Line-to-Neutral Loads. Multiwire branch circuits shall supply only line-to-neutral loads. Exception No.1: A multiwire branch circuit that supplies only one utilization equipment. Exception No.2: Where all ungrounded conductors of the multiwire branch circuit are opened simultaneously by the branch-circuit overcurrent device. Your current dryer installation is covered under Exception #1 (Line to Line load - 240V). You are proposing to add Line to Neutral loads to this branch. This may be covered under Exception #2 if your breaker opens both legs of the circuit simultaneously due to an overcurrent in either leg. Code Updates - Found the following on the Mike Holt site (http://ecmweb.com/nec/code-basics/electric_branch_circuits_part/ Multiwire branch circuits. Multiwire branch circuits are circuits that have more than one ungrounded conductor sharing a common grounded (neutral) conductor. These circuits are very beneficial in that they use less material, result in a lower circuit voltage drop, and ultimately result in cost savings. They do, however, have some specific Code rules that can't be ignored. To prevent inductive heating and reduce conductor impedance for fault currents, all multiwire branch-circuit conductors must originate from the same panelboard or distribution equipment [210.4(A)]. Multiwire branch circuits must supply only line-to-neutral loads [210.4©]. [*:30rmpb4w]Exception 1: A multiwire branch circuit can supply line-to-line utilization equipment, such as a range or dryer. [*:30rmpb4w]Exception 2: A multiwire branch circuit can supply both line-to-line and line-to-neutral loads if the circuit is protected by a device (multipole circuit breaker) that opens all ungrounded conductors of the multiwire branch circuit simultaneously (common internal trip) under a fault condition. If the continuity of the grounded (neutral) conductor of a multiwire circuit is interrupted (open), the resultant over- or undervoltage could cause a fire and/or destruction of electrical equipment. See 300.13( for the requirements relating to the continuity of the grounded (neutral) conductor on multiwire circuits. From that above NEC code revision (date??) - you are allowed to combine Line to neutral and Line to Line devices on a multiwire branch circuit. You'll need to determine the following: 1) What revision of the code applies to your area. My area uses 1999 base code with pieces of recent code. While I believe it could be installed safely, I would expect a lot of flak from my local inspector. 2) Whether there is a code exclusion preventing the use of dedicated appliance circuits (dryer) with 120V line to neutral branches. I don't have a full copy of current code to verify this. 3) Whether your current installed breaker/wiring will support the addition of 120V legs. This is a multi-part question - [*:30rmpb4w] Your total loading on the conductor and breaker cannot exceed NEC requirements. This was a dedicated circuit to your dryer. You are now changing the application and different rules will apply. [*:30rmpb4w] Most importantly - you will need to ensure that your 120V (Line to Neutral) branches will trip the breaker in the event of a Line to Neutral overload. This is covered under 210.19 (A) (4) http://ecmweb.com/nec/code-basics/branch-circuits-nec-requirements-20110201/ In summary, I can't say this would be a violation. On the flip side, I can't say that it would be code compliant either. It depends on your local code and your particular installation. My advice would be to call someone knowledgeable in local code and installation - have any neighbors in the business?
  21. I don't understand how you are coupling the phases. I believe my house is a fair amount smaller than yours. There are times when I can couple through the utility transformer well enough to communicate across phases. This is not reliable for long durations. Simply put, I would expect your performance to be worse than mine (with no coupling) given the increased size of your home. The XPCR is an X10 active repeater - it will not work for insteon. The repeater monitors X10 one one phase and then repeats it on the opposite phase. Since the repeater does not understand Insteon, it will not repeat the signal.
  22. Hi Lou, From our previous conversations, I've got a fair idea of the size of your home and installed equipment... I have to say here that I'm in Lee's camp on this one - I'm surprised your system is functioning. The current Smarthome 2406 hardwired Insteon Phase coupler is an X10 coupler. It previously carried a different model # and was advertised as an X10 coupler - the internal components are identical. Some X10 couplers are a bit different - the ACT CP-000 uses twin tuned transformers to couple the signals across phases. Elegant, but it actually performs a bit worse than the Smarthome model. Your X10 coupler should help (assuming it's passive). Were it me, I would try locating it as close to your PLM as possible. I say should because I don't understand how things are functioning now. IM
  23. Lou, You've already answered the question. Reading device link tables is a communication intensive action that takes a fair period of time. If your system was having communication problems you would likely have receive the dreaded "xxx failed to communicate" error. I have a excel macro that can post process the event viewer results from a link table scan. It rolls up statistics on the number of hops required throughout the process. If you're interested, PM me and I can give you instructions. Regarding your PLM - is it a dual band unit?
  24. That was my point. The SWL didn't hear the ack in 1 hop (it took two) which resulted in the SWL message being sent to the PLM twice. On the second ACK from the PLM, it allowed for more hops, so it got through to the SWL. So I was trying to get the ACK to go through in one hop (not 2). Not knowing the path taken, I consisdered that the rf signal lincs may have been involved. If using a dual band plm takes one hop out versus two signal lincs, then that was my idea. My mistake - I thought you were trying to improve communications to the PLM when the problem is actually in the opposite direction. A dual band PLM communicating to a dual band SWL might eliminate one hop. A dual band PLM to a Accesspoint would (I believe) still require one hop. Based on my subjective experience, I can would say that the dual band PLM is not as effective a RF receiver as and accesspoint. I do not know how the two compare when transmitting. ELA and I have been having a sidebar conversation on this and he has brought up a good point. Insteon devices are characterized for 3.2 Vp-p into 5 ohms. If you had a local signal absorber (plug in device with a EMC cap) at or below 5 ohms it would reduce the output of your PLM. In short, please police your PLM circuit for potential absorbers. This is really interesting. You may be one of the lucky few that has a low impedance path through your utility transformer (rare but it does happen). I am able to communicate through the transformer "at times". If I stress my system (turn on various CFL loads) my I break the system. My phase coupling is through a hardwired passive coupler (similar to Tim's). I have also been playing with a accesspoint close coupled to the dual band PLM. I've been performing link table scans of some of my KPL's and post processing the Event viewer to determine communication efficiency. I'm still playing with this, but I have a number of test runs that indicate that adding the accesspoint increases PLM retries. I will confess that I do not understand how the accesspoints/dual band features operate and am struggling to come up with a theory why RF coms would result in retries. The best I can come up with is a difference in powerline data VS RF data causing the PLM to throw up it's hands and retry the transmission. Would you mind trying some link table scans on your SWL to see how reliable the comm's are? IM
  25. Lou, If I understand Lee's diagnosis correctly, this is not a HOP count situation - 1) The PLM heard your SWL on it's original broadcast and activated your program. The PLM attempted to acknowledge, but the cleanup command was sent with a Hop count of 1. The PLM had to respond with a hop count of 1. 2) The SWL did not hear the PLM's acknowledge, and sent a second cleanup message to the PLM with a Hop count of 2. This activated your program a second time and caused the unwanted effects. The PLM acknowledged a second time and your SWL apparently heard the acknowledge with a hop count of 2 (I didn't try a third time). These are separate communications. The issue is that your SWL can't hear the PLM with a hop count of 1. Noise and signal absorbers act differently on transmitters and receivers - 1) A signal absorber close to a transmitter will normally not prevent devices from hearing it's transmissions. This is because the transmitter is capable of driving the load of the absorber. 2) A signal absorber close to a receiver will draw down incoming signal levels due to the impedance (resistance) of your home wiring. 3) A noise source close to a transmitter will have little affect on it's ability to transmit effectively. 4) A noise source close to a receiver can interfere due to the decreased level of the inbound signal. From the sounds of things, your PLM can listen and transmit effectively. At the opposite end (your SWL) the signal is either being absorbed for interfered with by noise - normally both with exist. If your SWL is within RF signal range, you could try moving a accesspoint to the same circuit. This could improve the signal/noise ratio to the point where the SWL could hear the PLM on one Hop. Not a fix - but it would help to isolate the problem. IM Edit: To answer your question on a 0 hop configuration - The only way that I know to accomplish this is with a passive coupler in close proximity to the PLM. The signal will be coupled to the opposite phase on the initial transmission. This would allow devices on both phases to repeat the signal on the first HOP. Do you know whether your SWL is on the opposite phase from your PLM?
×
×
  • Create New...