ALC Extended Dimming problems

[beelzerob]

This is a continuation of a discussion in the Legrand thread, and this topic begins in post 43.

Basically, I've written a CQC driver to interface with the ALC lighting control module, using the RS232 protocol. And in almost all respects, it works just great. The only problem I've had is with the extended ramp rate. Using that command, you should be able to set a ramp time (time to reach the level you specify) of HOURS and hours. This can be used for nifty things like having the lights slowly come on as the sun is going down...so, start them from 0 an hour before sunset, and have them take an hour to get to 100%. Neat stuff.

Well, for the longest time I couldn't get it to work...I'd just get NAK's from the controller, which meant I was doing something wrong. The protocol was a tad ambiguous at that point, so I thought maybe I just wasn't forming the command correctly.

After *months* of trying to get some help from ALC, I finally got the answer I wanted from wlj (see post 44 of the other thread). The actual, specific bytes needed to set the ramp rate to 2 hours. Well, I went home, modified my CQC driver, and sent out those very bytes. The result?? NAK. So even after that, something was still wrong.

The other thread debated that perhaps the extended ramp rate comes with other components, such as the Elk or HAI controllers. However, wlj is able to set the extended ramp rate, and he doesn't' have those other controllers. However, he also doesn't have the specific HLC (Home Lighting Controller) that I do...he has the SLI (Scene Learning Interface). And perhaps there is the difference.

Either way, that is what got this thread here.

Here is all the equipment I have (other than the switches themselves)

Top is the Serial Expansion Module. That connects to my PC for control via CQC.
Middle is the Home Lighting Control Module. That controls everything.
Bottom is the ALC Distribution Module. That's where all the wires come into.

I only have 1 branch of lights....4 dimmers, and 1 relay. The version of my dimmers is 1.7, and the version on my HLC is 1.29

Here is what I've discovered:

There are 3 RS232 commands associated with the extended dimming function of dimmers.
- Set the extended dimming rate (for a particular dimmer)
- Read the extended dimming rate (for a particular dimmer)
- Extended ramp to level (the actual command to move to a new light level at the extended dimming rate)

1) I can read the extended dimming rate of all of my dimmers.
- They are all set to the same amount....5, which equals about 12 seconds of dimming time.
- I never set these values myself, so they must be default values, especially since all of my dimmers have it.
2) I can use the extended ramp to level command. So, if I use that command to tell it to go from 0 to 100, it transitions from 0 to 100 over the course of 12 seconds (which is the extended dimming rate). This is definitely different than telling it to merely "ramp" to a new level, which is a different RS232 command, and takes about 3 seconds to accomplish.
3) I cannot set the extended ramp rate, for any dimmer. When I try to set it to a value, I get a NAK (0x42 80 00) back from the controller.

So, that's where I'm at!

 

[wlj]

Rob,

