Legrand Discontinues the ALC and PLC Lighting Systems!

[dutchyn]

I think he is just taking exception to the fact that you are claiming ALC is the only product that you can hardwire with a control wire yet still maintain traditional high voltage wiring

There is also the (difficult to find) EDT iLine product too.

 

[beelzerob]

That was discontinued over a year ago, I believe. I was deciding between ALC and iLine when that happened, which made my choice much easier.

 

[wlj]

Now here's a more specific way to look at your issue. The extended feature works with automation systems like Omni's and Elk controllers. But in your example it does not with the stand alone lighting controller. So what is different? For one thing, there is no time base capabilities with the stand alone lighting controller. I will come back to this thought!

So let's describe "Extended" first. I call it "Ramp over time". It's the ability for the ALC dimmer to take hours to go to the setpoint you gave it. In essence you can tell the ALC dimmer to take all day to gradually come to a setting, say 75%. And the ALC switch is so smooth most bulbs will not "jump" and instead move very smoothly. This is a desireable feature of any dimmer and the ALC dimmer does it superbly.

The time base I mentioned requires some sort of clock. The lighting controller does not have a clock (whereas Omni and Elk controllers have a very powerful clock). To add timed features of any level of sophistication) requires the addition of the lighting manager module. Then you have a robust time clock with capabilites of programming events over several days.

I need to prove this, but I think I finally understand why you are getting no where with the extended commands. You are using them correctly, but the lighting controller does not have the time clock to accomplish what you are asking of it. I should have realized this limitation as soon as noticed the lighting controller had no clock circuitry, crystal or battery.

Tony,

What you've written about how the ALC extended ramp rate works is not consistent with my observations using an ALC Scene Learning Interface (SLI) controller. The SLI has no clock, crystal, or battery, yet the extended ramp rate works. As far as I can tell from the traffic reported by the controller, the dimmer module itself performs the extended ramp -- the controller just tells it to go. There are other indicators that support this -- such as the extended ramp rate being stored by the dimmer, the fact the controller tells the dimmer to perform the extended ramp without first inquiring what the extended ramp rate is, the existence of a ramp interrupt command that gets sent to/processed by the dimmer to stop the ramp, etc. I've just verified all of this for Rob. Details are in the following post.

Cheers,
-Bill

 

[wlj]

I'm trying to set the extended ramp rate in my dimmers via the RS232 protocol. I am sending the exact bytes that Bill indicated on the 3rd page of posts of this thread...but all I get back from the controller is NAK.

This is the first 6-byte command I've tried sending...all of the 4-byte commands worked fine. Dunno if that matters.

Anyway, please let me know who to contact about this. thanks.

Rob,

I've just tested the extended ramp rate functionality using SceneTech and my ALC Scene Learning Interface (SLI) controller using firmware v1.12. Everything works as you'd expect it to, both according to SceneTech and my eyes watching the light under control. I've attached a few screen shots from SceneTech to illustrate the commands sent/received.

Hope this helps,
-Bill

 

[beelzerob]

I'm gonna ask Dan or BSR to move these particular posts to a new thread, as too often good info and stuff gets lost in these superlong ALC threads. We'll continue the conversation there, hopefully....

 

[TonyStewart]

Now here's a more specific way to look at

Tony,

What you've written about how the ALC extended ramp rate works is not consistent with my observations using an ALC Scene Learning Interface (SLI) controller. The SLI has no clock, crystal, or battery, yet the extended ramp rate works. -Bill

Hey Bill
Great research! You guys really think these things through! Here are some other things to add to your thinking. The SLI in fact does have a clock (it uses the HAI or ELK clock).

The SLI unlike the stand alone SLI lighting controller, links to the processors on-board the HAI or ELK controllers. Actually, this link and the matching of communications from ALC to the HAI/ELK controllers is all that varies from interface to interface. Basically all interfaces: the SLI, the ELk interface and the stand alone lighting controller that Beelzerob uses varies only in these two regards.

