not event a word about this in the documentation.
are we talking about the P5 module?
Hi Ady,
It's briefly mentioned on page 10 of the module documentation. I agree that the documentation isn't all that clear.
In the code that I posted, the array sizes need to be adjusted for your password and username... I used 'myusername' and 'mypassword', but the variable I defined was only for 8 and 7 characters respectively:
I would try to telnet into the Homeworks P5 processor using the username and password you assigned under Link 9 in the Illumination program just to make sure you're not having any issues with the IP address and login.
The last line in the code I posted where it lists SEND_COMMAND vdvLights, 'REINIT' is to reinitialize the module after you've updated the properties for the IP address and login.
Guess this thread resurfaces when someone else new to Lutron integration stumbles on the documentation.
Please could someone help me reconcile the differences between the code fragments quoted in this thread and the documentation / test .axs file included in the Duet P5 module.
I can assign a new user / pass in HWI - this seems to be a common thread in what's posted here. I've done this.
What I don't understand is the chunks of new code that seem to be needed to the test file to make it work. There seems to be so much additional stuff to add (that is not documented) that I'm not sure I understand the purpose of the module.
I'd appreciate some help in understanding what needs to be added and edited in the module's test file to get it to work
thanks
update
Ditched the module, just gone back to our own TCP/IP comms and it's now under control.
I am succesfully controlling and getting feedback over IP from an H8P5-MI.
The DATA.TEXT buffer updates with the strings from the device, and I am able to parse the circuit levels or the keypad LED's.
The question is: Why "Device Notifications" will not show any of these strings coming from the device? (0:3:0 in my case)
- I have enabled notifications for ALL DEVICES, ALL EVENTS, as well as 0:3:0 all events.
- I have enabled monitoring on Lutron side (DATA.TEXT receives this, I have to say it again...)
It's been requested but we currently don't get device notifications from IP ports.
a (somewhat) workaround is to put a buffer on the port and watch that. You don't get the logging info that you would with device notification. But you at least can see what's coming in.
Thanks.
I believe it wouldn't be such a major task to implement in NS2 if AMX considerred this request.
As we all observe, the processor acknowledges the strings coming in (or going out), just does not care for logging them.
Here is a useful code snippet, we assume the device has been defined earlier, also that the logging enabled variable is defined earlier and set, we usually set this to a channel code so from control a device you turn the channel on to enable logging.
I know there is a lutron homeworks duet module and it works fine. I am on a site which has 6 controllers and lutron was connected via rs232 port to one of the controllers. Now since i was not able to get the feedback properly, we decided to connect the lutron via IP. So i got this code sample from the amx forums for the feedback part and i connected it via IP. Now i am able to connect via IP and get the feedback. But when i put the IP code in all the controllers, there is a considerable delay in the commands being received and the feedback being obtained. When i observed in the diagnostic tab, the connection keeps getting lost an reconnection happens.
I have attached the code i am using, the diagnostic info i am receiving from the controller and also the screenshot when i am trying to connect to the lutron via telnet. The IP listed in the screenshot is another amx controller. Is there a better way to code for this device or should i create multiple user accounts in the lutron homeworks processor using link 9 for each controller.
There can only be 1 connection for each link9 user defined.
So yes, if you have multiple connections, you would require multiple user defined on the Lutron link 9.
If I remember correctly, you can only define 4 users on the Link9, so you'll have an issue if you need 6 AMX controllers connected via IP.
I don't know you full configuration but do you need all 6 AMX controllers talking to the lutron. Can't you define the module on 1 AMX master and access it through master to master communication?
I don't know you full configuration but do you need all 6 AMX controllers talking to the lutron. Can't you define the module on 1 AMX master and access it through master to master communication?
Ditto!
Shouldn't be any difference in feedback between RS232 & IP either. There are command that you can send in the online event to set the desire feedback.
KBMON (Enable keypad/dimmer/Sivoia control button monitoring))
DLMON (Enable dimmer level/Sivoia state monitoring)
KLMON (Enable keypad led monitoring)
You should also set up a driver for the serial port so that it maintains its settings after power is cycled and you can choose monitoring feedback there as well. Just like you would do for a telnet connection. They both work the same.
But to add to the 1st repsonse only connect via 1 master and link your masters together w/ M2M.
Thanks guys, previously it was on master to master with the lutron connected serially but we wanted to free up that controller and thats why we connected via IP. Probably i can connect 4 controllers directly to the lutron and 2 remaining via master to master.
here is the function i ve used for feedback, i am changing the button states in the define_program section .Any better way to do this
// Only care about LED feedback
if (!length_string(temp))
{
return
}
tProc = remove_string(buff, ':', 1) // get Processor #
set_length_string(tProc, length_string(tProc) - 1)
arr_proc = ATOI(tProc)
tLink = remove_string(buff, ':', 1) // get Link #
set_length_string(tLink, length_string(tLink) - 1)
arr_link = ATOI(tLink)
DEFINE_PROGRAM
//ROOMS LIGHTS STATUS
[virtualTPMBLutron,1] = LEDS [1] [4] [4] [1] // this is the KP address, will be different for wireless
[virtualTPMBLutron,2] = LEDS [1] [4] [4] [2] // this is the KP address, will be different for wireless
[virtualTPMBLutron,3] = LEDS [1] [4] [4] [3] // this is the KP address, will be different for wireless
[virtualTPMBLutron,6] = LEDS [1] [4] [4] [6] // this is the KP address, will be different for wireless
[virtualTPMBLutron,14] = LEDS [1] [4] [4] [14] // this is the KP address, will be different for wireless
[virtualTPMBLutron,15] = LEDS [1] [4] [4] [15] // this is the KP address, will be different for wireless
Why connect 4 masters though? Just connect to one and if you want to put a data_event for HomeWorks in each system (master) you can even though it's connected to just one, if you want put a button event in each master when all TPs are assigned to one master you can. If a TP is assigned to each system (master) you can put the button event in just one master just as you would if all the TPs were assigned to one system. You can do pretty much any combination of things you could possibly want by defining what you want where you want but 4 telnet connections to homeworks form 4 different masters IMHO is the wrong approach.
When you set up M2M all events are available to all masters if the devices are deifned in them and event handlers are created to handle them.
Previously i was doing your approach but when the controller with the lutron is not powered on, the whole house lights were not working. Each section of the house has its own controller and different sets of llighting presets associated with it. Here there are 2 lutron processors and so now i created 6 user profiles in lutron and connected simultaneously to each controller. Now the commands are going without a delay but certain controllers are not getting feedback there
Hmmm, it sounds like an odd way to set this up. I'm also not sure why the AMX master controller connected to the Homeworks processor wouldn't be powered on all the time. Like Vining says, you should be able to provide feedback, presets and control to several touchpanels connected to different masters pretty easily from one place. Even if each touchpanel has different presets, you should be able to handle that in one program running on one master. If you choose to break the program up and place a UI module on each master, it should still only communicate with one _comm module which is connected to the HW processor.
You may want to take a look at virtual devices and touchpanel device arrays and see if you can set this up with only one connection to the physical device. If the Lutron HW processors are connected to eachother (which I would expect them to be) then you can access both HW processors through one connection to the main HW processor too.
Not saying your way is wrong, just different and there are more efficient ways of approaching the Homeworks.
Thanks Guys, i will go with your approach and set up a master to master connection with the Lutron. How do i create the comm module to make sure that one master connects via ip and then the other controller connects via this master.
Put the module on 1 master and then just put the virtual used for comms in all the other masters making sure that if the module is on system 1 (for instance) in the other master you have:
vdvHWI_Comms = 33000:1:1 ; // in every master needing comms with the HWI
Note you use the system number and not 0 in this case so that all masters send to master system 1 which holds the code for the module.
If you have TPs assigned to the individual masters you can put a button event for each TP in each master to activate different presets or scenes and they all send commands to the same virtual. Like wise you can have a data_event in each master and modify the string event to handle just the traffic ear marked for that master or zone. Or you can handle everything in one location and it doesn't even have to be the same location that has the module or the physical connection. It's really very flexible that way.
Thanks Vining, but i am not using a netlinx or duet module here, more like using an ip_client_open command. How do in that scenario.
Can someone help me with the feedback for the keypad leds. The function that i am using is turning the channels on/off in the touch panel, but there is a delay sometimes and sometimes the channel is not turning on/off
Thanks Vining, but i am not using a netlinx or duet module here, more like using an ip_client_open command. How do in that scenario.
Can someone help me with the feedback for the keypad leds. The function that i am using is turning the channels on/off in the touch panel, but there is a delay sometimes and sometimes the channel is not turning on/off
You know, the AMX netlinx module for the Lutron Homeworks is pretty tried-n-true. I'd go ahead and use it and just make the quick mod for doing IP connection.
I've rolled most all my own modules but I can recommend the Lutron one. It's one of their oldest and works quite well. It'll save you a whole bunch of programming time parsing those strings.
I've personally had problems with the Lutron duet module... lots of communication loss, very laggy response, and other issues. The one that John Paul is using looks to be based on the code posted by Vincen early in this thread.
In the implementation you're using (John Paul), you're using a virtual to track the LED status. There are issues with the use of channel tracking on virtuals across master to master setups which I don't think has been fixed as of the most current firmware. Here's what you have (based on your earlier post):
DEFINE_PROGRAM
//ROOMS LIGHTS STATUS
[virtualTPMBLutron,1] = LEDS [1] [4] [4] [1] // this is the KP address, will be different for wireless
[virtualTPMBLutron,2] = LEDS [1] [4] [4] [2] // this is the KP address, will be different for wireless
[virtualTPMBLutron,3] = LEDS [1] [4] [4] [3] // this is the KP address, will be different for wireless
[virtualTPMBLutron,6] = LEDS [1] [4] [4] [6] // this is the KP address, will be different for wireless
[virtualTPMBLutron,14] = LEDS [1] [4] [4] [14] // this is the KP address, will be different for wireless
[virtualTPMBLutron,15] = LEDS [1] [4] [4] [15] // this is the KP address, will be different for wireless
On the other masters, you could have something like
DEFINE_DEVICE
virtualTPMBLutron = 33001:1:1 //Assumes that the virtual that we're tracking is on system 1 & was defined as 33001:1:0
DEFINE_PROGRAM
[dvTP_LutronPage,1] = [virtualTPMBLutron,1]
[dvTP_LutronPage,2] = [virtualTPMBLutron,2]
Or in the main code you're using for the Homeworks, you could do something like this:
DEFINE_CONSTANT
(*Define all of the Lutron Pages of each touchpanel here*)
dvTPLutronArray[3] = { 10001:1:1,
10001:1:2,
10001:1:3
}
DEFINE_FUNCTION
(*put this into your parsing and feedback section*)
[dvTPLutronArray,1] = LEDS [1] [4] [4] [1] // this is the KP address, will be different for wireless
[dvTPLutronArray,2] = LEDS [1] [4] [4] [2] // this is the KP address, will be different for wireless
[dvTPLutronArray,3] = LEDS [1] [4] [4] [3] // this is the KP address, will be different for wireless
[dvTPLutronArray,6] = LEDS [1] [4] [4] [6] // this is the KP address, will be different for wireless
[dvTPLutronArray,14] = LEDS [1] [4] [4] [14] // this is the KP address, will be different for wireless
[dvTPLutronArray,15] = LEDS [1] [4] [4] [15] // this is the KP address, will be different for wireless
Thanks Vining, but i am not using a netlinx or duet module here, more like using an ip_client_open command. How do in that scenario.
What Vining was showing is that in the code that you're using to communicate with the physical Homeworks processor, you have the device defined and a virtual device defined. In the data_event of your code, you have something that checks for an event on the virtual device, then performs an action on the phsyical device. For instance, using this code below:
DEFINE_DEVICE
dvTPHomeworks = 10001:1:0
dvHomeworksProcessor1 = 5001:1:0
vdvLights = 33001:1:0
DATA_EVENT [vdvLights]
{
COMMAND:
{
SEND_STRING dvHomeworksProcessor1,"DATA.TEXT,13, 10"
}
}
BUTTON_EVENT[dvTPHomeworks,BUTTON.INPUT.CHANNEL]
{
PUSH :
{
SEND_COMMAND vdvLights, "'KBP, [',cProcessorNum,':',cLinkNum,':',cKeypadAddress,'], ',ITOA(BUTTON.INPUT.CHANNEL)" //cProcessorNum, cLinkNum, cKeypadAddress should be selected by assigning variables to the KP chosen on the Touchpanel Page.
}
HOLD [5]:
{
SEND_COMMAND vdvLights, "'KBH, [',cProcessorNum,':',cLinkNum,':',cKeypadAddress,'], ',ITOA(BUTTON.INPUT.CHANNEL)" //cProcessorNum, cLinkNum, cKeypadAddress should be selected by assigning variables to the KP chosen on the Touchpanel Page.
}
RELEASE:
{
SEND_COMMAND vdvLights, "'KBR, [',cProcessorNum,':',cLinkNum,':',cKeypadAddress,'], ',ITOA(BUTTON.INPUT.CHANNEL)" //cProcessorNum, cLinkNum, cKeypadAddress should be selected by assigning variables to the KP chosen on the Touchpanel Page.
}
}
a button press on the touchpanel attached to this master would fire a command to the virtual device, the virtual device would then send it to the real device. On the other masters with touchpanels attached, you would have the same button_event code, where it would send it to the virtual device which is defined on system 1. That's one way of handling it where the Touchpanel (UI) code resides on each master.
I've personally had problems with the Lutron duet module... lots of communication loss, very laggy response, and other issues. The one that John Paul is using looks to be based on the code posted by Vincen early in this thread.
Just to be clear, I did say the 'Netlinx' version. I too have had major issues with the Duet version. The older Netlinx module works great.
There are issues with the use of channel tracking on virtuals across master to master setups which I don't think has been fixed as of the most current firmware.
Excuse the drift but can you expand on this statement? I not sure I?m familiar with the problem. Is this in regards to the master not keeping track of the current state of a virtual so it will trigger say an ON channel event even if the channel is already ON? I thought I heard about something like that a long while back but I never got the details and didn?t know it was associated to m2m, if that is indeed the case.
Excuse the drift but can you expand on this statement? I not sure I?m familiar with the problem. Is this in regards to the master not keeping track of the current state of a virtual so it will trigger say an ON channel event even if the channel is already ON? I thought I heard about something like that a long while back but I never got the details and didn?t know it was associated to m2m, if that is indeed the case.
Sorry Joe, I've been looking for some info about this but I can't find any of my personal notes on it (I always think I'll remember it). Here's another thread that mentions it, but no details either: http://www.amxforums.com/showthread.php?t=5627. I know I got caught by it with a statement where I was updating channel feedback across multiple masters. From what I recall, the channel event feedback was intermittent, and would sometimes get caught in the wrong state. If memory serves me right, my situation was that if a channel was off, and the feedback loop tried to turn it on, the channel event wouldn't always get sent becase the state tracking was wrong. The same thing would happen in the other direction.
If memory serves me right, my situation was that if a channel was off, and the feedback loop tried to turn it on, the channel event wouldn't always get sent becase the state tracking was wrong. The same thing would happen in the other direction.
Ugh, sounds nasty.
And it hasn't been fixed yet?
Double ugh.
I'm surprised I haven't been caught off guard by this.
Or maybe I have and just don't know it yet.
Thanks Guys for all the inputs, i have attached the code in this post. I have done master to master with the commands being send to the virtual.
i tried queuing the commands which i reach from the different masters but somehow the commands are getting delayed a lot. I tried setting up a timeline to poll the device when the touch panels come online but that seems to be written wrong.
The channel event feedback seems to be intermittent on masters 5 and 6 but the rest of the masters seems to show perfect channel event feedback. I have updated the firmwares of all the masters. The master which has the main lutron code is the ni3100 and the rest of masters are ni3100 signature series.
here are the firmwares of the masters that i am using here
2105-04_NI-X100_Master_v3_41_422.kit
2105-08_NI-X101_Master_v3_41_422.kit
and 2105_NI_X101_Device_v1_13_9.kit
Comments
Hi Ady,
It's briefly mentioned on page 10 of the module documentation. I agree that the documentation isn't all that clear.
In the code that I posted, the array sizes need to be adjusted for your password and username... I used 'myusername' and 'mypassword', but the variable I defined was only for 8 and 7 characters respectively:
I would try to telnet into the Homeworks P5 processor using the username and password you assigned under Link 9 in the Illumination program just to make sure you're not having any issues with the IP address and login.
The last line in the code I posted where it lists SEND_COMMAND vdvLights, 'REINIT' is to reinitialize the module after you've updated the properties for the IP address and login.
--John
BTW - page 10 got nothing that connected to this issue, as I said before , the word login is not mention in the document.
I really dont undestand why a module that its so important get such a poor documentation.
Ady.
Guess this thread resurfaces when someone else new to Lutron integration stumbles on the documentation.
Please could someone help me reconcile the differences between the code fragments quoted in this thread and the documentation / test .axs file included in the Duet P5 module.
I can assign a new user / pass in HWI - this seems to be a common thread in what's posted here. I've done this.
What I don't understand is the chunks of new code that seem to be needed to the test file to make it work. There seems to be so much additional stuff to add (that is not documented) that I'm not sure I understand the purpose of the module.
I'd appreciate some help in understanding what needs to be added and edited in the module's test file to get it to work
thanks
update
Ditched the module, just gone back to our own TCP/IP comms and it's now under control.
I am succesfully controlling and getting feedback over IP from an H8P5-MI.
The DATA.TEXT buffer updates with the strings from the device, and I am able to parse the circuit levels or the keypad LED's.
The question is: Why "Device Notifications" will not show any of these strings coming from the device? (0:3:0 in my case)
- I have enabled notifications for ALL DEVICES, ALL EVENTS, as well as 0:3:0 all events.
- I have enabled monitoring on Lutron side (DATA.TEXT receives this, I have to say it again...)
Many thanks, Felix.
a (somewhat) workaround is to put a buffer on the port and watch that. You don't get the logging info that you would with device notification. But you at least can see what's coming in.
I believe it wouldn't be such a major task to implement in NS2 if AMX considerred this request.
As we all observe, the processor acknowledges the strings coming in (or going out), just does not care for logging them.
DATA_EVENT[ndvLutron]{ STRING:{ LOCAL_VAR CHAR cDevNum[12] //[xx:xx:xx] cDevNum = "'[',itoa(data.device.number),':',itoa(data.device.port),':'itoa(data.device.system),']: '" if(nLutronLogging) send_string 0, "cDevNum,data.text" parseCinBuffer() } }I know there is a lutron homeworks duet module and it works fine. I am on a site which has 6 controllers and lutron was connected via rs232 port to one of the controllers. Now since i was not able to get the feedback properly, we decided to connect the lutron via IP. So i got this code sample from the amx forums for the feedback part and i connected it via IP. Now i am able to connect via IP and get the feedback. But when i put the IP code in all the controllers, there is a considerable delay in the commands being received and the feedback being obtained. When i observed in the diagnostic tab, the connection keeps getting lost an reconnection happens.
I have attached the code i am using, the diagnostic info i am receiving from the controller and also the screenshot when i am trying to connect to the lutron via telnet. The IP listed in the screenshot is another amx controller. Is there a better way to code for this device or should i create multiple user accounts in the lutron homeworks processor using link 9 for each controller.
So yes, if you have multiple connections, you would require multiple user defined on the Lutron link 9.
If I remember correctly, you can only define 4 users on the Link9, so you'll have an issue if you need 6 AMX controllers connected via IP.
I don't know you full configuration but do you need all 6 AMX controllers talking to the lutron. Can't you define the module on 1 AMX master and access it through master to master communication?
Eric
Shouldn't be any difference in feedback between RS232 & IP either. There are command that you can send in the online event to set the desire feedback.
KBMON (Enable keypad/dimmer/Sivoia control button monitoring))
DLMON (Enable dimmer level/Sivoia state monitoring)
KLMON (Enable keypad led monitoring)
You should also set up a driver for the serial port so that it maintains its settings after power is cycled and you can choose monitoring feedback there as well. Just like you would do for a telnet connection. They both work the same.
But to add to the 1st repsonse only connect via 1 master and link your masters together w/ M2M.
here is the function i ve used for feedback, i am changing the button states in the define_program section .Any better way to do this
define_function TESTkp(char buff[])
//lutron sent: $0D$0AKLS, [01:06:02], 000000000000000000000000$0D$0A
{
stack_var char temp[30]
stack_var char tProc[5]
stack_var char tLink[5]
stack_var char tKP [5]
stack_var char tBtns [35]
stack_var integer btn
stack_var integer arr_proc
stack_var integer arr_link
stack_var integer arr_kp
stack_var integer arr_btn
stack_var integer arr_status
temp = remove_string(buff, 'KLS, [', 1)
// Only care about LED feedback
if (!length_string(temp))
{
return
}
tProc = remove_string(buff, ':', 1) // get Processor #
set_length_string(tProc, length_string(tProc) - 1)
arr_proc = ATOI(tProc)
tLink = remove_string(buff, ':', 1) // get Link #
set_length_string(tLink, length_string(tLink) - 1)
arr_link = ATOI(tLink)
tKP = remove_string(buff, '], ', 1) // get KP #
set_length_string(tKP, length_string(tKP) - 3)
arr_kp = ATOI(tKP)
tBtns = remove_string(buff, "13, 10" , 1) // get Btn string
set_length_string(tBtns, length_string(tBtns) - 2)
// SEND_STRING 0,"'tBtns=',tBtns"
// SEND_STRING 0,"'arr_kp=',ITOA(arr_kp)"
// could nest next section within loops for links and processors if required
FOR(J=1;J<=24;J++) // buttons on KP
{
LEDS [arr_proc] [arr_link] [arr_kp] [J] = ATOI(MID_STRING(tBtns,J,1)) // possible states of lutron buttons
//SEND_STRING 0,"'LEDS [arr_proc] [arr_link] [arr_kp] [J] =',tProc,' ,',tLink,' ,',tKP,' ,',itoa(J),' '"
}
//SEND_STRING 0,"'LEDS [2] [4] [5] [15] =',itoa(LEDS [2] [4] [5] [15]),' '"
}
DEFINE_PROGRAM
//ROOMS LIGHTS STATUS
[virtualTPMBLutron,1] = LEDS [1] [4] [4] [1] // this is the KP address, will be different for wireless
[virtualTPMBLutron,2] = LEDS [1] [4] [4] [2] // this is the KP address, will be different for wireless
[virtualTPMBLutron,3] = LEDS [1] [4] [4] [3] // this is the KP address, will be different for wireless
[virtualTPMBLutron,6] = LEDS [1] [4] [4] [6] // this is the KP address, will be different for wireless
[virtualTPMBLutron,14] = LEDS [1] [4] [4] [14] // this is the KP address, will be different for wireless
[virtualTPMBLutron,15] = LEDS [1] [4] [4] [15] // this is the KP address, will be different for wireless
When you set up M2M all events are available to all masters if the devices are deifned in them and event handlers are created to handle them.
You may want to take a look at virtual devices and touchpanel device arrays and see if you can set this up with only one connection to the physical device. If the Lutron HW processors are connected to eachother (which I would expect them to be) then you can access both HW processors through one connection to the main HW processor too.
Not saying your way is wrong, just different and there are more efficient ways of approaching the Homeworks.
--John
Note you use the system number and not 0 in this case so that all masters send to master system 1 which holds the code for the module.
If you have TPs assigned to the individual masters you can put a button event for each TP in each master to activate different presets or scenes and they all send commands to the same virtual. Like wise you can have a data_event in each master and modify the string event to handle just the traffic ear marked for that master or zone. Or you can handle everything in one location and it doesn't even have to be the same location that has the module or the physical connection. It's really very flexible that way.
Can someone help me with the feedback for the keypad leds. The function that i am using is turning the channels on/off in the touch panel, but there is a delay sometimes and sometimes the channel is not turning on/off
You know, the AMX netlinx module for the Lutron Homeworks is pretty tried-n-true. I'd go ahead and use it and just make the quick mod for doing IP connection.
I've rolled most all my own modules but I can recommend the Lutron one. It's one of their oldest and works quite well. It'll save you a whole bunch of programming time parsing those strings.
In the implementation you're using (John Paul), you're using a virtual to track the LED status. There are issues with the use of channel tracking on virtuals across master to master setups which I don't think has been fixed as of the most current firmware. Here's what you have (based on your earlier post):
On the other masters, you could have something like
Or in the main code you're using for the Homeworks, you could do something like this:
DEFINE_CONSTANT (*Define all of the Lutron Pages of each touchpanel here*) dvTPLutronArray[3] = { 10001:1:1, 10001:1:2, 10001:1:3 } DEFINE_FUNCTION (*put this into your parsing and feedback section*) [dvTPLutronArray,1] = LEDS [1] [4] [4] [1] // this is the KP address, will be different for wireless [dvTPLutronArray,2] = LEDS [1] [4] [4] [2] // this is the KP address, will be different for wireless [dvTPLutronArray,3] = LEDS [1] [4] [4] [3] // this is the KP address, will be different for wireless [dvTPLutronArray,6] = LEDS [1] [4] [4] [6] // this is the KP address, will be different for wireless [dvTPLutronArray,14] = LEDS [1] [4] [4] [14] // this is the KP address, will be different for wireless [dvTPLutronArray,15] = LEDS [1] [4] [4] [15] // this is the KP address, will be different for wireless--John
What Vining was showing is that in the code that you're using to communicate with the physical Homeworks processor, you have the device defined and a virtual device defined. In the data_event of your code, you have something that checks for an event on the virtual device, then performs an action on the phsyical device. For instance, using this code below:
DEFINE_DEVICE dvTPHomeworks = 10001:1:0 dvHomeworksProcessor1 = 5001:1:0 vdvLights = 33001:1:0 DATA_EVENT [vdvLights] { COMMAND: { SEND_STRING dvHomeworksProcessor1,"DATA.TEXT,13, 10" } } BUTTON_EVENT[dvTPHomeworks,BUTTON.INPUT.CHANNEL] { PUSH : { SEND_COMMAND vdvLights, "'KBP, [',cProcessorNum,':',cLinkNum,':',cKeypadAddress,'], ',ITOA(BUTTON.INPUT.CHANNEL)" //cProcessorNum, cLinkNum, cKeypadAddress should be selected by assigning variables to the KP chosen on the Touchpanel Page. } HOLD [5]: { SEND_COMMAND vdvLights, "'KBH, [',cProcessorNum,':',cLinkNum,':',cKeypadAddress,'], ',ITOA(BUTTON.INPUT.CHANNEL)" //cProcessorNum, cLinkNum, cKeypadAddress should be selected by assigning variables to the KP chosen on the Touchpanel Page. } RELEASE: { SEND_COMMAND vdvLights, "'KBR, [',cProcessorNum,':',cLinkNum,':',cKeypadAddress,'], ',ITOA(BUTTON.INPUT.CHANNEL)" //cProcessorNum, cLinkNum, cKeypadAddress should be selected by assigning variables to the KP chosen on the Touchpanel Page. } }a button press on the touchpanel attached to this master would fire a command to the virtual device, the virtual device would then send it to the real device. On the other masters with touchpanels attached, you would have the same button_event code, where it would send it to the virtual device which is defined on system 1. That's one way of handling it where the Touchpanel (UI) code resides on each master.
--John
--John
Just to be clear, I did say the 'Netlinx' version. I too have had major issues with the Duet version. The older Netlinx module works great.
Sorry Joe, I've been looking for some info about this but I can't find any of my personal notes on it (I always think I'll remember it). Here's another thread that mentions it, but no details either: http://www.amxforums.com/showthread.php?t=5627. I know I got caught by it with a statement where I was updating channel feedback across multiple masters. From what I recall, the channel event feedback was intermittent, and would sometimes get caught in the wrong state. If memory serves me right, my situation was that if a channel was off, and the feedback loop tried to turn it on, the channel event wouldn't always get sent becase the state tracking was wrong. The same thing would happen in the other direction.
--John
And it hasn't been fixed yet?
Double ugh.
I'm surprised I haven't been caught off guard by this.
Or maybe I have and just don't know it yet.
According to the post I linked, looks like 422 may have fixed it. I wasn't aware of that when I posted my original comment.
--John
Thanks Guys for all the inputs, i have attached the code in this post. I have done master to master with the commands being send to the virtual.
i tried queuing the commands which i reach from the different masters but somehow the commands are getting delayed a lot. I tried setting up a timeline to poll the device when the touch panels come online but that seems to be written wrong.
The channel event feedback seems to be intermittent on masters 5 and 6 but the rest of the masters seems to show perfect channel event feedback. I have updated the firmwares of all the masters. The master which has the main lutron code is the ni3100 and the rest of masters are ni3100 signature series.
here are the firmwares of the masters that i am using here
2105-04_NI-X100_Master_v3_41_422.kit
2105-08_NI-X101_Master_v3_41_422.kit
and 2105_NI_X101_Device_v1_13_9.kit