OnQ/Legrand ALC Lighting Driver - In Progress

[beelzerob]

The currently released driver is version 1.1, available as part of the official CQC release. Refer to the Supported Devices for how to use the driver and set it up. The driver posted below is a beta (test) version, and is not recommended for beginners.


New Capabilities
1) Support for scene switches
2) Serial or IP connection

Events
The scene events take the form of:
EventType ..............EventData
ButtonPress .............<SwitchName>+ButtonNum (1 - 4)
ButtonRelease ..........<SwitchName>+ButtonNum

DB9-RJ45 Adapter Pinout
DB9 Pin RJ45
2.............4
3.............5
5.............2
7.............3

[sic0048]

This is great news. I've always thought that I would use the OnQ ALC system if I ever automated my lighting. It's nice to know there are some people already using it and there potentially being a CQC driver for it.

I saw your posts on Cocoontech and was getting excited!

I'd love to hear you experience with the hardware as you go along. I've seen the system working first hand in a commercal setting, but it's always nice to hear what other people have to say about it.

[beelzerob]

I'll be happy to post my impressions on the whole system as it goes.

[beelzerob]

Hardware received. Woot! I'm buried in house work right now, but my first order of business is to build a hobby box of powered switches and lights so I can do the programming right next to the lights, instead of trying to program lights I can't even see....

[Sacedog]

Sweet! I am very excited about this driver, as I will be using ALC lighting. They started framing two days ago, so I'm finally starting to see some progress.

[sic0048]

Rob,
just curious who you used as the supplier for the ALC equipment? Did you use SetNet out of SC or another firm?

[beelzerob]

Setnet is the only one I'm aware of. Everything I've bought, I got from them.

[sic0048]

They are local for me (although a little out of the way in an area I don't frequent very often) which is why I asked. Great guys IMHO. Always very friendly and extremely willing to share their knowledge. I love to plug them any time I can.

Keep us updated on the progress - I'm sure it is going to be much slower than you want it to be :)

[beelzerob]

Keep us updated on the progress - I'm sure it is going to be much slower than you want it to be :)

Hehe..you have no idea....

We're on our 3rd week of a stone veneer undertaking at our new house, which was supposed to only take 1 weekend. We're finally down at ground level, which makes things infinitely easier, but we've got to put stone around the mantle, fireplace, and hearth, all of which are much more complicated to do than simple flat wall, which we've had up to now.

That, and the cold/flu has made its rounds in our family, and we're finally getting out of it, but it slows everything down.

And I've got a backlog of drivers I need to clear out somewhat before I can truly dive into this one. And, I need to build my "hobby box" of switches and lights, which will be relatively fun and a learning experience, but will still require some weekend I haven't yet been able to find.....

So yes... you are right. ;-) But I'm still very excited about this stuff. I find the protocol to be pretty full powered, and I'm very impressed with the hardware I have so far.

[beelzerob]

Well, as rightly predicted, it IS going slower than I'd like. I have the hardware needed to build the hobby box now, but time is slipping past again.

We finally finished all the stonework, and even put the hearthstones on. So Wed night, we're going to grout them, and also lay down some slate on the floor around the fireplace. While my wife does most of that, I'm going to attempt to wire a switch and light up a wall to light the unfortunately and unexpectedly dark toilet area of the downstairs powder room. If I can manage to do that, then I'll be more emboldened to build my hobby box. Hopefully I can make that happen during the week nights, as this weekend I'm going to be driving around a little excavator and digging ditches...whee. :roll:

[beelzerob]

Well, step one accomplished....

http://home.comcast.net/~beelzerob/onq/hobbyboard1.JPG

With a combination of boxes, switches, and fixtures from Lowes (maybe $20 total spent), and wood and sheetrock scrounged from the house construction, I now have my first step towards a hobby box to work on the driver with. A simple arrangement of 2 switches controlling 2 lights.

The next step is to remove the switches and replace them with an OnQ dimmer and relay, and then verify THOSE work as-is. THEN I'll wire them with cat5 and hook them up to the controls.

Fun stuff!

[ToyMaster458]

I have been thinking about looking into On-Q lighting so I am looking forward to your findings. Can you post a couple of pics of the switches front and back?

[beelzerob]

Sure thing. It's going to be interesting to see how well they fit in the gang boxes I bought. Mine are pretty standard depth, and I believe they're as deep as the ones in my actual house.

They'll actually fit fine, I have no concerns about that. It's just the wire and wire nuts that I'm concerned about fitting in the remaining space.

[beelzerob]

Here are the switches.

http://home.comcast.net/~beelzerob/onq/switches_front.jpg

Relay (15a max) on the left, dimmer (900W max) on the right. The only noticeable difference is the heat sinks around the edge of the dimmer.

http://home.comcast.net/~beelzerob/onq/switches_side.jpg

Here you can see the wires that need connecting. 4 high voltage wires...ground, neutral, hot, and switched hot. The low voltage control lines are routed up the top of the switch and are supposed to end up on top of the gang box so you can make your LV connections there without being inside the box. You can also route them in the box if you want, assuming you can shield them propertly.

Hopefully tomorrow I can yank those standard switches and put these in and see how well they work.

[beelzerob]

Here's a question for you electric types.... I've installed several fixtures now, which all seem to come with stranded power wire (including the 2 fixtures above, and all the power wires from the switches). How do I securely connect those to solid copper wire?

The manual for the fixtures says to use pliers to wrap them around each other...ya right. The solid copper won't twist at all around stranded, instead you just start breaking off strands. So, I just took the stranded and wrapped it around the solid copper, and then put a wire nut on it and twisted a little more, than taped the whole thing. Is that as good a method as any?

[sic0048]

Yes - that is all you have to do. As long as you use the correct size wire nut for the job, that is perfectly acceptable.

I generally start the electrical tape by wrapping the wires together below the nut to make sure they are secured, and then move up and wrap the tape around the wire nut to keep it attached. But I think wrapping the wires together below the nut is probably the most important step.

[beelzerob]

Ya, that's what I ended up doing, because I was concerned about the stranded wire pulling apart, since I have no confidence that the wire nut will keep the wires together (unlike if they were both solid wires).

[beelzerob]

Step 2 accomplished!

I took the standard switches out and replaced them, dimmer on the left, relay on the right. I haven't hooked up any control yet.

I'm pleased!

The wiring was a little challenge, as I didn't have much spare wire to work with from the switches. But I managed it, and I don't think it'll be a problem in my house, because the electricians always leave enough so you can pull the switch out. Stuffing it back in the box was a greater challenge, though, for a couple reasons. For one thing, I didn't trim any of the wire coming off the switch, and those are pretty long. Also, the boxes I got are maybe standard, but not as deep as my house ones. The real challenge was the 4 wire nuts that had to be shoved to the back...I don't know if there's a more slim way to connect wires or not. I pretty much could have shoved it all the way in, but I didn't trust my wire nutting enough to stress it.

The dimmer feels better in use than I feared. I'd heard they're kinda squishy, or not clear when you've hit it or not. Just playing with it, I didn't have that sense. On felt like on. Holding the switch on or off will dim the bulb in that direction. Hitting off turns it off, and hitting on turns it up to the dim setting. Hitting on again while it's dimmed turns it up to full. Either it's programmed for 2 hits, or it just responds fast, because hitting on twice while its off will bypass the dim setting and go straight to full. I didn't hear any buzzing or any sounds coming from the switch, though to be fair, I'm testing a 60w bulb on a 900w dimmer....so I don't think it's struggling much here.

The relay acted just like you'd expect a relay to...on = full, off = off. However, there is a quite audible click when it goes on and off. Obviously that's the relay clicking, but its louder than I'd thought it would be. You could make an arguement with some validity that it's no louder than the sound a normal light switch makes when you flip it...but if you're replacing rocker switches in your house, then it might seem a bit loud.

Anyway, step 2 is a success. I'm pleased with how the switches work, and also pleased to demonstrate that these switches work just fine without any control, so they conform to the #1 WAF demand, which is that they'll work flawlessly if the control goes kaput.

I can create and post a short video of the dimmer if you want, but it's otherwise what you'd expect.

Step 3 will be connecting the control lines. I didn't run the wires over the top of the box like they suggested just because I didn't feel like cutting more of the sheetrock and making a mess...so, for my purposes, I'm just going to make the connections on the front where the wires are available.

[beelzerob]

Connections have been made, though there was some confusion. My relay and my dimmer have different colored wires, whereas the ALC documention I received online only references one color for all switches. I was finally able to sort it out, but I'm going to have to go back and double check, because I think some documentation somewhere might be in error. As for the different coloring of wires, I guess I have 2 different "version" switches.

