ELK <> ALC Interface

[felixrosbergen]

ok folks..

I've started to do some experimention on my ELK/ALC setup since there are quite a few things not documented or clear about this. I'll post as i progress, hopefully this will be usefull to somebody at some point.

My current setup is a direct connection from the ELK to the ALC system using the special ELK<>ALC controller/interface module (will add part number soon) that sits directly on the ELK databus. This part takes the place of the 3 components that used to be needed for this connection (ALC Controller, ALC Serial module, ELK M1-XSP). I am having some odd issues with my setup and i plan to purchase the parts needed for the 'classis' setup soon so that i can test it that way as well.

For each section I'll indentify the setup used. ELK<>ALC will identify the direct conenction explained above. ELK<>Serial<>ALC will identify the 'classic' method. I also use CQC and will provide my notes on that as well. The goal is to get a system that is reliable (i.e. hardware based control), flexible and user friendly.

In detail my configuration is ELK<>Databus Hub<>ALC/ELK Interface <> ALC expander (to create 3 additional branches) <> ALC Distribution Module (for landing of the field wiring and interconnecting LV aux wiring).

The basic functionality between the ELK and the ALC system works flawlessly. Based on ELK rules the ELK can turn lights ON and OFF, set them to certain levels, etc. In 6 months time I don't think a light has ever not come on when it was supposed to. Within CQC all ELK light related activities work fine as well.

ELK<>ALC Configuration
- Current issues experienced
	- #1 - ALC dimmer do not always seem to remember their last state.  They 'should' come back to their previous state with a single ON tap, but sometimes they go full bright and sometimes to do remember.
	- #2 - When double tapping ON they lights shoudl go to full bright.  They indeed do this, but there is a short hestiation somewhere along the ramp-up.  I think the hesitation may be at the previous 'memory' point, but I cannot aboslutely confirm this.
	- #3 - Double tapping on OFF should results in a slow transition (approx 15 seconds) to off.  This does not work when the lights are connected to the system.
	- #4 - There is a bunch of things unclear on how the scene switches can be used for other things and how to control scenes.
	- #5 - The ALC net appear to take it's power from the ELK databus eventhough it comes with it's own power supply, with a growing net i don't particularly like this.
	- #6 - When through the ELK you command a light to go ON it goes on instantly, when you command it to 'SET TO 100%'  there is a nice smooth transition.  When you command it to go OFF it goes of instantly.  ELK does not permit you to use 'SET to 0%' through the ELK RP interface.  HOWEVER, when controlling the lights from CQC you CAN set the level to 0%.  Seems like this is mostly an ELK RP issue.

Some Experiments:
Experiment A - Completely standalone switch operation 
	- Setup
		   - Disconnect all LV wiring from a switch for complete standalone operation.
	- Results
		   - Besides the obvious issue of not having control other than from the local dimmer pad issues #1, #2 and #3 do not occur when the dimmer is not connected to the rest of the world. 
	- Preliminary conclusion
		   - The switches themselves seem ok

Experiment B1 - Remove connection between ELK and ELK/ALC Interface/Controller and remove power supply
   - Setup
		  - Disconnect the ELK/ALC Interface/Controller from the ELK Databus
		  - Remove the ELK/ALC Interface/Controller power supply
   - Results
		  - ELK/ALC Interface/Controller has no power whatsoever (status lights off, etc)
		  - Issues #1, #2 and #3 do not occur, operations is the exact same as in Experiment A, except the AUX switches are fully functional.
		  - Scene switches are not functional
   - Conclusion
		  - The LV wiring is OK ( i had tripple checked that anyway) since operation via AUX switches is working fine
		  - Since the scene swtiches are not functional it appears the actual scenes are stored in the controller and the scene switches merely translate the 4 button's state onto the ALC COMM loop.

Experiment B2 - Remove connection between ELK and ELK/ALC Interface/Controller and keep power supply
	- Setup
		  - Same as B1, except leave the power supply that came with the ELK/ALC Interface/Controller plugged in.
	- Results
		  - Exact same results as Experiement B1
	- Conclusion
		 - The power supply appears to have no function.  And YES, did put the meter on the 12v power supply and it does put out 15.5V.  I also plugged it into the 12VDC input on the ALC Bracn Expanded and this did not seem to have any affect either.

