Legrand Discontinues the ALC and PLC Lighting Systems!

First, its RadioRA. The RA name comes from the sun god RA! [/quote]

[/quote]

Well you got me on a number of levels. Sometimes it's best to keep quite and I am learning this the hard way. I do have support for my beliefs, but am not going to waste everybodys time further airing this out.

We did test the RadioRa and still own an elaborate system. Remember that above all else, we are also Distributors selling anything of quality that sells. I simply was not a fan of that particular family. We were going to distribute that product line and the other Lutron models as well, but turned them down after testing RadioRa and another family and after reviewing the pricing situation and their business case.

I am not able to talk about all their families and should just plain quite trying to do so. And I have not looked at pricing for some time, but it was a concern then.

They sent us a lot of gear and never asked for it back. Let me contact the rep that promoted the line(s) to us and if he does not call for the product, I may install it again and beat on it some more. The Engineer that spent the most time with it is now retired, but I will take him lunch soon and get some of his more specific comments. I rarely give a product a second chance because we do such a thorough job evaluating products in the first place. But, you are convincing me to reconsider.

This may take some time, so I won't post results for a couple of months at least.

Until then, I hope not to raise your blood pressure again.
God Bless
TS

PS: Sun god Huh? I never knew that until now, Strike one!
 
When you say query, do you mean from your PC via serial to the serial port add on board for the lighting controller, or by sending ALC protocol/commands down the polling loop directly to the lighting controller?

From PC via serial to the serial port addon board, which is connected to the lighting controller. The RS232 protocol is in a PDF doc that someone from OnQ (Tom Cunningham) gave me quite a while ago.

I've not tried talking on the Com+/Com- lines of ALC itself, nor see any reason to do so. The RS232 protocol is pretty full featured, though it certain has some quirks. If you ever get to the point of considering updating/upgrading the protocol, I'd be happy to make some suggestions that will make using the protocol quite a bit easier for the average interface-person. Of course, updating the protocol would mean firmware updates, and having to preserve the existing protocol for legacy support...so I don't hold out much hope it'll happen, and honestly, it's not even nearly a need...just a want.

I'm still convinced that the set extended ramp rate error I'm having is an issue, since the command bytes I'm sending are the exact same as sent by the Scenetech software (according to the 3rd page of posts...I don't have the software myself). I also discovered...not so much a protocol error...but an error in the documentation, I *guess*. Either that, or perhaps I have older documentation.

The RS232 protocol indicates that when a scene button is released, it will send out a message, and the last byte of that message will be 0x20 (or the space char in ASCII). It sends out the same "button released" byte, no matter which button of the 4 on the scene switch is released...thus meaning you have to poll the switch to see which button was actually released. That was annoying, but livable. However, once I started getting actual bytes from the device, I found that this was not the case. It sends back a DIFFERENT byte depending on which button was released. So, if you press button 1, it sends you a message ending in 0x21. If you press button 2, the last byte is 0x22. Etc. And when you release button 1, the last byte is 0x51. When you release button 2, it is 0x52. Etc.

All that to say...what actually happens in the hardware is better than what the protocol indicated would happen. So I'm guessing the protocol doc is in error.

I'd be happy to look at the latest protocol doc you have, to see if perhaps I have an out of date one, and maybe this isn't an error at all.

Thanks for the support Tony. I'll try to call you later today like I said I would to describe my setup...it'll be around 4:30p EST, so dunno if that works.
 
I do have support for my beliefs, but am not going to waste everybodys time further airing this out.

I would like to hear your beliefs as to how a wired 4 Series Lutron system using Maestro dimmers/switches uses non-standard wiring and once installed, it can't be replace by regular switches.

Really would love to hear it.
 
I do have support for my beliefs, but am not going to waste everybodys time further airing this out.

I would like to hear your beliefs as to how a wired 4 Series Lutron system using Maestro dimmers/switches uses non-standard wiring and once installed, it can't be replace by regular switches.

Really would love to hear it.

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.

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

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

There are many readers who need both our wisdom, so let's focus on that now. I will share more good things about ALC, you share the same about RadioRa or wired Maestro. The result will be what this forum should be about - Learning! Many of the readers must install retrofit products. As such, they need to compare RF to UPB, not RF to Hardwired. What is your experience with the RF Maestro line?

