NOTICE: REMOTE ACCESS IS EXPERIMENTAL AND CANNOT BE IMPROVED AS WE ARE OUT OF MEMORY SPACE IN THE CURRENT CPU.
THE FINAL VERSION OF REMOTE ACCESS SUPPORTS DIGI 900HP/S3B MESH NETWORKING COMMUNICATION MODULES.
Introduction
The Fusion® Series is our fourth generation relay controller offering the ultimate relay control solution . . . without exception.
If we had to pick just one guide we hope our customers will read, it is the Remote Access Quick Start Guide. Remote Access does things that you have never seen before. Remote Access is how Fusion controllers talk to each other through 802.15.4 wireless communications. Remote Access also allows you to send commands from any Fusion controller to any other Fusion controller. Using Remote Access, 257 relay controllers can act as one gigantic relay controller. All 257 relay controllers must be within 1 mile, line of site, for proper operation.
There are four parts to Remote Access. Part 1 is Configuration. And if you will bear with us through configuration, it will be worth your while, because Part 2 (Tunneling), Part 3 (Remote Command Execution), and Part 4 (Remote Data Collection) will let you see just how much engineering is inside your Fusion Series controller. Fusion Remote Access was the most difficult feature to design as the Remote Access routines are intensely complex. We view the Fusion Remote Access routines as one of our greatest engineering achievements, and we hope you will explore these features in full.
Overview
Remote Access uses the second communication port on your Fusion controller. Every Fusion controller must use the second port to join in on the Remote Access “group”. You agree to give up the use of the second port for communications with a computer in exchange for communications with other Fusion controllers. Remote Access wirelessly links your Fusion controllers together. Up to 257 relay controllers can be wirelessly linked together using Remote Access (Master + 256 Wireless Remote Slaves). What you end up with is a single, gigantic relay controller with all the pieces spread up to one mile away. Every remote Fusion controller is capable of talking to the entire group, so every Fusion controller can act as a Master or a Slave to another Fusion controller. Building this group is what configuration is all about.
Tunneling is the ability to use a Fusion controller to take control of another Fusion controller. Tunneling essentially turns your Fusion controller into a modem or communications relay station, forwarding all commands directly to a remote Fusion controller. Tunneling can effectively double the useful wireless range of a Fusion controller as it is possible to send wireless commands to a Fusion controller and have this controller forward your commands to a remote Fusion controller.
Remote Command Execution is where one Fusion controller forwards a single command to a remote Fusion controller. If you are a software developer, you can easily forward commands to 256 different Fusion controllers in the local area. Remote Command Execution is instantaneous, allowing you to process up to ten commands per second. Instantly control relays in the pool house, the kitchen, the office, or open any of the doors to your 20-car garage. Read sensors all around the estate to gather temperature, humidity, light levels and even ground moisture. Your software talks to one controller, Remote Access COMPLETELY handles communications to all 256 slaves.
Remote Data Collection is a Reactor feature. Using Remote Data Collection, Reactor has the ability to access up to 16 remote sensors on any of the first 16 wireless Fusion controllers that are connected to the Remote Access group. Reactor can be configured to control relays automatically based on remote sensor values.
The expansion possibilities are endless, as each Fusion controller can serve as a master that can talk to 256 remote slaves. You could easily setup five masters, each with a different interface technology and each capable of talking to all slaves in the area. In this way, it is possible to communicate to the entire group of Fusion controllers using RS-232, Bluetooth, USB, WiFi, and Ethernet, all at the same time. Combined with the capability of separating each Fusion controller up to one mile (yes, we tested it, one mile unobstructed line of site), Fusion controls working together can easily automate large industrial buildings with unlimited expansion capabilities.
Remote Access redefines the communication capabilities of a Fusion controller. We understand it is not possible to have everything in the same place at the same time. We think Remote Access is the perfect solution to a wide variety of automation tasks.
Requirements
Before getting too deep into Remote Access, please make sure that you meet the following requirements:
- At least two Fusion series controllers.
- Each Fusion controller must be configured for Remote Access using Base Station software.
- Each Fusion controller must have a Digi 802.15.4 wireless communications module installed in Port 2.
- Each 802.15.4 wireless communications module must be configured for API and set to 115.2K Baud using the same Pan ID.
- Each Fusion Master controller requires a TLEE expansion module. Slave devices do not require this expansion.
- You must be using the latest version of Base Station software http://www.ncd.io/start
Note: If you purchased your controller with Remote Access enabled, or you purchased a Remote Access communication module, you may skip Steps 2, 3, and 4.
Please check to make sure your Fusion controllers are ready for Remote Access.
Start by running Base Station software and clicking on the “Device Configuration” Button. Make Sure Port 2 is set for Remote Access as shown below:
Note: If you are unsure if your communications module is properly configured for Remote Access, run X-CTU available from www.Digi.com. Next, make sure the Digi 802.15.4 Wireless Communications Module is set for API, 115.2k Baud, and shares the same Pan ID as all other Fusion controllers. This step may require advanced knowledge of 802.15.4 communications.
Getting Started
Configuration
Remote Access configuration is about as easy as we know how to make it. Your Fusion controller simply needs to know the address of all the other remote Fusion controllers in the area. Make sure your remote devices are powered up during this process, as we need to “Build a Tunnel” to these devices. Building a tunnel copies important information about the remote device into the master Fusion controller.
To begin configuration of remote devices, simply run Base Station software.
- Click on “Remote Access (Tunneling to Nearby Wireless Devices)”
- Click on “Setup Remote Devices”
- Next, enter the serial number of every device you would like to remotely access and click the “Build Tunnel to Remote Device” button. If all goes well, you will get a green box that says “Tunnel Built!”. Keep track of the number shown to the left of the serial number. This is the number you will use to access each remote Fusion controller; you might want to put this number in a log book and put this number on the device itself. If the remote device is not within range, or you have entered the wrong serial number, a yellow box will appear with an error message.
The serial number is printed on the bottom of the 802.15.4 communications modules, as shown in the photo above. The serial number is highlighted in pink. The top set of numbers is not needed, as these numbers never change, and are hard-coded into the Fusion firmware. Keep track of the bottom group of numbers; create a log book that contains these serial numbers and their locations. Make sure there is no power connected to the Fusion controller when removing and reinserting communications modules. Also make sure you carefully align the pins when re-inserting the communications module.
The Log Book
Make sure that you keep a log book of each remote device. Record the serial number, installation location, and most importantly, the number to the left of the serial number in Base Station software (where you built your tunnels). This number will be used in Base Station software. If you choose to write software, you will need this number to access the remote device.
Tunneling to a Remote Device
Tunneling is the process of using a Fusion controller to completely take over another Fusion controller as though it were directly connected. Let’s say you have a Master Fusion controller with a USB interface and a Slave Fusion controller. Both controllers are equipped with Remote Access in this scenario. Normally, when you talk to the Master Fusion controller through the USB Port, you are talking directly to the master device controlling relays, reading sensors, and changing settings in Base Station software. When you tunnel to the slave controller, a new Base Station window opens, and this new window completely controls the slave device. When you exit the tunnel, control is returned to the Master controller. When you are tunneling to the slave, the computer sees the slave device as though it were directly connected to the USB port, even though data is actually going through the master controller to get to the slave through the USB port. You can enter a tunnel to any remote device, control that remote device, leave the tunnel, and tunnel to another remote device, and control that device as needed. Note that it is not possible to tunnel to a controller and sub-tunnel into another controller. Sub-tunneling introduces too many possibilities for communication errors and is intentionally blocked in the firmware.
If you are a software developer, you only need to learn two commands:
Decimal: 16 <Device> 0 0 Tunnel to the remote device number as recorded in your log book
Note: All subsequent commands will be sent to the remote device until you exit the tunnel.
16 255 255 255 Exit the Tunnel and return control to the local device
Hex: 0x10 <Device> 0x00 0x00 Tunnel to the remote device number as recorded in your log book
Note: All subsequent commands will be sent to the remote device until you exit the tunnel.
0x10 0xFF 0xFF 0xFF Exit the Tunnel and return control to the local device
Remote Command Execution
If you need to tell a relay to activate on a remote device, you do not have to tunnel to the remote device; you can simply forward your command to the remote device. Remote Command Execution is the process of sending your command to a remote device for execution. The remote device will execute your command and return a result just as though it were directly connected to your computer. Simply develop your software to talk to the master Fusion controller, all remote devices will respond to the master as though they were directly attached to your computer.
Here are some programming examples:
Decimal:
254 131 1 Toggles the relays on Bank 1 of the Master Fusion Controllers
15 <Device> 254 131 1 Toggles the relays on Bank 1 of the remote <Device>
(remote device as recorded in your log book)
Hexadecimal:
0xFE 0x83 0x01 Toggles the relays on Bank 1 of the Master Fusion Controllers
15 <Device> 0xFE 0x83 0x01 Toggles the relays on Bank 1 of the remote <Device> (remote device as recorded in your log book)
Remote Data Collection
The Reactor features of the Fusion Series controllers are also capable of reading sensors from remote Fusion controllers using Remote Access technology. Remote Access allows Reactor to gather sensor data from remote Fusion controllers. Once data has been collected, Reactor can decide to control relays as needed. Remote Data Collection is an automatic process, meaning it simply must be configured. Once configured, Fusion controllers automatically access each other, gathering data for evaluation and relay control. Remote Data Collection is easy to configure using Reactor.
Advanced Remote Access: API Communications to Multiple Fusion Controllers
If you are an experienced 802.15.4 software engineer, there is yet another feature of Remote Access that will benefit you. It is possible for you to write software that will speak to multiple 802.15.4 devices. Using the Remote Access features, multiple computers can speak to multiple devices, and data is always routed to the computer that originally asked for the data.
Developing software to speak to a Fusion class controller using the Remote Access features is very easy. We strongly suggest users purchase an 802.15.4 development kit from www.digi.com. You may contact Digi engineers to determine the best development kit for your application. Once you have reviewed the development kit in full, you will have a much better understanding of the topics that will be discussed in this section. Before proceeding, the Digi development kit will include X-CTU software, used to configure 802.15.4 communication modules (this software is a free download from www.digi.com).
To get started, you will need an 802.15.4 Modem (ZigMo Modem, available from http://www.ncd.io, part number: XBP24-AUI-EXT_ZIGMO). Note that we can ship you this modem pre-configured for Remote Access, just include a note in the “Special Instructions” during ordering to include “Set ZigMo to API Remote Access.”
If you have not purchased a pre-configured modem and want to setup your own modem, here is what you need:
Use Digi’s X-CTU software to configure the 802.14.4 Modem for API communications.
Make sure the 802.15.4 Modem is configured to use Pan ID 3332 (most of them are unless you have changed it).
In the interest of speed, the 802.15.4 Modem should be configured for 115.2K Baud.
Also, users should know how to check Device Manager for the selected COM port. You will need to open a COM port connection to the ZigMo Modem in your software.
Building a Packet
If you studied the Digi development kit for 802.15.4 communications, you know that an API Packet must be created to speak to the remote device. Here is a packet that we created to talk to one of our Fusion controllers using Remote Access. Note this packet will NOT work for you, as it references a serial number that is used by us for internal testing.
Decimal API Packet: 126 00 17 00 01 00 19 162 00 64 170 55 148 00 01 02 00 00 254 33 114
Hex API Packet: 7E 00 11 00 01 00 13 A2 00 40 AA 37 94 00 01 02 00 00 FE 21 72
Let’s deconstruct this packet, so you can fully understand what each byte does:
Byte, Hex, Dec
1, 7E, 126 API Header Byte, Always Used to Indicate the Beginning of 802.15.4 API Packet
2, 00, 0 Length of Packet, Most Significant Byte (MSB)
3, 11, 17 Length of Packet, Least Significant Byte (LSB)
4, 00, 0 Reserved for 802.15.4 Communications, ALWAYS Use 00
5, 01, 1 Reserved for 802.15.4 Communications, ALWAYS Use 01
6, 00, 0 Address of 802.15.4 Device (See Sticker Printed on Module)
7, 13, 19 Address of 802.15.4 Device (See Sticker Printed on Module)
8, A2, 162 Address of 802.15.4 Device (See Sticker Printed on Module)
9, 00, 0 Address of 802.15.4 Device (See Sticker Printed on Module)
10, 40, 64 Address of 802.15.4 Device (See Sticker Printed on Module)
11, AA, 170 Address of 802.15.4 Device (See Sticker Printed on Module)
12, 37, 55 Address of 802.15.4 Device (See Sticker Printed on Module)
13, 94, 148 Address of 802.15.4 Device (See Sticker Printed on Module)
14, 00, 0 Reserved for 802.15.4 Communications, ALWAYS Use 00
15, 01, 1 Transmit Counter, Use 1
16, 02, 2 Destination, Use 2
17, 00, 0 This Byte will be Returned in the Receive Packet, Use anything from 00 to FF.
18, 00, 0 This Byte will be Returned in the Receive Packet, Use anything from 00 to FF.
19, FE, 254 Device Command for Testing 2-Way Communications
20, 21, 33 Device Command for Testing 2-Way Communications
21, 72, 114 Checksum: See Notes Below
Packet Organization
Some elements of the packet shown above will need further explanation. The following sections will explain the most important parts of the packet organization.
Length of Packet (Bytes 2 and 3)
The length of the packet must be defined as soon as a packet is started. The length is a 16-bit value (word) that is broken into two separate bytes. The MSB is the most significant byte and the LSB is the least significant byte. For the purposes of working with NCD Fusion Series controllers, the MSB will always be 0 and the LSB will usually be a value under 50. In the sample packet provided, 17 bytes are defined as the packet length. There are 21 total bytes, subtract 3 header bytes, subtract the checksum byte (byte 21), and the result is 17.
Address Number
The Address Number (sometimes referred to as the serial number) of an 802.15.4 device is printed on a sticker on the bottom of the 802.15.4 communications module as shown below:
Serial Numbers (address numbers) are shown highlighted in the above photo.
Bytes 15 and 16
Bytes 15 and 16 are required by the Fusion controller and are not part of the Digi API frame. Byte 15 should always be 1, indicating this is a transmission. When a return packet is received, the Fusion controller will return 2, indicating this is a response from a remote Fusion controller. Byte 16 should always be 2, indicating data is to be sent back to the user on Port 2 (the Remote Access port). Note that users should not experiment with this value, as other values may cause unpredictable behavior. You cannot send data back to the user on Port 1, as Remote Access is strictly a Port 2 feature.
Reflect Bytes 17 and 18
Bytes 17 and 18 are what we call “Reflect” bytes; these bytes MUST be included in the transmission packet. These bytes are not used by the Digi API; however, they are used to help Fusion understand how to organize data that is returned from a remote Fusion controller. If you are constructing your own Digi API frame to talk to a remote Fusion controller, you can use these two bytes for anything you want. These bytes will be returned to you as part of the response from a Remote Fusion controller. Software developers may want to use these two bytes to help organize data coming back from multiple Fusion controllers. These bytes may contain any value from 0 to 255 (00 – FF Hex).
Bytes 19 and 20
Bytes 19 and 20 are command bytes. The values 254 33 is the Fusion command for testing two-way communications, which causes the Fusion controller to respond with 85 or 86. Note that some commands may be much longer than 2 bytes. In this case, simply add the additional bytes for Byte 21, 22, etc. Do not forget to adjust Byte 3 for the length of the Digi API frame.
Calculating the Checksum
To Calculate the Checksum, add the value of Bytes 4 through 21 together:
00+01+00+19+162+00+64+170+55+148+00+01+02+00+00+254+33=909
Now we extract the lower 8 bits of the value 909:
The LSB Value of 909 = 141 (Use this equation: 909 AND 255 = 114, use the match function AND, some programming languages use &)
Now, subtract 141 from 255: 255 – 141 = 114
114 is your checksum value (indicated on Byte 21 in our sample above).
Receiving an 802.15.4 API Frame
Until now, we have been discussing sending data to a Remote Fusion controller using a Digi API Frame. Once a command is sent to a Fusion controller, the controller will process the command and send a response. In our sample above, we are sending 254 33, the command used to test 2-way communications with a Fusion controller. The Fusion controller will be responding with an 85 or 86. Since we are speaking to the remote device using a Digi API Frame, the remote device will respond with a Digi API Frame, which will include or 85 or 86 response that we are looking for (along with a few other important values).
As we continue our sample, we need to decode the Digi API frame that is sent from the remote device. The raw, undecoded Digi API frame will look like this:
Decimal API Packet Received: 126 0 16 128 0 19 162 0 64 170 55 148 40 0 2 2 0 0 85 148
Hex API Packet Received: 7E 00 10 80 00 13 A2 00 40 AA 37 94 28 00 02 02 00 00 55 94
| Byte | Hex | Dec | Description |
| 1 | 7E | 126 | API Header Byte |
| 2 | 0 | 0 | Length of Packet, Most Significant Byte (MSB) |
| 3 | 10 | 16 | Length of Packet, Least Significant Byte (LSB) |
| 4 | 80 | 128 | Flag, indicating Received Data, it will always be 80 |
| 5 | 0 | 0 | Address of 802.15.4 Device that is Responding |
| 6 | 13 | 19 | Address of 802.15.4 Device that is Responding |
| 7 | A2 | 162 | Address of 802.15.4 Device that is Responding |
| 8 | 0 | 0 | Address of 802.15.4 Device that is Responding |
| 9 | 40 | 64 | Address of 802.15.4 Device that is Responding |
| 10 | AA | 170 | Address of 802.15.4 Device that is Responding |
| 11 | 37 | 55 | Address of 802.15.4 Device that is Responding |
| 12 | 94 | 148 | Address of 802.15.4 Device that is Responding |
| 13 | 28 | 40 | Signal Strength of Remote Device |
| 14 | 0 | 0 | Option Byte, will always be 0 for Fusion controllers |
| 15 | 2 | 2 | Fusion Transmit Counter Byte |
| 16 | 2 | 2 | Fusion Data Returned on Port 2 |
| 17 | 0 | 0 | Reflect Byte (Same as Transmit Packet Byte 17) |
| 18 | 0 | 0 | Reflect Byte (Same as Transmit Packet Byte 18) |
| 19 | 55 | 85 | Fusion Response from the Controller |
| 20 | 94 | 148 | Checksum |
Summary
In summary, we have sent 254 33 to test two-way communications with a remote Fusion controller. The controller sent us back 85 (Byte 19 of the Digi API return frame). From here, you should have a complete framework for sending and receiving data using the Remote Access features in combination with a Digi API frame.
Special Notes
The test two-way command was sent using byte commands 254 33. This command can be encoded using the NCD API Codec. The response will be API encoded as well. Please see the API Codec Quick Start Guide for more information on encoding commands using NCD API Codec. When using the NCD API Codec in combination with the Digi API Frame, users benefit from two checksums calculated in two different ways, which should completely eliminate the potential for errant data transfers.
900HP-S3B Wireless Communications
NCD Fusion class controllers are also capable of sending/receiving data using the Digi 900HP-S3B Wireless Mesh communications protocol. The packet structure is very similar to above, here are some sample API frames that demonstrate communications. Please note the target serial number is 0, 19, 162, 0, 65, 120, 143, 155 (decimal), this will need to be changed. Note the checksum will change accordingly.
Test 2-Way Communications
This command sends 254, 33 for testing two way communications between the modem and the remote device. The controller responds with 85. Note that 1, 2, 0, 0 appear before the command, this is very similar to the above structure. Similarly, this controller will respond with 2, 2, 0, 0 before 85 payload byte.
Send:126 00 20 16 00 00 19 162 00 65 120 143 155 255 254 00 00 01 02 00 00 254 33 56
Rec:126 00 17 144 00 19 162 00 65 120 143 155 255 254 193 02 02 00 00 85 192
Reading the Type of Current Monitoring Controller
This command can be used with NCD Current Monitoring controllers to read the type of current monitoring device attached. Note that 1, 2, 0, 0 appear before the command; similarly, this controller will respond with 2, 2, 0, 0 before actual payload data.
Send:126 00 32 16 00 00 19 162 00 65 120 143 155 255 254 00 00 01 02 00 00 188 50 10 84 146 106 02 00 00 00 00 254 85 07 179
Rec:126 00 23 144 00 19 162 00 65 120 143 155 255 254 193 02 02 00 00 04 70 06 01 00 00 81 115
Reading Current
The following command demonstrates reading current from a current monitoring controller using wireless communications. Note that 1, 2, 0, 0 appear before the command; similarly, this controller will respond with 2, 2, 0, 0 before actual payload data.
Send:126 00 32 16 00 00 19 162 00 65 120 143 155 255 254 00 00 01 02 00 00 188 50 10 84 146 106 01 01 06 00 00 04 85 19 155
Rec:126 00 35 144 00 19 162 00 65 120 143 155 255 254 193 02 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 21