Projection Screen control with Room Controls using Global Cache IP2CC

[Matt_Nolley]

I'm struggling to work out how to reasonably control a Dalite projection screen using Room Controls and a Global Cache IP2CC.  The JSON examples for the IP2CC use a "position" key-value pair not documented elsewhere, and, according to the only provided example that makes even a vague attempt to explain it, then uses an "automatically generated 'power' method" to provide control.  That's also not documented anywhere I can find.

The example code produces an "On" and an "Off" button for each declared contact closure "port".  That is far from ideal, as the projection screen's movements are triggered by instantaneous contact and are stopped automatically by a limit switch.  Further, when declared at the "port" level, as they are in the examples, these controls can not be hidden.

We would very much like to be able to create our own methods for these operations, so that they can be individually hidden, controlled discretely, and triggered as part of a scene.  Any guidance would be appreciated.

[bstrelko]

We've come to expect this from Zoom documentation, especially when it comes to rooms/AV.

Upon a quick review of the IP2CC sample JSON and iTach's API doc, the 'position' value corresponds to the relay number from left-to-right when looking at the unit (let's say your projector is plugged into the leftmost PHX terminal - in this case, its position is '1').

Please clarify if I'm misunderstanding, but you're looking for a momentary contact vs a latched one and the sample JSON file appears to latch. I am not familiar with the IP2CC (would rather use something more robust like  Crestron/Q-SYS/Extron/AMX to issue relay commands), but you may be able to trigger sequential commands to achieve the desired result.

It does appear that the flag for invisibility is missing in any documentation when using the IP2CC, nor is it available in the Control Concepts generator (https://controlconcepts.net/zoom/). This might be another case for an IP-controlled relay solution vs. using the IP2CC.

[Matt_Nolley]

Thanks for your response.  Yes, I'm looking for a momentary contact.  The term had fled my brain after beating my head against this issue for too long.

More than that, though, I'd like to be able to construct my own methods for the IP2CC, or have a better understanding of the construction of the automatically-generated method Room Controls apparently provides.  That would allow me to offer my own custom controls via scene declarations, in which I could either try to generate momentary behavior, or at least turn off "Up" before powering on "Down" and vice-versa.  Something like either:

"scenes": [
    {
      "id": "proj_screen_down",
      "name": "Screen Down",
      "icon": "icon_down",
      "commands": [
        "proj_screen.down.on",
        "proj_screen.down.off"
      ]
    },
    {
      "id": "proj_screen_up",
      "name": "Screen Up",
      "icon": "icon_up",
      "commands": [
        "proj_screen.up.on",
        "proj_screen.up.off"
      ]
    }
  ]

or

"scenes": [
    {
      "id": "proj_screen_down",
      "name": "Screen Down",
      "icon": "icon_down",
      "commands": [
        "proj_screen.down.on",
        "proj_screen.up.off"
      ]
    },
    {
      "id": "proj_screen_up",
      "name": "Screen Up",
      "icon": "icon_up",
      "commands": [
        "proj_screen.up.on",
        "proj_screen.down.off"
      ]
    }
  ]

[Matt_Nolley]

Actually, @bstrelko, your mention of the iTach API has nudged me in what I hope is the right direction: instead of trying to use the Zoom-provided schema for the IP2CC, I should be able to address it as a "GenericNetworkAdapter", and just send it the appropriate API commands.  That would solve the "methods" and "scenes" parts of my goal. Then, it would just be a matter of generating momentary behavior.

[bstrelko]

Great idea! This makes the most sense.