Options
Touchpanel Level Management
Brad.Odegard
Posts: 40
Okay, I can't help but feel like I've overlooked an easier way to do this, so I figured I'd run this one by you guys to see if there are some better ideas.
Here are the parameters of the problem I'm facing:
1. System performing individual load control of a Lutron Homeworks Interactive system via RS-232
2. I have individual control and raise/lower functionality working for each zone
3. I am receiving level feedback for each zone and storing into a variable that is part of a structure.
4. I have a virtual level device for one room that I'm successfully updating the level based on the values coming back from Lutron - Right now I'm doing a send_level to the VDV as part of the string parse - could I just tie the level to the variable and have it update on it's own without the send_level?
5. I have a single page for lighting in the TP files (6 iPads using TPC) with control buttons that have dynamic text based on which room is currently being controlled.
I would like to have the levels on this TP page reflect the current load levels for the lights as currently being controlled.
Right now, I'm thinking that I'll have to have a virtual level device for each room of lights, and then I'll have to do combine/uncombine levels in runtime to move the physical touchpanels from virtual device to virtual device depending on which room I want to control at that time.
I've done this using Combine_Device in the past to move physical TP's into and out of UI modules when having 16 UI modules running brought the system to it's knees, so I'm reasonably familiar with the mechanics.
Is there an easier way, other than having 16+ lighting pages on each TP with independent levels? I don't like the multiple pages because it's not scalable, and changes have to be done on every page when design is adjusted.
Thanks,
Brad
Here are the parameters of the problem I'm facing:
1. System performing individual load control of a Lutron Homeworks Interactive system via RS-232
2. I have individual control and raise/lower functionality working for each zone
3. I am receiving level feedback for each zone and storing into a variable that is part of a structure.
4. I have a virtual level device for one room that I'm successfully updating the level based on the values coming back from Lutron - Right now I'm doing a send_level to the VDV as part of the string parse - could I just tie the level to the variable and have it update on it's own without the send_level?
5. I have a single page for lighting in the TP files (6 iPads using TPC) with control buttons that have dynamic text based on which room is currently being controlled.
I would like to have the levels on this TP page reflect the current load levels for the lights as currently being controlled.
Right now, I'm thinking that I'll have to have a virtual level device for each room of lights, and then I'll have to do combine/uncombine levels in runtime to move the physical touchpanels from virtual device to virtual device depending on which room I want to control at that time.
I've done this using Combine_Device in the past to move physical TP's into and out of UI modules when having 16 UI modules running brought the system to it's knees, so I'm reasonably familiar with the mechanics.
Is there an easier way, other than having 16+ lighting pages on each TP with independent levels? I don't like the multiple pages because it's not scalable, and changes have to be done on every page when design is adjusted.
Thanks,
Brad
0
Comments
Of course, a lot depends upon how you go about managing your touch panels. I do all mine from code, so it makes this kind of thing rather easy.
So, I'll let you know how I'd do it myself.
All incoming levels from the device would be stored in an integer array.
Since I'm already tracking what page each panel is currently on and thus what feedback is needed a timeline handling the TP feedback would send the current zone(s) fader levels just prior to opening the popup page and then again after any changes of the feedback level from the device (Lutron in your case) When the TP in queetion leaves the page, the feedback stops.
The TP Feedback routine can actually deal with busy times by adjusting the speed at which it's sending feedback.
That's how I'd do it. I wouldn't spend a lot of time dealing with connecting and unconnecting devices and levels back and forth.
Hope that helps.
Eric,
I'm doing most of the TP management from code already. I like where you are going with this, and I've got all the levels in room specific structures (Structure includes name to display on panel, load address in lutron for sending commands, keypad LED state if that location is a button instead of a load, and last returned load level).
How would you handle knowing when the value of the variable has changed to then know that you needed to update the level on the 1 or more TP's that are currently on that room? I guess I am already seeing the change occur since I'm writing it to the variable as a new value - just have to have that trigger a subroutine/function/call that then causes the panel update to happen on all panels that are currently viewing that room.
Brad
Personally, I'd do without the timeline. I'm getting away from define_program all together and timelines as much as I can. There are only two times that the panel should be updated in this instance. When the user selects the lighting page, and when the lighting system reports a change. Other than that, the system should be idle when it relates to lighting. At the end of each string event for devices that I care about displaying feedback, I have the same exact routine fire that is fired when the panel first gets to the page.