Experiment C - Power power to ELK/ALC Interface/Controller via the ELK databus, but no communication
	- Setup
		 - Remove the A and B wiring from the ELK/ALC Interface/Controller terminal blocks but leave the 12V connections
	- Results
		- Issues #1, #2 and #3 do not occur
		- Scene switches work (since the ELK/ALC Interface/Controller is powered up)
		- ELK cannot control the lights.  Duh !!!
	- Conclusion
		- Something about the communication between the ELK and the ELK/ALC Interface/Controller causes the ALC systemm to misbehave.

Experiment D - How to power the Elk/ALC Interface/Controller from the wall wart that came with it.
	   - Goal
				  - My controller didnt seem to want to be powered from the wall wart (see experiment B1 and B2) while AceCannons did this out of the box. The goal is to figure out the difference and how make it be powered from either source.  There is jumper (JP3) right above the 12vdc barrel connector which is not documented.	 
	   - Setup
				  - Normal configuration
				  - Case A:  With the JP3 in position A remove the ELK connection and plug in the wall wart
				  - Case B:  Do the same with JP3 in position B.
				  - Test lighting functonality (comunication between ELK and ligthts and scene switch operation) for both cases.
	   - Results
				   - With JP3 in position A and removal of the ELK connection the ELK/ALC Interface/Controller goes dead.  Insetting the barrel connector from the wall wart does not make it come alive, but inserting the power supply barrel connection AND switching the JP3 jumper to position B will allow it to be powered and functional without the ELK connection.
				   - Upon reconnection to the ELK with JP3 in position B (i.e. power from the wall wart instead of the ELK) the system functions as normal. 
		- Conclusion
					- JP3 allows you to select from which source you want the ELK/ALC Interface/Controller to be powered.  If the connection to the ELK databus is present the communication between ELK and ALC will work in either case.

		 - other notes
				   - I did this test by pluging / unplugging the RK45 from the databus hub so whenthe communication connection was there technically the 12v from the ELK is also there.  I have no idea if this causes any 'backfeeding' or if the ELK/ALC interface/controller is now powered from both at the same time.  My guess is that the power is isolated (i.e. no backfeeding).  It would have to be this way since a very large ALC install with multilpe powered hubs would otherwise create too much of a draw on the ELK system

 

[felixrosbergen]

OK, now onto the scene switch operations.

First of all, if you're planning your pre-wire and plan to use ALC AND scene switches AND control via ELK then keep in mind that the scene switches MUST be on ALC branch 1. So keep this in mind when planning your wiring especially if you plan to have more than 1 branch of ALC. If i had to do it again i would plan for a total of 4 branches, put all the normal switches on branches 2,3,4 and put all the scene switches on branch 1. This woudl mean you will need and extra set of conductors to the locations where you have normal ALC switches AND a scene switch. The scene switch gets power from the HV and only connects to the COM+ and COM- of the ALC system so you only need 2 conductors. Depending on your configuration you have have these as spare in a cat5 run to the light switches or maybe you want to run an etxra cat5 where you have scene switches. There's other threads covering details on ALC pre-wire, these and the manuals provide pretty good guidance, but feel free to PM and I am happy to help out and save a fellow cocooner the hours of research i had to put in. ray:

Also when dealing with the scene switches through the ELK RP interface the X10 format adress only reflects Button 1's state/action. The X10 format adress for the other buttons on the same switch has a completely different adress (read the documents carefully on this or ask me, since it's rather obscure).

I also don't really know to to configure the ELK to reconize this is indeed a scene switch. Since the scene switch shows up as 4 independent X10 format adresses I defined each as an On/Off switch (options within ELK-RP are: Dimmer, Appliance, On/Off Switch, Other). I tried experiment S-C with all 4 settings and it made no difference.

So...onto the experiements:

