Maybe. It is certainly something to try.
Also, try putting the TCP Binding’s logging into debug or trace mode. You can use the example at the bottom of the Zwave Binding for an example of how to do that.
I have added the logging as directed above, a TCP.log file is created yet nothing is appearing in the log when i execute the above described switch, so it seems that OH is not sending anything out.
Any thoughts appreciated.
Squid
We have reached the end of my expertise.
I appreciate your assistance…maybe someone else will be able to jump in and provide some guidance!
Cheers!
Rich - wanted to thank you for all of your assistance. I went and started fresh and found out why I was not seeing any TCP data in my captures. One must put the binding in the folder for it to be loaded. 
I was so caught up in making sure the configurations were correct that I overlooked the simple part adding the binding to the addons folder.
Now I have evidence in the log files…now all i have to do is find out why I’ve got extra characters in the transmission. I’m getting there 
1 Like
@KidSquid, bringing this back up because I’m probably the only other person in the universe who needs this, but I’m at the point of trying to control Vantage with OpenHAB. Did you get this fleshed out, and if so, would you mind sharing the more completed work? Would be very much appreciated.
–Donnie
Hi Donnie -
Here’s a bit of a write-up that I created for someone who asked the same question a few months ago…see we are not alone! 
This write-up assumes you have a Qlink controller and a IP Enabler so that you can communicate through TCP.
Please let me know where you wind up, I’m always looking to take my system to the next level and if you are able to use what I’ve come up with and improve it - I would love to share in the fruits of your labor.
Let me know if you have any questions, I’ll do my best to help where I can.
Squid
Hmm, I just realized you haven’t upgraded your hardware to InFusion, you still have Qlink. I’m still digging for the documentation, but I think the TCP protocol is different between the two. For instance, I can use BTN as the command (with a CR, as you found) to toggle a button by it’s ID number. So your work is probably useful and very similar, but isn’t exactly the same between Qlink and Infusion. I’m also guessing there’s a way to fetch status.
The reason I know what I know is simply because a former employee figured this out many years ago and I do have some iRule control of Vantage now. So I just sort of went through the iRule config to find out what it was doing. I’ve successfully done this by using telnet to the proper port and doing the command by hand.
So I’ll see what I can do using the above. Thanks!
–Donnie
Yes, I’m still stuck with Qlink.
Please let me know if you turn up anything.
Squid
Well, shoot. I can not find a PDF anywhere with anything official from Vantage, but Googling found that someone had posted the stuff at the bottom of this post. What’s weird is when I monkey around via telnet, I see no way to get BUTTON status. You can get LOAD status, but not button status. I prefer to only live in a world where my higher level control mimics button presses because those are already well-defined to handle groups of loads. I don’t want to re-do that when it’s already done once.
So for now I’m going to punt and not care and just create something that can toggle the button (using BTN, notice the difference between it and BTNPRESS…using that requires you to also use a BTNRELEASE and ain’t no way we’re doing there…that’s for automated dimming control, which is crazy in this real, IMHO). Anyway, the command I think I want would be a “GETBTN” command, which doesn’t seem to exist (tried it). STATUS seems to return NOTHING, which is odd, IMHO.
Anyway, this is better than a sharp stick in the eye. I’ll see in the next couple days if I can massage the stuff @KidSquid posted to use these commands instead.
–Donnie
Overview
InFusion Systems will integrate with Crestron®, AMX®, Elan®
etc. using Host Commands. Typically integration modules are
written by the 3rd Party company that is communicating with
InFusion. If integration modules have not been written by these
and other companies, that does not mean these devices will not
integrate with InFusion. Host Commands allow integration of
these products even if modules do not exist. Host Commands
are similar to V-Commands used in Vantage’s QLink system.
Design Center Diagnostics
Below is a list of Host Commands currently available. The
Design Center programmer can test Host Commands in the
Design Center Diagnostics Window. Type “help” in the Host
window and click send to get a list of Host Commands. When
“help” is typed and Send is clicked, the “Messages Received
from Controller” section of the diagnostics window displays the
following:
Description and Syntax of Host Commands:
Messages Received from the Controller
• BTN <button vid>
• BTNPRESS <button vid>
• BTNRELEASE <button vid>
• LOAD <load vid> <level (0-100)>
• RAMPLOAD <load vid> <level (0-100)> <seconds>
• GETLOAD <load vid>
• LED <button vid> <color1(0-255)> <color2> <color3>
<offcolor1> <offcolor2(0-255)> <offcolor3>
<blinkrate(FAST/MEDIUM/SLOW/VERYSLOW/OFF)>
• GETLED <button vid>
• TASK <task vid>
<eventType(PRESS/RELEASE/HOLD/TIMER/DATA/POSITION/
INRANGE/OUTOFRANGE/TEMPERATURE/DAYMODE/FANM
ODE/OPERATIONMODE/CONNECT/DISCONNECT/BOOT/LE
ARN/CANCEL/NONE)>
• GETTASK <task vid>
• STATUS <type
(LOAD/LED/BTN/TASK/TEMP/THERMFAN/THERMOP/THERM
DAY/SLIDER/TEXT/VARIABLE/BLIND/PAGE/ALL/ NONE)>
• GETTEMP <temperature vid>
• THERMTEMP <thermostat vid> <type (COOL/HEAT)>
<temperature>
• GETTHERMTEMP <thermostat vid> <type
(INDOOR/OUTDOOR/COOL/HEAT)>
• THERMFAN <thermostat vid> <fan(ON/AUTO)>
• GETTHERMFAN <thermostat vid>
• THERMOP <thermostat vid> <op mode
(OFF/COOL/HEAT/AUTO)>
• GETTHERMOP <thermostat vid>
• THERMDAY <thermostat vid> <day mode (DAY/NIGHT)>
• GETTHERMDAY <thermostat vid>
• SLIDER <slider vid> <level (0-100)>
• GETSLIDER <slider vid>
• TEXT <text vid> <text>
• GETTEXT <text vid>
• VARIABLE <variable vid> <text>
• GETVARIABLE <variable vid>
• GETFIELD <Obj vid> <field name>
• GETSENSOR <Obj vid>
• BLIND <Obj vid> <control (OPEN/CLOSE/STOP/POS)>
<position>
• GETBLIND <Obj vid>
• INVOKE <Obj vid> <interface.method> <parameter> ...
• ECHO <text>
• VERSION
• GETCOUNT
• DELIMITER <Hex Byte 1> [<Hex Byte 2>]
• LOG [<master> ... ] [MASTER] [TYPE] [TIME] [SOURCE]
[FULL] [DEBUG] [DUMP] [INFO] [WARNING] [ERROR]
[FATAL] [TASK] [DEVICE] [QUERY] [PROF]
• DUMP <master> [MASTER] [TYPE] [TIME] [SOURCE] [FULL]
[DEBUG] [DUMP] [INFO] [WARNING] [ERROR] [FATAL] [TASK]
[DEVICE] [QUERY] [PROF]
Host Command Characteristics
1. Commands have the following characteristics
a. ASCII text, not case sensitive, Space or Quote Delimited
b. All commands are replied to with a R:<Command> …
c. Command Syntax is:
i. <Command> [<VID>] [Param1] [Param2] … [ParamN]
ii. Example: Send: BTN 73 – Press & release button 73 –
has no parameters
iii. Reply: R:BTN 73 – Acknowledgement that BTN 73
command was executed
iv. Example: Send: RAMPLOAD 91 75 4.5 – Ramp light
91 to 75% in 4.5 seconds
v. Reply: R:RAMPLOAD 91 75 4.5 – Ramp light 91 to
75% in 4.5 seconds
TIP: Try sending a [cr] and [lf] with all Host Commands if
command appears not to work
Sending Host Commands VIA, TCP/IP
1. It is possible to send Host Commands over TCP/IP.
a. Use Telnet, HyperTerminal, Design Center, or any
terminal program
2. TCP/IP Protocol
a. The IPAddress of the InFusion Controller – can be
verified by using the “NET” menu on the front panel of
the controller
b. Configure the connecting device to open a socket to the
InFusion Controller on port 3001
3. Use the standard Host Commands above
Sending Host Commands Via RS-232
InFusion Controller RS-232 Ports are ready for Host
Commands by default. Do not setup the port in Controller
Properties for versions of Design Center prior to 2.0. Version
2.0 and later, serial ports will have a feature that allows port
setup to be for Host Commands or 3rd Party devices. The
standard communication protocol is:
• Baud: 19200
• DataBits: 8
• Parity: None
• Stop Bits: 1
NOTE: When connecting 3rd party devices to any serial port
on the Main Controller Terminal Board, for the purpose of
receiving Host Commands, DO NOT click on the Add Serial
Port button in Controller setup if using a version of Design
Center prior to 2.0. This leaves the port properly configured for
receiving Host Commands. Instead, if the serial port will be
used by one of Design Center’s 3rd Party Drivers, then click
Add Serial Port and set up the port for the 3rd party driver.
These port settings are subject to change. Look for additional
features in future releases of Design Center for setting up
these ports.
InFusion Design Center — HOST COMMANDS
SEND
RECEIVE
SEND
RECEIVE
SEND
RECEIVE
SEND
RECEIVE
Host Commands Outside The Local Network
To access the InFusion Controller outside the home network
(for remote programming), forward internet ports 2001 and
3001 from the router or modem connected to the internet, to
the IP address of the InFusion Controller. Allow the Ping
operation as this is used by InFusion to verify its connection. At
the remote location, enter the external IP Address, assigned
from the ISP of the router or modem, into Design Center to
connect. If you are unsure how to do this you may need to
contact an IT professional to setup a connection.
Communication Management With 3rd Party Devices
3rd Party Devices will be connected via IP or RS-232. It is
recommended to have the connected system send the
following commands to open and maintain communication with
the InFusion System. To control the amount of status
information returned the 3rd Party programmer may want to use
STATUS LED and STATUS LOAD commands only, however,
STATUS ALL may be used if the amount of information does
not slow the system down.
RS-232 Connections:
• Send – GETCOUNT
• It is recommended to send the GETCOUNT message every
1 minute or so. This command will increase by a count of
one (1) each time it is sent.
• The SEND and RECEIVE history would look like the
following:
TIP: Try sending a [cr] and [lf] with all Host Commands if
command appears not to work
• Notice above that the GETCOUNT returns 0 the first time
sent, then 1, then 2 etc. Each time the GETCOUNT
command is sent the count increases by one. This count
continues to increase unless the system is reset. This allows
the 3rd Party programmer to setup a check to see if the
system has reset or not.
• In the above example we have indicated the point of RESET.
Notice the GETCOUNT returns a 0 after the RESET.
• The 3rd Party programmer should write a program if 0 is
returned that would send new STATUS commands to update
the status of the system after a reset or power outage. It is
recommended that a short delay (about 2 minutes) be
inserted before sending the STATUS commands to give the
systems sufficient time to completely reset.
IP Connections:
• Send – STATUS, commands to cause the InFusion System
to report information back to the 3rd Party device. LED and
LOAD status fields are the most common elements that 3rd
Party systems need to know for integration.
• The GETCOUNT command used in the RS-232 example
above is not necessarily needed for an IP Connection
because the 3rd Party device should know when the system
goes down and the IP Connection is lost. The 3rd Party
programmer should write a program that will send new
STATUS commands if the IP Connection failed due to a
RESET or Power Outage to update the status of the system.
It is recommended that a short delay be inserted before
sending the STATUS commands to give the systems
sufficient time to completely reset.
Examples
I. How to control TASKS from a 3rd Party device. It should be
understood that some tasks in Design Center use specific
Triggers to properly function while others do not require
specific triggers. For example DIM uses three specific triggers
to execute while TOGGLE does not require a trigger to
execute. The table below shows how a 3rd Party device would
execute a TASK set to perform a TOGGLE.
TOGGLE TASK:
ACTION SEND HOST COMMAND RESULTS
PRESS or RELEASE
3rd Party Button
TASK < task VID> The specific Task is
Executed
IMPORTANT: In the table above, notice that the ACTION is
Press or Release, not both. The 3rd Party device cannot send
the TASK <VID> Host Command on the press and the release,
or the task will be executed twice, negating the desired results.
As mentioned above, DIM uses three triggers:
Triggers Used: (by DIM function)
• Button Press
• Button Hold
• Button Release
The table below shows how a 3rd Party device would execute a
TASK set to perform a DIM.
DIM TASK:
ACTION SEND HOST COMMAND RESULTS
PRESS 3rd Party
Button
TASK <task VID> PRESS The specific Task executes
a PRESS Trigger
HOLD 3rd Party
Button
<If pressed and held for one
second or longer then…>
TASK < task VID> HOLD
The specific Task executes
a HOLD Trigger
RELEASE 3rd Party
Button
TASK < task VID> RELEASE The specific Task executes
a RELEASE Trigger
IMPORTANT: In the table above, notice that the ACTION
matches the Host Command sent. Because the DIM task only
executes on these specific Triggers there is no other way to
make the DIM TASK run.
NOTE: The HOLD command, in the above example, should be
programmed to be sent after the 3rd Party button has been
pressed and held for 1 second or more.
II. How to control BUTTONS from a 3rd Party device. Often the
3rd Party integrator will want to press buttons that have tasks
already assigned to them instead of executing the task directly.
The two examples below echo the examples above but Buttons
are Pressed and Released instead of Tasks.
The table below shows how a 3rd Party device would execute a
BUTTON set to perform a TOGGLE.
TOGGLE BUTTON:
ACTION SEND HOST COMMAND RESULTS
PRESS or RELEASE
3rd Party Button
BTN < button VID> The specific Button is
Pressed and Released
IMPORTANT: In the table above, notice that the ACTION is
Press or Release, not both. The 3rd Party device cannot send
the BTN <VID> Host Command on the press and the release,
or the task will be executed twice, negating the desired results.
As mentioned above, DIM uses three triggers:
Triggers Used: (by DIM function)
• Button Press
• Button Hold
• Button Release
SEND
RECEIVE
RECEIVE
RECEIVE
RECEIVE
RECEIVE
RECEIVE
The table below shows how a 3rd Party device would execute a
BUTTON set to perform a DIM.
DIM BUTTON:
ACTION SEND HOST COMMAND RESULTS
PRESS 3rd Party
Button
BTNPRESS <button VID> The specific Task executes a
BUTTON PRESS
RELEASE 3rd Party
Button
BTNRELEASE < button VID> The specific Task executes a
BUTTON RELEASE
IMPORTANT: In the table above, notice that the ACTION
matches the Host Command sent. If the 3rd Party button is
pressed and held it will automatically start the DIM cycle
because the button in Design Center is being held down. Once
the button is released the DIM cycle will stop. If the button is
pressed and released before 1 second the load simply toggles
on and off.
III. In the example below, a 3rd Party device has sent a Status
All command to InFusion. Next, a button is pressed and
released on the InFusion system turning on a light. Study the
following to understand the communication protocol.
TIP: Try sending a [cr] and [lf] with all Host Commands if
command appears not to work
• The 3rd Party system sends a STATUS ALL[cr]
• InFusion Controller replies with R:STATUS ALL[cr]
• Button (VID) 12 is pressed and released on the InFusion
System
• InFusion Controller replies with
RESPONSE DESCRIPTION
S:LOAD 18 100.000[cr] Load 18 turned ON to 100%
S:BTN 12 PRESS[cr] Button 12 Pressed
S:TASK 20 1[cr] Task 20 is triggered to ON
S:LED 12 1 255 0 0 0 0 0[cr] Button LED 12 is ON with RED
S:BTN 12 RELEASE[cr] Button 12 is Released
NOTE: Notice the order of the events returned in the protocol
does not necessarily match the true order of events. For
example, in the above scenario the button was pressed and
released turning the button LED and Load ON. The order of the
commands above is not important. What is important, is the
information needed by the 3rd Party system.
Examples Of Host Commands
Most Host commands are based on a Command followed by a
VID number. Therefore the 3rd Party integration programmer,
will want a list of Buttons (and possibly Loads) and their
respective VID numbers. One of the most common interfaces
is a button press and release. To press and release a button
from a 3rd Party device send BTN <VID#>. As a result of
pressing and releasing the button, with the STATUS
commands active, the 3rd Party device will get the necessary
feedback.
Explanation of LED Receive String
• Button 12 toggles Load 18 turning the load on to 100%
• The toggle task is VID 20 and the task is ON showing a
value of 1
The button LED State is typically 0 (OFF) or 1(ON) but in
Design Center it could be the same as the load value.
The next two number sets consist of three numbers, and
represent red, green and blue led ON and OFF values. The
last parameter is for BLINK status (see LED Host Command on
page one).
Out of curiosity have you ever listened to your IP Enabler? 
Mine is extremely chatty…
I constantly see data flowing back from the enabler when button presses are made throughout the house (I currently do have every wall switch in OH, have over 40)
I constantly see data in the logs that looks like the following:
2018-02-12 23:54:11.186 [WARN ] [rm.AbstractFileTransformationService] - Could not transform 'SW 1 89 4 1SW 1 89 4 0' with the file 'off.map' : Target value not found in map for 'SW 1 89 4 1SW 1 89 4 0'
This is typical of the system reporting a button press. (it’s complaining that I don’t have a map transformation for that particular light switch.)
The way I debugged a lot of what I did with Vantage was using Wireshark and looking at the traffic.
Squid
No, and I’m not sure how to listen to it. How do I do that?
One thing that hit me, though…if you want button status, you just need to check the status of any load that the button is attached to. So you just need to track a button/load pairing.
–Donnie
To see what the IP Enabler was spitting out I used WIRESHARK to monitor the traffic and then I filtered by the IP address of the IP Enabler.
You can also set up the TCP binding and and a 2 way switch (item) that sends command and listens for commands via the IP Enabler. If you look at the example I posted you will notice there is code for sending to (starts with >) and code that listens (starts with <) all of the traffic coming back from the IP Enabler will get logged in the openhab.log file.
Also look in the TCP documentation for more specifics.
https://docs.openhab.org/addons/bindings/tcp1/readme.html
Squid
Oh oh, I see what you mean. I’m not sure how that helps, though. I mean you can telnet to the device, issue the commands, and see what it responds with.
I mean I can see it being useful for troubleshooting the openhab gateway to the device, but not sure what else it is good for.
–Donnie
I think it’s my fault…I read that you were looking to capture button status if someone was manually pressing one. Sorry…after re-reading I see you are looking to query the button status.
I did see in the documentation you posted that STATUS + TYPE seemed to be valid. And there is a type=BTN.
Did you try that?
Squid
Yeah. It just returns nothing useful (this is two tries, the second trying a button ID):
STATUS BTN
R:STATUS BTN
STATUS BTN 91
R:ERROR:5 "Wrong Number of Parameters"
But yeah, if I leave that telnet open, I’m seeing real button presses. So you’re right that those could be captured. But you’re also right that I just want to query status so I can have a “turn this thing on” button in openhab rather than a less-intelligent “emulate a button press on this button.” Because if I’m somewhere I can’t see the output, I don’t know if it’s on already or not.
–Donnie
Okay, I’m finally back to poking at this. But I’m a tad lost. Here’s where I am so far:
Used PaperUI to install TCP binding and Map transformation.
Added your tcp.cfg to /etc/openhab2/services
Now I’m a bit stuck. I think I understand what to change in your examples to convert your QLink stuff to my Infusion stuff (the VSW stuff gets converted to BTN, basically, then my IP address and port numbers, etc). But what’s vague to me is still things like where the .things file and the Map file go.
And then once I have those in the right places, what do I do to create a button in OH to trigger the on and off?
I think these are fairly easy questions to answer for someone experienced with OH, but getting started is a bit of a maze of documentation.
–Donnie
Glad to see that you are back at it
I’ll do my best to assist where I can.
First thing to note, is that the TCP binding is a OpenHab version 1 binding which does not utilize Things - so there is no .thing file. You will need to manually create Vantage Items for each load/switch you want to control. These items will be placed in a .items file which is placed in your conf/items folder
The .map files are placed in your conf/transform directory.
So let’s take a simple light switch that controls my hallway lights.
I have a file called uplights.items which contains all of my upstairs lighting. The first line of that file contains the switch for my hallway lights:
Switch Hallway "Hallway Lights" [ "Switchable" ]{ tcp=">[ON:10.5.x.x:3040:'MAP(90.map)'],>[OFF:10.5.x.x:3040:'MAP(90.map)']"}
Switch = The type of item
Hallway is the name of the item
“Hallway Lights” is the label of the item (used on the sitemap)
[ “Switchable”] is a tag for allowing ALEXA to control via Hue Emulation to control it
{ tcp=“>[ON:10.5.x.x:3040:‘MAP(90.map)’],>[OFF:10.5.1.6:3040:‘MAP(90.map)’]”} is the command that we are issuing to control the light via Vantage. TCP is the protocol, the > sign indicates we are sending commands via TCP (if it were < it would indicate we are listening for data to process) The [ON:10.5.x.x:3040 ‘MAP(90.map)’] says for the ON command send it to 10.5.x.x port 3040 and the ON command string can be found in the 90.map file. The [OFF:10.5.x.x:3040 ‘MAP(90.map)’] performs the same function for the OFF command.
My 90.map file looks like this:
ON=VSW!1 90 1 6\r
OFF=VSW!1 90 1 6\r
These are the Vantage commands I am sending to mimic a button press, that’s the reason they are the same for ON and OFF as I am toggling the button.
Now that we have an item and the mapping which shows which commands to send, we need a switch to operate this item.
You create this switch in your sitemap.
The switch in my sitemap looks like this:
Switch item=Hallway icon="light"
The above code must be part of a valid sitemap to work, I think it would be in your best interest to review the docs for sitemaps and items so you can get a good understanding of how they work if you are new to OpenHab. I have a feeling that once you get a handle on the concepts you’ll be miles ahead of me in making your system work the way you want it to.
Let me know what else I can do - can’t wait to hear your results.
Squid
YOU DA MAN
Followed these instructions plus the instructions on creating a Sitemap and now I have a working basic switch that turns one light on and off.
Biggest difference is my .map file is a much simpler “ON=BTN 171\r” followed by the same OFF like you. But same thing, different syntax.
I also learned something about InFusion TCP that wasn’t clear before. If you just telnet to it, you get no status output until you TELL it you want it. I don’t mean direct queries…I mean rolling output whenever something happens on the system (ie. someone hits a physical button). You see that by issuing the proper STATUS , like “STATUS ALL” shows all sorts of info, including which loads turned on.
So if you want to get jiggy with things, it is possible to listen to the TCP traffic and know what state the lights are in for sure. How you do that with OH, though, is a much bigger learning matter. For now I’m okay with toggling and not knowing. I’m going to skip straight to seeing how to get this going with IFTTT from here. I may revisit state, we’ll see.
BOOM, thanks @kidsquid. Big big help.
–Donnie
And it took me not very long to connect to the cloud connector, then connect IFTTT to that, and now I control my outside lights from anywhere in the world via SMS, button widget, Alexa, and web.
Awesome. Thanks again!
–Donnie