Options
Large Job - Tips & Pointers Please
jjames
Posts: 2,908
I have a very large job (for us) coming up and I'm getting started with actually coding it (I've been working on the UI for quite some time.) Here's the break down.
8 x Masters
* 1 in the rack to control the majority of the panels, audio & video switching
* 5 auxiliary / stand alone rooms, but still need switching from master in the rack
* 1 master for lighting control, which will need to send feedback to all masters above
* 1 master for pool control (controllable from specific panels)
17 x touch panels
10 x R-4s
Short of hearing on how you would have designed it differently (we're past that part - gotta deal with what we have now), what advice would you have for the communication between the masters (use SEND_COMMAND for information, pulse channels,etc.) I think that's where I'm really stuck. I've done M2M with 2 masters, and that's about it (we almost never have the need for more than one master, let alone eight!) So M2M is a clear-as-mud concept for me. I've not had to manage the amount of data going between the masters or truly manage the feedback of connected panels (i.e. sending feedback, etc. ONLY when needed) so I'm trying to plan this out and do it right the first time - I won't have the time or opportunity to do any significant changes in the way that stuff is handled.
Also, any management ideas, dos-and-dont's (in respect to coding in general) would be great. A job this size isn't something I do all the time.
8 x Masters
* 1 in the rack to control the majority of the panels, audio & video switching
* 5 auxiliary / stand alone rooms, but still need switching from master in the rack
* 1 master for lighting control, which will need to send feedback to all masters above
* 1 master for pool control (controllable from specific panels)
17 x touch panels
10 x R-4s
Short of hearing on how you would have designed it differently (we're past that part - gotta deal with what we have now), what advice would you have for the communication between the masters (use SEND_COMMAND for information, pulse channels,etc.) I think that's where I'm really stuck. I've done M2M with 2 masters, and that's about it (we almost never have the need for more than one master, let alone eight!) So M2M is a clear-as-mud concept for me. I've not had to manage the amount of data going between the masters or truly manage the feedback of connected panels (i.e. sending feedback, etc. ONLY when needed) so I'm trying to plan this out and do it right the first time - I won't have the time or opportunity to do any significant changes in the way that stuff is handled.
Also, any management ideas, dos-and-dont's (in respect to coding in general) would be great. A job this size isn't something I do all the time.
0
Comments
That's bigger than anything I've ever done too but don't imagine it to be functionally much different than having 2 masters. I would still run basically everything on 1 central master and leave the other masters to handle their local equipment (I assume that's why you have them). I like all the TPs & other UI's on the main system and talk to the local equipment via M2M.
Also, create a good queue to handle all the TP feedback. The comm chatter of a system that large is silly.
Have fun! Sounds like a nice one to put a notch on your belt with.
I am managing the feedback on a "need-to-update" basis, but am still trying to think of a way to queue the info up in a reliable manner.
What's everyone's thoughts on using virtual channels for feedback (source select, lighting, etc.) and having the panels grab the status when needed? I can see needing to queue up feedback such as text (i.e. radio stations, DSS station feedback, etc.), but again - using a virtual channel as a flag to tell when to update.
Yeah, that's what I'm afraid of.
That's actually what I do for Lutron stuff right now. I've found that our clients are all over the map with using Lutron. Some want every possible button / fader/ etc. on the panels, some want someting in between and some want only a few simple lighitng controls.
coming up with a 'modular' way to program that was driving me crazy. So, I ended up creating a virtual device and dev_chan array and structure for all possible Lutron VirtKeypads and it populates and builds itself from the data you fill in when setting it up. What the client sees on the panels is all determined from the data entered. The panel's layout is built when they access the lighting pages. Feedback for that is only active for the specific button(s) they're looking at at the moment.
At first it was a daunting task. But afterwards, it changed doing and entire house's lighitng (programming and TP design) in two days to about 1-2 hours.
So, I think it's a great idea. I'd definitely go for it.
For the really complex stuff (like using room temperature offsets developed on one system that are compared to astronomic time data from another system to control shades attached on yet another system), well you'll need your own api communicating through a virtual device for that.
What I was planning on doing for the lighting would be this...
We've got the seperate master (#7) for the LiteTouch processor. I was thinking about having a single virtual device (vdvLIGHTS) on that master (35007:01:07) on all of the other masters, and update when needed (entering lighting page and when a button on the keypad changes states.) The only purpose vdvLIGHTS would serve is just an on/off status of the keypad's buttons. I would have a function or two and some variables on each of the masters that would keep track as to which keypad they're looking at.
The virtual device would break down like so: 1,107 channels (there are 123 keypads with a maximum number of 9 buttons). Parse the incoming feedback and do a little bit of math so that keypad 72, button 3 would be channel 642 on the virtual device.
For having the auxiliary masters tell the main master to switch, I was going to simply do some SEND_COMMANDS in the format of: "'a:IbOc',$0D" where a is A for audio, C for component, or V for video; b is input, c is output. I had thought about some crazy thing of having a bunch of channels that'd be designated for input, output and some that be for what needed to be switched (audio, component or video) and one last one for a "take" command - but quickly abandoned that as it'd be A WEE BIT complicated. Am I over thinking this a little?
I'm trying to have as few dependencies as possible, so each master will control their own equipment and that's it. If another master needs to control another's equipment - which the only time that'll happen is a whole house off command - functions on the respective master will be triggered by a channel. I don't want to have them all depend on one another in the case of a break down in the chain. If the lighting master goes out - they have no lighting; I don't want it to be if master #4 goes out, lighting goes out because #7 depended on #4.
Ugh - it just seems like it's so complicated - but in reality, it's not. There's just more of what I'd normally be doing to do . . .
Anyway - thoughts on my rambling would be appreciated.
Got that right
DEFINE_DEVICE dvTP1_THIS_MASTER = 10001:1:0 dvTP2_OTHER_MASTER = 10001:1:2 dvTP3_YET_ANOTHER_MASTER = 10001:1:3 DEFINE_CONSTANT MAX_TP = 3 DEV dvTP = {dvTP1_THIS_MASTER,dvTP2_OTHER_MASTER,dvTP3_YET_ANOTHER_MASTER} INTEGER TP_BUTTON_CHANGE_LIGHTS_ROOM[ ] = {1,2,3,4,5,6,7,8,9,10} INTEGER TP_BUTTON_LIGHTS_KP[ ] = {101,102,103,104,105,106,107,108,109,110} INTEGER TP_BUTTON_LIGHTS_KP_FB[ ] = {201,202,203,204,205,206,207,208,209,210} DEFINE_VARIABLE PERSISTENT INTEGER nLightRoom[MAX_TP] DEFINE_EVENT BUTTON_EVENT[dvTP,TP_BUTTON_CHANGE_LIGHTS_ROOM] { PUSH: { TO[BUTTON.INPUT] nLightRoom[GET_LAST(dvTP)] = GET_LAST(TP_BUTTON_CHANGE_LIGHTS_ROOM) } } BUTTON_EVENT[dvTP,TP_BUTTON_LIGHTS_KP] { PUSH: { TO[BUTTON.INPUT] LightsButtonPush(nLightRoom[GET_LAST(dvTP)] ,GET_LAST(TP_BUTTON_LIGHTS_KP)) } RELEASE: { LightsButtonRelease(nLightRoom[GET_LAST(dvTP)] ,GET_LAST(TP_BUTTON_LIGHTS_KP)) } } DEFINE_PROGRAM WAIT 1 { LOCAL_VAR INTEGER iTp, iButton FOR(iTp=MAX_TP; iTp; iTp--) { IF(nLightRoom[iTp]) { FOR(iButton=LENGTH_ARRAY(TP_BUTTON_CHANGE_LIGHTS_ROOM); iButton; iButton--) { [dvTP[iTp],TP_BUTTON_CHANGE_LIGHTS_ROOM[iButton]] = (nLightRoom[iTp] = iButton) } FOR(iButton=LENGTH_ARRAY(TP_BUTTON_LIGHTS_KP_FB); iButton; iButton--) { [dvTP,TP_BUTTON_LIGHTS_KP_FB] = (nLightsFb[nLightRoom[iTp]][iButton]) } } } }Setting it up this way should greatly reduce any unneccesary chatter from referencing raw devices using master to master. The theory behind it is that the modules can handle all of your buffering, message translation and verification, and device behaviour standardisation (ie. a projector in the home theatre will act the same as the plasma in the lounge room, no need to worry about telling one to unmute when your swich inputs and the other one does it automatically). This should distribute any processing load for this across your system. It will also mean your only having to use standardised API's for communicating with every type of device and if things are changed in the future its all done at one point in the system.
The other way you could take it is that if you are wanting to distribute the system behaviour processing you could look into rolling some SOAP libraries for passing meaningfull data between your masters.