It took some trial and error, but now when I press a switch, I see the ALC "activity" light flicker on the controller....so that's a good sign. I then tried hooking up the PC, but no luck there, so I think again I have a miswire. At least a good portion of this problem is my own ignorance of cat5 wiring...the ALC instructions are overall pretty good.n They direction you to connect their wires to specific cat5 colored wires, and then it's all cat5 from there.

Anyway, next step is to try and get PC communication going. I can see the controller board "transmit" light flickering when I press a switch, so it is definitely sending out a message.

It's been a real tough past week or so with the movein, and next week is no better due to grandparent deaths. But hopefully the week after that, and assuming I've sorted out the wiring, then I look forward to posting a working version of a driver.

[beelzerob]

Woot! Successss!!

After MUCH wiring of rj45 connectors and re-reading of the docs, I finally hit on the magic formula to communicate with the controller. And shortly after that, I hand-calculated the correct value to turn on and off a relay via serial command. Woot!

That means I'm finally at the point where I can put together a (rough) CML driver to give simple on/off control.

There's no name storage in this thing (unlike the Centralite I've spent so much of my life on), so light configuration will have to take place via a config file. Looks like an initial cut would be:

Name, BranchID, ModuleID

[beelzerob]

Ok, version 1 is posted and working. I'm able to turn the relay and dimmer on and off. That's all it does right now, but it's a good start.

[beelzerob]

Well, this driver has languished too long. I want this listed among supported devices, so I'm making this my new #1 priority, until I get a publishable version.

What I'll shoot for is 2-way control, as well as dimmer rate and level. That should be pretty complete.

[beelzerob]

Ok, so loads are 2-way now. In other words, they'll reflect in CQC when they're changed via switch. Also, pressing and releasing switches, in the on or off position, sends a user event you can trap.

[AceCannon]

Ok, so loads are 2-way now. In other words, they'll reflect in CQC when they're changed via switch. Also, pressing and releasing switches, in the on or off position, sends a user event you can trap.

I think it is great you are working on this. We are starting framing on our house this week and I tentatively plan to use ALC switches. I was planning on using the Elk to interface, but now with your CQC driver. . . I dunno.

Are you using the "Home Lighting Controller" along with a "Serial Expansion Module" to interface with CQC?

[beelzerob]

I think it is great you are working on this. We are starting framing on our house this week and I tentatively plan to use ALC switches. I was planning on using the Elk to interface, but now with your CQC driver. . . I dunno.

You'll have to choose one or the other, I believe. It's a different serial expansion card ( I THINK) for the Elk, and you can't have them both plugged in at the same time.

Are you using the "Home Lighting Controller" along with a "Serial Expansion Module" to interface with CQC?

