The app number this came from.

General purpose bitfield. b0: 1: API is performing a Query. When the API sends the lower layer a query, the response to the query should have this bit set. This will indicate to the API that it should not fire an event. This will be used when the user tries to read a property (a query will be sent by the API, the API will wait for a timeout. The thread that reads from the queue will either fire an event or not based on this bit. 0: API is setting the given value. Lower layer when it responds should have this bit cleared, which means that the API will fire an event back to the programmer.

Size of the structure, including itself [AutoUpdateConstants.ControlSystemToDeviceUpdateProgressStructOverhead + CurrentFileNameBeingTransferredToSpecificDevice.Length + CurrentNameOfDeviceBeingTransferredTo.Length]

Valid for ControlSystemToDeviceUpdateProgress.

Status of the transfer: 0: Started, 1: Completed successfully, 2: Already Up to date, 3:"Configured" (auto-updatable/Delegated devices). 100+: Failures This is propagated to the user via the eCurrentTransferStatus in the AutoUpdateEventArgs.cs file. This is the status of the overall device. For example, if you are updating firmware on a SWAMP and 3 attached expanders, this status would be of the entire process; i.e. when you start transferring, it is 0, and then when you finish with the SWAMP + 3 expanders, it would go to completed.

The current file number being transferred from the control system out of NumberOfDevicesToSendTo total. If this system had a SWAMP + CEN-TRACK, this would either be 1 or 2 (If the SWAMP and all of it's subcomponents is the first device, then this is 1. When we finally get to the CEN-TRACK and it's subcomponents, this changes to 2).

The current file name being transferred from the control system to a specific device concatenated with the device name, separated by a comma. i.e. MyFirmware.zip,Slot-05.IP-ID-25.ID-AA.RF-ID-07:CLW-DIM-EX-P As a modification for an enhancement, we are altering this to deal with subcomponents {string:FirmwareFile},{string:Fully Qualified Path to Primary Device},{string:Subdevice},{string:Status of subDevice = InProgress|Complete|Failed|AlreadyUpToDate} For a single device like a dimmer this would look like: MyFirmware.zip,Slot-05.IP-ID-25.ID-AA.RF-ID-07:CLW-DIM-EX-P,Slot-05.IP-ID-25.ID-AA.RF-ID-07:CLW-DIM-EX-P,InProgress Note that the status, since it's a single device, would track the autoUpdateStatus member. For a device with a subcomponent, this would look like: MyFirmware.zip,IP-ID-25:CEN-TRACK,IP-ID-25.Slot-01:ATC-AMFMXM,InProgress When this is broken up for AUSTATUS or the API, the subcomponent and subcomponent status may show if it's an older API.

The length of the CurrentFileNameAndDeviceNameBuffer field.

The current file number being transferred from the control system out of NumberOfFilesToSendFromControlSystemToSpecificDevice total. For example, if this were a SWAMP + 3 expanders, it would be 1 or 2 or 3 or 4, depending on which device we are updating.

The current file size in bytes being transferred from the control system to a specific device.

The number of files that need to be transferred from the control system to all devices. If this system had a SWAMP + CEN-TRACK, this would be 2 (i.e. we have 2 devices to send to). This does NOT reflect the subcomponents; that is handled by CurrentFileNumberBeingTransferredFromControlSystemToSpecificDevice and NumberOfFilesToSendFromControlSystemToSpecificDevice.

The number of files that need to be transferred from the control system to a specific device. For example, if this is a SWAMP + 3 expanders, this would be 4.