None

[RHA-837] - RF Output Power and Channel Agility

• All previous outstanding issues with RF Output Power have been resolved
• When moving channels, the application will now apply the appropriate RF Output Power when scanning on the new channel

None

None

• Implemented functionality to ensure correct operation of OTA upgrades on both standard HA 1.2 and Daintree ControlScope networks

[RHA-847] - Attribute Reporting Behaving Incorrectly when Manufacturing Bit Enabled

• Per summary, corrected an issue where incoming Attribute Reports with the Manufacturing Bit enabled in Frame Control were rejected by the application with a default response

[RHA-837] - RF Output Power and Channel Agility

• Though the more critical issue of the application transmitting at maximum output during the Scan/Join cycle has been resolved (see Bug Fixes) there remains a secondary issue:

• The application will always apply the RF Output Power of the first channel the application joined to

• This implies that when moving to a new network (i.e. in pursuit of the coordinator) the application will apply the same RF Output Power when transmitting on the new channel

• This issue is minor, but we would caution that users should avoid operating the application on Channel 26 where possible

[RHA-796] - Application Version Request

• Application now includes facilities for querying the Virtual Host application version

• New frames under Utility command group (PH 0x55):

• Application Version Count Request (0x06) (H > M)

• Application Version Count Response (0x07) (M > H)

• Application Version Request (0x08) (H > M)

• Application Version Response (0x09) (M > H)

[RHA-805] - Incoming Attribute Report Passthrough

• Application now includes facilities for enabling passthrough of incoming Attribute Reports to the Host

• New frame under ZigBee Configuration Support command group (PH 0x03):

• • Attribute Report Passthrough Control (SH 0x26) (H > M)

     

[RHA-837] - RF Output Power

• It was determined that regardless of the RF Output Power configuration applied at manufacturing time, the application would transmit at maximum output during the Scan/Join cycle

• The application would then apply the expected RF Output Power once joined to the network

• This issue has since been corrected, with the RF Output Power being applied during the Scan/Join cycle as expected
  
  

[RHA-837] - RF Output Power and Channel Agility

• Though the more critical issue of the application transmitting at maximum output during the Scan/Join cycle has been resolved (see Bug Fixes) there remains a secondary issue:

• The application will always apply the RF Output Power of the first channel the application joined to

• This implies that when moving to a new network (i.e. in pursuit of the coordinator) the application will apply the same RF Output Power when transmitting on the new channel

• This issue is minor, but we would caution that users should avoid operating the application on Channel 26 where possible