Making it complicated... (programming-wise)

Jorde_V

Trying to create a universal system for our touchpanels and systems. So I'll post what comes out of my head and hopefully someone push me in the right direction for what I'm trying to do.

I have rooms, touchpanels and devices. Aside from climate, light control etc.

I want to keep track of the device to control according to the room and the touchpanel controlling it. I then need to update the panels text (room text and device/page text).

So if I push the button 'tv' the following needs to happen:
- Open pop-up for TV
- Update panel's page-text
- Set the device to control

The issue is that text isn't a number nor are devices (well technically 3 numbers). So I need to keep track of all that using numbers and then if a number matches a device/text send that to the panel or use it to control a device.

So I would need to keep track of the device number and it's port. Because if it's in the 5001 range it's either IR or RS-232, but if it's in the 0 range I'm controlling an IP device. So there are exceptions, not to mention the possibility of multiple systems.

So I guess the way to go is structures, but if I look at the possibilities I'm probably making it way too complicated for it to be a useful system.

I would like to create a room according to a structure, but the structure would need to keep the rooms amount of lights, climate, security, devices, which touchpanels can control it, keep track of whether or not it's powered on fully or at least has powered on the necessary stuff, etc.

Most likely I'm just really looking at this in a very complicated manner and I hope you guys have different ways of figuring this all out.

So I hope I can some different views on this matter if you've been wanting/have done the same thing.

ericmedley

The process involves essentially object-ising (is that a word???) everything. I have done this myself on my systems. My designers were driving me batty with all the changes that occur every time a new whiz-bang thing came down the pipe.

examples:

My touch panels always have basically one page with a navigation bar/buttons. I call these buttons 'modes' They might be TV,House Music,HVAC,Ligthing, Security, etc... The buttonss themselves are blank and are filled in by the program from a big data array that holds all the values for these buttons and what kind of button they are going to be. This system also works with the smaller panels as you can scroll up and down the list of modes. So, there are typically 4-6 mode buttons on a panel. How the scroll behaves is also determined in the data table.

There's a big data table that manages the popups as well, which should be up, which go away, what they do. So, for example I have a standard Cablevision page. what box it controls is determined by the TV choice which is controlled by the mode section. Which audio zones are available on a given touch panle, which audio sources, what controls are available are, again controlled by the modes section.

TV control is done in a similar way. i don't have a section for Den TV, Living TV, etc.. They're just TVs and they have a numeric ID. The possibility to control any TV is there for any touch panel, but I limit it to whatever is considered local. (This also works with Man Caves as well - multiple TVs in one room)

I wrote a big TV control section on the same principle. I know when I select a TV source I mean to do the same thing each time: If TV power off, turn on. If TV not on source, get it there, If sound processor not on, turn on. If not on source, get it there. I also allow for 2 more aux source routers in the TVs because my designers seem to find the craziest ways to need to get some source where it's going.

Similarly, within the TV routine is a big section on just how the TV is controlled, IR and its channels, RS232 and it's commands, IP and its commands, AMX module and it's commands. You simply populate the data table and the correct flags for what kind of control is used.

Once you go through the heartache of getting all this setup, making a system is pretty much plug-n-play. I haven't written any actual code for TVs in quite some time.

That is how I approached it.

DHawthorne

My approach is similar to Eric's. The core of my standard program is pretty much the same thing for every job, with some minor difference that I could probably also modularize, but didn't feel worth the effort. The differences are in INCLUDEs that specify how many zones are in a job, how many controllers, and how many devices; they also have data structures in a series of arrays for each that spell out their capacity: for example a zone might have audio, and it might have a TV, or it might have both ... the TV speakers may carry the audio, or room speakers on a system amp, or it may have a receiver ... all of that is indicated in the data structure, and every room has its own entry. My main program just says, essentially, turn on a device in a room; the room handler looks up what's appropriate, turns on receivers, TVs, whatever is necessary and appropriate, and activates the device. It's completely modular, and adding a room, adding a controller, adding a device is just a matter of expanding the structure array to include the new object. The feedback routine for each controller (all of which have a similar structure array with the controller type and capacities) makes sure when a control element changes that the controller reflects it. All of my panel files are identical, and have buttons for every possible device; that same feedback routine hides buttons that are not available (no point having a BluRay button on a room with no TV) so that if you walk around with the control and tell it to control a different room, it will look different according to what is available there.

My first version of this program took me two solid weeks to create, and another to troubleshoot and iron out the kinks. I've been fine-tuning it as I run into different situations, but it's been a rock-solid approach so far.

jjames

Yup - I'll "third" the approach Eric and Dave have laid out.