Yup. I have a minimal working set right now (not even an install really, since it's sitting on my desk). Both switches are wired together, and wired into the HLC. The HLC is connected to the serial expander, and that is connected via RJ45 to RJ45-DB9 adapter to my PC.

[AceCannon]

Yup. I have a minimal working set right now (not even an install really, since it's sitting on my desk). Both switches are wired together, and wired into the HLC. The HLC is connected to the serial expander, and that is connected via RJ45 to RJ45-DB9 adapter to my PC.

Yes, I believe I saw your bench testing setup on another thread (or another forum elsewhere). Would you consider adding a pic or two to this thread?

[beelzerob]

Yes, I believe I saw your bench testing setup on another thread (or another forum elsewhere). Would you consider adding a pic or two to this thread?

Heh...actually it WAS this thread...but I changed ISP's, so my online storage went away and the links are bad. Ya, I'll take a new pic of the current uber-cool setup and post it.

[beelzerob]

Ok, added dimmer level field, 2-way.

The protocol allows for 3 different was to set the dimmer level...you can jump straight to it (which the driver currently does), you can ramp to it...and you can extended ramp to it. geez.

I'm considering making that something that you set in the config file...which of the 3 ways you want to change the level. Or i suppose it could be a field you set LevelChangeMethod or something. Or I could change the level field to a string instead of card, so you can enter level and change method...but then you couldn't use a slider for the level. So that will stay a card.

I guess I'm leaning towards the changemethod field. You can input the branch, address, and change method.

[beelzerob]

And here's the pic of my kick-ass setup!

http://home.windstream.net/robandsheryl/misc/alc.jpg

In reality, though, the driver is ALMOST to the point where I can dispense with the setup and actually install the switches somewhere. I just haven't figured where yet...There are places for the relay, but probably not where there are lights, since I'd rather user dimmers for that. I guess maybe the garage...who cares about dimmed garage lights?? The dimmer is the 900w kind, so I have to find the biggest collection of lights I can. I know a couple 400 watt ones, but that'd be a waste. The other challenge is finding one in a single gang install so I don't have to break off heatsink tabs. I guess there's always the basement....

[beelzerob]

Added global scene learn and restore fields. This allows you to create up to 16 different global scenes, which is basically just the setting of all ALC switches.

I'm still kinda trying to figure out the best way to deal with dimmers. I'm thinking that in the config file you can specify which way the dimmer changes to its light level, and then I'll include a field you can write to to change it later on, should you so choose.

One other issue....this protocol ALMOST has too many options.... The way the dimmers work (manually), when you press and hold the button, it sets the dimmer level. And then when you press on from an off state, it goes to that dimmer level. If you press on again, it'll go to full bright.

The way the driver works, if you set the dimmer level via the field, that does NOT affect that set dimmer level. That's a separate command. In other words....if I have manually set the dimmer level to 60...and then I turn off the light...and then using the dimmer level field, I set it to 30....then when I hit the On button, it will then go to 60, because that is the set value for the dimmer. The set value is different than the value directed by the driver field.

Now, I COULD have the driver always re-write that set value, whenever the light level is set via the driver. The commands to set that light level are in there. I just didn't know if that was a good idea or not. If you set the dimmer light level via the driver, would that normally be the light level you would want the dimmer going to if you hit the "on" switch manually?

Food for thought, if you can possibly understand what I'm trying to say....

[AceCannon]

Now, I COULD have the driver always re-write that set value, whenever the light level is set via the driver. The commands to set that light level are in there. I just didn't know if that was a good idea or not. If you set the dimmer light level via the driver, would that normally be the light level you would want the dimmer going to if you hit the "on" switch manually?

Food for thought, if you can possibly understand what I'm trying to say....

Yep, I understand. It sounds like the protocol is quite robust. Have you considered coding a way to re-write the set value via the driver on demand only? So perhaps in CQC you would go to a separate lighting screen, set the light level, then tap a button if you wanted to make it the new set value. Otherwise it would not change the set value if you simply adjusted the dim level via the driver in the majority of the CQC interface. Just a thought. This might not be the best way to go about it. . .

[beelzerob]

Ya, that's actually a pretty decent solution. Good enough for me, anyhow. I can always change how the driver works once people start using it, if there's some preference one way or the other.

[beelzerob]

Ok, added the ability to set the dimming method, either Jump, Ramp, or Extended Ramp. Currently those can only be set in the config file, but I'll add a field for changing it while running.

The neat thing about that is that Ramp is a very nice gradual transition, kind of what you'd expect in a dimmer. But say you're in the theater or TV room and the movie is starting...you could use an Extended Ramp to have them very gradually go down...say over the course of 10 seconds. But then the smoke alarm goes off during the movie...so then you Jump the lights back on.

Anyway, it's a neat feature.

[AceCannon]

So do you use an Elk, also? How much of this lighting control of ALC is available via CQC's Elk driver already? I take it the options are more limited?

[beelzerob]

No idea on that...I'm Elk-less. There are more OnQ lighting users in the cocoontech forums, so there might be a better chance of catching someone there that uses it via Elk. There's probably some kind of interface spec somewhere also....but I dunno.

[beelzerob]

Dean, I'm getting some really bizarre results here....

I've created a light object that holds pertinent info about each light. When a certain string field is changed, then it goes into the appropriate light object and changes a byte value (card1). I've verified it does this. However, every time I go back into that light object...the value is back to what it was originally.

I've checked every possible place that the value could be changed at, and put breakpoints at all locations, and it is never called unexpectedly.

Possibly associated with that....I got an unhandled c++ exception while trying to debug this. After changing the string field again, i got:

An exception occured, so the current operation has been aborted.

All it has is "Ok". As it turns out, clicking OK does nothing either....the error box just sits there. Hitting escape finally dismissed it.

I also get:

An unhandled exception occured during dialog box processing. It will now exit.

I keep getting these error boxes until I close the harness, which had to be done via task manager.

Any ideas? I'm on 2.4.0

[Dean Roddey]

Sounds like you've found something wierd there. Are you storing a vector or array of these objects I assume?

Keep in mind that, unless you are using a collection, when you access a member you are getting a copy. So if you have some class that is providing access to other objects that are members, the caller is setting the value on a copy he is getting back, not the original. No one can ever access the members of a class directly. In those types of scenarios, you want to do something like pass in an id of some sort along with the value, and have the target class make the change internally.

If you us a collection, then those are not members, they are just contained within the vector or array, so you do have access to the objects in a collection.

But anyway, that aside, it sounds like you may have found some gotcha in the runtime. So you may need to explain more of what you are doing.

[beelzerob]

that musta been it...I changed it to use the returned index instead, and it now works.

I had been passing in an object as an [Out], and setting it to one of the array objects, and then passing it back out so I could change it. Must have done the wrong thing. Thanks!

[beelzerob]

Ok, latest version is almost feature complete.

I added the ability to change the dimming method, either Jump, Ramp, or Extended Ramp. The extended ramp has a settable value for how long it takes, but the protocol is too confusing for how to set that value, so I have a question in to the engineers at OnQ. They've been pretty helpful so far, so I hope to have that figured out soon.

I also added the ability to set the "preset" light level of each dimmer. That is the value that the dimmer goes to when you physically press the On button. Note that that is different than what happens when you write True to the State field. When you write True to the state field (which executes an "On" command), it goes to full bright. That doesn't seem intuitively right to me, so I also have a question in about that. But either way, you can now set that preset level via a field, and it's 2-way, so if you change it at the switch, it will still be reflected.

The only thing left I have slated is that extended ramp rate value, and once that's figured out, I'll package this up and give it to Dean for formal inclusion. Any last requests?

[AceCannon]

The only thing left I have slated is that extended ramp rate value, and once that's figured out, I'll package this up and give it to Dean for formal inclusion. Any last requests?

I am too ignorant to make requests a this point, but I am quite pleased that you have put the work in to make the driver.

We've been framing for one week now, and they are already done with basement and main level, started on second level. So it is almost time to have my wiring, switches on hand.

Where do you recommend I purchase the ALC hardware? Or should I count on my electrician being able to get a better price than I can?

[beelzerob]

You can certainly ask an electrician, but unless they're some kind of dealer, I don't think they're going to have low prices.

The only place I'm aware of even to get them is setnetpro.com. If you go there, create an account, and then check the prices. For whatever reason, the prices are a lot lower when you're logged in....but of course, for switches, they're still pretty expensive.

The setnet people are really good, though. They're very firm believers in ALC/OnQ.

[beelzerob]

Ok, the driver as it exists now has been given to Dean, and will be version 1.0 included in the next release.

But just so you know...there's more work to be done. I don't have the scene switces and I/O modules supported yet because my hardware hasn't arrived yet. However, even the relay and dimmer control presently in the driver rivals most other lights systems, in my opinion. I'm pretty pleased with it.

As you start to use it, be sure to post any quirks, bugs, or anomalies you may encounter.

[AceCannon]

Ok, the driver as it exists now has been given to Dean, and will be version 1.0 included in the next release.

But just so you know...there's more work to be done. I don't have the scene switces and I/O modules supported yet because my hardware hasn't arrived yet. However, even the relay and dimmer control presently in the driver rivals most other lights systems, in my opinion. I'm pretty pleased with it.

As you start to use it, be sure to post any quirks, bugs, or anomalies you may encounter.

I am a little ways off from using it (still framing the house), but I will certainly give you feedback when I can. Hopefully, you will get some other beta testers before me. .

[beelzerob]

I have a pretty high confidence level in it, as I've been toying with it for a while. It always helps to have others breaking it, but I definitely feel good about its stability.

In fact...I'm finally actually considering using the system in my house! (up to now, it's been stuck on a board next to my PC so I could see what was happening right there). That might be a good idea actually, since actually using the system will probably reveal any areas that could use some driver enhancement.

[AceCannon]

Here (http://www.cocoontech.com/index.php?showtopic=10149)is a thread on cocoontech where a guy is interested in the ALC switches.

[klindy]

Rob (or anyone using this driver) do you have any updated comments on this driver? I'm looking for a sense of if/how it's been implemented and whether the CQC/OnQ ALC combination has met expectations.

[beelzerob]

Well, the "if" = "yes".

The "how"...I'm not sure exactly what you mean....I'm assuming you don't want the technical explanation. The driver docs are in the beta online webpages, by the way, if you haven't perused those yet.

As far as meeting expectations...I can't say, as I'm not actually using it yet either. I have the switches, I have the wires...I've just not had the time. I think it'll happen sometime after I put my rack in, so who knows when that'll be. I am curious if anyone else has actually been using it....

[klindy]

I guess I should have said "how well" it was implemented. In other words, if it's working as expected, in use, WAF, etc, etc.....

[beelzerob]

I guess I should have said "how well" it was implemented. In other words, if it's working as expected, in use, WAF, etc, etc.....

Oh....well as to "how well" it was implemented, I think I can safely say that the protocol was implemented in the most awesome fashion possible, with absolutely no way for there to be any better implementation....ever.

I can also safely say that it is working "as coded".

But I still can't speak to how it rates in use, or WAF, or even one etc (let alone two etc's).

[Sacedog]

Hi Rob,

I finally got CQC installed last night, and am looking forward to using your dirver within the next couple of months. Originally, I was going to do my lighting through the Elk, as there wasn't support through CQC, but I am leaning towards using CQC now.

Can you post the part numbers of the OnQ HLC and Serial board that you are using? I believe that I have the correct HLC, but will need to get a Serial board, as I originally bought the Elk Expansion Board for the OnQ system.

[sic0048]

Any good reason to choose CQC over the ELK for control? It seems that the ELK actually provides slightly more integration at this time (can use scene switches, etc) and you should be able to control the ALC system from CQC by going through the ELK.

If we use the ELK and control it via the CQC ELK driver, will that add any noticable delay in commands? Are there any other compelling reasons to use one method over the other?

I'm just trying to wrap my brain around it. I am getting closer to moving to an ALC system (would retro my house slowly) and I'm trying to figure out the best way to control it.

So here are some of my ideas. Please help me complete the thought process....

Using the ELK
Positives:
Cheaper if buying new hardware - you should be able to use the ALC ELK Controller which is the main controller, the ALC serial controller, and the ELK serial adapter all integrated into one device
ALC control even if computer goes down - I know the ALC switches will work even if the controller goes down, but using the ELK could allow some automation to occur even if the CQC system goes down. Of course this depends on how you program the system. You would have to rely on ELK programming for this to be true.
More complete ALC integration right now - the CQC driver isn't able to use all the capacities of the ALC system in it's current form (as of 2/5/09). Mainly because it is lacking the scene switch support. Beelzerob simply needs a volunteer with a scene switch to get this working however. So it should not be a long term disadvantage.
Better potential resale if the system doesn't rely on CQC to work. Moot point if you plan on putting in regular switches (non-ACL) to resell.

Negatives:
????? - What are they
Obviously requires an ELK to integrate with.
Is it slower to route commands through the ELK than it is to go straight from CQC to the ALC system?? In either case I would assume that you would have to use the event manager to watch for field changes and then act on those field changes for more of the "automation" events. If using the ELK you will watch ELK field (perhaps this could add a slight delay since the ELK would have to update its status first), if using the ALC CQC driver, then you would be watching those fields. Writing commands could go directly to the ALC controller if using the CQC driver rather than writing to the ELK driver and letting the ELK pass the commands on to the ALC controller.

Using CQC ALC Driver
Positives:
Could be cheaper if you already have existing ALC hardware because it doesn't require the use of the ELK serial interface. If starting an ALC system from scratch, and you already own an ELK, I think the all in one ELK controller is cheaper becuase it combines several components into one controller.
Doesn't require an ELK or other hardware to be able to control lighting with CQC.
???? - Help me complete the list

Negatives:
CQC Driver doesn't support scene switches as of 2/5/09 - but should once someone can test an updated driver.
Some buyers may not be interested in using CQC for automation. If the lighting system is tied to CQC, you may run into problems if you have to sell your house. Moot point if you plan on putting in regular switches (non-ALC) for resale.
???? - Help me complete the list

[beelzerob]

I'll (try to remember to) post the serno of what I've got tonight.

As far as supporting the 4 button switches, there are two types. There's the 4-button aux switch, which is inherently supported, since it's just the same as your regular aux (dummy) switches..there's just 4 in one gang. It just closes the relay/dimmer it's attached to, whether directly to the switch, or to a control board.

If you mean the scene switch that has its own address, it's true that there's not currently support for that, but that's just because I don't have one on hand to test with. The actual coding is pretty easy for that, really...and I think it may actually be mostly in there. But since I couldn't test it, I didn't want to advertise it. However, as soon as someone gets one of those and wants to be the tester, I will implement it. I've commited to doing that.

[klindy]

Brian,

I've also headed down the path on usung OnQ ALC lighting. In the course of my water damage/remodel, I've pulled all the LV wiring in anticipation of using ALC lighting.

One thought I had regarding CQC control direct or ELK/OmniPro (I have the HAI OmniProII) is some added flexibility if or when you sell the house. I anticipate leaving the OmniProII installed regardless of whether a new owner wants CQC or not. Going through the OPII initially will save some change over effort if CQC comes with me.

That said however, response times, features and reliability rank far higher on the list than any potential of selling the house at some point.

[beelzerob]

Ya, I've tried not to think about resale...it scares me. Thank goodness for the OnQ route, though, I can just throw the old switches in there if needed.

But otherwise that is true, I'm not leaving anything that required CQC to work right because I'm not leaving CQC with the house.

I sometimes cry silently to myself that so much of this money and time invested is actually probably going to be a negative selling point when the time comes, not a positive. But then that's when I decide I'm living here forever....

[klindy]

...But otherwise that is true, I'm not leaving anything that required CQC to work right because I'm not leaving CQC with the house...

Unless it decreases the value of the house at selling time, I'd rather buy a new license and leave my mistakes/experiments behind than make the effort it will take to completely remove all the HA stuff.

Some of the things I have done are easily adaptable - such as whole house audio vs. our 'most common' TV viewing area. In that instance I have all the equipment centrally located but, if removed, the wiring allows for a cable box/DVD player/TV to all be local to the viewing area.

In terms of lighting however, I'd be inclinded to leave the ALC switches in place and let the HAI equipment provide the basic lighting control and remove the rest of the HA stuff as required. The incremental upgrade path I seem to be on makes the 'effort to remove' items a bigger deal than the 'investment in switches/etc.' That opinion may change once I get further down that road however.

Back to Brian's post, at this point I am inclinded to let CQC control whatever it can natively assuming the same features are available. If/when we sell the house, I sort that out then. That said, assuming the same features are/will be available, the real issue would be response time and reliability correct?

[beelzerob]

I can't imagine leaving CQC in a house would appeal to any normal home buyer. Sure, I could just leave all the PC's and equipment and even the license there...but would any possible home buyer really consider it a plus to have software running stuff they totally don't understand? It wouldn't be a month before some glitch happened.

[klindy]

I can't imagine leaving CQC in a house would appeal to any normal home buyer. Sure, I could just leave all the PC's and equipment and even the license there...but would any possible home buyer really consider it a plus to have software running stuff they totally don't understand? It wouldn't be a month before some glitch happened.

Not sure I understand your comment Rob..."leaving CQC in a house" appeals to 100% of the Integrators customers!

I think I'd whittle it down to something which is pretty stable and leave it without any concern. If there's a problem, I guess it's their problem. Referring them to a helpful integrator may be possible.

The way I look at it, I bought a "pre-owned" home with all it's warts and scars. I've felt like it's a money pit recently too. But I sort out what I have to and handle it or hire someone to come in and deal with it. If their advice is to "pull it out and start over" I weigh that with what I know and go from there.

For example, the house I live in had "whole house" audio (in other words, speaker wires pulled to a central location) and a "state of the art alarm system". Neither were true since some of the speaker wires were broken and the speakers installed were worse than those in the '67 Chevy Impala I once owned. "State of the art alarm" consisted of a key pad and loud siren. Problem is many of the window/door sensors were non-functional.

My point is, I would have NO concerns about leaving CQC installed as long as they knew it was as-is, where-is with no warranty or gaurantee expressed or implied. My hope would be to leave someone with a pretty well documented 'blueprint' of what's in the house, etc.

[beelzerob]

I think my plan is to make leaving the stuff optional, for a price. Kinda like leaving the fridge. but certainly with no warranty or support from me.

But honestly, it'd take a nuclear holocaust to get us to move...and even then, we're probably in the best place to endure one. So for now, all these discussions are just academic.

I otherwise can't weigh in on the Elk vs CQC debate, since I don't own an Elk, so I'm 100% CQC.

[AceCannon]

Elk vs CQC:

Beelzerob and I went back and forth about this before. I remember that there are some controllable fields in the ALC protocol that I wasn't sure were implemented via the Elk. So I think his CQC driver may be able to control some "ramp rates" or somesuch to a greater degree than the Elk can.

As I recall, there are some "default brightness" levels that could be specifically set via CQC. . .

[beelzerob]

Oh ya, I forgot about that. There was never a definitive answer on just how much control the Elk gave.

[beelzerob]

FYI. I finally installed my first onq relay. Yay! But then couldn't get it to find it in the driver!

So, to aid in that effort, I added some code to the driver. Now, when it can't find the config file during connect, it will basically "map" the light objects and create fields based on that.

It's crude, as there's no way to find out names for the devices. So the field/object names are based off of the branch, address, and type.

So, for instance, though I thought I had put an address of 1, my driver found the relay at address 30. So now I have a field: "Br1_Addr30_Relay_State". Like I said, it's not pretty...but it works!

Of course, now that I know the address, I can go back and edit my config file with that address, and I'm good to go.

Anyway, it works for relays or dimmers. I'll send it to Dean as an update.

[AceCannon]

Beelze - it sounds like you are having to kludge this together. What is your current assessment of the additional benefit of a CQC driver over existing control via the ELK driver? I realize you do not have the M1G, but I think this is the crux of the matter for a lot of folks.

[beelzerob]

Oh, I wouldn't call this a kludge by any means. I am a little surprised, since I was SURE I had set the address to 1, not 30. But maybe I knocked one of the little dip switches while installing. Either way, the address issue would be the same whether using CQC or the Elk.

For that matter, I wonder how easy it is to troubleshoot the switches when they're attached to the Elk. Do you get debug messages? How easy is it to track down a misaddressed relay? can you name your lights? In CQC, you can give a name to every light, which makes the programming a little more intuitive.

So other than getting the address right, this has been bang easy to do. Wrote a few simple rules in the event manager, and now our shower fan turns off automatically after 10 minutes. (eventually it will probably be humidity triggered).

I know you and a few others are really agonizing over this...guess I'm glad I'm not. One of the many great things about these OnQ lights is they don't require any control in order to work, so the control is just bonus. So in that regard, I don't see the advantage of having hardware control as far as being more bullet-proof. You need your CQC server either way.

the only other thing was I didn't know if anyone had ever figured out if the Elk supports all of the dimming options (ramp, jump, and extended ramp).

[AceCannon]

OK here is another question. Say you are going to set a "scene" using CQC. You have a button in your GUI that will set three different lights to different dim levels at a certain ramp rate.

When you hit the button, do all there lights begin ramping at the same time?

Or does it do the first light, then start on the next one?

And what is the delay between hitting the button in CQC and the ALC controller getting the message and starting the process?

[beelzerob]

Well, your first option is to use one of the global scenes. Granted, I think it involves EVERY light in the house, but they're pretty easy to use. You just write to the specific global scene field to set it, and then write again to trigger it.

Otherwise, if you're talking creating your own scene in CQC (as in, once you click the button, it sends out, say, 5 different lighting commands), then I'm pretty sure it just sends out the commands, one after the other. It will probably wait for an ACK when it sends out each command, but it won't wait for that light to have completed its dimming before starting on the next one. It'll just send them all to the controller as fast as it can. Unfortunately, I don't have any dimmers installed yet, just the one relay. I do have a test rig though that has a dimmer and relay in it, and I could replace that relay with a dimmer and then test the two dimmers together to see if they both start dimming at the same time. If that'd be useful info for you (granted, it's only 2 dimmers), then I can do that tonight without much effort.

As for the delay...when using the test rig and having the lights, controller, and cqc driver all right in the same area, I can't recall there being any noticeable delay. The only delays are whatever is built into the CQC system when a field is changed. Otherwise, the command goes to the controller and it immediately gets executed. Again, with the test rig, I can try that out. I'd call it as instantaneous as everything else CQC controls is.

[AceCannon]

Nah I wouldn't test it unless it would be useful for you. I am just curious. I am a ways away from deploying my setup so I can't test anything yet.

[beelzerob]

Well ok, if you can wait, then I WILL be installing more lights in the somewhat near future. The next ones on the list are all 3 or 4 ways, and I just can't figure them out, so I'm going to wait for an electrician, which hiring requires Ministerial approval.

[beelzerob]

Hmmm...for some reason that learn/restore of global scenes doesn't appear to be working. I know I tested it before and it did.

I'm probably going to change the event (for button presses) to have the switch name, instead of the branch and address. The switch name has to be unique anyway, since it is the basis for the field names...and the name will be more intuitive to use.

[beelzerob]

Ok, I've changed the events to hold the switch name now, and that's a bit more helpful. I also fixed the global learn/restore functionality.

However, I have discovered that if you hit the switch a double tap Off (which causes a very slow dim down), the state and level of the switch does not update. So I'm investigating that.

[beelzerob]

Ok, doubletap now updates level and state. And also restoring a global scene will update all switches it affected. Events have been changed so they're easier to work with. New version is posted on the front post.

Note that changing the event data will break this driver if you're currently using it, as the event type and data both changed. Check the first post for what it will be.

The only remaining issue is that if a global scene changes a relay, that isn't reflected. I should be able to get to that tomorrow.

[beelzerob]

I'm toying with this idea....

There is an extended ramp rate that can be set, which can give you a ramp time (from current level to desired level) anywhere from 0 sec to 10 hours. Right now, that is only settable via the config file...so it's a one shot deal. Once that's set, then you can change the dimming method to either ramp like normal, or do the extended ramp, using the ramp rate you set in the config file. I just figured it wasn't something you'd change often.

However, it SHOULD be something you can change. So, I see two main ways of doing it.

1) Give each dimmer its own ExtendedRampRate field. The field would be a card, with limits of 0 to 16383, where it represents ramp time in increments of 2.33 seconds. So, a value of 5 would equal just over 11 seconds. Once set, you'd have to change the RampMethod field to ExtendedRamp for the dimmer to use this value.

2) Create a single field that lets you enter a string phrase to say what to do. So, for example, you'd write: Foyer 20 Minutes 5