Are you performing any sort of transmit pacing when sending the set extended ramp rate command to your HLC? Your mention of the NAK bytes reminded me of extreme timing sensitivity that used to exist in the ALC protocol handshake (versus the current high sensitivity . The handshake was eventually changed to loosen timing restrictions, but perhaps this is related...or set extended ramp rate was inadvertently overlooked? The developer's documentation says the following on this topic in section "3.6 Transport Layer Handshaking" (page 18 of "Doc.: 1307659 Rev. D 11/26/03"):

When the ALC Interface receives a command from the network Controller, it converts and sends that command to the appropriate ALC module on the specified ALC branch, and it waits for a reply from the ALC module. If the ALC Interface receives a reply from the ALC module, it returns that reply to the Controller. If the ALC Interface does not receive a reply from the ALC module (typically within 10 milliseconds), it returns a NAK ìNot Acknowledgeî reply [42 80 00] to the Controller. Every network command sent by the Controller will receive a reply (Acknowledge, Status Report, ID Report, etc. or NAK) from the ALC Interface.

NOTE: In ALC Interface firmware version 1.05 and later, this handshaking sequence is still acceptable but not required. The Controller can send its entire message including the Ready byte in one packet [e.g. 23 83 02 7B]. The ALC Interface initially replies with 40 to indicate that the message was received and it has no data bytes to send. After the ALC Interface has interpreted the message and sent it to a device on the ALC branch, it waits for a reply from the device. After the ALC Interface receives a response from the ALC device on the branch, the ALC Interface returns this response to the Controller in one packet including the Start byte [e.g. 42 83 00].

And, for a bit more color, here's an excerpt from the depths of my mail archive (circa 2003) with an AMP/OnQ engineer involved with writing the original SLI firmware and protocol spec:

You mentioned receiving 40 00 00 00 00 42 80 00 in response to your 24 header. This corresponds to the 40 and 4 extraneous 00's followed by a 42 (2-byte reply) and 80 00 (NAK - Negative Acknowledge). The NAK was sent because the SLI didn't get a valid message from you soon enough following your initial 24.

All in all, newer firmware will greatly simplify RS232 communications for you - just send the whole packet including the header, and wait for the reply.

Let me know if you need the developer's documentation. I can't readily find a link to reference via Google.

Hope this helps,
-Bill

 

[beelzerob]

No, I'm pretty sure I have that doc. It's got all of the protocol commands in it, along with the handshaking info (what you posted looks familiar).

I don't *think* it's timing related, mainly for this reason: The other two extended dimming rate commands work just fine, as well as all of the OTHER RS232 commands. So it would seem strange, if it was something as picky as timing, that this one command is giving the error.

Unfortunately, the NAK could mean many things. For example, sending a dimming command to a Relay will get you a NAK. So it's almost impossible to know why it's rejecting this command.

I can't remember how many other 6 byte commands there are...I'll take a look and see if I'm implementing any of those as well, maybe that has something to do with it.

I definitely have a firmware later than 1.05, so in that case, the handshaking isn't even supposed to be required.

 

[rbroders]

Any chance this is a checksum problem? Maybe you can brute force try all the checksum values and see if it likes any of them...

Have you tried this on all of your dimmers, maybe you have a dud.

Hmmm -- Bob

 

[beelzerob]

Good suggestions.

I've confirmed that the checksum I'm sending is correct. And all other messages that get sent out with a checksum are processed normally. So that would mean that this ONE command treats the checksum differently, which I find very hard to believe. Still, it might be worth a shot.

I've tried it with all the dimmers I have installed, which is 4, and they all react the same. Those were all bought from setnet, I believe. I did buy some dimmers off of one of the cocoontech members here a while ago, maybe they're from a different set. I'll at least take a look at them and see what the firmware sticker says on it.

 

[TonyStewart]

Good suggestions.

I've confirmed that the checksum I'm sending is correct. And all other messages that get sent out with a checksum are processed normally. So that would mean that this ONE command treats the checksum differently, which I find very hard to believe. Still, it might be worth a shot.

I've tried it with all the dimmers I have installed, which is 4, and they all react the same. Those were all bought from setnet, I believe. I did buy some dimmers off of one of the cocoontech members here a while ago, maybe they're from a different set. I'll at least take a look at them and see what the firmware sticker says on it.

I sent a note to the original programmer to add some wisdom.

The intent when migrating from the HLC to the new scene learning interface was among other things to add scene learning support for the 4 button ALC switches. It was my understanding that nothing (feature wise) was left out with the new control interface, but I can't say for sure.

I'll simulate the system you have in our lab and let you know what I see. I have a few things ahead of that, but I will get on it when I can.

Here the latest firmware versions and the date when they were last worked on.

Lighting Manager - (LMM) - Version 1.15 Date 10/07
Home Lighting Controller (HLC) (includes scene learning) Ver 1.37 Date 7/06
HAI Interface - Version 2.62 Date 9/05
Scenetech - Version 2.75 Date 1/06
Branchtech - Version 1/19 Date 7/06
Dimmer - Version 1.05 Date approx. 2007
Relay - Version 1.03 Date approx. 2007

Since ALC was sold primarily for the HAI and the ELk controllers and since all features like extended (called ramp in some of these controllers) works as designed, no work has been done on the software for a few years. Not to say that some reworks are not ever going to happen, but processor capacity must be considered as well. More code just might require another processor and that would then be more than just a software fix. So, for now, we are only speculating on what might happen next with development.

Our marketing plans will involve adding support for more controllers and making HLC sales bigger. Just can't say when all this will happen.

TS

 

[beelzerob]

I'll simulate the system you have in our lab and let you know what I see. I have a few things ahead of that, but I will get on it when I can.

That would be GREAT! I'd really like to know if I'm the only one having this problem, but so far no one else has had the same setup as me, so they can't test it. Who knew I was so cutting edge!!!

So, I'm 0.8 behind on the HLC version....wonder what some of the changes were for that. But I know my dimmers say 1.7 and my Relays says 1.6. So I don't know how that corresponds to the other version nums you posted.

thanks for the help Tony!

 

[TonyStewart]

I'll simulate the system you have in our lab and let you know what I see. I have a few things ahead of that, but I will get on it when I can.

That would be GREAT! I'd really like to know if I'm the only one having this problem, but so far no one else has had the same setup as me, so they can't test it. Who knew I was so cutting edge!!!

So, I'm 0.8 behind on the HLC version....wonder what some of the changes were for that. But I know my dimmers say 1.7 and my Relays says 1.6. So I don't know how that corresponds to the other version nums you posted.

thanks for the help Tony!

I looked through the notes on the source code for the dimmers and relays. The numbers you have are later, so the source code notes simply don't have the latest rev #s. I will look into the correct rev #s and advise. I know that no firmware has been changed since OnQ let the programmer go about 3 years ago. He and I are talking about future work, but I can't promise his involvement since he is not yet on our payroll. I have the source code and notes, but am not the right person to make any modifications. When needed, that will be done by the original programmer I am talking with.

OnQ has been good about providing all firmware resources, so I now have the Zilog 8 burner to make firmware but have no clue on how to use it. I am not looking forward to a new thing to master, but master it I must. Once I do, I can provide updated firmare for you as needed.

It's been years since I dealt with source code and object files and am pretty rusty.

TS

 

[beelzerob]

My HLC has a sticker on it with the firmware number...if there are future firmware updates, are those directly upgradeable, or is that a new chip? One is easy, the other not so much....

Thanks for looking into it Tony. I've worked with embedded code, but each system is different, so I'm afraid I probably won't be much help for you to figure it out. Shame I can't stop by and take a look at it, it'd be fun. Hopefully you can find the latest version docs.

 

[TonyStewart]

My HLC has a sticker on it with the firmware number...if there are future firmware updates, are those directly upgradeable, or is that a new chip? One is easy, the other not so much....

Thanks for looking into it Tony. I've worked with embedded code, but each system is different, so I'm afraid I probably won't be much help for you to figure it out. Shame I can't stop by and take a look at it, it'd be fun. Hopefully you can find the latest version docs.

I think the chip is a OTP (One Time Program), and will need to be replaced. Hold on until I test your configuration as the firmware difference may not be a factor.

Thanks
TS

 

[beelzerob]

Well, here's another data point for you. I had a fellow CQCer use his setup to try and set the extended dimming value, and it *worked* for him. He has the same hardware setup (HLC), not Elk or omni, or any of that. Also a note that his HLC sticker says 1.31, which is later than my 1.29. I'm definitely not saying that's it, but it's worth mentioning as it is a difference between our setups.

I'm glad to know that CQC'ers will be able to use the full range of the protocol, including extended rate dimming....but this would seem worth figuring out why I can't, or certainly there will be someone else who can't too.

 

[Jimmyjam]

I am the one who tested the extended dimming using CQC that worked. My setup is almost the same as yours. I have an enhanced branch hub after the distribution module, but everything else is the same.

 

[TonyStewart]

I am the one who tested the extended dimming using CQC that worked. My setup is almost the same as yours. I have an enhanced branch hub after the distribution module, but everything else is the same.

What firmware level do you have?

 

[beelzerob]

The sticker on his HLC says 1.31. The sticker on mine says 1.29.

I'm curious what the fixes were in those revisions, by the way, because I swear that some of my dimmer preset values are changing by themselves. I won't go into detail here, as I don't want to derail this on-topic thread, but I'm going to dedicate a task to checking the preset dim values of certain dimmers and notifying me when they change, so I can for sure rule-out human meddling.

 

[TonyStewart]

The sticker on his HLC says 1.31. The sticker on mine says 1.29.

I'm curious what the fixes were in those revisions, by the way, because I swear that some of my dimmer preset values are changing by themselves. I won't go into detail here, as I don't want to derail this on-topic thread, but I'm going to dedicate a task to checking the preset dim values of certain dimmers and notifying me when they change, so I can for sure rule-out human meddling.

Both issues may be related. In my experience, it's rare to see two unrelated problems occur in the same system. I'll look for the revision notes and see if any exist for the fix from 1.29 to 1.31