I was an array kind of guy, but now have mostly (95+ %) structures. I use a lot of pre-compiler directives that dictate which structures get called. For example:

#if_not_defined GENERAL_STRUCTURES
	// Define device usages here
	// Required Structures:
	//		- _zone
	//		- _source (this is done in EU_Structures.axi)
	
	// Components
	#define struct_tp
	#define struct_display
	#define struct_receiver
	
	// Sources
	#define struct_bluray // BDP
	#define struct_cd // CD
	#define struct_psx2 // iPod
	#define struct_aux // Piano
	#define struct_uverse // TV & Music
	#define struct_game // Game source
	
	#include 'EU_Structures, Rev 3'
#end_if

Inside EU_Structures, Rev 3 is:

#DEFINE GENERAL_STRUCTURES
define_constant
integer i_max_source = 30
#if_not_defined struct_tp 				#end_if
#if_not_defined struct_r4 				#end_if
#if_not_defined struct_kp 				#end_if
etc.,etc.,etc.
.....
DEFINE_TYPE

#if_defined struct_dvd_ir
	/******************************************************************************
	Standard DVD Player
	
	******************************************************************************/
	STRUCTURE _dvd_ir
	{
		dev 	device			;	// Holds the device (D:P:S) information
		
		i_compInput			;	// Component input on switcher
		i_hdmiInput			;	// Hdmi input on switcher
		i_vidInput			;	// Composite input on switcher
		i_audioInput			;	// Audio input on switcher
		integer	i_recInput	[04]	;	// Input on receiver - up to four receivers
		integer	i_displayInput	[10]	;	// Input on display - up to ten displays
	}
#end_if

In the main code, I have an init() function that again based on pre-compiler directives calls functions that fill in each structure's data. I set up how what the max number of TPs, max number of BDPs, max number of displays, etc. I also have a "Source" structure where the pop-up name is, whether it's a video source or an audio source only (this tells the display if it needs to turn on automatically or not - ex. satellite always turns on the TV - but these can be changed in the init() function as well.) I have allocated up to 40 different sources, but am at 30 at the current moment. You could even go as far as using #if_defined on the specific parts of the structure (which I'm starting to think about doing.) This way, you don't have an i_hdmiInput property if there is no HDMI switcher; or any receiver inputs if you don't have any receivers. This could (though I've not tried) cut down on the compile size.

Once all this information is filled in, the core code is nearly identical. My panel structure AND zone structures both have DEV vars in them - much like you are looking to do. It's a bit redundant in my opinion; the *only* time the panel's control device is different than the device in the zone it's controlling is when we are looking at what I call the "Whole House" page, which is a very quick glance at all of the sources available, and all of the rooms available (essentially a glorified matrix view of the system) and it allows the user to send and control specific sources to specific zones.

I have found that consistency is the key. I have a separate include file that lists all of the TP button numbers and that is what my TP must conform to. Otherwise, when I put in the code, it just doesn't work. While the panels are identical, customization is vital, if not for the client, out of necessity for the job; for example: Room A has 6 sources it can control / view, and Room B only has 4. What I do now (starting on this current job), is assign the source buttons the same variable text address as is their channel, and now I can move (using the BMF command), and hide (SHO command) source buttons on-the-fly dependent on what is needed. There's nothing more silly looking than buttons looking out of place and in my opinion, it's not necessary to have 5 different popups having all these different configurations based on the room. It got out of hand once when I had 18 panels (8400s, 5", 7", and 10" panels) with 50+ zones to control with all sorts of different configurations. I each popup had at least 5 different source configs so the popups were named "AV NAV 1", "AV NAV 2", etc. and I had to keep track of this in code. It was a disaster just because of the sheer size. I think I'd prefer one popup with the ability to move and remove buttons I need.

Anyway - sorry about the long (possibly useless) post. Good luck on the endeavor to become more organized; as Dave mentioned: it's a PITA to get it done, but once it is - it's a breeze there on out.

alexsquared

every time I feel like I have a good handle on things, I come across a post like this. There are many people on this forum who's knowledge is pretty astounding. You guys are unreal. Keep up the good work!

vining

I don't know if you're considering the 2 port approach or not but if not it's not a bad idea and worth considering. I personally don't but lately wish I did. I believe JJ does, JN (Cinetouch Guys) do, I'm not sure who else but it has tons of advantages so if you're going to take the plunge you might want to go all the way.

Who else is doing 2 port programming?

FYI, for those that don't know what the F' I'm talking about, all UI devices pretty much operate on the same TP port and you determine push function and feedback via code. The other port handles main page common features, etc.

Jorde_V

vining wrote: »