We had to change the source code in the SLI models (HAI or ELK) to use the processors present on the main controllers. The amount of power available in the stand alone lighting controller is limited since it can't lean on the HAI or ELK processors as much. Adding the lighting manager gives it back some horsepower.

In addition, all the SLI controllers do have a processor which contains a little bit of ram (which get's it's time base from the system timing). This allows for some time based events, but has limited room for advanced functions. The dimmer and the relay also both have processors, with the same limitations. The extent of how much and how far the on-board processors can go is yet untested by me. Of course on board processing and storage/time base on the stand alone SLI does not compare to that of the HAI/ELK versions dues to the power coming from HAI/ELK controllers.

The on-board processors with these products are not present with most competitive products and are also rarely tested. You folks do a better job of raising the hood and testing that than most anyone.

With dedicated controllers like HAI or Elk's family of controllers, you have the bulk of the processing power handled by those processors and the horsepower found in the switches are rarely taxed if at all. This is also why we never hear any feedback on such issues as this one, since it is basically a non-issue with those models.

When using Beelzerobs setup you can build a rather detailed system. But we are still limited by the amount of area to house programs and by the processor power. For example, you can write 64 scenes using scenetech (or by using the local programing features of the 4 button scene switches). While this may sound like a lot of scenes, it may not have enough horespower for larger installs.

Frankly, I admit that these scenarios are places where some lab work from us is on the agenda. But balancing these issues against others places them down low in the stack. Still, they are worth some time in the future.

We are looking into replacing the processors inside the dimmers and relays which will give them more processing power. But these design issues will not happen in 2010, closer to late 2011 if at all. The decision involves the old saying "If it ain't broke, don't fix it"!

Let me know what else you find.

TS

 

[TonyStewart]

Now here's a more specific way to look at

Tony,

What you've written about how the ALC extended ramp rate works is not consistent with my observations using an ALC Scene Learning Interface (SLI) controller. The SLI has no clock, crystal, or battery, yet the extended ramp rate works. -Bill

Hey Bill
Great research! You guys really think these things through! Here are some other things to add to your thinking. The SLI in fact does have a clock (it uses the HAI or ELK clock).

The SLI unlike the stand alone SLI lighting controller, links to the processors on-board the HAI or ELK controllers. Actually, this link and the matching of communications from ALC to the HAI/ELK controllers is all that varies from interface to interface. Basically all interfaces: the SLI, the ELk interface and the stand alone lighting controller that Beelzerob uses varies only in these two regards.

We had to change the source code in the SLI models (HAI or ELK) to use the processors present on the main controllers. The amount of power available in the stand alone lighting controller is limited since it can't lean on the HAI or ELK processors as much. Adding the lighting manager gives it back some horsepower.

In addition, all the SLI controllers do have a processor which contains a little bit of ram (which get's it's time base from the system timing). This allows for some time based events, but has limited room for advanced functions. The dimmer and the relay also both have processors, with the same limitations. The extent of how much and how far the on-board processors can go is yet untested by me. Of course on board processing and storage/time base on the stand alone SLI does not compare to that of the HAI/ELK versions dues to the power coming from HAI/ELK controllers.

The on-board processors with these products are not present with most competitive products and are also rarely tested. You folks do a better job of raising the hood and testing that than most anyone.

With dedicated controllers like HAI or Elk's family of controllers, you have the bulk of the processing power handled by those processors and the horsepower found in the switches are rarely taxed if at all. This is also why we never hear any feedback on such issues as this one, since it is basically a non-issue with those models.

When using Beelzerobs setup you can build a rather detailed system. But we are still limited by the amount of area to house programs and by the processor power. For example, you can write 64 scenes using scenetech (or by using the local programing features of the 4 button scene switches). While this may sound like a lot of scenes, it may not have enough horespower for larger installs. Of course the 64 scenes programming would require the addition of the lighting manager.

Frankly, I admit that these scenarios are places where some lab work from us is on the agenda. But balancing these issues against others places them down low in the stack. Still, they are worth some time in the future.

