Qlab 4 Net cues - no HTTP/TCP?

Jay Ashworth

Well-Known Member
It occurred to me last night while I was manually shuttering and unshuttering my Panasonic laser projector that hey! this is a web page... and after tearing it apart I got to the URL parameters that shutter and unshutter it... but am I right in thinking Qlab 4 has no way to send an HTTP/TCP packet, even if it ignores the answer? I see OSC, UDP and QLab internal protocols, but not TCP...

Is that, perhaps, New In 5.0?
 
A lot of projectors support OSC type protocols
 
HTTP requests work best as script cues that run some AppleScript. Little goofy, and I wish there was better documentation for it, but it's very reliable once it's going.
 
PJLink is pretty ubiquitous for projector control, but the last time I tried to use it in QLab I found it to be very slow. 90% shure that was an issue with the projector rather than QLab, though. I ended up getting a cheap UDP to RS232 converter off Amazon to make everything play better.

In my main space I have a Panasonic projector where I did the webpage trick to remotely control it. Figuring out exactly what I needed to send was a little tricky, but the script cues are super simple:

Close Shutter:
do shell script "curl http://[email protected]/act.htm?SET=shut_on > /dev/null 2> /dev/null"

Open Shutter:
do shell script "curl http://[email protected]/act.htm?SET=shut_off > /dev/null 2> /dev/null"
 
PJLink is pretty ubiquitous for projector control, but the last time I tried to use it in QLab I found it to be very slow. 90% shure that was an issue with the projector rather than QLab, though. I ended up getting a cheap UDP to RS232 converter off Amazon to make everything play better.

In my main space I have a Panasonic projector where I did the webpage trick to remotely control it. Figuring out exactly what I needed to send was a little tricky, but the script cues are super simple:

Close Shutter:
do shell script "curl http://[email protected]/act.htm?SET=shut_on > /dev/null 2> /dev/null"

Open Shutter:
do shell script "curl http://[email protected]/act.htm?SET=shut_off > /dev/null 2> /dev/null"
Slightly different syntax on the URL, but this will probably do it, yes; thanks.

And I even have a curl(1) installed already.

Ends up like this:

tell application id "com.figure53.QLab.4" to tell front workspace
do shell script "curl http://dispadmin:\@[email protected]/cgi-bin/proj_ctl.cgi?key=shutter_on > /dev/null 2> /dev/null"
end tell

Do I actually need the tell wrapper?
 
Tried with and without, tried escaping that pesky @-sign in the default Panasonic password with one and two backslashes (zero was a syntax error), ended up here:

do shell script "curl http://dispadmin:\\@[email protected]/cgi-bin/proj_ctl.cgi?key=shutter_on > /dev/null 2> /dev/null"

but it still exits with non-zero status, and doesn't affect it. Hmmm...
 
I'm doing my first extensive projections for elf.. have a used large venue Epson 6500 lumen.. but it's web interface is https, which the modern browsers interpret it's cert as "dangerous"
So I have to punch through the warning on IE to get there. I know there should be a way to set security to bypass, but firefox won't even let me bypass. Epson got smart.. my ultra short throw for captioning is newer.. and it's http.
 
This was quite a while ago, but I'm pretty sure I ended up using Wireshark to catch exactly what gets sent when clicking the button in the web interface. Might be worth doing that on the way out from the Mac as well to see if the problem is between that and the projector, or internal.

...and yeah, for me it's usually less about easy and more about being repeatable. Plus this was (at most) a couple hours of work several years ago that will continue to be useful as long as we own the projector. The other one was a one-off, but had a lot of really close timing that just wouldn't have worked using the remote to control the shutter.

Okay, sometimes I'm also just stubborn and refuse to let the problem get the best of me...
 
This was quite a while ago, but I'm pretty sure I ended up using Wireshark to catch exactly what gets sent when clicking the button in the web interface. Might be worth doing that on the way out from the Mac as well to see if the problem is between that and the projector, or internal.

...and yeah, for me it's usually less about easy and more about being repeatable. Plus this was (at most) a couple hours of work several years ago that will continue to be useful as long as we own the projector. The other one was a one-off, but had a lot of really close timing that just wouldn't have worked using the remote to control the shutter.

Okay, sometimes I'm also just stubborn and refuse to let the problem get the best of me...
Well, I dug down with the HTTP inspector and got the URL string, I just can't get it to take in the curl command.
 
I'm doing my first extensive projections for elf.. have a used large venue Epson 6500 lumen.. but it's web interface is https, which the modern browsers interpret it's cert as "dangerous"
So I have to punch through the warning on IE to get there. I know there should be a way to set security to bypass, but firefox won't even let me bypass. Epson got smart.. my ultra short throw for captioning is newer.. and it's http.
You need to copy the self-signed cert to some magical place on your PC and approve it.

I think that's Keychain Manager on a mac and Credential Manager on Win 10.
 
I've had luck using Bitfocus' Companion as a gateway for this sort of thing. It can react to OSC commands to trigger buttons and can output all sorts of HTTP requests. You don't need a Streamdeck to run it and it's open source. There also appears to be an existing module for Panasonic projectors - https://github.com/bitfocus/companion-module-panasonic-projector
 

Users who are viewing this thread

Back