Hardwired Lighting System Using Cat5

oh..maybe i wasnt that clear..it's not how HARD i press on the button that makes the dimming go faster or slowing...that woudl be cool though..i'm saying that if one light take 3 seconds to go from 0 to full when holder the on button another may take longer or shorter...

yeah...too bad we're not the same setup...then we'd know if we were crazy or not..lol

Somebody please take the plunge and get the ELK<>ALC setup eventhough i'm complaining about it lol....tired of being the guineau pig...between this and the Music Port i'm getting grey...lol
 
oh..maybe i wasnt that clear..it's not how HARD i press on the button that makes the dimming go faster or slowing...that woudl be cool though..i'm saying that if one light take 3 seconds to go from 0 to full when holder the on button another may take longer or shorter...

yeah...too bad we're not the same setup...then we'd know if we were crazy or not..lol

Somebody please take the plunge and get the ELK<>ALC setup eventhough i'm complaining about it lol....tired of being the guineau pig...between this and the Music Port i'm getting grey...lol


oh boy! Problems with Music Port also!!?
 
I will begin connecting lightswitches soon (1-3 mos) and intend to get the ALC<->Elk, distribution hub, and a branch hub. Can't give any perspective til then. . .
 
- Dimmer appear to have different sensitivity to touching the paddle as far as how fast they fade on or up.

That's a new one. I just tried it...nope. Same rate no matter how hard I press on the switch. There's a definite point at which you can feel the dimmer is being pressed "on", and at that moment, the lights come on and ramp up.

- Dimmer don't always seem to remember their preset

Ya know, there's been a few times where I've wondered about that. I keep wondering why the garage lights have a preset at all, I keep setting the preset to full (who needs dimmed garage lights??). However, I can't exclude the humans from the equation...I think someone in the house is just using the switch wrong, holding it too long, whichever. Some people here hold the button, some just press it. So I think they're the reason for those random anomalies.

- When previously dimmed and then double tapped to full the dimmer wil hesitate halfway through the ramp and then continu.

I still only see that if I take my time with the 2nd tap.