So that would take the foyer lights to level 20 over the course of 5 minutes. The nice thing about that is if you want to do a "one-time" extended ramp, you don't have to worry about saving the current ramp method (which will probably always be Ramp), changing it to extended ramp, setting the ramp rate, and then setting the level...then reset the ramp method back to what it was. Instead, the ramp method field wouldn't change. It'd just be a one-time command to do an extended ramp (using the entered ramping time, not the value put in via the config file).

Any inputs?

[AceCannon]

What is the "config file"? Where is it stored?

Does each ALC device store an extended ramp rate variable?

[klindy]

I haven't started installing any ALC stuff yet (but I will) however, I like the sound of the first method best. I guess I can foresee using some variables and perhaps some simple math to allow different ramp times for different purposes.

That said, it seems the "0 to 16383" (I assume that's 0 to 10 hours) is an extremely wide range. I suspect that most ramps would want to be 'minutes' in duration at most. Perhaps ramping the lights based on a sun rise or sunset is the longest duration extended ramp I can envision using (again this is a guess since I haven't installed anything yet).

Is it possible to have an programmable extended ramp range from say 0 to 30 minutes and leave anything longer than that as a config file solution only? Not sure if that makes sense but just thinking out loud here I guess.

Thanks for all your work with this driver. Sounds like it has quite a few features!

