ALC Lighting Poll

[JayH]

Jay - I tried google, but failed - what's LMM? Local Monitoring Module?

Have you used a recent version of the ALC SceneTech software? Or is it redundant with the Elk?

Thanks for taking the time to post your review.

Sorry for the delay in this response. I've started it 3 times but never managed to finish.

First, a link:
http://www.onqlegrand.com/products/nav=a0f300000005ZJKAA2

HLC = Home Lighting Controller
- 1st module required for standalone installs
- Supports 1 branch and X-10
- Processor supports scenes and up to 3 more branches
- Pass-through serial comm to allow direct comm with switches

LMM = Lighting Management Module
- Event scheduling (time, event)
- Clock w/Sunset calcs
- Serial Port w/RTS(?) to toggle between HLC and LMM comm
- Links to HLC with ribbon cable

Home Lighting Expansion Module
- Adds 3 more branches to HLC

Serial Expansion Module
- Provides Serial port to HLC
- Not required with LMM

There are other serial modules (1 port, 4 port) for host-based control where the host does all the polling/commands/scenes etc. I have these but have since put them aside except for development/troubleshooting. It should be noted that the ALC physical interface is "almost" RS-485 but the levels are slightly off so an RS-485 device can "read" the commands but transmissions are ignored.

Regarding the SceneTech, I just updated to the most recent to verify functionality:
- Branch scanning and diagnostics (HLC)
- Supposed to have scene creation but not there (HLC), so the only way is via the switches (not fun)
- LMM Configuration for date/time/latitude/longitude
- LMM Rules

No, it isn't even close to Elk. While I have scenes created in the HLC all the real work is done in my Elk regarding rules (or via some python code I'm playing with to create eventlets). My LMM is only used for a serial port today.

However, at the same time, the Elk doesn't have access to all the scene buttons or taps/holds on buttons. My acronyms were wrong in my original post, this really needs a more intelligent HLC (not LMM) and some additional smarts in the Elk serial interface - Neither is hard, they just take time and somebody to have the desire for them.

One thing not mentioned here is what I would call "Installation Packaging" - for the ALC products I put in a 14" enclosure for _just_ the ALC-related stuff (HLC, LMM, Branch Expansion, Distribution Module and 8-port RJ45) with appropriate cabling to the Elk enclosure, branch hubs, switches (for local dist module) and Altronix 12VDC PDU/Distribution panel. I've opted to not use wall-warts and instead use a 10A 12VDC PDU for everything. I'll post a picture in the next day or two.

Any other questions, ask here or send me a message. I'll try and be more responsive.

Jay

 

[Neurorad]

Jay - I tried google, but failed - what's LMM? Local Monitoring Module?

Have you used a recent version of the ALC SceneTech software? Or is it redundant with the Elk?

Thanks for taking the time to post your review.

Sorry for the delay in this response. I've started it 3 times but never managed to finish.

First, a link:
http://www.onqlegrand.com/products/nav=a0f300000005ZJKAA2

HLC = Home Lighting Controller
- 1st module required for standalone installs
- Supports 1 branch and X-10
- Processor supports scenes and up to 3 more branches
- Pass-through serial comm to allow direct comm with switches

LMM = Lighting Management Module
- Event scheduling (time, event)
- Clock w/Sunset calcs
- Serial Port w/RTS(?) to toggle between HLC and LMM comm
- Links to HLC with ribbon cable

Home Lighting Expansion Module
- Adds 3 more branches to HLC

Serial Expansion Module
- Provides Serial port to HLC
- Not required with LMM

There are other serial modules (1 port, 4 port) for host-based control where the host does all the polling/commands/scenes etc. I have these but have since put them aside except for development/troubleshooting. It should be noted that the ALC physical interface is "almost" RS-485 but the levels are slightly off so an RS-485 device can "read" the commands but transmissions are ignored.

Regarding the SceneTech, I just updated to the most recent to verify functionality:
- Branch scanning and diagnostics (HLC)
- Supposed to have scene creation but not there (HLC), so the only way is via the switches (not fun)
- LMM Configuration for date/time/latitude/longitude
- LMM Rules

No, it isn't even close to Elk. While I have scenes created in the HLC all the real work is done in my Elk regarding rules (or via some python code I'm playing with to create eventlets). My LMM is only used for a serial port today.

However, at the same time, the Elk doesn't have access to all the scene buttons or taps/holds on buttons. My acronyms were wrong in my original post, this really needs a more intelligent HLC (not LMM) and some additional smarts in the Elk serial interface - Neither is hard, they just take time and somebody to have the desire for them.

One thing not mentioned here is what I would call "Installation Packaging" - for the ALC products I put in a 14" enclosure for _just_ the ALC-related stuff (HLC, LMM, Branch Expansion, Distribution Module and 8-port RJ45) with appropriate cabling to the Elk enclosure, branch hubs, switches (for local dist module) and Altronix 12VDC PDU/Distribution panel. I've opted to not use wall-warts and instead use a 10A 12VDC PDU for everything. I'll post a picture in the next day or two.

Any other questions, ask here or send me a message. I'll try and be more responsive.

Jay

Thanks, Jay. Good to hear from someone with many years of ALC experience.

Are you saying the 14" enclosure is too small? Sorry to hear SceneTech sux.

'Almost' 485? I thought 485 was like Serial - all depends on the protocol, nothing to do with DB9. Care to expand on your frustrations?

 

[JayH]

Thanks, Jay. Good to hear from someone with many years of ALC experience.

Are you saying the 14" enclosure is too small? Sorry to hear SceneTech sux.

'Almost' 485? I thought 485 was like Serial - all depends on the protocol, nothing to do with DB9. Care to expand on your frustrations?

