Closed mkurajica closed 3 years ago
The module is working according to the published specifications.
What test app are you using?
PJLINK 0
is a response sent only by the projector which informs the remote app that there is no security.
All commands to the projector start with %.
This sounds like a non-standard Optoma implementation.
Test app is from pjlink site class 1.
Yes i can see that PJLINK 0
is being sent from projector . Also my command does not work with test app from pjlink but works with the projector so its not module's fault....
Have you tried setting a password (both companion and the projector)?
There is no option to set the pjlink password on the projector, otherwise it has no other passwords enabled.
Test apps offer the option with or without authentication tests.
Here are two commands from test apps, first with authentication and second without.
Remote app: `[2021.03.30 20:04:18.605] Connected!!! [2021.03.30 20:04:18.627] RECV:PJLINK 1 699bb32a
[2021.03.30 20:04:18.643] SEND:099ba3b188165e08fd67ef1366edd269%1POWR 1
[2021.03.30 20:04:18.643] RECV:%1POWR=OK
[2021.03.30 20:04:18.643] Closed!!!(Disconnect) [2021.03.30 20:06:11.106] Connected!!! [2021.03.30 20:06:11.106] RECV:PJLINK 0
[2021.03.30 20:06:11.122] SEND:%1POWR 0
[2021.03.30 20:06:11.122] RECV:%1POWR=OK
[2021.03.30 20:06:11.122] Closed!!!(Disconnect)`
Projector app: [2021.03.30 20:04:18.605] Connected [2021.03.30 20:04:18.627] SEND:PJLINK 1 699bb32a
[2021.03.30 20:04:18.643] RECV:099ba3b188165e08fd67ef1366edd269%1POWR 1
[2021.03.30 20:04:18.643] SEND:%1POWR=OK
[2021.03.30 20:04:28.664] Client Disconnect [2021.03.30 20:06:11.106] Connected [2021.03.30 20:06:11.106] SEND:PJLINK 0
[2021.03.30 20:06:11.122] RECV:%1POWR 0
[2021.03.30 20:06:11.122] SEND:%1POWR=OK
[2021.03.30 20:06:11.122] Client Disconnect
so something is being exchanged before the %
The authorization token is generated from the password plus the 4 bytes sent by the projector. It may not be labeled as a PJLink password. What password/id/authentication code does the app use?
if the projector is not sending the PJLINK 0 would that be a problem ?
Password field is empty in the app. I will test tomorrow , it has to be the projector not behaving to specs. Projector has only one password and that is the menu access password.
another thing , I can send PJLINK 0 and then in the next TCP command %1POWR 1 and it also works.
The remote should never need to send 'PJLINK' so that is non-standard. When connected, the projector should send either PJLINK 0 (no authentication) or PJLINK 1 aabbccdd (authentication with hash). If authentication (PJLINK 1) is needed, the module sends a token + query to the projector (is power on?) and either gets a response or an error.
That menu password may also be the PJLINK code.
You are definitely right , there is something wrong with their implementation . Will check few more things tomorow and see whats the problem. Thanks.
We tested the module with the projector simulator apps, too. I am curious what the issue is with that projector. Tomorrow, then.
hi,
after more testing ......me sending PJLINK 0 before command had nothing to do with this , it works with generic TCP when sending proper commands (%1POWR 1).
I noticed some more differences between test apps and pjlink module
test app with projector : 1) creates new TCP connection for every command sent from interface 2) projector sends PJLINK 0 3) command get's send from the app (%1POWER 1) 4) projector responds (%1POWER=1) 5) TCP connection gets terminated
and everything works.
module with : 1) when you create the instance of pjlink module in companion and specify the IP of the projector , TCP connection gets created 2) projector sends PJLINK 0 3) for now nothing until you create button with PJlink command 4) PJlink command button created and pressed and nothing happens on network...
Projector does not send PJLINK 0 ever again because the connection is not terminated ever again until closing of companion.
Using generic TCP to send commands works because i can send the command without receiving PJLINK 0 before, does module require to receive the PJLINK 0 before sending the command ? Test app handles the thing differently because of the TCP connection termination every time so it gets the PJLINK 0 , and projector works with the testbed and OPTOMA probably didn't notice this .
Should the projector send PJLINK 0 everytime when remote app requests TCP packet transfer or on creation of connection ?
The module only expects PJLINK message once per tcp connection. If it does not send messages when you press the keys, I would think that something is wrong with the initial message from the projector. Maybe it is with line feed? Does it only send lf or cr and lf?
It sends 0D
Tried the module with a different projector , Eiki WUL100 , everything works as expected.
But totally different behaviour from projector. Eiki sends KEEP ALIVE TCP messages / or restarts connections every few sec with PJLINK 0 being sent once per connection.
Really stuck with this .... after receiving ACK for PJLINK 0 message from projector , no TCP traffic from PC. Also disable instance in companion works in terminating TCP connection , but enable does not make new connection it gets stuck at connecting .....
The protocol specifies connections are only good for 4-5 seconds, which requires a close/reconnect sequence. That is what you are seeing with the Eiki (which is normal operation). Somehow the response from the Optoma is not being recognized, so the command/ack sequence stalls.
So inproper implementation on projector prevents this module from working Is it posible to modify the module to work more like test app with tcp connections being made once the commands are being sent and not when the instance is created . Doubt that optoma will fix this considerng that projector passes the test app.
The module also passes the test app. I'm looking over the module now to see what is happening. What OS are you using for Companion?
Win 10, 64 bit PRO on Lenovo Thinkpad , with firewall off if you need wireshark captures i can upload them .
That would help. I'd like to look over the initial exchange to see what is stalling.
The module has been updated before for non-standard implementations. While the protocol specifically states case-insensitive commands shall be accepted (upper or lower case), the Hitachi projectors only respond to upper case.
Wireshark captures : https://we.tl/t-oHaXs1pLvN
IPs 192.168.0.100 - OPTOMA 192.168.0.102 - PC 192.168.103 - EIKI
OK. The module has a protocol sequence problem if there is no password required. There should be a fix posted soon.
Hi,
I tried sending controls to Optoma ZU1050 but didn't work. Then I tested the thing with a PJlink test app and the controls where working so there must be something wrong with the PJlink implementation on optoma ?
Test app can also send controls to projector and controls from PJLink app went ok.
I checked TCP traffic with wireshark and there is small difference in commands , test app sends PJLINK 0 ,than %1POWR 1 and this instance sends just %1POWR 1 and for some reason this does not work for the Optoma.
For now I configured standard TCP/UDP instance targeting projectors IP:4352(port) with the commands starting with PJLINK 0 and everything works.
Also just configuring the PJ link instance in bitfocus prevented any controls from PJ link test app from reaching the projector at the same time, could this could also block any other app from remote controlling the projector at same time?
Am I doing something wrong with this module ,or Optoma didn't implement the thing , or the module needs a fix ?
Thanks,