[Squintz]

That is a tough choice. Is there a way to request what the current ramp time is? If so then I would make multiple fields. If there is no way to request the current rate then a single field would be best.

I almost wish that fields were more like objects. It would be nice to create an object of the type Switch which would have Methods to read and write the ramp rate and other properties. It would make things a lot more structured.

[beelzerob]

Actually, I use a switch object to store and manipulate this data. Works pretty well. But I understand what you mean about the fields.

Yes, the extended ramp rate is queryable (so, 2-way), and it is per switch (dimmer only, of course). The values that can be written are from 0 to 16838, where each bit is worth 2.33 seconds. So I figured I'd just take whatever value was input, convert it to seconds, divide by 2.33, and that'd be the value I'd use. It'd be accurate to within 2.33 seconds anyway.

The config file goes in the macroroot directory, and is explained in the first post. You can go without a config file, but then all your switches will be named "Br1_Addr29_Dimmer", and the like...since the objects have to be named something. The config file mainly lets you give them more understandable names.

[AceCannon]

Actually, I use a switch object to store and manipulate this data. Works pretty well. But I understand what you mean about the fields.

Yes, the extended ramp rate is queryable (so, 2-way), and it is per switch (dimmer only, of course). The values that can be written are from 0 to 16838, where each bit is worth 2.33 seconds. So I figured I'd just take whatever value was input, convert it to seconds, divide by 2.33, and that'd be the value I'd use. It'd be accurate to within 2.33 seconds anyway.

The config file goes in the macroroot directory, and is explained in the first post. You can go without a config file, but then all your switches will be named "Br1_Addr29_Dimmer", and the like...since the objects have to be named something. The config file mainly lets you give them more understandable names.

Gotcha. So - You could have a toggle to use normal ramp or extended ramp on most screens. Then, you could have a normally hidden field to set the extended ramp rate. I am envisioning a separate screen in the IV where all the extended rates are listed next to each dimmer with changeable values. Those values would be stored in each dimmer and become the default, not likely to be changed often.

Or you could have a field in the IV for an individual room that would change all the extended rap rates for the dimmers in that room only.

I can't see the downside to making that extended ramp rate a user-definable field. . . ? It would not have to be used at all if the user didn't need / want to, right?

[jrunde]

I am starting my ALC installation but having trouble getting the driver to stay connected. It does connect, but only for about 10 seconds, and then goes back into waiting for connect mode. I have attached a log file if someone can help me find out what is going on. I'm using the driver (v1.1) that ships with the latest version of CQC.

[beelzerob]

I'm not sure if there's other problems, but it can't find the config file for starters.

Could not find file: \Drivers\OnQ\ALCLighting\ALC_config.csv

The driver doc page describes how to setup the config file.

I actually updated the driver so that it will search out the system and create default named fields for everything it finds...but maybe I forgot to send that to Dean.

Anyway, if you setup the config file, we can see if anything else is amiss.

[jrunde]

With a config file, it's not connecting at all.

If I try to connect with hyperterminal, I am not seeing anything. Should I be?

[jrunde]

One other thing to mention is that I never see the transmit light on the serial expander light up.

[beelzerob]

Ok, let me get you the updated driver I made, because even though the driver now sees the config file, I think that whatever you have in there does not correspond to what is on the ALC network. So it asks for a status on something that isn't there, and there is no reply (no transmit), and thus it never connects.

With the updated driver, get rid of the config file, and it *should* go through and make fields for everything it finds. It'll be a good test of that capability either way.

There are *some* commands you can send via hyperterminal that should get a response, yes. I can look those up when I get home. Have you experienced communication with ALC any other way (in other words, do you know you have the RS232 pins correct?)

[jrunde]

I believe I have the correct pins. I am using pins 2 (ground), 4 (transmit), and 5 (receive) of the rj45 connector connected to pins 5 (ground), 2 (receive), and 3 (transmit) on the serial adapter (2 to 5, 4 to 2, and 5 to 3) I believe I Tried switching 2 and 3 on the serial adapter around as well.

[jrunde]

I have it working now. I re-did the cable, and removed my enhanced branch hub and connected the switches directly to the distribution module. Not sure which corrected it.

BTW, the driver included with the latest version of CQC does poll through to find the devices on the network as that's what I used the first time. Then I put in the config file, and it worked as well.

thanks for the help...

[beelzerob]

Oh, good to hear. I'm glad the release is the latest after all.

6 times out of 5...it's the cable.

[jrunde]

I put the switch back on the branch hub, and it still won't connect when hooked up to the hub. Any ideas how to troubleshoot this?

[beelzerob]

So is it one particular switch that is causing the issue, or is it a branch? In other words, do you have any other switches on that branch, or is it only when you hook up THAT particular switch?

You might try creating a config file containing only that one switch, and see if that connects. If it doesn't, then post the log file and I'll take a look at it.

[jrunde]

I only had one switch to test at the time. I have 2 now, but I have them hooked only to the distribution module. They are both on branch 1. Once I get home from work, I'll put the branch hub back in and see how it goes.

[beelzerob]