If it sounded like frustration it wasn't meant. I wouldn't trade the ALC equipment for anything out there - my only "frustration" is echoed by others around here, lots of wires run and not enough time to finish !

The 14" panel is just fine, even has room for a couple more modules (picture below - more knockouts are out because this panel had a different purpose before this). My comment was more around general planning. They started in a 28" panel with some elk expansion modules, 12VDC PDU module, batteries, etc. and it was packed tight and messy. One thing I've learned since I've upgraded some of the gear as technology changed is to leave room in panels, slack in wires and label well.



As you stated, 485 like 232 (Serial, as you called it) or 422 is really subject to the protocol. In this case it was just a note for those interested that the physical layer is "almost" 485 in that it is differential, half-duplex and uses standard baud/parity/stop bits. It is also similar enough that a -485 interface can monitor/read the data stream. I haven't captured scope data to weed out the fine points, but where it differs is (1) the drive voltage appears to be significantly higher and (2) it is run in a loop or star configuration without needing terminating resistors, of which I suspect the higher drive voltage and some dampening is part of how the reflections are controlled.

The only reason this matters is if you want to create your own direct interface - you have to buy one of OnQ interfaces or do some hardware work.


Elk has an annoying issue that hasn't been resolved in 2+ years regarding ALC and you have to be aware of it. Call it "echo suppression" where the Elk Serial bridge buffers N commands it has seen go by and kills duplicates. Where this matters is sending a "Br1A1 On" you get an acknowledge followed by a "Br1A1 On" on a subsequent poll indicating the light has turned on.. It is a loose attempt at eliminating a feedback loop between the switch and the Elk controller. Where it fails is N only buffers about 4 commands so a scene switch that issues >3 commands or dimmers set to slow fades cause command feedback that make the lights turn on/off/dim/... and usually end up on full after a 4-10 seconds.

Jay

 

[Neurorad]

Jay-

You certainly know your equipment.

Good to hear you're, for the most part, happy with ALC.

(Is that an OnQ can? Where do you keep your 'extra slack'/service loops? Are those 1/2" shrink wrap labels? You can't show a pic of a clean install without expecting a few OT Q's. )

Perhaps the increased drive voltage was used to keep the system proprietary, but I'm sure this is causing problems with integration with non-ALC equipment.

So the Elk falls short, lacking a feedback loop between the switch and Elk. If the Elk serial bridge N buffered 10 commands, would this solve the problem, short of implementing a feedback loop? 'Loose attempt' sounds pretty negative. Three commands doesn't seem like much, to this noob, for a scene - and that's for all commands, not just lighting, through the serial bridge?

 

[rosenqui]

I've had a bunch of ALC switches (upwards of 60) running since 2000. The controller is an Aegis 2000 - an OEM version of the OmniPro with firmware support for ALC and a few other things that the Omni Pro didn't have at the time (but now does in the II series). The switches are the white "dimple" style that predate the inclusion of LEDs.

If I were building a new house I probably wouldn't go with ALC and would use one of the powerline or wireless technologies. It's much easier to just let the electricians install $2 switches with neutrals everywhere and then go around and replace them yourself one by one. The hardwired aspect of ALC is a double-edged sword; it eliminates most of the transmission problems of other solutions, but in new construction there's a pretty good chance that the drywall crew or some other trade will damage at least one of your wires.

I spent weeks with our home-automation / low-voltage wiring guy troubleshooting the ALC install, and it's still not as reliable as it was advertised to be. As a hardwired system I expected 100% reliability, and at well over C$150 per switch (back then) I didn't expect units to fail and need replacing at my time and expense. I've had 5 or 6 switches go bad and need replacing - almost 10% of my total! Some would just stop responding, others would respond on the wrong address regardless of their dip-switch settings after 5 years of working fine. I suspect that many of the problems I've encountered were due to the inexperience of my home-automation installer with such a large project. There also needs to be very good communication between the LV guys and the electricians when 3/4/5-way circuits are concerned. Our Cat5 LV lines for ALC were not home run, and a few of the AUX switch setups were quite difficult to get going as a result. We also had our share of bad wires (damaged by the drywall or trim crew) and bad connections (LV crew) that killed a ton of switches due to the daisy-chain wiring.

On really hot days we get a couple of switches upstairs that simply won't respond to automation commands.

The other source of frustration is that the Aegis controller is too slow to handle scenes containing a large number of ALC commands. I have scenes like "All basement lights off" that turn off 13 or 14 lights. The controller takes about 6 or 7 seconds to process and queue up the ALC commands, then all of the ALC basement lights go on together. It tells me that it's not an issue with the ALC protocol since the switches all get their commands at the same time; my controller is just too slow.

All of these problems are fixable and aren't directly attributable to ALC, other than perhaps the poor quality of some of my switches. If my controller supported UPB / ZWave / Zibgee I'd be auditioning those technologies, picking one, and gradually replacing my ALC switches with something else. For now I've got my 60+ ALC and a few X10 switches mixed in where the pre-wire guys forgot a Cat5 drop or we had a dimmable load > 600W that ALC couldn't handle.

Perhaps someday I'll upgrade my controller to an OmniPro II; that should hopefully help the response time problems. Alternatively I could connect my RCS KPL7 scene switches and all of my ALC runs to my Crestron controller and deal with them there. Upgrading to the OmniPro II would probably be less work

I like the idea of a lighting system that handles scenes on its own, but I still need it to integrate with a control system for things like "All-on with alarm", dusk/dawn activation, motion/occupancy sensor activation, etc. The kicker is that the software or procedures required to setup a scene needs to be on par with doing the equivalent programming on an automation controller. If I have to run around and visit every switch to get it enrolled in a scene, I'll just have the controller do it.