Zones Help

staticattic

I have been trying to wrap my head around the concept of zones but I am getting in over my head. I think it is because I am trying to create multiple zones across 2 video switches. Something smaller and simpler would probably be easier to understand. Here's a scenario:

1 room
1 master
1 panel
1 8x8 switch
2 displays (1 has audio the other is display only)
2 serially controlled cable boxes
2 IR controlled DVD players

The quick, no frills programming would be to create a new port for each device. No worries. That would work just fine. Now 6 months down the road, that customer uncovers a pot of money so they expand. They add 2 more panels, 2 more displays, and 4 more cable tuners. A programmer could create new ports for each new device, but the system would not be expandable friendly. Each panel needs to be able to control all devices. What would be the better way to make this system infinitely expandable? This is where zones and event tables come into play, correct?

Spire_Jeff

I would look at employing "tracking" variables. You start to track which room and which device each touch panel is controlling. Once you have that information, you can decide what to do with button pushes. The more time you spend up front thinking about what you want to do (within reason) and the more planning you do, the better you will be able to easily expand and adapt the system.

If you know that the touch panel is selecting cable box 1 in room 1, you can send a command to the video switcher to make output 1 use input 1. You can make this more efficient by using arrays to determine what is connected where and you can condense the switching code to something as simple as:

define_function doVideoSwitch(integer myDevice, integer myRoom){
     send_string dvVidSwt,"'CI',itoa(nInput[myDevice]),'O',itoa(nOutput[myRoom]),'T',10,13";
}

.
.
.
button_event[dvTP,BTN_SRC_SELECT]{
   push:{
     stack_var integer nTpIndex;
     stack_var integer nDevIndex;
     nTpIndex = get_last(dvTP);
     nDevIndex = get_last(BTN_SRC_SELECT);
     nSrcInUse[nTpIndex] = nDevIndex;
     doVidSwt(nDevIndex,nRoomInUse[get_last(dvTP)]);
   }
}

Hoep this helps,
Jeff

a_riot42

staticattic wrote: »

I have been trying to wrap my head around the concept of zones

It can get complicated. Don't forget that in addition to AV zones, you can also have HVAC zones, Security zones, Lighting zones, etc that may or may not correlate to your AV zones. You may need 2 AV zones called 'Living Room' and 'Dining Room' that require different AV settings, but for HVAC, there is only one zone since both rooms are on the same HVAC pump. However, in the living room alone there might be 10 security zones. Like others have said, the more time you spend thinking it all through before writing any code, the less code you end up writing.
Paul

jjames

Here's what a zone is to me (obviously opinions will definitely vary.) I always start out with an A/V zone as an audio zone. If there's an output on the audio switcher, it's a zone whether there's a display in it or not. I feel this is one of the easiest ways to think of a zone since you can only listen to one thing in there at a time. You can watch multiple things at a time - but can only hear one.

So code-wise, if I'm dealing with an 8x8 Precis - I have 8 zones. If I have an output going to an Integra DTR hooked up to that 8x8 - I still have 8 zones, but if the DTR is not hooked up to it and is sort of its own little area - I now have 9 zones. If on that Precis I only have 2 outputs hooked up - I still have 8 zones. As Jeff said, tracking variables of the area your controlling and what you're controlling will help big time - however you do that, is up to you. Use channels on a virtual device, use levels, use a variable - whatever.

If my logic is way off base - some one advise.

DHawthorne

Wrapping your head around it is the hardest part. Often, writing the code is easy ... making it efficient and flexible is not.

For devices, I will share a single panel port for all simple controls: IR, basic RS-232 (i. e., limited feedback, not a lot going on), then run a test on the button event to determine what device gets it. To accomplish this, I use a variable that tracks what device each panel in the system is currently controlling, and switch it as new devices are selected. At that point, IR control is as easy as SEND_COMMAND dvControlled_Device[<panel index>], "'SP', BUTTON.INPUT.CHANNEL", and will work for any IR device you care to use ... just edit the button channels on the page to match the IR channels they fire.