While I am still not yet a fan of Lutron, my education is old and my head hardened. But my heart is warm and willing!

TS
 
When you say query, do you mean from your PC via serial to the serial port add on board for the lighting controller, or by sending ALC protocol/commands down the polling loop directly to the lighting controller?

I've not tried talking on the Com+/Com- lines of ALC itself, nor see any reason to do so. The RS232 protocol is pretty full featured, though it certain has some quirks.

Scentech would give you some luxuries not present when using Hyperlink to view the traffic. It also has built in testing, programming (if you have the lighting manager) and something I use a lot which is a window which shows all traffic on the comm bus. It's like windows hyperlink on steroids. Scenetech (and a serial interface module) is used with systems using the stand alone lighting controller and works in conjunction with the controller. Branchtech (when you have the branchtech interface for your laptop) on the other hand works by replacing the lighting controller completley for testing purposes. It too has the test features and advanced comm window feature.

Branchtech is my first line of attack when troubleshooting and should be owned by any installer or users with large systems.

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.

Sorry, that it took me so long to realize this. Sometimes I am just plain slow!

God Bless
TS
 
I have been watching all the rock throwing hoping to learn something and I feel I need to bring this up before more rocks are thrown.

Tony, With all due respect, I think you are missing Herdfans point. I think he is saying that there IS a competing product to ALC that is wired and controlled the same way. He introduced them in Post 82 and mentioned them again in Post 88. 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 and hence, replace the switches back to standard. It does appear that the Homeworks wired series does just that. Now I don't know anything about capabilities, prices, etc. I also don't know the interaction/compatibilty between this Homeworks/4 series or RadioRa stuff but I think you need to at least concede that Lutron has a competing product to ALC, at least technology wise.
 
Oh...well there ya go. I'm glad it's figured out....though I'm sad it means no long ramp times for me or CQC users. ;) Thanks for thinking on it and figuring it, Tony, and the explanation makes complete sense.
 
I have been watching all the rock throwing hoping to learn something and I feel I need to bring this up before more rocks are thrown.

Tony, With all due respect, I think you are missing Herdfans point. I think he is saying that there IS a competing product to ALC that is wired and controlled the same way. He introduced them in Post 82 and mentioned them again in Post 88. 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 and hence, replace the switches back to standard. It does appear that the Homeworks wired series does just that. Now I don't know anything about capabilities, prices, etc. I also don't know the interaction/compatibilty between this Homeworks/4 series or RadioRa stuff but I think you need to at least concede that Lutron has a competing product to ALC, at least technology wise.


Could be, let me dig a little more. While I hate to be wrong, I was wrong a few times already today (and yesterday and the day before). My experience with Maestro was with the RF line. Anything newer than that is above my knowledge.

I will get into the drawings and advise if I need to prepare a dinner of crow feathers or not!

TS
 
Oh...well there ya go. I'm glad it's figured out....though I'm sad it means no long ramp times for me or CQC users. ;) Thanks for thinking on it and figuring it, Tony, and the explanation makes complete sense.

Maybe not! Since you can still send all commands that is required to the lighting manager through the serial module, maybe you can get the extended features you wanted if you add a lighting manager. I bet CQC users could get the extended featuresand some other goodies with this addition. The clock on the lighting manager may in fact allow some of your basic CQC Lighting programs (related to time/date) to run even when your PC is turned off.

Here too, I reserve the right to be wrong. With this blue sky thought and my limited knowledge of Lutron Maestro, my neck is really out there. Hopefully I can dodge the executioner for a little longer.

TS
 
The clock on the lighting manager may in fact allow some of your basic CQC Lighting programs (related to time/date) to run even when your PC is turned off.

TS

Hmm...an interesting thought. I'd be curious to know what else it might affect, other than just ramp over time. It would be pretty handy to be able to setup time-of-day events to run autonomously (without CQC), though I don't have a lot of those myself. I turn the outside lights on at dark and off around 1a. That's about it.

With CQC, basically the PC running stuff is always on, unless it's broken, so there is no "when the PC is turned off. I have lighting that reacts to various events, but I use CQC to detect those events and then command the lights to do stuff.
 
