Vantage Controls "InFusion" lighting system

Are there any plans to support Vantage Controls “InFusion” lighting system? Their controller is IP based.

We contacted them in October, but even with a lot of grease applied to the transmission with a huge customer they seemed not to understand the request for IP control interface documentation and kept sending us their designer app and other inapplicable stuff. Anyway, we hope we spoke to the wrong people. If you have concrete information on their IP interface, please pass it along and we’ll take a look. Their website seems to be locked down so that nothing is really available.

Thank you.

Bringing this back from the dead. Trying to add Vantage support myself. Here’s the relevant tech info, such as it is:

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
• BTNPRESS
• BTNRELEASE
• LOAD <level (0-100)>
• RAMPLOAD <level (0-100)>
• GETLOAD
• LED <color1(0-255)>
<offcolor2(0-255)>
<blinkrate(FAST/MEDIUM/SLOW/VERYSLOW/OFF)>
• GETLED
• TASK
<eventType(PRESS/RELEASE/HOLD/TIMER/DATA/POSITION/
INRANGE/OUTOFRANGE/TEMPERATURE/DAYMODE/FANM
ODE/OPERATIONMODE/CONNECT/DISCONNECT/BOOT/LE
ARN/CANCEL/NONE)>
• GETTASK
• STATUS <type
(LOAD/LED/BTN/TASK/TEMP/THERMFAN/THERMOP/THERM
DAY/SLIDER/TEXT/VARIABLE/BLIND/PAGE/ALL/ NONE)>
• GETTEMP
• THERMTEMP <type (COOL/HEAT)>

• GETTHERMTEMP <type
(INDOOR/OUTDOOR/COOL/HEAT)>
• THERMFAN <fan(ON/AUTO)>
• GETTHERMFAN
• THERMOP <op mode
(OFF/COOL/HEAT/AUTO)>
• GETTHERMOP
• THERMDAY <day mode (DAY/NIGHT)>
• GETTHERMDAY
• SLIDER <level (0-100)>
• GETSLIDER
• TEXT
• GETTEXT
• VARIABLE
• GETVARIABLE
• GETFIELD
• GETSENSOR
• BLIND <control (OPEN/CLOSE/STOP/POS)>

• GETBLIND
• INVOKE <interface.method> …
• ECHO
• VERSION
• GETCOUNT
• DELIMITER <Hex Byte 1> [<Hex Byte 2>]
• LOG [ … ] [MASTER] [TYPE] [TIME] [SOURCE]
[FULL] [DEBUG] [DUMP] [INFO] [WARNING] [ERROR]
[FATAL] [TASK] [DEVICE] [QUERY] [PROF]
• DUMP [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: …
    c. Command Syntax is:
    i. [] [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
  2. It is possible to send Host Commands over TCP/IP.
    a. Use Telnet, HyperTerminal, Design Center, or any
    terminal program
  3. 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
  4. 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 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 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 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 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).

I can verify by doing a ‘telnet hostname 3001’ that the TCP interface works. I can do something like “STATUS BTN” and from then on, when I hit a physical button on my system, I see feedback on which button was hit. That’s useful for looking up the ID number of a button you don’t know.

Then you can simply type ‘BTN number’ and hit enter and it is as if you pressed that button. So it’s easy to toggle a button with Vantage via TCP. So I created a custom device as shown:

<dict>
	<key>codes</key>
	<dict>
		<key>TV Area Lamps</key>
		<string>BTN 733</string>
	</dict>
	<key>method</key>
	<string>lineio</string>
	<key>brand</key>
	<string>Vantage</string>
	<key>cat</key>
	<string>InFusion</string>
	<key>type</key>
	<integer>12</integer>
</dict>

I put it in the right place in my backup, zipped it, reloaded it. I setup a “device” with the proper IP and port. I assigned it to a room. But I don’t know how to actually get light control from there. What gives?

–Donnie

Did you send the command to the device to see if it works from for instance an Activity command list?

Hmm, fairly new to Simple Remote. Okay, that’s not entirely true. I used it a LONG time ago for a little while, and then didn’t for a long time, and am trying to see if I can revive it.

Anyway, how exactly do I do that?

–Donnie

Crap, I see what you mean. Yes, I added a command to an activity and ran the activity and it does send the command properly.

So how to do I make that an actual lighting control? I was assuming the light button in the lower left would let me add it there, but it seems like I need a custom button?

–Donnie

You can make Toggle Activities with state, or use a custom Remote Design, or reference the commands in any other Activity.

Homebar devices (bottom of the screen) require feedback parsing [two way] which is something we add for internally supported devices.

Gotcha. Would be very nice if we could do custom things in the Homebar with one-way devices for sure.

As for state, I should mention that in more depth…there’s a big problem with state in Vantage via TCP. As near as I can tell (and I’ve beaten on it quite a bit), there’s no way to query button state. I know the above doc makes it look like you should be able to, you just can’t seem to. You can get load state, but not button. Buttons are typically one or more loads, but they have their own ID(s) independent of button. So if you have a way to enter a button/load pair, you could query the button state by querying a load.

But even THAT isn’t complete. In theory it’s close enough for most (would be for me), but in reality it’s not the complete picture. The way Vantage works, if you push button X that turns on loads 1 and 2, and then push button Y that only turns off 2, then the button state of X will now be off, even though ONE of its loads is still on. So technically to get button state you need to track every load.

Anyway, I feel your pain in the original response that Vantage isn’t helpful with data. It really seems like they have some kind of other mechanisms for talking to Vantage now other than this TCP interface, but they don’t seem to document ANY of it very well. I think they really want you to setup a freakin Windows server with their own conduit or some such nonsense. sigh

Anyway, I think I get what I need to do now. Thanks.

–Donnie