Hello -
I am new to OpenHAB and am reviewing to see how I can integrate into my home. I currently have an older Vantage Qlink System that controls the lighting…is there a BINDING (hope I’m using the correct nomenclature) that will allow for the control of the Vantage system?
Many thanks and apologies if this is posted in the wrong area.
Squid
Right place.
The Davis binding mentions a Vantage 2 but I don’t think they are the same thing. I could find no mention of Qlink in any of the other bindings so it looks like there is not an existing binding.
Rich - Thanks for the information.
I’ve done a bit of research on my vantage system and it looks like it takes ASCII commands send to a TCP Address/Port.
From what I can deduct, it looks like I may be able to use the TCP binding.
The commands are unique to vantage, for example to turn my upstairs hallway lights on at 100% the command is VLA@1 218 1 100
Would someone mind assisting me with the structure of the item and the configuration file settings to make a switch so I can test this.
I am very new to OpenHab and still working on principles…
Thanks,
Squid
The full documentation for the TCP/UDP binding is here:
I don’t use this binding so am limited in how much I can help with specifics. Where I can help is that you will need to define your Item as a Dimmer, bind the Item as an outgoing socket (i.e. >) and the main challenge will be setting up the transformation rule to prepend the “VLA@1 218 1” to the Dimmer value. You would probably want to use the JavaScript transform for this.
So the transform would be something like the following in a file I’ll name “vantageDimmer.js”
(function(i) {
return "VAL@ 1 218 1 " + i;
})(input)
NOTE: I’m not great with JS so the above may be completely bogus. You might need to do something to i to convert it into a format that can be appended to a string.
Then your Item would look like:
Dimmer HallLight <light> { tcp=">[*:123.4.5.67:8910:'JS(vantageDimmer.js)'] }
Theoretically this means:
> - Outgoing, i.e. sends messages, not receiving messages
[ ] - binding config markers
* - any command the Item receives activate this binding config
123.4.5.67 - IP address of the device
’8910’ - port of the service to send the message to
JS(vantageDimmer.js) - actually send whatever the JS transform defined in cantageDimmer.js returns
Couple of questions…
In looking at the documentation it seems that transform files need to end with .transform, do I need to call your JavaScript file vantagedimmer.transform?
I see you have the IP address in the item, do I need to add the binding information in the CFG file as well?
I guess I could use a listener to display the value of the dimmer as well?
Thanks,
Sid
Where did you see that? Are you sure you didn’t misread it and it said they need to be in the configurations/transform folder? Different types of transforms have different extensions. For example I have two files that end in .map, and one that ends in .xsl in my transform folder. A JavaScript transform file ends in .js according to the examples on the wiki and in other examples I’ve seen on this forum. If there is documentation somewhere that says it should end in .transform it is wrong.
I don’t think so. I think you only add it to the openhab.cfg if some external device needs to make a connection to OH (i.e. OH is the server awaiting connections from third parties as opposed to the client establishing connections to a server).
Yes, you can add a < binding to the same Item to receive messages coming from the device. You will likely need a transformation there as well to translate the messages to a number between 0 and 100 or ON and OFF.
Ok…I’m doing my best to plug along here…really appreciate the help.
Here’s my switch…
Switch HallLights <light> (VANTAGE) { tcp=">[ON:10.5.1.6:3040:'MAP(218.map)')], >[OFF:10.5.1.6:3040:'MAP(218.map)']" }
Here’s my map
ON=VAL@1 218 1 100\x0D
OFF=VLA@1 218 1 0\x0D
I see the switch performing in the events log, yet i see nothing in the openhab log. I also am not seeing anything when I sniff the TCP traffic.
Any suggestions would be greatly appreciated.
Do I need to do anything to the CFG file?
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 
@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