Lutron notifications problem

adys

Hi all


I am having strange lutron problems.

Some of the keypads that use to work, don't send notifications anymore to the lutron driver (p5)

I am sending commands to the keypad, the commands are executed ok, the lutron sends the notification but the driver ignore them. I print every string that is coming from the driver, and some specific keypads just not notified.

There are registered to the driver like all the rest of the keypads, and some of them use to get notification, and now they don't.

I check few days from different directions.
Went back to previous versions of the lutron, and previous versions of my code, and its just wont notify the driver... I can see the notification in the lutron console but they are not getting to the driver, and only on the specific keypads.

Any ideas?

Thanks,

Ady.

Spire_Jeff

I have recently abandoned most of the lutron module from AMX. I have used the netlinx module in the past, as well as the duet module, and they have worked well enough. I did have to write some additional code to deal with some specialized data coming from the Lutron processor, but overall, the modules were functional. I will say that I found some problems with the Duet module handling feedback properly, but it was only on certain keypads. I believe I posted the specifics previously, and as I recall, it had to deal with only a couple of the keypads (index 17 comes to mind) not correctly reporting LED states. I thought I saw an update that was supposed to fix the problem, but I never implemented it as I just enabled passback and parsed the data myself.

Recently tho, I have had to stop using the duet module for everything other that a communication buffer. If I had the time, I would probably just write my own module, but using the duet module to maintain communication and buffer commands seems to be working well enough right now. I started having problems when I tried to add more than 32 keypads to the module. I feel it may have worked, but the boot up time of the processor jumped to absolutely unbearable (over 20 minutes, but I never let it actually boot up all the way cause I needed to get work done).

Parsing the data that comes from the Lutron processor is actually very easy and if you see it coming from the processor, I would just circumvent or replace the module.

Jeff

vining

adys wrote:

I am having strange lutron problems.

Are you connecting via serial or IP?

Are you using the AMX module or something else?

The driver you speak of, is that a driver you set up in the Lutron processor for that port (ip/serial) with the desired feedback checked?

So some keypads send the KLS string and others don't?

Do you have your own buffer set up so you can watch what is actually coming in from Lutron or are you just looking at what the module shows you coming in?

adys

vining wrote: »

adys wrote:

Are you connecting via serial or IP?

Are you using the AMX module or something else?

The driver you speak of, is that a driver you set up in the Lutron processor for that port (ip/serial) with the desired feedback checked?

So some keypads send the KLS string and others don't?

Do you have your own buffer set up so you can watch what is actually coming in from Lutron or are you just looking at what the module shows you coming in?

IP

AMX P5 module

Yes

All of them send KLS, but the module sends notifications only for some of them, even that all keypads are registerd. I am listening to evey string coming from the driver, its just don't send nothing for those specific keypads.

no, I am listening like this:



DATA_EVENT[vdvLights]
{

COMMAND:
{

printDebug("'LutronCommnad : ',DATA.TEXT")

...do the reset...
}
}

Spire_Jeff

Try moving the keypad that is not responding to a different index to see if the problem resolves itself. For example, if you are having problems with keypad 16, try this: send_command vdvHWI,''LUTRONKEYPADADD-1,[1:5:16]'" ;