The clock on the lighting manager may in fact allow some of your basic CQC Lighting programs (related to time/date) to run even when your PC is turned off.

TS

Hmm...an interesting thought. I'd be curious to know what else it might affect, other than just ramp over time. It would be pretty handy to be able to setup time-of-day events to run autonomously (without CQC), though I don't have a lot of those myself. I turn the outside lights on at dark and off around 1a. That's about it.

With CQC, basically the PC running stuff is always on, unless it's broken, so there is no "when the PC is turned off. I have lighting that reacts to various events, but I use CQC to detect those events and then command the lights to do stuff.

The lighting controller has Inputs/outputs that you can only access when the lighting manager is installed. Yet another reason to add one. And this feature may also allow you to do more I/O that you currently handle with CQC. In addition you can add I/O modules to create a cadillac one part at a time. The result is a really powerful system on a limited budget. There is also a wireless Garage door interface with a bunch of Inputs and outputs.

At some point you would be better off with HAI or Elk controllers. But with the stand alone lighting controller and add ons, you can link it to the CQC in a way that can't be done as easily with HAI or Elk controllers (if at all).

I really want a CQC system now. But my plate is so full I won't get one until I have a window of time to be consumed by it!

TS
 
I have been watching all the rock throwing hoping to learn something and I feel I need to bring this up before more rocks are thrown.

Tony, With all due respect, I think you are missing Herdfans point. I think he is saying that there IS a competing product to ALC that is wired and controlled the same way. He introduced them in Post 82 and mentioned them again in Post 88. 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 and hence, replace the switches back to standard. It does appear that the Homeworks wired series does just that. Now I don't know anything about capabilities, prices, etc. I also don't know the interaction/compatibilty between this Homeworks/4 series or RadioRa stuff but I think you need to at least concede that Lutron has a competing product to ALC, at least technology wise.

I concede reluctantly and partially! While still not a fan, that one point is proven. Anybody know how to make crow taste better?

TS
 
At some point you would be better off with HAI or Elk controllers. But with the stand alone lighting controller and add ons, you can link it to the CQC in a way that can't be done as easily with HAI or Elk controllers (if at all).

Some of the cqc users who have Elks (many do) have found the elk interface with the ALC control to be limiting...for instance, sending it many commands at once to change lights result in a second or so delay between lights changing. So instead of all lights instantly changing, they change in sequence.

Or so I've heard anyway. I'm elk-less, mainly (only) for money reasons. But I've found CQC to do everything I need, so long as you have the separate parts for the various needs(Datanab for sensing stuff, Ocelot for controlling relays and sensing doors/windows, ALC for controlling lights, etc). Others can probably describe their experiences much better than me...but I understand the point you're making, as far as control and adding more and more stuff.

I had seen the I/O module mentioned in the RS232 protocol, and had assumed I could support it someday if needed. Will I need the lighting manager to use the I/O modules also?? (I have no plans to get any....I have oodles of I/O capability within my HA system already).
 
At some point you would be better off with HAI or Elk controllers. But with the stand alone lighting controller and add ons, you can link it to the CQC in a way that can't be done as easily with HAI or Elk controllers (if at all).

Some of the cqc users who have Elks (many do) have found the elk interface with the ALC control to be limiting...for instance, sending it many commands at once to change lights result in a second or so delay between lights changing. So instead of all lights instantly changing, they change in sequence.

Or so I've heard anyway. I'm elk-less, mainly (only) for money reasons. But I've found CQC to do everything I need, so long as you have the separate parts for the various needs(Datanab for sensing stuff, Ocelot for controlling relays and sensing doors/windows, ALC for controlling lights, etc). Others can probably describe their experiences much better than me...but I understand the point you're making, as far as control and adding more and more stuff.

I had seen the I/O module mentioned in the RS232 protocol, and had assumed I could support it someday if needed. Will I need the lighting manager to use the I/O modules also?? (I have no plans to get any....I have oodles of I/O capability within my HA system already).



Yes, you will need the lighting manager as this is where any programs reside including all I/O. Let me study on the Elk issues, just remember that I have proven to have poor comprehension on one of your questions already!

By the way I emailed Herdfan my apology!

TS
 
Back
Top