OmniPro II solution for greater than 176 hardwired zones?

[jcd]

Hi All,
 
As the title says, I'm trying to find a solution for a system with greater than 176 hardwired zones (the OPII limit). Is there such a thing, or am I now in the Crestron territory?
 
I use a lot of hardwired IR sensors for automation (often 4-5 per room to have very granular control over timing triggers, direction of travel, etc.) and find there is nothing like copper for reliability - although I confess that I usually get stuck with the "CPU" processing capability of the OPII struggling to act fast enough with all of the inputs and event logic.
 
One solution I have considered is to run multiple OPII controllers in parallel, but then I haven't really devoted the time to think through the overhead required to keep the two in sync (passing IO back and forth to sync flags, how to manage Z-wave without collisions, etc.)
 
Does anyone have experience they might share with a really complex system based on OPII (or multiple OPII's), or perhaps alternate systems that do not require six-figure budgets?
 
Many thanks,
Jcd

 

[StarTrekDoors]

You could use an RS485 demux/mux encoder, but problem is that you would need a seriously large number of automation programming to action on specific messages and the OP is just too under-powered to handle that large a number of inputs/logic.  Plus the limitation on the number of programming lines is a hindrance for small installations, let alone a very large one with complex logic.
 
However; that doesn't mean the multiple OPII scenario won't work.  Since you did not provide much detail about what you are trying to do, I can only suggest something vague at this point, but it would be possible to setup multiple (zoned) OPII's could be used to drive relay outputs or upstream messages which could be used to run a master OPII using the same type of multiplexing logic.
 
The advantage to multiple units is you could offload processing to "zoned" OPII's, rolled up to the master.   By "zoned", I mean an OPII handling an area, a bank of zones, or limited number of zones.  This type of logic would need to be planned based on some segregation plan to maximize efficiency and allow you to identify the automation routines that are common to each OPII bank; provided your use of hardwired zones has some logic and can be split into groups. Also might be a very good cost value to functionality ratio vs. a truly industrial automation system, especially given the OPII is more slanted toward security than automation.

 

[jcd]

Thanks for sharing your thoughts StarTrekDoors! I will do some more discovery on this path and I appreciate your help in validating the notion...
 
I have heavy "equipment" and "operations" both indoors and out, so that might be a starting place as I think about how I could split this up. One OPII could handle all of the exterior sensors and logic; another OPII could handle the interior. Just having this simple split would free up significant expansion space on each "subsystem", respectively - and the logic drivers of "stuff that happens outside" tends to be discrete from "stuff that happens inside" so this could be a great solution!
 
I'd still need some overhead to pass actions from outside to inside - for example, if an exterior sensor triggers, I'd need to pass that somehow to the "inside OPII" to trigger cameras on the touchscreens, turn on lights, switch audio for announcements, etc. So while the functional split is "easy", I'll have to give some thought on how to share statuses of inputs, flags, timers, etc. between the two systems, and have this communication be fast enough to not negate the intended reason for having hardwired inputs in the first place. I wonder if there's a way I could simple have a variable that one system loads and the other decodes?
 
For example:the exterior OPII loads a variable from 0-255 for a mapped series of trigger events, and the inside OPII reads that variable and actions accordingly:
outside OPII: if front driveway sensor is NOT READY, load "transfer variable" with 3...
outside OPII: if forest sensor is NOT READY, load "transfer variable" with 16...
inside OPII: if "transfer variable" = 3, then do XYZ action (and presumably, afterwards reset "transfer variable" to a resting state of 0 until the next change.)
...and so forth.
 
I'm not an electronics SME though and I have basically only used digital inputs on the OPII, with the exception of analog via the OmniPro TSTATs and external temp sensors; is there an efficient way to create/manipulate a variable such as I described where a single IO could be configured as an analog variable and loaded/read with a precise range of preset values?
 
I wish the JDS StarGate and the HAI OmniProII got married and had a baby - THAT system would have rocked!
 
Cheers,
Jcd

 

[BobS0327]

Have you considered using Leviton/Hai's SDK to establish a communications link between the the two independent OPII's?  This would be a piece of cake if you have someone with decent programming skills on your team.  There is also a third party open source project name JOmniLink which is written in Java which will also fit your requirements to interface two OPII's.
 
Your customized software would be middleware (bridge) between the two systems, passing/receiving data to/from both systems.