I only had one switch to test at the time. I have 2 now, but I have them hooked only to the distribution module. They are both on branch 1. Once I get home from work, I'll put the branch hub back in and see how it goes.

Ya, I'm definitely curious if it's a branch issue. I'm not sure how many who are using this driver use it with different branches, so there's a chance it's a lurking bug of some kind.

Anyone else who happens to be reading this and using the driver...have you tried it with more than just branch 1??

[jrunde]

From what I understand, even adding in a branch hub, all the switches are still on branch 1. That is unless you add in an Expansion Module, which I don't have.

[beelzerob]

Ah, ok...so it's not a branch addressing issue then.

So then....a switch that is wired normally is found and used by the driver, but that same switch wired through the branch hub causes the disconnects? Is that about right?

There's no different protocol for communicating to switches wired through branch hubs....only if they're on different branch numbers. So I'd think that might be a connecting/wiring issue then.

[jrunde]

Yeah, you have it right. I think I have it wired correctly. Might have to contact SetNet where I bought it from if I can't figure it out.

[beelzerob]

Just for fun (whee!!!!), why don't you try different branch numbers for the switch, in the config file. So, hook one switch up to the branch hub, and then try that one switch at branch numbers 1 - 4 in the config file...see if it responds for any of those.

[beelzerob]

Say, anyone here using this driver and have a scene switch? I realize the current driver doesnt support it, but that's only because I haven't had the means to test it. If someone there can test it with scene switches, I'll get it in. Otherwise, I finally acquired a scene switch, and I'll have to rig something to get it to work (since I'm not ready to install it first).

[beelzerob]

Ok, rigging is done, and I've updated the first post with a new driver version that supports the scene switch.

Adding the scene switch (to your config file) will result in 4 boolean fields being created, one for each button. The buttons will stay True as long as the button is held, and False once it is released. There will also be an event on button press and release.

Enjoy.

[beelzerob]

So, in case any of you are still hanging around here, let me get an opinion....

How useful would it be if you were able to define "scenes" in the config file, and then execute them by setting a field to true?

Here is what I mean....In the config file, add something like this:


StartScene
Name=TestScene
Garage,Level=40
MasterBathFan,State=Off
Catwalk,Level=70
EndScene


That would produce a boolean field named TestScene, and if you write True to it, it would then set all of the named switches to the levels or states specified.

That's all it would do...writing False to the field wouldn't mean anything...it won't "undo" the scene.

Anyway, if there's more than just a passing interest, then I can see finding the time to do that. Or, I'm open to suggestions of a better way to do it.

[beelzerob]

well kids, it's official....we won't get to enjoy those super-duper long ramp times with our setup.

I talked with Tony Stewart, the owner of the ALC line, and he finally puzzled out why I was getting NAKs when trying to write the extended ramp rate. Turns out that having that long of a ramp time requires an internal clock, which the controller by itself does not possess. However, if you have one of the interface boards for the Elk or Omni, those *DO* have the clock, and so those controllers do get the extended ramp times.

But if you're poor like me and only have the controller board, serial port board, and distribution board...then the dream of a 3 hour ramp time has finally died. :oops: Oh well. Thankfully that wasn't one of the must-have features of ALC lighting for me...or Id be miffed.

[beelzerob]

Hey...is anyone still alive on here? I'm trying to troubleshoot this extended dimming rate stuff (since Tony's explanation doesn't quite fit the symptoms), and it'd be *really* handy if someone else from CQC here tried it out.

I can post a version of the driver that allows for setting of the extended dimming rate, and then we can see if your system allows it or not.

Anyone out there?? *PFT PFT* Is this thing on?

[klindy]

Sorry Rob...I've been out of town since basically Christmas. Besides while I have the parts to test it, they aren't quite completely installed yet.

[beelzerob]

Well, the hardest part of testing this is simply hooking up a dimmer to a high voltage source. I took an old power cord and some wire nuts and just connected it directly to do some of my initial testing.

It's probably not worth putting something together adhoc for this, as you'd have to tear it back down when you go for your real install. So don't sweat it.

Tis good to hear someone out there uses this thing, though! ;-)

[jrunde]

I could test it out. Let me know what I need to do.

[beelzerob]

Do you have the scenetech software? That makes it easy if you do. If not, I'll have to post a new driver that lets you set the extended ramp rate (not a big deal to do).

And all you have is the HLC and serial expansion module? No Elk or Omni interface board?

Thanks for the offer!

[jrunde]

I don't have scentech. I have the HLC using the Serial Module controlled by CQC. I do have an Elk, but it is not interfaced with ALC.

[beelzerob]

excellent, that's perfect. Tomorrow I'll put out a driver to test setting the extended ramp rate. Thanks!

[beelzerob]

Humorously, I think the version I've posted already has this capability!

Please install that driver pack and give it a try. It should create an ExtendedRampRate for each dimmer. If it does, then set verbose on the driver to Medium, try to set a value for that extended ramp rate, set verbose back to Off, and then dump/save the log and post the pertinent contents here (or PM me for my email, and you can send the whole thing).

[rbroders]

So, in case any of you are still hanging around here, let me get an opinion....

How useful would it be if you were able to define "scenes" in the config file, and then execute them by setting a field to true?

Anyway, if there's more than just a passing interest, then I can see finding the time to do that. Or, I'm open to suggestions of a better way to do it.

Rob this sounds absolutely perfect for me. My install is going to be 99 loads, 59 auxes and zero scene switches. There are still a few scenes I'd like to use though and I plan to invoke them from my touchscreens. Defining them in the config file rather than a bunch of macros will be a huge win for me.

The only possible improvement would be the ability to edit the scenes, either by interacting with the switches or a bunch of sliders on the GUI. Frankly I don't think its worth the effort and tweaking the config file is fine.

Thanks -- Bob

P.S. I don't really need extended ramp rate either, but I can't wait to find out what the problem is. Tony is a great guy, but he doesn't quite have a full technical understanding of the product...

[beelzerob]

Ok, sounds good then. Frankly, the method for setting scenes in ALC (you have to run around to all the lights you want to set) didn't appeal. I also would rather put it in a config file.

If the extended ramp rate thing get resolved, this will be one very well rounded product/driver for controlled lighting, I think. Pretty good as is.

[jrunde]

The extended ramp is working for me. It's slowly ramping and dimming based on what I change the ramp rate to. I first changed it to 60 and it took 5-10 seconds to go from off to full on and off again when I set it back to off. I changed to 600 and took about a couple of minutes to ramp up.

I have attached the log file.

[beelzerob]

Innnnnnnnteresting.

I checked the log, and sure enough, when you set the new extended rate, it's replying ACK to you...it replies NAK to me.

This is good info...very good.

Do you know what the version of your HLC firmware is? It should be on a sticker on the chip. Maybe that holds the key.

[jrunde]

I'm on v1.31.

[beelzerob]

Hmm. Well, that's later than mine. I'll pass that info to Tony and see if he can discern if the firmware is indeed the culprit. Makes sense to me.

Thanks for looking into that. Now that I"ve got someone who can at least test the extended dimming stuff, I'll get that in there fully.

[beelzerob]

Added a version of the driverpack that will install a .manifest file for connecting to the ALC controller via TCP/IP. This is useful if you have something like a Quatech Serial/IP server box.

[beelzerob]

jrunde, I'm taking stabs at implementing the extended ramping. It's easy enough, but I'm pondering the workability of it. Currently to set a dimmer to dim from one light level to another at a specific rate, you have to do this:

1) Put the dimmer in extended ramp mode (instead of just "ramp", or "jump")
2) Set the extended dimming rate (in seconds)
3) Set a new level.

Part of the problem here is that it seems to me that making a dimmer do an extended ramp is going to be a fairly rare event. I'm sure all other times, you'll just have the dimmer Ramp from level to level. But the way it's setup, you'd have to always check what dimming mode the light is in first. Otherwise, if you set it to extended dimming rate, and forget to reset it to Ramp, then you're going to be waiting for quite a while for your lights to come on!