We are looking into replacing the processors inside the dimmers and relays which will give them more processing power. But these design issues will not happen in 2010, closer to late 2011 if at all. The decision involves the old saying "If it ain't broke, don't fix it"!

Let me know what else you find.

TS

 

[Herdfan]

OK I did some research by looking at the link you mentioned in post 82. The wired Maestro uses an 18/2 or 22/2 to communicate with the dimmer. That's good. But from the drawings the remote dimmers(3 or 4 ways) talk back to the wired dimmer over the black AC wire? Is that right? I am not sure if this is bad or good! Please elaborate.

Close. The remote dimmers communicate over the traveler wire connected to the blue terminal. The black wire provides power to the next remote dimmer. Works like a regular single pole dimmer. Power into black, power out on red to the light or the next remote dimmer. All communication is done over the blue wire.

Each bus branch supports 8 dimmers. How much would a house with a large number of lights cost as relates to controllers/processors?

A single processor can handle 256 devices. A device can be a light or shade. Lights can be wired or wireless (limit 64 wireless devices per processor) or can be a WPM (Wallbox Power Module - non-standard wired 6 dimmer box) or a Grafik Eye (similar to a WPM, but is great for use in theaters. Can have up to six loads in a 4-gang box and has IR control and scene selection). Most houses can get by on one processor, but there may need to be a couple of add-on buses.

Now that I concede to your point, I am now grasping for the next level(s) of comparison - Features, costs, dependability.

Features - almost limitless. Processor drives all the logic, scenes, time clock events, vacation mode, security mode (wife loves this as she can press a button in the MBR if she hears something and it will force all the lights in the house ON for 10 minutes (or any set period) and flash the outside floods, lights inside can not be turned off as the processor send on ON command continuously), energy saving mode and states.

Dependability - rock solid. Lutron has been around since 1952. You don't become one of the biggest names in automated lighting if you make junk.

Cost - dimmers run $150 MSRP, but can be had for less. Processor w//enclosure runs $2600 MSRP, but again can be found for less. If you are building a house that you are putting $100+ dimmers into, there is someplace you can find the $2K for a processor even if it means having to add some dimmers later.


Feel free to ask any questions you might have. We may want to start a new thread as to not take this one any more off topic.

 

[wlj]

Tony,

What you've written about how the ALC extended ramp rate works is not consistent with my observations using an ALC Scene Learning Interface (SLI) controller. The SLI has no clock, crystal, or battery, yet the extended ramp rate works. -Bill

Hey Bill
Great research! You guys really think these things through! Here are some other things to add to your thinking. The SLI in fact does have a clock (it uses the HAI or ELK clock).

Tony,