I don't know if you're considering the 2 port approach or not but if not it's not a bad idea and worth considering. I personally don't but lately wish I did. I believe JJ does, JN (Cinetouch Guys) do, I'm not sure who else but it has tons of advantages so if you're going to take the plunge you might want to go all the way.

Who else is doing 2 port programming?

FYI, for those that don't know what the F' I'm talking about, all UI devices pretty much operate on the same TP port and you determine push function and feedback via code. The other port handles main page common features, etc.

That's what I've been doing for a while now, I can tell you that it can save you a lot of time especially when you have multiple touchpanels. Apart from that you centralize issues using this approach and you know it'll be in all your touchpanels if you make 1 error. (Aside from messing up the tp4 design). So yeah that's my approach, can be a pain to set up correctly, but a timesaver once done.

jjames wrote: »

Yup - I'll "third" the approach Eric and Dave have laid out.

I was an array kind of guy, but now have mostly (95+ %) structures. I use a lot of pre-compiler directives that dictate which structures get called. For example:

#if_not_defined GENERAL_STRUCTURES
	// Define device usages here
	// Required Structures:
	//		- _zone
	//		- _source (this is done in EU_Structures.axi)
	
	// Components
	#define struct_tp
	#define struct_display
	#define struct_receiver
	
	// Sources
	#define struct_bluray // BDP
	#define struct_cd // CD
	#define struct_psx2 // iPod
	#define struct_aux // Piano
	#define struct_uverse // TV & Music
	#define struct_game // Game source
	
	#include 'EU_Structures, Rev 3'
#end_if

Inside EU_Structures, Rev 3 is:

#DEFINE GENERAL_STRUCTURES
define_constant
integer i_max_source = 30
#if_not_defined struct_tp 				#end_if
#if_not_defined struct_r4 				#end_if
#if_not_defined struct_kp 				#end_if
etc.,etc.,etc.
.....
DEFINE_TYPE

#if_defined struct_dvd_ir
	/******************************************************************************
	Standard DVD Player
	
	******************************************************************************/
	STRUCTURE _dvd_ir
	{
		dev 	device			;	// Holds the device (D:P:S) information
		
		i_compInput			;	// Component input on switcher
		i_hdmiInput			;	// Hdmi input on switcher
		i_vidInput			;	// Composite input on switcher
		i_audioInput			;	// Audio input on switcher
		integer	i_recInput	[04]	;	// Input on receiver - up to four receivers
		integer	i_displayInput	[10]	;	// Input on display - up to ten displays
	}
#end_if

In the main code, I have an init() function that again based on pre-compiler directives calls functions that fill in each structure's data. I set up how what the max number of TPs, max number of BDPs, max number of displays, etc. I also have a "Source" structure where the pop-up name is, whether it's a video source or an audio source only (this tells the display if it needs to turn on automatically or not - ex. satellite always turns on the TV - but these can be changed in the init() function as well.) I have allocated up to 40 different sources, but am at 30 at the current moment. You could even go as far as using #if_defined on the specific parts of the structure (which I'm starting to think about doing.) This way, you don't have an i_hdmiInput property if there is no HDMI switcher; or any receiver inputs if you don't have any receivers. This could (though I've not tried) cut down on the compile size.

Once all this information is filled in, the core code is nearly identical. My panel structure AND zone structures both have DEV vars in them - much like you are looking to do. It's a bit redundant in my opinion; the *only* time the panel's control device is different than the device in the zone it's controlling is when we are looking at what I call the "Whole House" page, which is a very quick glance at all of the sources available, and all of the rooms available (essentially a glorified matrix view of the system) and it allows the user to send and control specific sources to specific zones.

I have found that consistency is the key. I have a separate include file that lists all of the TP button numbers and that is what my TP must conform to. Otherwise, when I put in the code, it just doesn't work. While the panels are identical, customization is vital, if not for the client, out of necessity for the job; for example: Room A has 6 sources it can control / view, and Room B only has 4. What I do now (starting on this current job), is assign the source buttons the same variable text address as is their channel, and now I can move (using the BMF command), and hide (SHO command) source buttons on-the-fly dependent on what is needed. There's nothing more silly looking than buttons looking out of place and in my opinion, it's not necessary to have 5 different popups having all these different configurations based on the room. It got out of hand once when I had 18 panels (8400s, 5", 7", and 10" panels) with 50+ zones to control with all sorts of different configurations. I each popup had at least 5 different source configs so the popups were named "AV NAV 1", "AV NAV 2", etc. and I had to keep track of this in code. It was a disaster just because of the sheer size. I think I'd prefer one popup with the ability to move and remove buttons I need.

Anyway - sorry about the long (possibly useless) post. Good luck on the endeavor to become more organized; as Dave mentioned: it's a PITA to get it done, but once it is - it's a breeze there on out.

