M2M System design in a large project Question
troberts
Member
After composing this post, I think I can sum up my question as follows: When all UIs are connected to system 1 and you send out text and feedback to a UI from System 2, does it somehow still go through system 1, or is System 1 not taxed at all due to sending text and fb this way? Feel free to read my original question below, but an answer to this would answer my question....unless there are other ideas out there on how to design a large M2M system.
My question, is should I stick with my typical design or try my proposed design or something else. My biggest priority is system reliability and speed. To clarify what I mean by large project (48 audio zones, 17 video zones, 50 UIs, 62 Lutron Phantom KPs, 22 HVAC zones, 47 PTZ IP cameras, Gates, Doors, 100+ zones of HAI security, 3 Pentair pool, Shades, Weather, Traffic, email when a device or system goes offline, I think that is it)
- My typical system design consists of multiple processors where all UIs connect to system 1. On system 1, I track almost everything, per UI (what page each panel is on, what zone are selected for all subsystem on each panel, etc). System 1 also sets all my default zone on all panels for all subsystem. System 1 also has the majority of the programming for multi room audio and multi room video. I define my UI ports based on system number....so all UI functions using port 1 are for system 1. All UI functions using port 2 are for System 2, etc.
System 1 has all systems and UI ports defined on it
System 2 might be running a KScape module, plus tracks what page each UI is on. System 2 has UI port 2 and UI port 1 defined on it
System 3 might be running some HVAC and camera PTZ code, plus tracks what page and zone each UI is on. System 3 has UI port 3 and UI port 1 defined on it
Remaining systems are running other subsystems (Lights, Pool, etc), plus tracks what page and zone each UI is on. They also have UI Port 1 and its own corresponding UI port defined.
All systems in "route mode direct", systems 2-x in UI List of System 1
- My proposed design would basically be all UIs connect to System 1. Same as before... I define my UI ports based on system number....so all UI functions using port 1 are for system 1. All UI functions using port 2 are for System 2, etc. System 1 has all systems and UI ports defined on it. I am assuming this would allow System 1 to only have the task of button routing to the correct master...????
System 2 would do all that System 1 was doing in "typical system design"
Remaining system would be same as "typical system design"
My question, is should I stick with my typical design or try my proposed design or something else. My biggest priority is system reliability and speed. To clarify what I mean by large project (48 audio zones, 17 video zones, 50 UIs, 62 Lutron Phantom KPs, 22 HVAC zones, 47 PTZ IP cameras, Gates, Doors, 100+ zones of HAI security, 3 Pentair pool, Shades, Weather, Traffic, email when a device or system goes offline, I think that is it)
- My typical system design consists of multiple processors where all UIs connect to system 1. On system 1, I track almost everything, per UI (what page each panel is on, what zone are selected for all subsystem on each panel, etc). System 1 also sets all my default zone on all panels for all subsystem. System 1 also has the majority of the programming for multi room audio and multi room video. I define my UI ports based on system number....so all UI functions using port 1 are for system 1. All UI functions using port 2 are for System 2, etc.
System 1 has all systems and UI ports defined on it
System 2 might be running a KScape module, plus tracks what page each UI is on. System 2 has UI port 2 and UI port 1 defined on it
System 3 might be running some HVAC and camera PTZ code, plus tracks what page and zone each UI is on. System 3 has UI port 3 and UI port 1 defined on it
Remaining systems are running other subsystems (Lights, Pool, etc), plus tracks what page and zone each UI is on. They also have UI Port 1 and its own corresponding UI port defined.
All systems in "route mode direct", systems 2-x in UI List of System 1
- My proposed design would basically be all UIs connect to System 1. Same as before... I define my UI ports based on system number....so all UI functions using port 1 are for system 1. All UI functions using port 2 are for System 2, etc. System 1 has all systems and UI ports defined on it. I am assuming this would allow System 1 to only have the task of button routing to the correct master...????
System 2 would do all that System 1 was doing in "typical system design"
Remaining system would be same as "typical system design"
Comments
But to the question itself, I can say that at one point we were experimenting with memory load balancing across masters, and had half of the 50 panels talking to system 2 for reporting pushes, but being updated exclusively by system 1 with all the other panels. This itself posed no extra traffic or loading. While this is the reverse of what you are suggesting, I think it may be informative.
We did abandon the split design when we developed more memory efficient ways to accept input from very large numbers of panels, but it worked.
Thanks John, You might be right. I have also done systems comparable to this size on a single master, but no PTZ IP cameras, not nearly as many UIs, and no KScape. What kind of interpreter and buffer values do you see in your systems like this? Also I know you guys do some cool UI work, do you use one TP4 file per UI model? Can you fully control any room from any full size UI (not handheld remote), including TVs? Sometime I think on systems I've done "load balancing" on, they seem to act slower, than a single master system...what do you think?
I am, right now anyway, thinking I will keep with "My typical system design" unless anyone can chime in and tell me I have a very poor approach and tell me of a better way. It is just easier to program it separately now than realizing the processor is out of juice later, then reprogramming it.
The KSCAPE will be a challenge for you as their modules aren't really friendly to simultaneous use on many panels. You will find it no fun to roll your own complete 2-way KSCAPE interface for the purpose of distributed feedback... but frankly, one-way control of KSCAPE systems is quite satifactory. The value of the now-playing info and cover art is actually small. And since the music capability of the KSCAPE is crippled by the fact that you can't actually search by song name, most of our customers use something else for music, and that's the only area where the two-way really matters on KSCAPE. Also the NOW PLAYING info for MUSIC differs from MOVIES, complicating any display even more.
We see buffers staying at 0 most of the time, if you see them climbing and staying up, you will also see system hangs while the buffers are up. If you have extensive refreshing of, say, multiple thermostats on many panels, you may find the system gets busy in that loop and users find panels are unresponsive during the update. Fix this by making the update or loop "porous" so that other high level events get serviced along the way, instead of stacking up waiting their turn. You can do this by waits or other means that allow the thread to revisit the main loop instead of staying in your lengthy subroutine until finished.
We have a single TP design, but it is tuned to each panel model, such as extra pages for video overlays on CV models, differences in battery level display (the codes work differently for different wireless devices), larger icons on smaller panels, etc. But the same project(s) are used in every job, without modification for location, they are dynamically rendered by the needs of the room/source/user at the moment. Data defines what is connected where, and the same UI works completely, everywhere, even if the devices work differently (as in the same panel button operates the aspect ratio of the display actually in use even though it results in different commands for RS232, IPO, and IR controlled TV's at different times).
All that is to say, the smarter the central process is, the less overhead in managing a large system. Yes, we've seen multi-master systems that moved slower than glaciers, because all the processors were all doing it all, and telling each other about it.... marginally better than completely separate systems.
The worst system I saw used 7 masters for 6 rooms with TV's plus the "multiroom" for house audio. None of the systems communicated at all. Each had its own dedicated panel, and each operated differently. So no one used any of it, and they blamed AMX as a bad brand, and replaced it all with Crestr0n rather than trust another design from another AMX dealer.
Yikes, that's awful.
This implies that you presume handheld remotes would of course not fully control any room. They can, if you design it right.
Even a simple IR remote (we use a credit-card sized thing we call a "MicroMote") can completely control every room using the same commands everywhere, if your central controller interprets both the codes AND THE CONTEXT. A TV-ON coming from a particular pickup tells you what equipment needs to come on. "PLAY" needs to cause whatever source is in use in the area where it came in from to go into PLAY... no need to make the remote send a specific device PLAY command to work it out.
Yeah, worse yet, the "multiroom" used 8 separate sat receivers, one for every room serviced... no matrix switch, no sharing across rooms, lots of hardware, and any single sat failure meant that room would have to be silent....
HVAC I only update when the panel being used is on the HVAC page, so there should not be a blast of traffic at any given point. But I hear what you are saying.
That is sad and too often the case. It all comes down to programming.
I would not expect AMX to address the "limitation" of 500 sub pages at any time. It's tied up in the authoring tool, the panel formware, and the preview app. A lot of work to change it, and the need for a change isn't clear... there being many ways to design a panel within the original intent of the structures.
My complaint with sub-pages is that you cannot programatically tell the panel which sub page to show. If you have a long, scrolling sub-page set, there are times when it would be nice to jump to a specific sub-page.
Check out ^SSH-
Lets you do just that .....
Simon
The concession I've made to processor load distribution is that I will allow for a remote master to run modules to control a device local to it, then use my "main" master to tell it what to do, ether via a send command, or do_push, as dictated by the module in question.
Most programming will be on system 1 with no modules, Modules to be on other processors. Only exception will be, Pool, HVAC, and cameras (no modules) on system 3. Reason being, these are most often changed (at this job) and the most often to have issues (hardware, corrupt data, surges). Another reason is, if I need to load system 3, I am not interrupting the end users.
SYSTEM 1 (HE 4100) GENERAL UI, MRA, ZONE CTRL, MRV, LIGHTS, SECURITY, DOORS/GATES
SYSTEM 2 (HE ENOVA) KSCAPE, AUTONOMICS
SYSTEM 3 (HE 3100) EMAILER, CAMERAS, POOL, HVAC
SYSTEM 4 (OFFICE 3100) IPOD, ADA tuner
SYSTEM 5 (FAMILY 3100) no code
SYSTEM 6 (MBED 3100) no code
SYSTEM 7 (GYM 3100) no code
SYSTEM 8 (2ND FLR BED NI900) no code
SYSTEM 9 (3RD FLR BED NI900) no code
SYSTEM10 (Mill NI3100) no code
That's how I generally do it as well