Controlling Panasonic Projectors through Web Address in Watchout

[QuinLoft]

So this is a weird request. I'm basically trying to control Panasonic shutter cues through Watchout, but I'm actively avoiding trying to using the PJ Link command. For the inevitable question why, this is because of the stupid port closing issue that happens after 30 seconds. I know I can spam the command multiple times, but I really don't want to. I need to work when it's supposed to, not on the 4th try. The web command always works, so I'm trying to give that a shot. Anyway, in the past I've sent URL commands successfully to Panasonic PTZ cameras, so I think this would be the same. What I'm trying to send is:

 

GET /cgi-bin/proj_ctl.cgi?key=shutter_on&lang=e&osd=on$0D

 

I've sent this on ports 1024 and 4352. Unfortunately, no luck with either. That link works though in a browser once I add the IP before it. I think it's failing because I'm missing authentication for the login. However, this I don't know how to send in Watchout. My login/password is set to "admin1" with no password. Has anyone had any success with this before?

[matkeane]

Hi,

 

In the past, my solution to the port closing issue was to create a looped task in Watchout which fired a blank - literally "$0D" - command to the projector every 10 seconds to avoid the connection timing out. My real commands for the shutter could then be sent once when needed and worked reliably and on-cue.

[RBeddig]

Do you add the port number to the ip address when you control it through your browser?? If not, the browser uses port 80.

 

Very often those web servers use standard ports and in this case it would be port 80 for html.

[Mike Fahl]

I doubt you'll be able to simulate a browser request using the network output of WATCHOUT, especially one that requires some form of authentication.  If it's possible to turn off the authentication, it may work. Note, however, that you need to send a *complete* GET request, which is a multi-line thing that looks something like this:

 

 

GET /cgi-bin/proj_ctl.cgi?key=shutter_on&lang=e&osd=on$0D

cache-control: no-cache

user-agent: PostmanRuntime/7.1.1

accept: */*

host: 123.123.123.123:80

 

 

Last ine specifies the IP address of the projector. Each line terminated y a carriage return. There need to be TWO carriage returns at the end of the whole shebang. Using smething like wireshark to snoop the line while sending a working command may hwlp getting things right form WATCHOUT.

 

Even though WATCHOUT's network port disconnects after some time of inactivity, it automatically re-establishes the communication once a new command is sent. However, PJLink may be a bit tricky to deal with due to its initial handshake. Assuming you can make it connect reliably once, your best bet may be to have an auxiliary timeline then sending some harmless command to the projector every 20 seconds or so to keep the port open, and then your command should work without the need to re-open the port.

 

I also believe WATCHNET now has PJLink support, so throwing that into the mix could be an option. Although WATCHNET requires a separate license key and adds some complexity to the system.

 

Mike

[Mike Fahl]

Woops, seems I have a mistake above. You may be able to get away with sending just this:

 

GET /cgi-bin/proj_ctl.cgi?key=shutter_on&lang=e&osd=on$0D$0A$0D$0A

 

Note there are two end-of lines at the end of that (last) line. The HTTP protocol specifies header lines should be terminated by CR/LF pairs, and not just $0D as in my example above. For the remaining lines in my example above, my guess is that the projector won't really need any of them. But if you do include them, each line should be terminated by $0D$0A, with an extra $0D$0A at the very end of the whole shebang. You write the whole thing as a single line in WATCHOUT – my example above is split across multiple lines just to make it more readable.

 

Hope this helps!

[mfbergmann]

I have also has some success doing this in a bit of a roundabout way. Using an Image Proxy with the URL of the request as the "media" sends the request, which is enough for the projector to respond. However, it does seem to pre-cache, so I put the proxy into an aux timeline, and triggered it when needed. You will get an error (as there is no actual image to load) but that was fine for us. 

 

Also since it's using a request, it doesn't run into the issue of the TCP port closes.