I have found that many large systems wind up with multiple systems ... be it a multizone amp with a switcher, receiver for a local system, or just a TV. Once upon a time, I wrote a separate module for each system, but found it terribly cumbersome for all the individual modules to be aware of what was going on in the others. So I treat a house like one big system now, and create a structure tailored to the job that determines what controls each zone. The program then not only tracks what device each panel is controlling, but which zone, and a simple reference to the system structure tells whether to send those volume commands to the local TV, or an audio switch, or whatever. This also makes it easier to "move" control in a panel from one room to another if desired.

staticattic

Zones are starting to make sense, I am just going to have to keep playing with them. My work pace has slowed down for a second, so I figured now would be the perfect time to learn some new tricks. I have also been playing with tables. I have not mastered them yet, but I have started using them in the real world. 99% of my jobs involve one panel with one master. What I have started doing was creating a structure and using arrays to keep track of the "active" panel, which in my case will always be 1. However, if the customer suddenly decided to add 100 panels to a system, it wouldn't really be much of a hassle for me. I doubt that would ever happen, but if it were to happen, all I would have to do would be change the size of my panel array, tweak the code a little, and I would be back in business. Through variables, the system would keep track of what panel was trying to control which device and act accordingly.

Zones are going to take more practice. 99% of my jobs are purely A/V, no lighting, HVAC, alarms, or anything else. Told you my jobs were boring, cookie cutter jobs.

staticattic

I've got it. This is probably going to probably be the craziest thing I have ever said on this forum, but bear with me.

Last night I was playing with my 10 month old daughter and it hit. My problem with "zones" was that I wasn't stepping back and looking at the big picture.

If I had a multi panel / one master system, in front of each panel I could place a coffee table. On that coffee table I can place all of the toys that particular panel is allowed to play with. When the master rx'd a "Channel UP" command, it would go something like this:

"Panel 1 just sent me a 'Channel Up' command. Looking at his coffee table, I see he can only play with Tuner 1, so I am going to relay the message to Tuner 1 that he needs bump up his current channel."

Taking it even further, I can put two tuners on Panel 1's table. Then it would go something like this:

"Panel 1 just sent me a 'Channel Up' command. Looking at his coffee table, I see he can only play with Tuner 1 and Tuner 2. He is currently asking for control of Tuner 2, so I am going to relay the message to Tuner 2 that he needs bump up his current channel."

And even further, I can have a "boss" panel:

"Uh oh. The 'Boss' Panel just sent me a 'Channel Up' command. Since he is the boss, he can play with all of the tuners. Right now, he is currently standing in front of coffee table 1 and the only tuners on coffee table 1 are Tuner 1 and Tuner 2. He has asked to control Tuner 2, so I need to tell Tuner 2 he needs bump up his current channel."

What toys I place on each coffee table, or zone, is totally up to me. I can place them by Audio, Video, or even get silly with it and place them by faceplate color, control methods, or names that rhyme with each other. It really doesn't matter. What does matter is that I divide the toys up in such a way as to make logical sense, ease of programming, and a way that would make things easier for expansion or for the next guy that comes along. That would be the difficult part and the part requiring the most planning. Now I just need to draw out my system, figure out the best way to divide the toys, and how many coffee tables I need. This is going to be fun.

In my one panel / one master systems, there are 2 "modes" the user can select: VTC or Local Presentation. I think I am going to start out by making each mode a zone. I think that would be the easiest, for now anyway. Then divide up the toys by which zone needs which devices and levels of control, and take it from there.

Spire_Jeff

Sounds like you are on the right path. If you come to a fork in the road, feel free to ask advice on which way to go....but be prepared for the Wizard of Oz Scarecrow response

Jeff

vining

Even though most jobs you do only use 1 TP you'll find it's still beneficial to get into the habit of creating a UI_Array even if it only contains 1 TP (UI). Then your code can become flexable and you can create further arrays to determine which TP is actve and on what source, which TP is online, which TPs need feedback and what type of feedback based on what source they're on. Another array to let you know what type of TP or UI it is to further aid in determining capabilites, functions and again what feedback to send it and another array to tell you what UI corresponds to what audio zone, hvac and anything else that relates one to one or one to many. Arrays and/or structures, the more the merrier and very essential in large jobs but equally as helpful in small jobs even if there's only one UI and 1 master. After all what's the difference?