The SLI (OnQ Part #364614-01, Link to Product PDF) is a standalone controller. I have no HAI or ELK system, nor am I aware of any provision to connect the/this model SLI to an HAI or ELK system.

We are looking into replacing the processors inside the dimmers and relays which will give them more processing power. But these design issues will not happen in 2010, closer to late 2011 if at all. The decision involves the old saying "If it ain't broke, don't fix it"!

Interesting. From my perspective, at least, the current dimmers and relays are OK with regard to processing power. I'd rather see you invest your resources into things like new modules or shoring up the serial programming interface.

Cheers,
-Bill

 

[TonyStewart]

Tony,

The SLI (OnQ Part #364614-01, Link to Product PDF) is a standalone controller. I have no HAI or ELK system, nor am I aware of any provision to connect the/this model SLI to an HAI or ELK system.

You can attach the 364614-01 to the Elk or HAI controllers using the 364698-01 serial interface board and a serial port on either controller (plus some cables). On the Elk, this was the way it was done before we created the Elk interface.

It was more parts and more money to do it this way. And I am not sure if this configuration adds anything or not.

Also, while I like the interfaces for HAI and ELK, the stand alone SLI opens up more markets for expansion. As such, it will see some attention and upgrades at some time.

TS

 

[rbroders]

Okay, now I'm confused. Since I don't care about scenes I was planning the following configuration:
HLC (home lighting controller)
SEM (serial expansion module) -> connected to CQC
LEM (lighting expansion module)
lots of hubs and switches...

Does this mean I can't use extended ramp dimming?

What if I get an SLI instead of the SEM? Do I need one per branch? Do I still need the HLC?

--Bob

P.S. Beelzerob theoretically you could enhance your driver to simulated extended ramp dimming with internal timers and discrete dim level commands...

 

[beelzerob]

P.S. Beelzerob theoretically you could enhance your driver to simulated extended ramp dimming with internal timers and discrete dim level commands...

Ya, I had thought about that....but I think it really is in the "theorhetical" realm. If you tell it to ramp over the course of 4 hours, and then something happens to the CQC setup, the timer gets lost and the light stays at whatever setting it was left at. I think there's just a lot that can go wrong. Maybe I'll play with it tonight and see about some kind of extended ramp in the one-hour type range.

I'm a little confused now on if it really is an external timer issue, since wlj doesn't have an elk or other, and hence not the interface. Sounds like the SLI is the only part he has different from me. Some more investigation is warranted here...

 

[wlj]

Tony,

The SLI (OnQ Part #364614-01, Link to Product PDF) is a standalone controller. I have no HAI or ELK system, nor am I aware of any provision to connect the/this model SLI to an HAI or ELK system.

You can attach the 364614-01 to the Elk or HAI controllers using the 364698-01 serial interface board and a serial port on either controller (plus some cables). On the Elk, this was the way it was done before we created the Elk interface.

Tony,

I think we're going a bit sideways -- my points were that the SLI supports extended ramp rates as a standalone controller, and that the SLI does not have a 'special' Elk or HAI interface that provides tight coupling as you implied in a previous message. I don't want anyone to be left with the incorrect impression that full-bore automation systems are needed to fully take advantage of the capabilities that ALC provides.

the stand alone SLI opens up more markets for expansion. As such, it will see some attention and upgrades at some time.

Sounds great!

Cheers,
-Bill

 

[TonyStewart]

Tony,

The SLI (OnQ Part #364614-01, Link to Product PDF) is a standalone controller. I have no HAI or ELK system, nor am I aware of any provision to connect the/this model SLI to an HAI or ELK system.

You can attach the 364614-01 to the Elk or HAI controllers using the 364698-01 serial interface board and a serial port on either controller (plus some cables). On the Elk, this was the way it was done before we created the Elk interface.

Tony,

I think we're going a bit sideways -- my points were that the SLI supports extended ramp rates as a standalone controller, and that the SLI does not have a 'special' Elk or HAI interface that provides tight coupling as you implied in a previous message. I don't want anyone to be left with the incorrect impression that full-bore automation systems are needed to fully take advantage of the capabilities that ALC provides.

the stand alone SLI opens up more markets for expansion. As such, it will see some attention and upgrades at some time.

Sounds great!

Cheers,
-Bill

I understood, just wanted all people to see the full picture. I made an assumption that the Ramp over time command (you call it extended) could be limited without a time clock like that found on the HAI/ELK. From your comments, I see that you believe this limitation does not exists. Beelzerob will test and come back with his finding. Standing by for that.

TS

 

[TonyStewart]

What if I get an SLI instead of the SEM? Do I need one per branch? Do I still need the HLC?

--Bob

P.S. Beelzerob theoretically you could enhance your driver to simulated extended ramp dimming with internal timers and discrete dim level commands...

The SLI (Scene Learning Interface) and the HLC (Home Lighting Controller) are one and the same. Just don't use the scenes (you need the 4 button scene switches anyway).

Yes you will always need the SLI. And your configuration is accurate for what you want to do. One SLI can handle 31 ALC addresses and can be expanded to add 3 more 31 ALC unit branches with the LEM (new name for it, think I will keep it).

Based on the recent news from CQC users, the extended feature is adequate on the SLI (HLS) as is. See Beelzerob testing coming up later.

TS