So, what I'm considering is just a String field per dimmer called ExtendedRampToLevel, and you'd write the new level and the ramp time to it. So, writing "127, 40" would set it to level 127 over 40 seconds (extended ramping doesn't actually work like that, but this is just an example). Doing it this way, it doesn't affect the current dimming method...that will stay at either Ramp or Jump, as you prefer.

Anyway, that's what I'm thinking. I'm just thinking that it will be a fairly infrequent "event" where the light is going to extended ramp, and so you're not going to want to ever leave it in that dimming mode. *shrug* Just a thought, I'd love your input on it.

[jrunde]

Having one step rather than 3 makes a lot more sense to me. Most of the time, I don't think extending would be used and if you did, you wouldn't have to remember set it back to normal ramp.

[beelzerob]

Ya, I'm glad we agree on that. The HLC doesn't have dimming modes to be put into (Jump, Ramp, ExtRamp), it just has separate commands. I put the Jump/Ramp into a dimming method, as it seemed more likely you'd setup a dimmer to be one of those methods all the time. Not so with ext dimming.

Ok, I'll work on the single field solution.

[MavRic]

Hey Rob..

Did you ever get this driver working well via a Quadtech? Last time we spoke you were still having issues with it.

This would be great since i am about to move CQC to a virtual machine.

If it doesn't work is will have to have the CQC Master server on the virtual machine and then still have a CQC server on the host as well for the drivers that need a true serial port.

Although from what i hear VirtualBox may be able to forward 2 serial ports to the VM...i'll need to test that.

[beelzerob]

Not reliably no....which is why I sold 2 of the 5 quatech units I bought. I honestly had troubles with several devices, so it may have been more my fault than the ALC or quatech.

But I heard from others, and my own experiments seemed to say the same thing, which is that the ALC controller is very very picky, and is only happy on a native RS232 port, or maybe a digi port. All I know is that trying to use the IP version of the driver I created, I didn't have enough stability to make me happy...it kept disconnecting far too much because of garbled or missing transmissions.

[beelzerob]

Added the most recent driver description doc. And (now 1.3) has been given to Dean for inclusion.

[MavRic]

Hey beelzerob,

I am noticing the field values are not updating when i adjust the dimmer manually with the physical switch.

Am i missing something or doing something wrong?

I am trying to display the current state of the lights on my GUI (i.e. 50% On, etc).

[beelzerob]

well, I always assume operator error until the log tells me otherwise. ;)

All dimmers, or just 1 particular dimmer? I've not had that problem. To answer your question, yes, the fields should definitely be updating when you use the switch manually. Turn on medium verbose and check the logs, see what it is saying.

[MavRic]

No..it's all devices (or at least all dimmers, i don't have any relays).

When i set a value from CQC the light will adjust and the new value shows. If i use the local physical switch then the field is not updated.

I believe this used to work, but it's been a while since i messed with this.

Log file attached. I am using version 1.3 of the driver.

Is it possible that this worked when the driver scanned the dimmers and such but now that i defined the config file it doesn't? I am pretty sure i recall this working at some point.

[beelzerob]

Try this for a percent level field.

[MavRic]

Hi Beelzerob,

So i'm still having this strange issue with 2 of my dimmers.

If i set a value from CQC they will go to this value just fine.

If i change the actual dimmer, the CQC field does not update at all.

If i run an action in CQC that has multiple light instructions in a row sometimes the action is taken on these 2 dimmers, and sometimes not. My other dimmers are rock solid and respond perfect and physical change reflect in the CQC field browser.

Any ideas? I tried this while running the serial driver via a Quadtech but also directly connected to the server..same difference.

When i change the actual dimmer i definitely see messages coming in 'extended ramp rate something'...so is it possible that the driver is somehow not processing this right? I have no idea why it would be just these 2 dimmer and not the others.

I've attached a medium log file, but don't see anything odd in it.

I also attached a piece of High verbose, the activity shown in this log me physically adjusting the dimmer and it sending it's status to CQC.

Any suggestions before i rip out these dimmers and try new ones? I really don't want to go that route since it's with some aux switches connected it's a lot of wiring.

By the way..when connecting via the quadtech i get the occasional 'lostcon' but generally (other than these 2 dimmers) no command is ever missed.

I'm pulling my hair out here.. :(

[beelzerob]

Well, a quick look didn't reveal anything obvious. 0x2D *is* the extended dimming rate message byte, but the whole message should be longer than is shown there....so that's suspicious. Also, looking at the code, I discovered that I don't actually use the checksum byte and compare for data integrity...I need to do that.

All of that to say...I had absolutely nothing but trouble with my quatech and ALC. Lots of lost connection, lots of messages that just disappeared (and those are the worst). I gave up on that. My other devices work just fine with the quatech, but the ALC controller was too finicky for me to make it work.

[MavRic]

The log shown is while connected directly. I've tried both ways and they give the same results.

Don't know why the dimmer is sending an extended dim message to CQC...i don't use the extended dimmer ramping...at least not that i know off...

[beelzerob]

Well, I don't think necessarily it IS sending an extended dim message...but it IS being interpreted as such. So, I need to add some extra logging statements to the driver and have you use that so I can get a look at some more of the data coming across. Hopefully I can get to that...

[rbroders]

Hi Beelzerob,

I have been using your ALC driver for a few years now and I'm very happy with it. Thanks!

I decided to make a few enhancements:

1) Startup with loads off-line. Now the driver will warn you that a load is off-line (by putting its fields in error state and logging an error), but the driver will still come on-line and all the other loads work fine.

2) OnLightList. This StringList field contains all lights that are currently on (and their level if dimmed).

3) [In Progress] Light and power usage. How long (dim normalized) has each load been on and what is the total power consumption of the lighting system.

These make my 100 load system a bit easier to manage, and hopefully will help me prioritize my LED conversion project. I will post the new version soon.

However, while testing the new stuff I discovered that my D8 relay load wasn't communicating changes to the driver (though it responded status during connect, and accepted ON/OFF commands). Strangely, the D9 relay switch next to it worked perfectly.

Good Switch D9 (off press):
<GetMessage>: Msg received [242926]
<WaitForMessage>: Msg received: SwitchOffPressed
<ProcessMessage>: Processing message [SwitchOffPressed]
<ProcessMessage>: Sending user event: OffSwitchPress, LaundryUnderCabinet
<Send> Msg sent (ready): [24]
<Send> Msg sent: [E909000E]
<GetMessage>: Msg received [40]
<WaitForMessage>: Msg received: MessageIncoming
<ProcessMessage>: Processing message [MessageIncoming]
<GetMessage>: Msg received [E909000E]
<WaitForMessage>: Msg received: Status
<ProcessMessage>: Processing message [Status]
<ProcessMessage>: Status word match with LaundryUnderCabinet(Relay): Branch ID: 4 Address: 9

Bad Switch D8 (off press):
<GetMessage>: Msg received [242826]
<WaitForMessage>: Msg received: ID
<ProcessMessage>: Processing message [ID]
<GetMessage>: Msg received [242856]
<WaitForMessage>: Msg received: ID
<ProcessMessage>: Processing message [ID]


So the bad switch sends the same message as the good switch, but for some reason, the driver interprets it as an ID message instead of an OffSwitchPress. I think this is just because the switch address (8) happens to match the command string of the ID message. I just verified that, anyBranch13 clashes with the ExtendedRampRate message as well. Possibly anyBranch31 will clash with MessageIncoming, but I don't have any switches addressed to 31.

The bad code is in GetMessage where it does BuffToStr and then result.FromText before Trying to see if it is a button. I'm happy to try to fix it, but I'd like a peek at the Protocol document before I do. Any chance you could send it to me? bob at starbright.name I found references to

Part No. 1307659 Developers Guide for detailed protocol information.
HLC_SI application note for lighting control, programming and unsolicited messaging examples utilizing the ASCII character based protocol.

But cannot find them on-line.

Thanks -- Bob

P.S. This is definitely the same bug that MavRic reported almost 2 years ago. Anyway, the fix is pretty easy, but I would be happier if I could see the protocol doc before making the change.

[rbroders]

Just FYI, I have received the ALC protocol document and I should be able to fix this bug in a bit.

BTW, ALC is alive and well. They have moved the production from China to the US and are maintaining/enhancing the product at setnetpro.com

--Bob

[AceCannon]

I've been in my house 3 years now and still love my ALC equipment.

We did take a lightning hit and several switches were damaged.

My latest project is going to be getting some garage lights changed to ALC. Then I plan to have the Elk-connected motion turn on garage lights for a certain amount of time.

[rbroders]

Well I've put the driver through a bunch of tweaks in the last week. The address 8 bug has been fixed, as well as the release event for relays bug.

I discovered a cool message which updates the status of all lights in a single round trip (<100ms), but unfortunately it isn't accurate under all circumstances.

The driver provides a textlist (and count) of all ON lights. I also added the ability to specify the wattage for each load and the driver calcs the total wattage in use.

Next step is to integrate over time and track daily kwhr usage from the lighting system.

I'll post the new driver when I get back from holidays in the Midwest.