- The double OFF tap doesnt work (although according to TS it's not a feature to begin with) when connected to the controller, when not connected it works just fine.

Mysterious off dimming works on double OFF, whether controller is plugged in or not (didn't disconnect wires).

ALC<>CQC, though. *shrug* It would be interesting to hear from another ALC/ELK'er


Hey folks
I've got some news from the Engineering staff at OnQ. The issue related to double tap for slow off or single tap for slow off has been heard of before.

It seems that they have taken a call on this some time back. They confirmed my belief that there has not been a revision change in years so it is NOT related to that.

The are now pulling a sampling of switches for testing to see if they can duplicate it. The normal operation is single tap is fast off.

Since it is so rare that a single tap does a slow off then it may be something that they can't repeat. As such, you may want to contact them and offer to mail the switch that behaves this way for evaluation. Also understand that they can and will correct that for you under warranty. However, you may like that feature in which case do nothing.

My guess is that during assemly the wrong value of a component got installed. Or a better guess is that a polarized device like a diode may have been installed backwards.

On another note on the test bench, as yet, I can't repeat any flaky operation of the Elk to ALC interface nor can I repeat any local switch operation problems. I hae spent little time with it and will beat on this some more as time permits.

The ONLY difference in the Elk to ALC interface over that of the stand alone ALC interface or the ALC interface for HAI is simply in the communication side. The control electronics is identical. So, the ALC interface side is not as likely to be suspect. I don't know where that leaves us. Excpet for this......
Before the OnQ created the Elk to ALC interface we used a Elk M1XSP, OnQ Serial Interface and OnQ stand alone ALC interface. I will test this link as well (again when time permits).

You folks are great! I mean that! You are a great test case for any product. Where else can a product get such a thorough check out. Finding the rare and infrequent issues is often difficult. Keep up the good work!

God Bless
TS
 
You folks are great! I mean that! You are a great test case for any product. Where else can a product get such a thorough check out. Finding the rare and infrequent issues is often difficult. Keep up the good work!

No worries...

Another question...in ELK can use a function to turn on the light (means full on) or i can use 'set to xx%'..when you say 'set to xx %' the transition is nice and smooth...when turning off through i cannot use 'set to 0%' i will only let me go down to 1%.

Any suggestions on getting a smooth ramp to off?
 
- The double OFF tap doesnt work (although according to TS it's not a feature to begin with) when connected to the controller, when not connected it works just fine.

Mysterious off dimming works on double OFF, whether controller is plugged in or not (didn't disconnect wires).

ALC<>CQC, though. *shrug* It would be interesting to hear from another ALC/ELK'er


...

Since it is so rare that a single tap does a slow off then it may be something that they can't repeat. As such, you may want to contact them and offer to mail the switch that behaves this way for evaluation. Also understand that they can and will correct that for you under warranty. However, you may like that feature in which case do nothing.

On another note on the test bench, as yet, I can't repeat any flaky operation of the Elk to ALC interface nor can I repeat any local switch operation problems. I hae spent little time with it and will beat on this some more as time permits.

The ONLY difference in the Elk to ALC interface over that of the stand alone ALC interface or the ALC interface for HAI is simply in the communication side. The control electronics is identical. So, the ALC interface side is not as likely to be suspect. I don't know where that leaves us. Excpet for this......
Before the OnQ created the Elk to ALC interface we used a Elk M1XSP, OnQ Serial Interface and OnQ stand alone ALC interface. I will test this link as well (again when time permits).
...

I've had the Elk<->ALC running for a number of years, so I'm on the M1XSP bridge. On some of the observations above:

- Yes, I've seen the single-tap off be a very very long fade. Not enough times though that I've actually investigated it. The switchs works normal the majority of the time but there is an 11-yr-old factor the sometimes results in "on" being ~1%. Very confusing the first few times it happened.

- No, I haven't seen anything "flaky" between the Elk and ALC that wasn't an ALC problem. It will be interesting with the integrated Elk/ALC bridge because you can't run the diagnostic software to monitor/play with the ALC side independently of Elk.

If you are playing on your bench and have both the integrated and M1XSP configurations, please try something:

The M1XSP appears to have a 'buffer' to catch/suppress the repeat of a light transmitting "on" and the panel repeating "on" for everything listening. (wish Elk distinguished status vs command) Take a relay switch and turn it on/off 4 times back-to-back with about 1/2 second between each paddle press. After about 4 seconds mine "repeats" the last 3 and turns the lights on/off/on/off/on/off. I don't call this "flaky" because, unfortunately, it is annoyingly very consistent!

Does it do this on the integrated and your M1XSP?

Where this really becomes a problem is a scene switch that changes 5 lights... after about 4 seconds they are in a completely different arrangement and not what I wanted.

Jay
 
Is there anybody else out there using the ELK<>ALC interface?

I have i think 12 dimmer installed now and am still seeing some pretty weird %*^*&.

- Dimmer appear to have different sensitivity to touching the paddle as far as how fast they fade on or up.
- Dimmer don't always seem to remember their preset
- When previously dimmed and then double tapped to full the dimmer wil hesitate halfway through the ramp and then continu.
- The double OFF tap doesnt work (although according to TS it's not a feature to begin with) when connected to the controller, when not connected it works just fine.

I've been carefull not to pinch LV wires. Quite of few of these don't even have auxes installed so i cut the LV aux wires, stagger them and tap them together.

I would love to hear from somebody that has the same setup to see how they are doing.

I still like ALC, but do wish it woudl be a bit more predictable when controlled locally. It has never failed yet to respond to scene switch scene or ELK rules, so that part seems rock solid. And thats the part i was worried about.

Excuse my venting...I'm a bit frustrated...it will pass again...

I wish TS lived in Connecticut...lol

Oh...while i'm on a rant...when programming a scene switch and you want to add a dimmer to the scene the manual sais to jus reteach the scene...this nice and dandy...but I have 3 scene switches current with 2 more planned and each is intended to have an ALL OFF 'scene'. My installationis still growing and from what it sounds like i need to reteach each scene switch each time i wish to add a dimmer....so 5 times i have to set the scene switch to learn mode and run around the entire house pressing all the dimmer to OFF. THERE HAS GO TO BE A BETTER WAY. Can the scenetech software help with this? And how can i run the scenetech software on the ALC<>ELK interface?

I am considering just using the scene switches as ELK inputs and programming the scene in the ELK. This woudl be much more flexible. Create Rule to turn of all the light and make each scene swtich trigger the rule. Add a dimmer? Just edit the rule. But programming scene via ELK rules eat up a lot of rule space and worse, ELK processes the lighting commands rather slowly. Turning 14 lights of in my house takes the ELK about 14 seconds...so having a nice coordinate scene change wouldn't work very well...maybe i don't have somethign setup right in the ELK.

OK...rant over..

Is it possible your Elk bridge is faulty? It seems like you have several switches that are acting up, but are fine when not connected to the bridge. So it could be a bad batch of switches, or perhaps the bridge?

Just a thought.
 
broconne:

beats me...I've moved onto other HA items for the time being and will come back to this at some point...

My next quest is CQC and if i get that under control i may try to use a serial router (some were linked recently) and switch the traditional serial control module for ALC. It sounds like configuration through their software and the control through CQC is a bit better/easier than the ELK<> module.

With the serial router ELK still can have some control over the lights. If would set up basic rules in ELK that all first check if CQC is running or not.

beelzerob: how fast can you send lichting command following each other from CQC to ALC? Fast enough to make several lights fade up/down in concert to make it appear a smooth scene change? Somehow through ELK there's between 500ms and 1s between each command so it's not smooth at all. There's a 'delay' function in ELK, but when i turn it off it seems half of the lights don't get their command so it may be too fast. The delay is not adjustable.
 
Welll...that's pretty darn hard to measure, just from a "watching it happen" standpoint. I don't have many lights controlled at this point, and 2 of them are outside...so I only have a foyer light and catwalk light I can try this with.

I created a command button that sets the level of each to 0. So what would happen is my CQC driver will be called with the new level for the light. It'll send that command, and then I think it waits for a reply from the controller, and once it gets that, it then returns from the call. At THAT point, the second command would be sent.....so there's some back and forth involved to do that.

HOWEVER...I can say for sure that doing a simple Ramp down (which is what happens when you set the level to 0 instead of setting the State to false), I can't tell a difference between when the two start. There was a massive difference at first, and then I realized the catwalk lights had been set to extended ramp, not ramp.

Doing a ramp comparison doesn't help much, though, since it's gradual. So I set the command button to send commands to each light to set the State to false. That's pretty much instant. Doing that, if there IS any delay between both sets of lights going to Off, it is VERY minimal. If you want, I can make a little video of it.

Keep in mind, this is only 2 switches...so it's not like it's a burden on the system. But I don't see any reason why adding more switches and commands would cause any other problem. Each command is processed and returned, which makes the event complete. If you put together a LOT of lights, then I'd say it's reasonable to think there might be some visible noticeable delay between the very first set of lights and the last one.

But half second between them? No way at all....it's negligible.
 
ok...according to Spanky at ELK the 1 second delay is normal. This suck pretty badly IMHO since beelzerob has already proven that when having CQC direct the ALC controller he can send commands MUCH faster than that.

In any case, I'm still having issues with my ELK<>ALC interface using the special ALC part that sits direclty on the ELK databus.

The symptoms are the following:
- presets levels are not consistently rememberred. Sometimes the dimmer go on to full sometimes to their presets, doesnt seem to be a pattern to it.
- I will unable to replicate the double OFF tap extensively discussed in the posts above

What works absolutely fine without missing a beat is that whenever ELK rules issue a command to ALC the lights will indeed do what they are told.

Other issues:
- ELK's lighting control screens allow the setting of ON/OFF and setting to a certain %. This is great and works well. When you do not use a percentage and just say 'ON' the lights come up fast and when you say 'SET TO 100%' they come up nice and smooth. However, it is not possible to use 'SET TO 0%' to turn the light off, the lowest value accepted by ELK is 1%. This means that there is no 'soft off' when using ELK to control the lights unless you double up on all rules and first use 'SET TO 1%' followed by a delay time and then 'TURN OFF'. This works but is silly complex to achieve something very simple.

General setup:
ELK M1G <> DATABUS HUB <> ELK/ALC INTERACE <> Distribution Module. Using a Cat5 / RJ45 from the 'branch 1' RJ45 on the ELK/ALC interface board to the RJ45 on the Distribution module. I also have an ALC expansion module (adds 3 branches) but other that the flat expansion cable it's not connection to anything.

All aux wiring for the dimmer is homerunning and cross connected on the distribution module. 'In the field' however multiple dimmers (in the same gangbox) may be on the same polling loop run.

TROUBLESHOOTING PROGRESS:
- When i remove the Cat5 cable between the distribution module and essentially make the system 'dead' but keep the LV wiring on the distribution module intact all the aux switches still control the dimmer, scene switches obviously don't work anymore BUT the double off tap produces a nice smooth transition to OFF and the presets are remembered without fail. This tell me the switches themselves are fine.
- No there could be an issue with the polling loop wiring, but since I've been very carefull to do this right i seriously doubt it. On top of that all command sent from ELK are executed without fail, so I think the physical communications links are good to go.
- I've found that the power supply provided with the ELK/ALC interface is absolutely useless. The controller gets it's power from the ELK DATABUS, even with the power supply plugged in and the databus connection removed the controller does not get power. The power from the ALC power supply doesnt seem to go anywhere. There is a jumper (JP3) right above the power connection which i suspect may determine where power is obtained from, but nothing is described in the documnetation about JP3 or any of the other jumpers. I don't like that it draws power from the ELK databus since this could potentially overload it. Ofcourse i can just take the 12V + /- and connect them to another supply, but then i believe i need to tie the negative together or something. If the stupid thing comes with a power supply, it expect it to do something. For the last 4 months it's been sitting plugged in the outlet warming up and using watts while doing nothing.
- When i provide power to the controller but no communication (i did that by disconnecting the databus comm wires but leaving the 12V +/- connected the scene switches work, the presets all remembered and the doubtap soft off works. In this configuration the ALC controller essentially works in standalone mode (without communication to ELK) and EVERYTHING IS FINE (except of course that i cannot use the ELK to control the lights).
- Based on this I'm tentatively concluding that the communication between the ELK and the ELK/ALC interface causes the system to misbehave. I have no idea whats causing this. The expanded ID is unique and the ELK databus is otherwise fully stable. I don't know how much power i'm drawing from the ELK or if this could have an affect, but the following is connected to the ELK without using an auxillary power supply (2 Input expanders, 1 M1XSP (for tstat control), ELK/ALC interface (logically treated as an M1XSP), 2 KP2 keypads, 1 KPAS decora size keypad, 1 strobe, 1 RT1 outdoor speaker/siren, 2 SP12F speakers).

NEXT STEPS:
- Disconnect a bunch of stuff from the databus to ensure that this is not an issue related to databus loading. I don't expect this to yield the solution, but it's the proper step to take in the process of elimination.
- Same step as above, particularly removing the other M1XSP (which talks to the aprilaire thermostates) from the system to ensure there's no conflicts.


Anybody have any suggestions? I'd like to hear if anybody using the 'old school' method of connecting the ELK to ALC (using a real M1XSP <> ALC serial module <> ALC controller) are having any of these issues. The failure to remember the presets is my biggest gripe.

I'm considering dumping the ELK/ALC special module and getting the kit needed for the 'old school' connection method. Hoping that this will work better and allow me to use a serial router (http://www.avocationsystems.com/SR-2.html) to allow ELK and CQC simulatenous control. I've already established a 'heartbeat' communication between ELK and CQC so i would use CQC for all normal control and have simplified backup rules in the ELK which all first check if CQC is online). Before i jump all into that solution i'd like to try to figure out if I can at least make this work prooperly.

Tony, when using the standalone controller with serial control module. Does this allow the use of the Scenetech software and what options does this give us? Can i use that software to programm the scene rather than then press/hold the scene switch button and run around the house to set the desired levels? That method is getting old pretty fast.

Has anybody succesfully 'recalled' an ALC scene using the ELK?
 
Back
Top