[RHA-831] - OTA Adaptation for Daintree ControlScope Networks
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
Known Issues
[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
Files:
This release has been retired in favour of RapidHA v1.5.7and is no longer supported
Release Notes:
New Features
[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)
Bug Fixes
[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
Known Issues
[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
Files:
This release has been retired in favour of RapidHA v1.5.7and is no longer supported.