Allegion Developer Portal
Allegion Developer Portal
This document compiles the changes from the RSI-485 protocol which was intended for the AD-400 and PIM ONR (Over the Network Re-flash), and implemented into the ENGAGE Gateway. Please note that the document Schlage AD-series and the ENGAGE RSI Protocol Specification contains all of the protocol specifications. This document is intended solely as reference for the major difference between ONR implementation with the AD-400 / PIM, and the Gateway.
This new command shall be issued for an ENGAGE device where the previous command FW_FILE_BLOCK (15H/02H) would have been sent to a PIM. This allows accommodation for the Gateway’s larger firmware image size which exceeds the limits of the other command FW_FILE_BLOCK (15H/02H). LARGE_FW_FILE_BLOCK (15H/06H) supports all ENGAGE devices, whereas FW_FILE_BLOCK (15H/02H) may only support certain ENGAGE edge devices.
This new response shall be issued for an ENGAGE device where the previous response FW_FILE_BLOCK_RESP would have been sent from a PIM.
The major implementation difference with the new RSI commands and responses for ENGAGE ONR is that the Gateway will save the entire firmware image in its memory before transferring the entire firmware image to the edge device. ONR for the PIM was implemented such that each 64 byte block of data would be transferred to the AD-400 before the PIM would accept the next 64 byte block of data, this is an inherently different operation for the Gateway.
The RSI command END_FW_DOWNLOAD must still be issued at the conclusion of the firmware transfer from the ACP to the Gateway just as it was required to be issued to the PIM. Once the Gateway receives this command it will begin to transfer the firmware image to the edge device.
For ONR implementation with the PIM, when the END_FW_DOWNLOAD command was issued, the PIM would have already sent the final 64 byte firmware block to the AD-400. The Gateway internally stores each of the 64 byte blocks and transfer the complete edge device firmware image to the edge device when the END_FW_DOWNLOAD command is received.
Timing for this command is inherently different with the ENGAGE system. A typical firmware transfer from the Gateway to an edge device can take around one hour once the Gateway has received the END_FW_DOWNLOAD command. This number is multiplied by the number of connected edge devices to a single Gateway, therefore a Gateway with 10 linked NDE locks can take 10 hours for the NDE firmware to complete the transfer to all 10 linked locks.
If any of the edge devices have a low battery condition after the start of the firmware download to the Gateway, the Gateway continues with the ONR process on all of the other linked edge devices having the same device type, which do not have low battery conditions. There is a 36 hour timeout on END_FW_DOWNLOAD, therefore low battery conditions should be fixed as soon as possible to prevent from the ONR process needing to start over from the beginning for the devices which had a low battery condition. If the edge device with a low battery condition is not fixed within the 36 hour timeout, the Gateway sets the ONR_STATUS to 0x55 (Error: Gateway failed to transfer firmware image to all targeted devices).
ENGAGE ONR only supports firmware updates on a device type basis, therefore if a single Gateway has 3 NDE’s, 3 LE’s, and 4 RMRU’s, linked to it, and a command is issued to only update the firmware on one of the 3 LE’s, all 3 LE’s will automatically be updated. The Gateway reports the actual lock bitmap of the devices that are being updated via ONR_STATUS. Only a single lock type (LE in the example above) is able to be downloaded at any single time.
The Gateway has implemented a 36 hour timeout on the START_FW_DOWNLOAD command if the target edge device is disconnected from the Gateway when the START_FW_DOWNLOAD command is sent. The Gateway does not block the START_FW_DOWNLOAD or START_FW_REFLASH commands if the edge device is offline at the time the command is received. The Gateway executes the command when the ENGAGE edge device re-connects to the Gateway.
The Gateway responds to the START_FW_DOWNLOAD command with 0x36 (Error: Target has low batteries) if any of the edge devices in the requested device type have a low battery. The Gateway does not proceed with the start of the firmware download process until the low battery condition has been resolved. If the low battery condition happens after the firmware download process has already started and before the END_FW_DOWNLOAD command has been received, the Gateway does not report the low battery condition until after the END_FW_DOWNLOAD_RESP, at which time the ONR_STATUS reports 0x36 (Error: Target has low batteries).
If any of the edge devices has a low battery condition after the start of the firmware download to the Gateway, the Gateway continues with the ONR process on all of the other linked edge devices having the same device type, which do not have low battery conditions. There is a 36 hour timeout on END_FW_DOWNLOAD; therefore low battery conditions should be fixed as soon as possible to prevent from the ONR process needing to start over from the beginning for the devices which had a low battery condition.
Please see comments from START_FW_DOWNLOAD (15H/00H) regarding firmware updates by device type. The same applies to ABORT_FW_DOWNLOAD.
Please see comments from START_FW_DOWNLOAD (15H/00H) regarding firmware updates by device type. The same applies to START_FW_REFLASH.
The Gateway has not implemented a timeout on the START_FW_REFLASH command. The Gateway does not block the START_FW_DOWNLOAD or START_FW_REFLASH commands if the edge device is offline at the time the command is received. The Gateway executes the command when the ENGAGE edge device re-connects to the Gateway.
The Gateway responds to the START_FW_REFLASH command with 0x79 (Error: Device has a low battery) if any of the edge devices in the requested device type have a low battery. The Gateway does not instruct any of the edge device types to start their firmware re-flash process until the low battery condition has been resolved. If the low battery condition happens after the firmware re-flash process has already started and before the re-flash is completed, the Gateway reports the status with an ONR_STATUS of 0x36 (Error: Target has low batteries).
Due to the inherent nature of the Gateway and BLE communication, 0x10 (Target WAPM currently offline) is not sent as part of the ONR_STATUS message for ENGAGE ONR. If an edge device temporarily disconnects from a Gateway during the firmware transfer, the Gateway automatically resumes sending the firmware package to the edge device once the device re-connects.
Additionally, the Gateway does not block the START_FW_DOWNLOAD or START_FW_REFLASH commands if the edge device is offline at the time the command is received. The Gateway executes the command when the ENGAGE edge device re-connects to the Gateway.
The Gateway does not report 0x11 (Error Encountered) on the ONR Status byte of APM_STATUS_EXTENDED for edge device disconnections.
The Gateway does report 0x11 (Error Encountered) on the ONR Status byte of APM_STATUS_EXTENDED for edge device low battery conditions if ONR_STATUS is reporting 0x36 (Error: Target has low batteries).
The Gateway does not report 0x11 (Error Encountered) on the ONR Status byte of RSD_STATUS_CHANGE_EXTENDED for edge device disconnections.
The Gateway does report 0x11 (Error Encountered) on the ONR Status byte of RSD_STATUS_CHANGE_EXTENDED for edge device low battery conditions if ONR_STATUS is reporting 0x36 (Error: Target has low batteries).
The Gateway does not report 0x11 (Error Encountered) on the ONR Status byte of RSD_STATUS_CARDDATA_EXTENDED for edge device disconnections.
The Gateway does report 0x11 (Error Encountered) on the ONR Status byte of RSD_STATUS_CARDDATE_EXTENDED for edge device low battery conditions if ONR_STATUS is reporting 0x36 (Error: Target has low batteries).
Please see the Schlage AD-series document and the ENGAGE RSI Protocol Specification for error codes which apply only to the AD-400 / PIM or the ENGAGE Platform.
NOTE: All file validation of firmware is completed by the device once the device has received the entire firmware image and has been issued the command to re-flash the firmware. The Gateway does not do any file validation or checking of the 64 byte blocks of data being transferred to the edge devices.