staticattic

My current project involves one TP, 2 displays (one with audio), DVD player, codec, and an 8x8 matrix switcher. The current level of devices on that system are TS. So, I decided to create a TS zone. My intentions were if they ever came back and added multiple classification devcies to the system, each classification would have its own zone. In doing that, here is what I did:

DEFINE_DEVICE

dvTP_1           =     10001:1:0

dvSWITCH       =     5001:1:0
dvCODEC         =     5001:2:0
dvLFT_MON     =     5001:3:0
dvRHT_MON    =     5001:4:0
dvDVD_1         =     5001:9:0

DEFINE_CONSTANT

DEV arrTP_MAIN[] =
{
            dvTP_1
}

DEV arrVIDEO_SWITCH[] =
{
               dvSWITCH
}
DEV arrCODECS[] =
{
                dvCODEC
}
INTEGER nCODEC_DEV_MAP[] =
{
                 1
}
DEV arrDVD_PLAYERS[] =
{
                 dvDVD_1
}
INTEGER nDVD_DEV_MAP[] =
{
                  1
}

DEFINE_VARIABLE

VOLATILE INTEGER nPNL_AV[MAX_PANELS]
{
              nZone_TS
}




DEFINE_EVENT

BUTTON_EVENT[arrTP_MAIN,nTransport_BUTTONS]
{
        PUSH:
        {
               STACK_VAR INTEGER nIND
               STACK_VAR INTEGER nIR_FUNCTION
               nIR_FUNCTION = GET_LAST(nTransport_BUTTONS)
               nIND = GET_LAST(arrTP_MAIN)
               SEND_COMMAND arrDVD_Players[nDVD_DEV_MAP[nPNL_AV[nIND]]],"'SP',nIR_FUNCTION"
        }
}

If I did it right, this essentially gave the current panel control of Zone 1, and placed the current DVD player in Zone 1. In the past, I would have created dvDVD_TP 10001:2:0 and done this:

BUTTON_EVENT[dvDVD_TP,0]
{
   PUSH:
   {
         SEND_COMMAND dvDVD_1,"'SP',BUTTON.INPUT.CHANNEL"
}

Now I am trying to utilize zones, and I am stuck. If I again start making ports for each device, that negates the need for zones. If I try to do most of my control from one port, I can't use BUTTON.INPUT.CHANNEL, because those channels are already being used somewhere else. To get around that, I created an array of transport buttons so I could utilize GET_LAST. Am I more or less working in the right direction? I am thinking with this method I can add panels or equipment and place them in their proper zones.

ROO

Security - for each device

I use a structure to describe each device and put the security limitations in it. The constants I use to reference the security level start at 1 for Unrestricted, 2 for Un-classified, 3 for secret.... etc. Since a un-classified device can be show/heard in a higher level classification (TS), the simple test against the room classification and the selection of a device to control (display or listen to) allows me to determine when to restrict acess. Each room has it's own classification, and each device in the room has a classification. An unrestricted device (like a projector) can always be utilized. This ensures that the user can't inadvertently show a classified PC in a unclassified briefing. Since we use multiple CODECs (classified/unclassified), they are also controlled by the Room Classification.

You might also want to consider writing your control code to a virtual device. The control of the CODEC in ROOM A, uses the same routines as one in ROOM B in our systems. I use a device array and a virtual device array that is in the same order. The get_last function returns the offset from the virtual device array, and the offset is used to control the real device from the device array. It's kind of like creating classes in Java, so the code doesn't need to change much. The Touch Panel can use the same buttons in each room, and use a touch panel device array to determine which room the touch panel is in to know where you're working too. The added benefit for us is that our customized IR Remote can control the devices as easily as a Touch-panel, and utilizes the same control routines.

Hope that gives you some additional ideas.
ROO