27.1.0

Created by Adam Daley, Modified on Wed, 3 Jun at 10:03 AM by Adam Daley

Dependencies

Components

Changes

Added support for our new elevator control feature.
Added support for offline PIN for BLE locks.
Support for a unified BLE driver, allowing for a single driver to be used to communicated with older IQs using the BGM111 module and the newer ones that uses BGM220.
Support to scan available mobile networks and report them to our backend
Stability improvements to the IQ's M2M reconnection logic, removing unnecessary dongle reboots where they were not needed.
Introduced improvements that reduce the likelihood of delays when responding to lock requests, particularly under high system load.
Prevented RF parameters from being allowed to be overwritten when locks are already attached to the IQ.
Added support to request RF data if it is currently unknown. This is not expected but serves more as a backend validation mechanism.

Bug Fixes:

Fixed the issue where the IQ rebooted if it could not start or end the office mode alarm, that was triggered when office mode or automatic office mode could not be disabled.
WR Keypad information was only persisted in lock initialization, resulting in reboots not indicating that the locks have a keypad
Fixed the issue where the IQ was sending multiple lock reconnection events to the backend, even if only one reconnection happened
SAMData was sometimes not sent to lock, resulting in the lock not to react to tags or digital keys. The workaround for this was to keep detaching and reattaching the lock and is no longer needed
Near detection mode was not enabled correctly on Wall readers, thus both near and far opening should now work as expected.

Known limitations in this release with regards to relay based elevator control:

Limited number of events reported to the backend if the CU was not connected to the IQ for prolong periods and openings were performed. When relays are triggered, they generate events when the outputs are activated and deactivated. The amount of events are dependent on how many relays were triggered at the same time. When the CU is not connected to the IQ, the CU stores these events, but the CU has a limit on how many it can store. As a result, the CU will only report the last groups of events. The entries that will be reported are dependent on the amount of relays triggered, and thus we can not specify how many events will be reported to the backend when the CU connects to the IQ again.
Connectivity change between the IQ and the backend requires no action and won't affect door operation; the new relay-based elevator control has known event-reporting limitations in this release.
The IQ will not receive an opening request for the second credential presented to a wall reader, if you presented the second credential in quick succession to the first and the IQ is still processing events from the first opening. This will result in the relays not being activated for the second credential, and will require presenting the credential again.