AMX

Pierre Kil edited this page Feb 3, 2017 · 10 revisions
Clone this wiki locally

Using OpenRemote with your AMX system gives you the following benefits:

  1. Integrate modern automation technologies with legacy AMX systems
  2. Add new touch interfaces to control AMX systems with no additional cost
  3. Gradually migrate from proprietary AMX systems to standardized, open solutions

With OpenRemote, you can start this development path towards the future of "Internet of Things" while maintaining your existing investments in AMX programming and AMX control panels.

Hardware

OpenRemote supports AMX via a module running on a NetLinx controller in your system. This includes all integrated controllers as well as controllers embedded in the Enova DVX and DGX products.

The functionalities of the following products are supported by OpenRemote.

AMX - table1

Configuration of System

The overall mechanism for AMX integration with OpenRemote is for the AMX system to expose its devices (real or virtual) and to allow OpenRemote to issue commands similar to what NetLinx allows on those devices, so ON, OFF and PULSE on a channel, SEND_LEVEL on a level and SEND_COMMAND and SEND_STRING on the device itself. Feedback from AMX devices back to OpenRemote is also included.

The communication between the AMX processor and the OpenRemote controller uses a custom protocol on TCP/IP, but all communication details are handled by an OpenRemote specific module running on the AMX controller. This means that you need to modify the AMX program to include and correctly initialise that module. You can download this module here.

The modifications required in the AMX program are:

  • define the socket to use for communication
  • define the TCP port to use (50000 is the default value used by OR)
  • define the list of devices that will be exposed to OR
  • define the OR module

Here is an example NetLinx code snippet demonstrating these steps:

DEFINE_DEVICE

dvRELAY = 5001:8:0   // NI-3100 Relay real device

dvOpenRemoteSocket  = 0:17:0

DEFINE_CONSTANT

VOLATILE DEV vdvOpenRemoteDevices[] = {
    dvRELAY
}

DEFINE_VARIABLE

INTEGER nOpenRemoteIPPort = 50000

DEFINE_START

DEFINE_MODULE 'OpenRemoteProxy' ORProxy(dvOpenRemoteSocket, nOpenRemoteIPPort, vdvOpenRemoteDevices)

Create AMX Commands in OpenRemote Designer

Performing an action on an AMX device is done from OpenRemote via a command. The commands are named identically to the instruction you would use in a NetLinx program: ON, OFF, PULSE, SEND_LEVEL, SEND_COMMAND and SEND_STRING.

Receiving feedback is performed using a sensor, linked to a "read" command. Those commands are CHANNEL_STATUS, LEVEL_STATUS, COMMAND_READ and STRING_READ (corresponding to AMX CHANNEL_EVENT, LEVEL_EVENT and DATA_EVENT).

All commands take at least one mandatory parameter, the "Device index". It is the index of the device to work on in the array passed to the AMX module (so vdvOpenRemoteDevices in the above code snippet). It starts at 1, as arrays do in NetLinx. In above code snippet, device index 1 would be used to work on the dvRELAY device.

For more details on how to create commands and sensors in OpenRemote Designer, please see the reference documentation:

CHANNEL

To work with channel, you need to provide the channel number. The action commands are ON, OFF and PULSE which work exactly like their AMX equivalent.

The PULSE command takes an optional pulse time parameter, indicating the duration of the pulse in 1/10th of a second. If not defined, whatever pulse time is defined in the AMX program at the time the PULSE command is issued is used.

For feedback, use the CHANNEL_STATUS command, which will read the feedback (on or off) of that channel.

CHANNEL_STATUS will issue a read to the AMX processor the first time it is triggered and will then register its interest in the status, so will receive feedback asynchronously as changes occur on the AMX side.

LEVEL

A level number is mandatory for all LEVEL commands. The action command SEND_LEVEL takes an additional value parameter. You might leave that empty and use the command with a slider, in which case the slider provides the value to use.

There is no validation on the range of the level used on the AMX side.

For feedback, use the LEVEL_STATUS command.

LEVEL_STATUS will issue a read to the AMX processor the first time it is triggered and will then register its interest in the status, so will receive feedback asynchronously as changes occur on the AMX side.

Important note: this only works for the first 256 levels for each device. If you need to use levels above 256, please contact us.

COMMAND and STRING

For action commands, use the value parameter in OpenRemote to provide the parameter to the SEND_STRING or SEND_COMMAND that will be sent to the device.

Feedback works in a way very much dictated by the way it works in an AMX system. The AMX processor always receives all STRING and COMMAND DATA_EVENTs, asynchronously, and forwards them to OpenRemote (for registered devices).

Feedback in OpenRemote requires a "read" command: COMMAND_READ or STRING_READ.

These commands take the value received from the AMX processor and expose it (verbatim or processed through a regular expression) to their sensor. If multiple COMMAND_READ or STRING_READ commands exist for a given device, they will all get the chance to process the same value. If none exist, the received value is discarded. Using a regular expression on the receive value is useful to extract the interesting value from the whole string.

As an example, consider an AV receiver connected to the AMX processor, its device being registered with the OpenRemote module. When the volume is changed on the AV receiver, the AMX device does generate a STRING DATA_EVENT with a string such as 'VOLUME=nn', which is forwarded to OpenRemote. When changing the source on the receiver, a string such as 'SOURCE=nnn' is generated.

By defining a STRING_READ command for this device, with no regular expression and linking it to a custom sensor, the sensor will be updated with whatever string is produced on the AMX side, such as 'VOLUME=80' or 'SOURCE=DVD'.

Defining a second STRING_READ command for this device but with a regex filter of "(VOLUME=)(\d+)" and a regex group of 2, allows to read the volume value. A linked sensor will then only be updated if the received value matches the regular expression. In that case, it'll be updated with the specified group as the value. Changing the volume on the receiver might generate a 'VOLUME=80' string, that matches the provided regular expression and the value '80' (that matches the second group) is used as the sensor value. On the other hand, changing the source might generate a 'SOURCE=DVD' string, that does not match the regular expression and the value of this sensor is unaltered.

Reference Cases

AMX - AMXVideo_256x164

The video shows an OpenRemote control panel which has integrated with various existing systems in a high-end media room. We cover blinds and lighting control, as well as automated audio/video source selection, projector control, Apple TV and media center integration.

With OpenRemote, we can create a modern, fully customizable user interface using cloud-based drag and drop tools and a standard web browser. The designed UI can be deployed on iOS and Android devices as well as used with a regular web browser. It can be used to replace difficult-to-program, proprietary and expensive AMX control panels, integrate with Lutron based blinds and lighting controls as well as replacing infrared-based remote controls.

For existing AMX systems, OpenRemote opens a possibility to integrate new or alternative automation technologies, such as Z-Wave, Zigbee, KNX or EnOcean with the legacy AMX installation. As the "Internet of Things" evolves and the technology evolves at an ever-faster pace, including OpenRemote as part of your AMX installation ensures an open migration path to future developments.

OpenRemote also allows installation of additional touch panels and control interfaces without additional license costs, only at the price of the hardware unit (iOS, Android, etc.) itself. You can gradually migrate AMX systems by taking advantage of the existing logic programming in AMX controllers as well as maintaining existing investments in AMX control panels in parallel to adding new OpenRemote touch interfaces.

See Also