--Bob

[rbroders]

The power usage integration over time is almost complete I just need to add some persistence and a Daily Report.

I discovered a couple of new types of messages the ALC system can produce - X10 messages if you have a TW523 module attached. Also Extended messages. I figured a strategy for decoding all the different types of messages that might come flying at me (global messages are still isolated becaues they overlap the others). While testing the GlobalScene stuff, I found a new undocumented unsolicited message as well. Ugh.

However I have added support for Editing the GlobalScene levels! The standard LearnGlobalScene just records all current levels. My SetGlobalSceneLightLevel allows you to change each light individually, and setting level 128 causes the light to be ignored! GlobalScenes no longer need to be global!

I have also created a GlobalScene report which lists all the lights controlled by the scene and the level it will be set at (stringlists are awesome). I need to add a utility to change all "off" lights to "don't change" in a scene to speed up editing (I have 97 lights).

-Bob

[rbroders]

Make/Model
Device Version
Connection Type

OnQ/ALC Lighting
2.02
RS232


Description:
This driver controls the OnQ ALC lighting controller. It allows for activation of switches, and relays, and state information for all of those things as well.

Quirks and Limitations:
The driver does not currently support scene buttons or I/O modules. That capability will be added upon CQC user request.
The dimmer state works differently than pressing the actual physical switch. If you press the switch "On", the light will go to its preset dim level. If you then press the "On" switch again, it will go to full bright. In the driver, however, if you write True to the dimmer State, it will only go from Off to full bright. This has been brought to the attention of the manufacturer, and it may be rectified in a future firmware release. The preset level of the dimmer is a field value, though, so you can accomplish this functionality on your own if so desired.
Currently the extended dimming rate is not settable. This issue is being worked out with OnQ.

Connection Details
See the ALC documentation for the correct method of connecting the Serial Expansion Module to your PC.

Events
This driver will send an event upon switch press and release. The event will be:
EventType....................EventData
OnSwitchPress............<SwitchName>
OnSwitchRelease........<SwitchName>
OffSwitchPress...........<SwitchName>
OffSwitchRelease........<SwitchName>

Global Scenes
The driver supports 16 global scenes. Write a number from 1 to 16 to the LearnScene field, and the current settings of all ALC switches will be memorized. Write the same number to the RestoreScene field to have all ALC lights change to the scene. The driver also supports editing global scenes via the "SetGlobalSceneLightLevel" field. Write sceneNumber,lightName,level to this field to change the level for a light. For instance write 1,MasterBedroom,62 to SetGlobalSceneLightLevel, and the next time you use RestoreScene 1, the MasterBedroom light will go to level 62. If you want a light to be not affected by a scene, sets its level to 128. You can also make mass changes by using the lightName "All" and two levels. SetGlobalSceneLightLevel 1,All,0,128 will change all lights that were previously turned off by scene 1 to lights that are not changed by scene 1 at all. For relays, 0 is off and 127 is on. There is also a report you can generate by calling QueryDrvText ID=GlobalScene Value=sceneNumber. The resulting stringList can be sent to a ListBrowser for display. Lights which are not affected by a scene (i.e. level 128) are not included in the list

Light Activity
The driver now summarizes light activity via the read only fields OnLightCount and OnLightList. The OnLightList stringlist only includes lights which are on. Most recent lights appear at the top of the list, and dimmers which are not at full intensity have their intensity after their name: MasterBedroom 74%. The driver also tracks light usage (dimmer normalized) over time. Calling QueryDrvText ID=PCT will produce a list of all lights and their overall "ON percentage" sorted by ON percentage. This is especially useful for determining which lights should be converted to high efficiency bulbs. Lights can be hidden from the list by marking them UNLISTED in the config file (useful for TowelWarmers or other non-lights that are switched via ALC).

Power Usage
The driver also calculates power usage via the read only field OnLightWatts. The total wattage used in the last 24HRs (rolling) is available in WattHRs24HRS. Also, every midnight the system records the power usage in the last 24HRs and the list of all days usage can be seen by calling QueryDrvText ID=Daily. The Power Usage code depends upon the user entering wattage for each load into the config file.

Dimming Methods
The rate of dimming can be set via the config file. There are 3 possible values:
JUMP - Changes made to the light level field will cause the light to jump to that level.
RAMP - Changes made to the light level field will cause the light to gradually move to the new level.
EXT_RAMP - Changes made to the light level field will cause the light to move to the next level at an extended rate, which will be configurable in a future release. The default ramp rate is about twice as long as standard ramp.

Config File
You may create a config file to specify the lights in use. It must adhere to these rules:
1) It must reside in the following directory (create it if it doesn't) on the machine where the driver is going to be loaded.
CQC\CQCData\MacroFileRoot\Drivers\OnQ\ALCLighting

2) The name of the file must be moniker + "_config.csv". So, if the moniker of this particular driver instance is "onq", then the file will be named "onq_config.csv". This allows you to load multiple different instances of this driver on the same PC.

3) Format in the file is as follows:

a. Each line in the file contains either a relay, or a dimmer.
b. The basic format is: "Name, Type, Branch, Module Address"
Name - Name you want this field to be shown as. Name must adhere to the normal CQC rules for field names (no special characters, no spaces, etc). See below for constraints on field names.
Type - Either RELAY or DIMMER
Branch - The ID number of the branch, from 1 to 4.
Module Address - The dip-switch address of the module.
Dimming Method (optional) - If a dimmer, enter a dimming method here, as described above. If none is entered, then the dimmer will default to "Ramp".
UNLISTED (optional) - If you don't want the load to appear in OnLightCount and OnLightList fields
Wattage (optional) - For the power usage fields to be non-zero you must enter a wattage

4) The last line in the config file MUST be "END"
Here is an example file:
LivingRoom,RELAY,3,4,240
MasterBedroom,DIMMER,1,12,200
MediaRoom,DIMMER,2,10,JUMP,480
TowelWarmer,RELAY,4,5,UNLISTED
END
If you do not specify a config file, then the driver will search the network and create field names for all devices it finds. The field names will take the form of:
Br<b>_Addr<a>_
Where b = Branch and a = Address.

Field Names and function
Field names are created automatically for a given switch name. Because of that, the names in the config file must be unique (except for default names, which are ignored). Any duplicate names will be ignored, and a message put in the log indicating the error.

Driver Fields
This section lists the fields that the driver makes available, their types, minimum and maximum values, etc... Name
Type
R/W
Description/Limits
LearnGlobalScene
Card
W
Learn global scene number <value>. Causes the current state and level of all switches to be saved. Value may be in the range from 1 to 16 only.
RestoreGlobalScene
Card
W
Restore all switches and levels to the saved settings.
<Name>Relay_State
Boolean
R/W
Get/Set the state of the relay named <Name>.
<Name>Dimmer_State
Boolean
R/W
Get/Set the state of the dimmer named <Name>
<Name>Dimmer_Level
Card
R/W
Get/Set the current dimming level of the light. Valid values are in the range of 0 (off) to 127 (full bright).
<Name>Dimmer_Method
String
R/W
Get/Set the method the dimmer uses to transition from one light level to another. Valid values are Jump, Ramp, and ExtendedRamp, and are described above.
<Name>Dimmer_PresetLevel
Card
R/W
Get/Set the level the dimmer goes to when the On switch is physically pressed. Please read the Quirks and Limitations above for more information.
ReloadConfigFile
Boolean
W
Write True to cause the config file to be reloaded. This is useful if you need to make a change to the file, without removing the driver.
ExtendedRampToLevel
String
W
Cause a dimmer to ramp to a new level, using the extended ramp rate. NOTE: This field currently does not work. See "quirks" section.


SetGlobalSceneLightLevel
String
W
Write sceneNumber,lightName,level to change the level for a light for a scene. Or Write sceneNumber,All,oldLevel,newLevel to change all lights at one level in a scene to a new level. Levels are 0-128 127 is full on (on for relays) and 128 means ignore this light for this scene.

OnLightCount
Card
R
The number of listed lights which are on.

OnLightList
StringList
R
The list of all listed lights which are on (most recent first). Dim level is include in the name for dimmers not fully on.

OnLightWatts
Card
R
Total wattage of all on lights. Dim normalized.

WattHRs24HRs
Total watt hours used in the last 24 hours (rolling).

QueryDrvText functions:
PCT
StringList
List of all lights and their dim normalized on percentages (most on first).

Daily
StringList
List of Dates and power usage for that day

GlobalScene sceneNumber
StringList
List of lights controlled by the global scene and their target dim level.