Not at all, I generally enjoy your long thorough explanations of how you're doing it. About the buttons thing, I was thinking of keeping that dynamic, so using the buttons numbers (say 6 sources on 1 page with possible expansion using an arrow).

101, 102, 103, 104, 105, 106 - change the icon and text according to what has to be loaded. Not using pop-ups at all. That way I can indefinitely expand it (theoretically) and have all the possible sources. So say if I have sources 1, 3, 4 and 6 available in a room I would allocate it to 101, 102, 103, 104 and leave out the last 2 buttons (105, 106) so that it still looks need from a UI/Design perspective. So using a check on the amount of sources and assign them accordingly.

I personally prefer structures as well as they allow me to hold any data_type.

DHawthorne wrote: »

My approach is similar to Eric's. The core of my standard program is pretty much the same thing for every job, with some minor difference that I could probably also modularize, but didn't feel worth the effort. The differences are in INCLUDEs that specify how many zones are in a job, how many controllers, and how many devices; they also have data structures in a series of arrays for each that spell out their capacity: for example a zone might have audio, and it might have a TV, or it might have both ... the TV speakers may carry the audio, or room speakers on a system amp, or it may have a receiver ... all of that is indicated in the data structure, and every room has its own entry. My main program just says, essentially, turn on a device in a room; the room handler looks up what's appropriate, turns on receivers, TVs, whatever is necessary and appropriate, and activates the device. It's completely modular, and adding a room, adding a controller, adding a device is just a matter of expanding the structure array to include the new object. The feedback routine for each controller (all of which have a similar structure array with the controller type and capacities) makes sure when a control element changes that the controller reflects it. All of my panel files are identical, and have buttons for every possible device; that same feedback routine hides buttons that are not available (no point having a BluRay button on a room with no TV) so that if you walk around with the control and tell it to control a different room, it will look different according to what is available there.

My first version of this program took me two solid weeks to create, and another to troubleshoot and iron out the kinks. I've been fine-tuning it as I run into different situations, but it's been a rock-solid approach so far.

Thanks for the info, I figured I'd start out small. But considering I've been using this system for a few projects now (a program as you go kind of approach, so it's been changed so much without a real set direction that it's not very usable or easy to expand or subtract stuff)

My designs are as identical as possible (obvious limitations left out (R4) or in case of bigger panels 12"+ a different approach).

The overlap is still great though.

ericmedley wrote: »

The process involves essentially object-ising (is that a word???) everything. I have done this myself on my systems. My designers were driving me batty with all the changes that occur every time a new whiz-bang thing came down the pipe.

examples:

My touch panels always have basically one page with a navigation bar/buttons. I call these buttons 'modes' They might be TV,House Music,HVAC,Ligthing, Security, etc... The buttonss themselves are blank and are filled in by the program from a big data array that holds all the values for these buttons and what kind of button they are going to be. This system also works with the smaller panels as you can scroll up and down the list of modes. So, there are typically 4-6 mode buttons on a panel. How the scroll behaves is also determined in the data table.

There's a big data table that manages the popups as well, which should be up, which go away, what they do. So, for example I have a standard Cablevision page. what box it controls is determined by the TV choice which is controlled by the mode section. Which audio zones are available on a given touch panle, which audio sources, what controls are available are, again controlled by the modes section.

TV control is done in a similar way. i don't have a section for Den TV, Living TV, etc.. They're just TVs and they have a numeric ID. The possibility to control any TV is there for any touch panel, but I limit it to whatever is considered local. (This also works with Man Caves as well - multiple TVs in one room)

I wrote a big TV control section on the same principle. I know when I select a TV source I mean to do the same thing each time: If TV power off, turn on. If TV not on source, get it there, If sound processor not on, turn on. If not on source, get it there. I also allow for 2 more aux source routers in the TVs because my designers seem to find the craziest ways to need to get some source where it's going.

Similarly, within the TV routine is a big section on just how the TV is controlled, IR and its channels, RS232 and it's commands, IP and its commands, AMX module and it's commands. You simply populate the data table and the correct flags for what kind of control is used.

Once you go through the heartache of getting all this setup, making a system is pretty much plug-n-play. I haven't written any actual code for TVs in quite some time.

That is how I approached it.

Thanks for the info. I want to incorporate enough to keep make my systems ready for virtually anything. Much like you've made yours. As plug-n-pray as possible.

Frankly I'm quite amazed by the replies, I expected a few others to have thought of it and incorporated it, but not at this level. Thanks for the info guys, I'm going to work it out with my colleague this friday. I'll update this thread with my findings afterwards and

@alex

You should start worrying when you don't.