Experiement S-A:  Normal scene switch operations
   - Setup
		- ALC install as described in post#1 using ELK<>ALC direct interface.
   - Results
		- Scene switches can be programmed and recall scene as per the instructions/manual.  Programming via the scene switches is a bit of pain since you have to put the scene switch into programming mode and then run around to set all your light switches to the desired level.  There is some sort of scene programming software out there, but i haven't used it or know of it's capabilities.
		- Important to note!!  
			  - When recalling a scene the various lights involved in the scene change their state (nearly) simulatenous.  
			  - When a scene calls for a light to be turned of, the light does a smooth transition to off. Rather than the abrupt method that happens when you just press OFF on the switch toggle.
	   - Conclusion
		 - No real conclusion other than that this woudl be considered the baseline case and things appear to work as advertised so far.

Experiement S-B:  Capturing Scene switch button actions for other HA fun
		- Goal
	 - To find a way to capture the scene switch button actiosn to allow it to be used as a trigger for things other than lighting (e.g. turn TV off, mute whole house audio, etc).
		 - Setup
	 - Same as experiment S-A.
	 - Within ELK-RP I programmed the following rules:
		WHENEVER 1-HAL-SS1-4 [164[K4] IS TURNED ON THEN ANNOUNCE On [vm310]
		WHENEVER 1-HAL-SS1-4 [164[K4] IS TURNED OFF THEN ANNOUNCE Off [vm311]
						 	 In which '1-HAL-SS1-4' is the name i gave the scene switch button in ELK (1st floor, HAL, Scene Switch 1, Button 4), '[164[K4]' is the X10 format adress that ELK will put in for you.
		  - Results
	 - Repeatedly pressing the button 4 woudl make the ELK say 'On' over and over again, never an Off. 
	 - The lighting scene associated with the button still executed
		   - Conslusion
	- It appear the button is a momentary contact of sorts and the way ELK monitors it via rules only lets you capture the On signal.  This is all pretty sensible.  HOWEVER:  when using CQC and viewing the lighting field for the Scene switch the field will initially be 'False' and when the button is pressed it will go 'True' and WILL NEVER GO BACK TO 'FALSE'.  This is a bit nasty.  I think there is a way around it by making an ELK rules to sets a virtual output to ON for a few seconds.  This will be an experiment to add to the list.

Experiment S-C:  Trying to trigger ALC lighting scene programmed through the scene switch from ELK
		  - Goal
	 - Make it so that pre configured scene are stored within the ALC system (i.e. configured through the scene switches) which can then be triggered through the ELK (and presumably therefore by CQC as well).
		  - Setup
	  - Same as before.
	  - Programmed the following rules in ELK RP
		WHENEVER Kitchen Slider (zn4) BECOMES NOT SECURE THEN TURN 1-HAL-SS1-4 [164[K4] ON
		  - Results
	 - On opeming the Kitchen slider the lighting scene is not activated, but the ELK spoke a  beatifull 'ON' since i had not removed the rules from experiement S-B yet.  So i know a ON command was sent to that X10 adress.  The modified the rules to set the scene switch OFF and another time i used TOGGLE. None triggered the lighting scene.
		   - Conclusion
	 - At this time i have no idea how to trigger a stored ALC lighting scene from the ELK.  There is a concept of 'virtual scenes' which i need to look into more to see if this brings a solution.

Experiment S-D:  Making lighting scenes within ELK
			   - Goal
							  - Since triggering a ALC lighting scene from the ELK appeared not possible based on what i know at this time and I do know I can capture the scene switch button status I figured why not use ELK rules to create the lighting scene and then have ELK and/or the scene switch button trigger the rule.
			   - Setup
							 - I am not going to quote all the rules verbatim, but i set up some rules to capture the scene switch button and i made an 'Autmation Task' that has several lights wanted levels in there.  ELK rules can trigger the automation task and another ELK rule makes the scene switch button trigger the same task.
			   - Results
							 - Somewhat of a success.  Everything works as intended EXCEPT the lights change one at a time in the squence according to the rules as a programmed.  The lighting changes are executed at about 1 second intervals, so my 10 light scene took 10 seconds to be executed.  This does not have the smooth/high end feeling to it that I am looking for and that the lighting scenes as programmed through the scene switches bring.	Under the ELK-RP Automation / Lighting tab where you give your lights names, etc there is a column for 'Opt' which the text on that tab describes that putting an X there eliminated the delays between lighting command (yeah, just what i'm looking for) but also warns that it's not for M1-XSP (bummer since the ELK/ALC Interface/Controller is essentially an M1-XSP plus the ALC modules all on one board).  In any case I put the X's there to see what happens. 

With the delay's removed only some of the lights programmed within the same rules turned On/Off as needed.  It was not reproducible which lights and running the rule multilpe times in a row (using ELK-RP 'Test Rule') woudl eventually turn most lights (not all) On or Off.
			   - Conclusions
						   - Using ELK rules to control the lights provides some rudimentary control and works well for single light changes (e.g. it works fine to turn the outside lights on at night, etc) but for more complex lighting scene the delays between commands cause it to look 'clunky' and removing the delays causes it to not work reliably.  The 1second delays seem rather exessive and i've asked ELK (Spanky) if this can be made less or be made configurable (e.g. at 200ms or so the visual effect might be a lot better).  I can't imagine any lighting processor needed 1000 miliseconds between commands.  Maybe there is something that can be done about the baud rate of the interface or soemthing, but it appears to be limited on the ELK side.  In any case I received no response from ELK.

OK..that took care of my sunday afternoon..stay tuned for more.

 

[rbroders]

MavRic this is awesome! Thanks for spending your Sunday doing this!

I'm doing a huge remodel and am planning a massive ALC installation (94 loads + 58 AUXes). I'm going to run conventional 3-way wiring to my AUXes so I can revert to conventional switches without tearing apart my walls in case ALC goes belly up (yeah, I'm a wimp).

I will also be using ELK and CQC. My current plan is zero scene switches (the wife and I just believe one button goes to one light). On the rare occaision that I want a lighting scene I'll invoke it from my CQC touchscreen, so your "programmatic scene" test is exactly what I want. I'll bet the CQC direct version works a lot better... Speaking of scenes, I think ALC also supports 16 "global" scenes, but I don't know all the details. Also, I there seems to be some ability to address all lights on a given branch simultaneously via address 0, is that exposed anywhere?

I prefer to have the ELK control the lights, but since there seems to be serious problems with the ELK <> ALC connection, I may be willing to have a direct CQC <> ALC connection instead, or possibly both via two serial interfaces on the ALC bus, or a serial splitter (yuck).

Can you try some latency tests as well: hallway motion detector turns on light. It has to be fast or you are arleady gone by the time the lights come on.

--Bob

 

[felixrosbergen]

Hi broders:

As far as I know you cannot have 2 serial interfaces on the ALC bus. I think you could have a A/B type switch possible controlled by ELK OR I've been reading about serial routers which essentially join and split serial signals so theortically both can 'talk' at the same time. I have no idea if it will actually will work but we'll see. I have already created a'heartbeat' between CQC and ELK so ELK knows when CQC is not online. Based on this it coudl then take over lighting control whereas it normally lies with CQC. In the end i may be confortable enough to just have CQC control the lights. It's not like the light wont work when the server is down, you'd just have to press the button like the old days, with ALC even the 3 ways would still work.

My house was wired conventionally with Cat5 added to the mix so I also always revent back to traditional. You can check out my showcase, i actually ran conduits to many locations so i could pull cat5 later as needed, this also circumvented a bunch of code/inspector issues.

I'm gonna plug away at this a bit more, but soon i think i'll get the traditional ALC controller and serial interface. Once i have that i can test both that with the ELK (using an M1XSP that i alreadu have) and the direct CQC connnection. From what i've heard from beelzerob things shoudl work nices when done directly from ALC. I still need to look into these Global or Virtual scenese some to see if they provide a solution.

94 loads..wow that is a good size installation.. I'm at 15 and will ultimately reach maybe 30 to 40 or so. With 94 loads and the branch limits you'll need to be pretty carefull about cable length limits and use power hubs and such i would think. What is your implementation schedule like? It might be a few weeks before i get to the direct ALC<>CQC connection part. Actually AceCannon just started his install and he's using the ELK<>ALC method as well, so i am hoping he will chime in to either confirm some of my observation or debunk them which means my situation might be a one-off or fluke.

 

[rbroders]

Yeah, I'm a little worried about the size of my setup, but since I don't care about scenes I figure I can always split it into two (or more) smaller systems. Heck even if you care about scenes, just split the system such that your scene/loads don't cross systems. I just finished the layout for my top floor. It has 30 load switches in 17 boxes. I figure that my runs need to average 30' or less to stay under 500' total polling loop length for this branch. I plan on using the enhanced branch hubs (mostly for debugging), but I don't know what that does to the length limitation...

Showcase looked good! How do you plan on covering the 4th position in your box? I noticed your LV connections are kind of half in/half out of the box. My electrician insists on doing them all in the box and then covering them with shrink wrap tubing (splices and all). The mudrings don't really allow anything outside the boxes...

You are probably right that you can't have two serial interfaces on the same ALC system, but it would be interesting to try it. Maybe Tony can make it happen. My implementation is still a month or two out.

--Bob

 

[felixrosbergen]

We'd have to check with Beelzerob, but maybe when controlled by CQC you could just have 'networks' and have 2 instances of the driver going.

From ELK's point of view there is no way to have more than the known limits since this is how many adresses are allocated for lighting within the ELK.

The 'lv wires' on top of the box is the recommended way by Tony and keeps all the LV out the box. The 4th gang/hole is there for scene switches, but I may not put in as many as i thought. You just buy a cover plate that is the right size and fill it with a decora blank plate.

 

[rbroders]

I don't really like the way Elk handles the lighting, because it only understands X10 and tries to map all other lighting solutions to an X10 framework. No wonder you are having trouble getting scenes to work!

I'm totally a fan of the LV outside the box concept. I like the way you route the LV into the box and then sneak it out the top to make your connection. Do I see some minor cutting in the upper right corner of your box?

My electrician (and my city inspector) prefer the inside the box method. He wants to use oversized boxes with mud rings to get everything to fit (though the light switches near pocket doors are problematic). His plan is to sheath the incoming CAT5 with oversized shrink wrap, slide it down (so it extends several inches outside the box), make the connections, and then slide it back up all the way to the back of the switch (with some tape to keep it in place). This way the LV is completely sheathed inside the box. It occurs to me that this will only work if each CAT5 is wired to only one switch. To keep my polling loop below 500' I need to have one pair connected to the polling loop pair from each switch. Hmmm, I suppose I could loop it back into the box four times so each connection can have its own sheath...

How did you wire your switches? It looks like you have three CAT5s coming into the box, but only two ALC switches so far. Do they share the polling loop wires?

Thanks -- Bob

P.S. My wife would kill me if I had a 4-gang plate with only three switches on it. Go figure...

 

[AceCannon]

MavRic:

1. Elk vs ALC power. I suspect the 12v inputs (one from Elk bus and one from ALC wall wart) feed in to the same place. The only thing being powered is the ALC controller hardware, which is certainly very minimal current (the dimmers themselves are of course powered from HV locally). Since my Elk is not connected yet, the lighting controller is being powered from the wall wart, but I presume it could be removed and powered from the Elk bus without a problem. I will probably leave it plugged in even after the Elk is connected.

2. CQC trapping scene switch presses, T/F: CQC detects the press, status becomes TRUE. You could then have CQC take whatever action you desire, then CQC could reset the status to FALSE. It would then be ready for the next scene switch keypress.

3. re CQC server being down: of course, the ALC controller would still be up since it is hardware. Scene switches would still work. Just the "CQC scenes" (assuming they can be made to work) would not be available.

4. I will certainly be trying out the Elk<>ALC aspects as soon as I can get that part connected up. CQC will be at least 1-2 weeks, maybe longer.

Rbroders:

1. I can't stress enough how nice scene switches are. The wife totally did not understand what it was all about throughout our entire construction project. I made her trust me, Now she LOVES them. I put all our kitchen switches in the pantry (out of sight), so the only switch visible in the kitchen is the one scene switch. Controls 5 loads with one keypress. Very intuitive, very aesthetically pleasing. I cannot see a single downside. Please make sure you both understand this fully before deciding for sure "one switch per light". Probably gives my project the biggest WAF thus far. My biggest regret in the entire house project is not hiding our master bath switches in the linen closet, since there are a ton of them scattered throughout the bathroom.

2. Instead of the enhanced branch hubs, I used 66-blocks to terminate my LV ALC wires. Just a thought. Accomplished the same thing since bridging clips can be removed to take devices out of the loop without effecting the others (for debugging). However, I did use a branch hub (non enhanced) to get the ALC signal amplification that it purports to have.

3. LV wires in box. The drywallers leave barely any space at all between the top of box and the drywall. I made all my connections inside the box, but did not every strip a single LV wire. Used these little bean connectors (pic below) (?3 wire connector splices, 19-26ga wire). Multiple dimmers in the same box also share the same polling loop to reduce the number of conductors required. These connectors can join two wires together, or 3. So a third wire can jump to the next connector. Got them at Lowes - they are REALLY great. Also used them in my security install.

 

[felixrosbergen]

1. Elk vs ALC power. I suspect the 12v inputs (one from Elk bus and one from ALC wall wart) feed in to the same place. The only thing being powered is the ALC controller hardware, which is certainly very minimal current (the dimmers themselves are of course powered from HV locally). Since my Elk is not connected yet, the lighting controller is being powered from the wall wart, but I presume it could be removed and powered from the Elk bus without a problem. I will probably leave it plugged in even after the Elk is connected.

Do your ALC controller is not connected to ELK in any way and you have the PSU that came with it (Spectre 1000ma, 12vdc) connected to it and your scene work and you have status lights etc?

There is a jumper right above where the power connects, can you have a look at the position that that one is in? Maybe that jumper determines if the 12v is obtained from the ELK bus or the wall wart.

At the moment (without moving any jumpers) the wall wart will not power my controller.

My distribution module also has a 12vdc connector on it and it seems to not do anything either...maybe my PSU is bad, but the meter says it's putting out power so i doubt it.

 

[AceCannon]

Do your ALC controller is not connected to ELK in any way and you have the PSU that came with it (Spectre 1000ma, 12vdc) connected to it and your scene work and you have status lights etc?

There is a jumper right above where the power connects, can you have a look at the position that that one is in? Maybe that jumper determines if the 12v is obtained from the ELK bus or the wall wart.

At the moment (without moving any jumpers) the wall wart will not power my controller.

My distribution module also has a 12vdc connector on it and it seems to not do anything either...maybe my PSU is bad, but the meter says it's putting out power so i doubt it.

Yep all works fine without the Elk connected in any way. I am using the PSU that came with the ALC/Elk Controller. I will check the jumper when I get home, but meanwhile here is a pic of the setup - zoom in on the jumper and you can compare to yours, probably. FWIW, I did not change any jumpers from the factory defaults. As you can see from the pic, power goes from the controller to the distr hub through the short cat5e patch cable, then from the distr hub to the branch hub through the brn/brnwht twisted pair.

 

[rbroders]

I just don't see the benefit of scenes. If you are going to control five loads at the same time all the time, why not just wire them together and treat them as a single load? Then you can have the benefit of conventional switch appearance and dimming capability. My old house had scenes "dining, party, tv, night". When we used them we were always changing things - dining mode, but the chandelier a little brighter or dimmer than the level contained in the scene. The only one we used regularly was night mode for prowling around the house. Maybe I'll use one of the four "inputs" for that.

I like the 66 block idea, I think I'll go back to std branch hubs (I can't imagine pulling the thing off the wall to screw with the dip switches anyway). Based on the number of chips, I bet you need to use all nine outputs to take full advantage of the amplification. I'm also thinking of eliminating the "Lighting Distribution Module" completely and just making a CAT5 pigtail to go direct to the branch hubs.

Sure drywallers go tight to the box, but that is easily fixed no? I'm excited that I'm not the only one with LV inside the box though. Any chance you could send a picture of your box please. Your connectors look great, but the individual wires don't have sufficient insulation to remain unprotected in the box do they? My latest thought is 1 CAT5 per switch so the electrician doesn't have to think too much.

--Bob

 

[AceCannon]

I just don't see the benefit of scenes. If you are going to control five loads at the same time all the time, why not just wire them together and treat them as a single load? Then you can have the benefit of conventional switch appearance and dimming capability. My old house had scenes "dining, party, tv, night". When we used them we were always changing things - dining mode, but the chandelier a little brighter or dimmer than the level contained in the scene. The only one we used regularly was night mode for prowling around the house. Maybe I'll use one of the four "inputs" for that.

I like the 66 block idea, I think I'll go back to std branch hubs (I can't imagine pulling the thing off the wall to screw with the dip switches anyway). Based on the number of chips, I bet you need to use all nine outputs to take full advantage of the amplification. I'm also thinking of eliminating the "Lighting Distribution Module" completely and just making a CAT5 pigtail to go direct to the branch hubs.

Sure drywallers go tight to the box, but that is easily fixed no? I'm excited that I'm not the only one with LV inside the box though. Any chance you could send a picture of your box please. Your connectors look great, but the individual wires don't have sufficient insulation to remain unprotected in the box do they? My latest thought is 1 CAT5 per switch so the electrician doesn't have to think too much.

--Bob

Scenes: the brightness of the chandelier can be changed in the scene very, very easily. This is a no-brainer. Scene switches are very helpful, time savers. Sounds to me like you may not have implemented them adequately in your last house. If the ALC scene is not correct for what you need, change it. My wife has even been able to do it herself, has the kitchen scenes all tweaked out like she wants them. No ugly 4-gang bank of switches mounted in her marble backsplash. One of our scenes will dim most loads but turn up the accent lighting above the cabinets and underneath the cabinets. One is all loads 100%. Completely customizable.

Wiring: Well, here is a pic of the wiring before putting it back in the box. I was going to put the heat shrink over the connectors, but it was a pain. I argue that the cat5e is insulated, as are all the HV wires in the box. There are no bare terminals on switches exposed (unlike the screw-terminals on low-cost switches). The telephone connectors allow for splices to be made without even stripping insulation off the LV wires.

 

[felixrosbergen]

I like the 66 block idea, I think I'll go back to std branch hubs (I can't imagine pulling the thing off the wall to screw with the dip switches anyway). Based on the number of chips, I bet you need to use all nine outputs to take full advantage of the amplification. I'm also thinking of eliminating the "Lighting Distribution Module" completely and just making a CAT5 pigtail to go direct to the branch hubs.

With the size installation you are talking about I think you run into cable length issues if you don't use the hubs (with or without dip switches). You may need to go through the insanely large Cat5 hardwired lighting thread (i'm sure you know which one i mean) to see if Tony Stewart ever confirmed that the cable lenghts 'restart' from a hub point. I woudl expect that they do since the hub is powered and supposedly conditions the signal. I don't see why like you say you can't go directly from the controller or expansion module (for branches 2,3,4) to the hubs, this is what i plan to do for the one location where i will have a hub. I only use the distribution modules to land all the wires in the structured wiring cabinet. Since the modules mount nicely in the structured wiring panel this keeps it all organized. Distribution modules are also much cheaper then hubs but don't provided the renewal of the cable length benefit since they are not powered. For the size installation you have you may want to consider some small structured wiring panel where you bring a cat5 from the main control into this subpanel, land it on the powered hub, then branch to some distribution modules to allow you to land so many wires without needing so many hubs.

If you do the RJ45 pigtail into the controller/expansion module, this will only give you 4 main runs. If you plan to have more hubs than 4 you'll need essentially a main hub right at the controllers. You;d end up with a 3 tier start topology i think. If you limit to 4 total 'sub panels' then you can go controller/expansion module to the subpanels and then depending on how many wires you need to land add distro modules or additional hubs off that hub in the sub panel. I've you're not doing many aux switches then you can tie the COMM+ and COMM- for all the dimmers in a location together and just land them on the hub as a single 'port'. If you run a cat5 to each switch in each location you'll need many more ports (or use the 66 block, but you still need the power conditioing aspect provided by a hub.

Thinking about it some more...i suppose in each 'sub panel' you could have a hub (to boost the signal) and then a 66 block in each sub panel. You could still make serveral connections from multiple hub ports to the 66 block and create 'sections' on the 66 block so you can troubleshoot easier and will have less signal strenth issue. If i had to do it all over and on a larger scale i think it would do it that way...all you need is to figure out how to mount the hub and 66 block into a sub panel since neither are really intended for structured wiring panels.

The hubs are designed to go into a 2 gang box or mudring, but you'll need a 'maxi' size 2 gang blanks cover plate to cover them up completely. I havent installed my only hub yet, but plan to put it in the master closet where a 2 gang blank plate is not an issue. I didn't want the hub up in the attic where the temperatures are too extreme, so i'll have this hub in the closet and then 2 or 3 short 3/4" conduit runs to the attic.

All in all for the size installation you are planning i woudl draw up some good conceptual schematics and get them vetted by Tony Stewart.

Sure drywallers go tight to the box, but that is easily fixed no? I'm excited that I'm not the only one with LV inside the box though. Any chance you could send a picture of your box please. Your connectors look great, but the individual wires don't have sufficient insulation to remain unprotected in the box do they? My latest thought is 1 CAT5 per switch so the electrician doesn't have to think too much.

See my notes above... you'd need many port and thus more hubs or you could land them all on 66 block.

 

[felixrosbergen]

New experiment (original post also updated):

Experiment D - How to power the Elk/ALC Interface/Controller from the wall wart that came with it.
- Goal
	 - My controller didnt seem to want to be powered from the wall wart (see experiment B1 and B2) while AceCannons did this out of the box. The goal is to figure out the difference and how make it be powered from either source.  There is jumper (JP3) right above the 12vdc barrel connector which is not documented.	 
- Setup
	 - Normal configuration
	 - Case A:  With the JP3 in position A remove the ELK connection and plug in the wall wart
	 - Case B:  Do the same with JP3 in position B.
	 - Test light functonality (comunication between ELK and ligthts and scene switch operation) for both cases.
- Results
	 - With JP3 in position A and removal of the ELK connection the ELK/ALC Interface/Controller goes dead.  Insetting the barrel connector from the wall wart does not make it come alive, but inserting the power supply barrel connection AND switching the JP3 jumper to position B will allow it to be powered and functional without the ELK connection.
	 - Upon reconnection to the ELK with JP3 in position B (i.e. power from the wall wart instead of the ELK) the system functions as normal. 
- Conclusion
	 - JP3 allows you to select from which source you want the ELK/ALC Interface/Controller to be powered.  If the connection to the ELK databus is present the communication between ELK and ALC will work in either case.

- other notes
	- I did this test by pluging / unplugging the RK45 from the databus hub so whenthe communication connection was there technically the 12v from the ELK is also there.  I have no idea if this causes any 'backfeeding' or if the ELK/ALC interface/controller is now powered from both at the same time.  My guess is that the power is isolated (i.e. no backfeeding).  It would have to be this way since a very large ALC install with multilpe powered hubs would otherwise create too much of a draw on the ELK system.

 

[beelzerob]

These connectors can join two wires together, or 3. So a third wire can jump to the next connector. Got them at Lowes - they are REALLY great. Also used them in my security install.

Hehe...I've had a little bag of those for half a year now, never thought of how to use them (just picked 'em up on a whim). I'll have to make use of them next ALC install.

I had no real issues cutting the drywall away from the top of the switch box and fishing out the cat5. Wall plate easily covers a pretty big cut. Just make sure you leave a lot of slack cat5 there, and not bound to anything too tightly (use maybe electrical tape, but no clips or nails).

FYI Mav, if it matters, the CQC driver currently doesn't officially support the scene switches, because I didn't have one to test with. I have one now (thanks sacedog!), so that will be added to the official ALC driver somewhat soon. I can't remember exactly what the protocol allows for scene switches, but at a minimum, I'd guess I'll be sending an event when the button is pressed.