See if that helps. This is sounding a lot like the problems I was having with the duet module. Make sure you are using the most current module (send a ?VERSION command to make sure that NS4 didn't pick an older version at compile time). I just don't remember if assigning the problem keypads to a different index fixed the problem or not.

Jeff

adys

Thanks

Its not working... I moved the keypad index from 6 to 64, not working... (I have 63 keypads for now)

Any ideas guys?

Thanks

Ady.

Spire_Jeff

Here is a bit of code that will parse the incoming data from the IP module if you use the command PASSBACK-1

data_event[vdvHWI]{
	STRING:
	{
		STACK_VAR INTEGER nHWI_PROC		//Current HWI Link Number
		STACK_VAR INTEGER nHWI_LINK		//Current HWI Link Number
		STACK_VAR INTEGER nHWI_BUT    	//Current HWI Button number 
		STACK_VAR INTEGER nHWI_KP     	//Current HWI KP Number 
		STACK_VAR INTEGER nBTN_CNTR
		STACK_VAR INTEGER nHWI_BTN_IDX
		STACK_VAR CHAR cHWI_BTN_VALUE[3]
				
    WHILE(FIND_STRING(cINC_DATA_LUTRON, 'KLS, [', 1))
    {
      REMOVE_STRING(cINC_DATA_LUTRON, 'KLS, [', 1) 
      
			nHWI_PROC = ATOI(REMOVE_STRING(cINC_DATA_LUTRON, ':', 1)) 
			nHWI_LINK = ATOI(REMOVE_STRING(cINC_DATA_LUTRON, ':', 1)) 
			nHWI_KP = ATOI(REMOVE_STRING(cINC_DATA_LUTRON, '], ', 1)) 
      
			nHWI_BTN_IDX = GET_IP_KP(nHWI_PROC,nHWI_LINK,nHWI_KP)
      FOR(nBTN_CNTR = 1;nBTN_CNTR<=24;nBTN_CNTR++)
			{
				cHWI_BTN_VALUE = GET_BUFFER_STRING(cINC_DATA_LUTRON,1)
				nHWI_BUTTONS[nHWI_BTN_IDX] [nBTN_CNTR] =  ATOI(cHWI_BTN_VALUE)
      }
    }//END IF
		IF(LENGTH_STRING(cINC_DATA_LUTRON) >1000)
			CLEAR_BUFFER cINC_DATA_LUTRON
	}
}

DEFINE_START
CREATE_BUFFER vdvHWI,cINC_DATA_LUTRON

You will need to write the GET_IP_KP function to return the proper index of the keypad within the array you are using to store the LED states (or modify the code to do what you need with the information).

I have given up on using the IP comm module for anything more than making the connection, maintaining it, and buffering the commands I send to it. I also only add 1 Keypad (maybe it was 2), because when the reboot time was stupid when I tried adding a bunch of keypads. It seems that the module creates a separate port on the virtual device for each keypad. This doesn't seem to work out well when you have 224 keypads

Jeff

adys

Thanks Jeff!

Sorry for the delay, I was in a vacation.

This is very helpfull information.

I notice that when using PASSBACK-1 command I am getting the notification string to the code, why the driver don't send it to me I don't understand...

I will try to use your solution, everything is working for me with this driver, except 3-4 keypads that the driver ignore the notifications coming from them.

Maybe the ip port issue you are saying is the key to solve the problem...

BTW, I never use the buffer way and work direct with the DATA.TEXT...
Any reason to work with buffer in this case?

Thanks,
Ady.

Spire_Jeff

First off, it seems that you are in fact running into the same problem I had. There is something funky happening in the duet module when it is parsing feedback. The problem was definitely only occurring on a couple of keypads for me. This is what made it difficult to understand... at least on my end. I figured "If it works for one, it should work for them all... must be something I am not doing correctly.". After much time wasted, I managed to prove that the problem existed in the duet module... I just wish I had written down the specifics because now I don't recall anything more than "It's broken, don't use it for anything more than making and maintaining comms"

As for the buffer approach, I had to add that in because occasionally the Lutron processor will send 2 updates in the same message. I also think that occasionally the updates are split between 2 messages. Because of this, I was missing a couple of updates occasionally. Switching to a buffer cleared everything up.

Hope this helps,
Jeff

adys

Thanks Jeff, that is very helpfull.

I will call supprt today to see if there is any chance to solve that.

Your fix is ok and easy to implement, but the "hard" thing to do is to save the leds state in the code for every keypad, and I will be happy to avoid that. not only that, I will have to sync all the leds and their states upon system loading.

Annoying...

Someone from AMX should fix that module.

adys

Solution found

We duplicated the virtual keypad, change its address to something else, and hope!

Its working!

Same code, nothing has been change...

I will update soon if it working for all the rest.

Ady.