TCP Plugin

[Crunchie]

James,

not even sure I know how to do that. I did however successfully link my button press and button release events since they are being reported to command VC.on and VC.standby respectively (by dragging the events from the log to the command editor per Kalle's excellent YouTube Tutorial on working with events). So on the RF remote I can now push and hold the button, VC.on commands VOX to green, and it stays green until i release the button.

I will look at pasting code per your request later when I have more time on my hands. I am currently wrapped up in another project  

Thanks,

C.

[Crunchie]

As it turns out this is not working the way I have it currently configured. It seems that any feed back that comes from processor is perceived as the same event, although I can see in the pop up when i roll my mouse over the events that they are unique. The Event Icon they come under however is simply labelled the same name as the group of commands that I have created. What it boils down to is that even though i have dragged the event that I want to correspond to VC.on and the other event that i want to correspond to VC.off to the right locations to fire the approximate actions, any other event that comes in from my lighting processor kicks out an event that is labelled per my group of commands (even though underneath it is different feedback).

I think one quick work around would be to create a different command set just for the on and another just for the off, but it feels like the wrong way to go.

[jitterjames]

Yes.  I think it is definitely the wrong way to go.

This is the expected behaviour of the TCP plugin with a client.  The event name will always be just the name of the client.

You need to create a single command that can process the events from your unit by analyzing the payload since the event name will always be the same.

[Crunchie]

Good morning,


I have a question that relates to the TCP plugin with respect to clients; can VOX connect to more than one TCP client at a time and keep the sessions concurrently open?

Thanks,

C.

[jitterjames]

Yes.  You create a new client using the Tcp.Client.Connect action.  Use this multiple times with different client names to create multiple clients.

Note that the server you are connecting to will sometimes only allow a limited number of clients.

[Crunchie]

Thanks JJ,

So if I have more than two or three different processors I am connecting to I can run concurrent connections from a single instance of VOX, which would constitute as one client connection per processor. I have a limitation that I am aware of on my lighting processor that it cannot have more than 4 concurrent users sessions simultaneaously and in no case more than one by the same user log in at the same time. ( IE if i was logging in by an android app and VOX at the same time they would be independent user log ins.)

Thanks,

C.

[jitterjames]

Yes, that sounds right.  Provided that by "processors" you mean some kind of TCP server (including devices that allow telnet connections) that VC can connect to.  I'm pretty sure that's what you meant, but I just wanted to be clear about it for posterity, since "processors" could mean something else that might confuse some users.

[Crunchie]

Yes, that is what I meant, some type of TCP server including those that allow telnet connections.

[Scitz0]

I have played around with this plugin alot the last couple of days.
Sending both single commands to iTach, Yamaha receiver and trying out tcp.client for feedback from the receiver.

It seems quite unstable to be honest. Sending for example TCP.Single.Write with @MAIN:MUTE=Off\x0D\x0A only works about one of five tries. If I just keep sending the command eventually the receiver will respond to the command.
The same goes for feedback calls with tcp.client. Tried sending @MAIN:VOL=?\x0D\x0A, I got a feedback event every time but most of the time its empty but now and again I receive the payload correctly.
Its just not reliable enough to be useful, at least communicating with my Yamaha A2010. PDF with API for receiver can be found here if interested, http://goo.gl/gJdQAC

For the tcp.client calls I have tried with different delays, after connection is made and before sending command, delay after command, no delay. Doesn't make a difference.
iRule does not have any problem speaking with the receiver, works flawlessly. I also tried telnet to the receiver and sending commands, works without any issues what so ever.

Really need to get this working so I can attenuate the receiver about -40db when voxcommando is activated to be able to send commands reliably.

Just now trying to put receiver in standby using TCP.Single.Write in command editor hitting the "play" button for the command after the fourth try it worked.
Not sure how to proceed, can I active some sort of debug to see where it goes wrong?
In history log everything seems fine, command is sent without any errors.

[jitterjames]

I use the tcp.client actions with my itach and it works 100% of the time.  I don't rely on the feedback though since itach basically just says "yeah I got your command and did it".   Although I don't use the plugin to control my Onkyo receiver normally because I use the Onkyo plugin, when I did do some tests they worked reliably.  I was also able to get feedback from the onkyo but is has been a while since I tested this.  Maybe I should try again since the plugin has undergone a few minor updates since then.

I recommend using tcp.client and not tcp.single. I generally leave the client open and do not open and close it for every command.

In order to get feedback reliably using tcp.client you must specify the correct terminator when creating the client.

I recommend you try to use client actions, and if you want to post your command xml I will take a look at it.

If you want you can enable logging in VC and upload your log after trying to send several times.  I don't know if it will tell us anything useful or not but it doesn't hurt to try.

I don't really have time to digest the entire protocol as described in that pdf but I did give it a quick look.  One thing that caught my eye is this:

2.2.3 Simultaneous Connection (Back To Index)
Maximum Number of Simultaneous TCP Connection: 1

Is it possible that iRule and/or something else is already using that one available connection and thus interfering with VCs ability to communicate with the device?

[Scitz0]

Because of the "Maximum Number of Simultaneous TCP Connection: 1" I would like to close the connection after sending the command so I can use both iRule and voxcommando to control my receiver.

Sending single tcp writes to irule to control my ir lights and so on works every time.

In order to get feedback reliably using tcp.client you must specify the correct terminator when creating the client.

Would that be \x0D\x0A in my case?
Because I have tried that, made no difference.

I also tried client.connect -> client.write -> vc.pause for 10s -> client.disconnect
Made no difference compared to closing the connection directly after sending command using default 10ms delay.

Another thing I noticed is that the feedback event from the receiver is received when closing the connection.
If I add delays like you can see below the feedback event is received first when delays are done and its about to disconnect.

Also after full restart of voxcommando the first command to receiver ALWAYS(even feedback) works.
Quick restart does not guarantee this.

A couple of different logs:

After full restart with a delay of 5s on the command it self.
Two feedback events from receiver as you can see, first one has a payload, second does not.

Code: [Select]

2013-11-22 09:37:00 27 doCommand:test
2013-11-22 09:37:00 27 action repeat set to: 1
2013-11-22 09:37:00 27 Action:  Tcp.Client.Connect - test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:37:00 27 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&&&testEvent

2013-11-22 09:37:00 27 [plugin] TcpMic: Not using message termination byte!
2013-11-22 09:37:00 27 [plugin] TcpMic: New thread created for client: test
2013-11-22 09:37:00 27 [vcevent] TCP.StartListen.test

2013-11-22 09:37:00 27 action repeat set to: 1
2013-11-22 09:37:00 27 Action:  Tcp.Client.Write - test&&@MAIN:VOL=?\x0D\x0A&&5000
2013-11-22 09:37:00 27 [action] Tcp.Client.Write:test&&@MAIN:VOL=?\x0D\x0A&&5000

2013-11-22 09:37:05 32 [vcevent] testEvent

2013-11-22 09:37:05 32 doCommand:testOSD
2013-11-22 09:37:05 32 action repeat set to: 1
2013-11-22 09:37:05 32 Action:  OSD.ShowText - Payload: @MAIN:VOL=-25.5\x0D\x0A
2013-11-22 09:37:05 32 [action] OSD.ShowText:Payload: @MAIN:VOL=-25.5\x0D\x0A

2013-11-22 09:37:05 32 action repeat set to: 1
2013-11-22 09:37:05 32 Action:  TCP.Client.Disconnect - test
2013-11-22 09:37:05 32 [action] TCP.Client.Disconnect:test

2013-11-22 09:37:05 32 [vcevent] testEvent

2013-11-22 09:37:05 32 doCommand:testOSD
2013-11-22 09:37:05 32 action repeat set to: 1
2013-11-22 09:37:05 32 Action:  OSD.ShowText - Payload:
2013-11-22 09:37:05 32 [action] OSD.ShowText:Payload:

2013-11-22 09:37:05 32 [vcevent] TCP.EndListenLoop.test
Same as above but without full restart of voxcommando.
Two events received again but this time both were empty.

Code: [Select]

2013-11-22 09:43:04 553 doCommand:test
2013-11-22 09:43:04 553 action repeat set to: 1
2013-11-22 09:43:04 553 Action:  Tcp.Client.Connect - test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:43:04 553 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&&&testEvent

2013-11-22 09:43:04 553 [plugin] TcpMic: Not using message termination byte!
2013-11-22 09:43:04 553 [plugin] TcpMic: New thread created for client: test
2013-11-22 09:43:04 553 [vcevent] TCP.StartListen.test

2013-11-22 09:43:04 553 action repeat set to: 1
2013-11-22 09:43:04 553 Action:  Tcp.Client.Write - test&&@MAIN:VOL=?\x0D\x0A&&5000
2013-11-22 09:43:04 553 [action] Tcp.Client.Write:test&&@MAIN:VOL=?\x0D\x0A&&5000

2013-11-22 09:43:09 545 [vcevent] testEvent

2013-11-22 09:43:09 545 doCommand:testOSD
2013-11-22 09:43:09 545 action repeat set to: 1
2013-11-22 09:43:09 545 Action:  OSD.ShowText - Payload:
2013-11-22 09:43:09 545 [action] OSD.ShowText:Payload:

2013-11-22 09:43:09 545 action repeat set to: 1
2013-11-22 09:43:09 545 Action:  TCP.Client.Disconnect - test
2013-11-22 09:43:09 545 [action] TCP.Client.Disconnect:test

2013-11-22 09:43:09 545 focused: VoxCommando
2013-11-22 09:43:09 545 [vcevent] unFocused.chrome

2013-11-22 09:43:09 545 [vcevent] focused.VoxCommando

2013-11-22 09:43:09 545 [vcevent] testEvent

2013-11-22 09:43:09 545 doCommand:testOSD
2013-11-22 09:43:09 545 action repeat set to: 1
2013-11-22 09:43:09 545 Action:  OSD.ShowText - Payload:
2013-11-22 09:43:09 545 [action] OSD.ShowText:Payload:

2013-11-22 09:43:09 545 [vcevent] TCP.EndListenLoop.test
Removed all added delays(full restart)
As you can see only one event received and it contains correct payload

Code: [Select]

2013-11-22 09:45:22 755 doCommand:test
2013-11-22 09:45:22 755 action repeat set to: 1
2013-11-22 09:45:22 755 Action:  Tcp.Client.Connect - test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:45:22 755 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&&&testEvent

2013-11-22 09:45:22 755 [plugin] TcpMic: Not using message termination byte!
2013-11-22 09:45:22 755 [plugin] TcpMic: New thread created for client: test
2013-11-22 09:45:22 755 [vcevent] TCP.StartListen.test

2013-11-22 09:45:22 755 action repeat set to: 1
2013-11-22 09:45:22 755 Action:  Tcp.Client.Write - test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 09:45:22 755 [action] Tcp.Client.Write:test&&@MAIN:VOL=?\x0D\x0A

2013-11-22 09:45:22 755 action repeat set to: 1
2013-11-22 09:45:22 755 Action:  TCP.Client.Disconnect - test
2013-11-22 09:45:22 755 [action] TCP.Client.Disconnect:test

2013-11-22 09:45:22 755 [vcevent] testEvent

2013-11-22 09:45:22 755 doCommand:testOSD
2013-11-22 09:45:22 755 action repeat set to: 1
2013-11-22 09:45:22 755 Action:  OSD.ShowText - Payload: @MAIN:VOL=-25.5\x0D\x0A
2013-11-22 09:45:22 755 [action] OSD.ShowText:Payload: @MAIN:VOL=-25.5\x0D\x0A

2013-11-22 09:45:22 755 [vcevent] TCP.EndListenLoop.test
Second time without full restart
This time feedback empty

Code: [Select]

2013-11-22 09:46:40 413 doCommand:test
2013-11-22 09:46:40 413 action repeat set to: 1
2013-11-22 09:46:40 413 Action:  Tcp.Client.Connect - test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:46:40 413 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&&&testEvent

2013-11-22 09:46:40 413 [plugin] TcpMic: Not using message termination byte!
2013-11-22 09:46:40 413 [plugin] TcpMic: New thread created for client: test
2013-11-22 09:46:40 413 [vcevent] TCP.StartListen.test

2013-11-22 09:46:40 413 action repeat set to: 1
2013-11-22 09:46:40 413 Action:  Tcp.Client.Write - test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 09:46:40 413 [action] Tcp.Client.Write:test&&@MAIN:VOL=?\x0D\x0A

2013-11-22 09:46:40 413 action repeat set to: 1
2013-11-22 09:46:40 413 Action:  TCP.Client.Disconnect - test
2013-11-22 09:46:40 413 [action] TCP.Client.Disconnect:test

2013-11-22 09:46:40 413 [vcevent] testEvent

2013-11-22 09:46:40 413 doCommand:testOSD
2013-11-22 09:46:40 413 action repeat set to: 1
2013-11-22 09:46:40 413 Action:  OSD.ShowText - Payload:
2013-11-22 09:46:40 413 [action] OSD.ShowText:Payload:

2013-11-22 09:46:40 413 [vcevent] TCP.EndListenLoop.test
Here is a log with the use of vc.pause after write instead of built in delay in write action.
sent command twise, first time I got feedback correctly, second time I did not.
Only quick restart this time, quick restart does not guarantee correct result on first try as full restart does, just "luck" I guess.

Code: [Select]

2013-11-22 09:49:21 874 doCommand:test
2013-11-22 09:49:21 874 action repeat set to: 1
2013-11-22 09:49:21 874 Action:  Tcp.Client.Connect - test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:49:21 874 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&&&testEvent

2013-11-22 09:49:21 874 [plugin] TcpMic: Not using message termination byte!
2013-11-22 09:49:21 874 [plugin] TcpMic: New thread created for client: test
2013-11-22 09:49:21 874 [vcevent] TCP.StartListen.test

2013-11-22 09:49:21 874 action repeat set to: 1
2013-11-22 09:49:21 874 Action:  Tcp.Client.Write - test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 09:49:21 874 [action] Tcp.Client.Write:test&&@MAIN:VOL=?\x0D\x0A

2013-11-22 09:49:21 874 [action] 09:49 VC.Pause: 5000

2013-11-22 09:49:26 896 [vcevent] testEvent

2013-11-22 09:49:26 896 doCommand:testOSD
2013-11-22 09:49:26 896 action repeat set to: 1
2013-11-22 09:49:26 896 Action:  TCP.Client.Disconnect - test
2013-11-22 09:49:26 896 [action] TCP.Client.Disconnect:test

2013-11-22 09:49:26 896 action repeat set to: 1
2013-11-22 09:49:26 896 Action:  OSD.ShowText - Payload: @MAIN:VOL=-25.5\x0D\x0A
2013-11-22 09:49:26 896 [action] OSD.ShowText:Payload: @MAIN:VOL=-25.5\x0D\x0A

2013-11-22 09:49:26 896 [vcevent] TCP.EndListenLoop.test

2013-11-22 09:49:38 706 doCommand:test
2013-11-22 09:49:38 706 action repeat set to: 1
2013-11-22 09:49:38 706 Action:  Tcp.Client.Connect - test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:49:38 706 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&&&testEvent

2013-11-22 09:49:38 706 [plugin] TcpMic: Not using message termination byte!
2013-11-22 09:49:38 706 [plugin] TcpMic: New thread created for client: test
2013-11-22 09:49:38 706 [vcevent] TCP.StartListen.test

2013-11-22 09:49:38 706 action repeat set to: 1
2013-11-22 09:49:38 706 Action:  Tcp.Client.Write - test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 09:49:38 706 [action] Tcp.Client.Write:test&&@MAIN:VOL=?\x0D\x0A

2013-11-22 09:49:38 706 [action] 09:49 VC.Pause: 5000

2013-11-22 09:49:43 744 [vcevent] testEvent

2013-11-22 09:49:43 744 doCommand:testOSD
2013-11-22 09:49:43 744 action repeat set to: 1
2013-11-22 09:49:43 744 Action:  TCP.Client.Disconnect - test
2013-11-22 09:49:43 744 [action] TCP.Client.Disconnect:test

2013-11-22 09:49:43 744 action repeat set to: 1
2013-11-22 09:49:43 744 Action:  OSD.ShowText - Payload:
2013-11-22 09:49:43 744 [action] OSD.ShowText:Payload:

2013-11-22 09:49:43 744 [vcevent] TCP.EndListenLoop.test

[Kalle]

Hi Scitz0, are you sure that iRule close the connection to your receiver?

[jitterjames]

I am pretty sure that Irule keeps the connection open.

[Scitz0]

iRule on ipad closed and I can successfully telnet to receiver without any problem now whenever I want so I dont think this is the problem.

[jitterjames]

Close Irule,  put the terminator into your connect action and leave the connection open. Remove the pause.

Your logs were all showing actions connecting without specifying the terminator.