.homeychangelog.json

{
  "3.0.6": { "en": "2020-11-03.\n* New condition flow card \"The contact alarm changed {less|more} than n seconds ago\" (for more information see https://github.com/pfreguia/nuki.homey/wiki/Nuki-Smart-Lock-and-Homey-presence )\n* Open (unlatch) a Smart Lock or an Opener by app UI or by action flow card: added a safety timer that restores the correct state in case the final event from the device is not received.\n* The new pairing procedure introduced in v3.0.5 always shows the page for the selection of a Bridge even if a single bridge was detected (this does not compromise the pairing).\n* Bug: the condition flow card \"Doorbell rang less than n seconds ago\" introduced in version v.3.0.3 was always evaluated as false." },
  "3.0.5": { "en": "2020-10-15.\n* Complete German translation of the app UI (thanks to Dirk).\n* Pairing procedure has been rewritten. The new pairing procedure asks automatically the Nuki Servers for the list of registered Bridges (each Nuki Bridge is always registered at the Nuki Servers infrastructure).\nThe Nuki Servers's answer can be one of the following:\n  1. More than one Bridge is registered. The user must select a Bridge from the list of Bridges.\n  2. A single Bridge is registered (or the user selected a Bridge in the previous step). The new pairing procedure tries to authenticate against the Bridge via HTTP API. If API Quick Discovery is enabled, Authentication requires the user to press the button on the Bridge. Once authenticated, the procedure asks the Bridge for the list of its devices (Smart Locks and Openers).\n  3. Other (unexpected answer, Nuki Servers are unreachable, ...). Go to manual pairing.\nThe Nuki Bridge's answer can be one of the following:\n  1. HTTP API is not enabled on the Bridge. Pairing failure.\n  2. API Quick Discovery is not enabled on the Bridge. Go to manual paring.\n  3. API Quick Discovery is enabled but the user did not press the button on the Nuki Bridge within 30 seconds. Go to manual paring.\n  4. The Bridge returned a valid device list. The user can select the device they want to add to Homey and the pairing is successful.\n  5. Other (answer not received, unexpected answer, ...). Pairing failure.\nThe manual pairing procedure prompts the user to enter IP address, port and API Token of the Bridge. If the entered data are correct, the pairing procedure retrieves the device list from the Bridge, the user can select the device they want to add to Homey and the pairing is successful.\nThus, in the most common case (a single Bridge, HTTP API and API Quick Discovery already enabled in the Bridge) the paring procedure only requires the user to press the button on the Bridge.\n* Previous versions of Nuki Direct lose all devices and flows if the local IP address Homey changes. This version loses neither devices nor flows.\n* Some users have reported Nuki Direct's slowness in updating the status of the devices in the first few minutes after a restart. Indeed, previous versions of Nuki Direct may take up to 5 minutes after a restart for the device status to update. This version updates the devices status immediately after the initialization.\n* Nuki Direct v3.0.0 introduced the ability to mark as unavailable all the devices of an unreachable Bridge. This version adds the ability to mark as unavailable a device that is unreachable by the Bridge as well." },
  "3.0.4": { "en": "2020-09-23.\n* Overlapping actions. Electromechanical actions such as Unlock or Lock take time to actuate (from a few seconds to a few tens of seconds for the Lock \u2019n\u2019 Go). Therefore, it may occur that an action (from user interface or from an action flow) starts when another action is already in progress. Previous versions of Nuki Direct did not handle explicitly overlapping actions and this could lead to unexpected behaviors. This version applies the following rules to overlapping actions (i.e.: action B starts before the action A is finished). RULE 1: If action B is the same as action A (for example: B is a Lock action in progress and A is also a Lock action) then action B simply waits for the completion of A and return success. RULE 2: If action B is different from action A (for example: A is a Lock action in progress and B is an Open/Unlatch action) then action B is rejected. The action flow card \"Nuki action\" provides a new setting that optionally enables the following RULE 3: If the action B defined in the flow card is different from action A (same as RULE 2) then the flow card defers the execution of action B after the completion of action A. These rules also apply to more than two actions.\n* The ability to open a door directly from the Homey app user interface has been reintroduced (it was removed in v3.0.3 for security reason). In order to avoid accidental opening the original tap gesture has been replaced by a swipe gesture on a slider. The slider can be hidden in the \"Advanced Settings\" of the device.\n* Added German UI language (partial translation).\n* Manual pairing procedure improved (stronger input verification; \"Test connection\" button, \"Connect\" button, \"Close\" button merged into a single \"Connect\" button).\n* Keypad battery (minimum firmware version required: Keypad firmware 1.7, Bridge firmware 2.7.0/1.17.1, Smart Lock firmware 2.8.3/1.10.1, Opener firmware 1.5.2). The availability of a Nuki Keypad is automatically detected. If a Keypad is detected, the Keypad battery status is shown in the \"Battery\" page of the device (Smart Lock or Opener) it is paired with. Also added trigger flow cards and condition flow card for Keypad battery alarm.\n* Fixed an error introduced in v3.0.3: the \"Open|Unlatch\" action of the \"Nuki action\" action flow cards did not work." },
  "3.0.3": { "en": "2020-08-28.\nThis is the first version after the handover of the app development. New developer and new intents.\n* Differentiate the aspect from the Nuki app by Athom to avoid appearing as a duplicate app.\nThe new name \"Nuki Direct\" emphasizes straight, fast, reliable communication between Homey and Nuki devices. The app's icon and color have also been changed.\n* Highlight the extra features offered by Nuki and implemented by this app over the standard features of Homey.\nFor this purpose, the icon and title of the device status displayed by the app have been changed; the trigger flow cards related to specific Nuki events have also been modified.\n* Make Smart Lock and Opener devices more homogeneous.\nBefore this version the devices were managed by two different developers and it was difficult to adopt the same model and the same terminology for the two devices.\n* Simplify the app.\nWhenever a new version is released, new features are introduced; when introducing new features, existing features should also be re-evaluated: Is the new functionality consistent with the existing ones? Is the application getting too complicated? Am I creating overlapping features? After this re-evaluation the Continuous mode of the Opener and the Smart Lock battery status have been simplified. The device settings have been reordered. The pairing instructions have been refined.\n* Improve security.\nIn my opinion the possibility to unlatch a Smart Lock (or an Opener) directly from the Homey app user interface is dangerous; a single wrong tap can open the door when you are miles away from home! For now, I have hidden the unlatch command from the user interface. If there are no counter-observations, I will remove it completely in the future.\n* Resolve known issues.\nThe \"Nuki Opener Ring Action\" trigger flow card added to version 3.0.0 did not work correctly; furthermore, the Timestamp tag associated with this flow-card was difficult to use in practice. The problem has been solved and the tag has been removed and replaced by a new condition flow card: \"Doorbell rang {less | more} than n seconds ago\"." },
  "3.0.2": { "en": "2020-08-17.\n* App structure refactored using Homeycompose model in order to reduce the duplicated code between Smart Lock driver and Opener driver.\n* Smart Lock and Opener have different objects (Smart Lock: 4xAA batteries; Opener: power supply or 4xAAA batteries). Created a specific Energy object for each driver.\n* Added to Opener an event handler that reacts immediately to Power Settings change.\n* Fixed a small comparison error that prevents the manual pairing of a Smart Lock device.\n*Manual pairing of Smart Lock and Opener: fixed the resolved promise argument (the custom view needs a result object, not the true constant)." },
  "3.0.1": { "en": "2020-08-08.\n* Started updating the app structure using Homeycompose.\n* Fixed manual pairing." },
  "3.0.0": { "en": "2020-08-06.\n* Updated to SDK3 (this require Homey firmware 5.x.y).\n* Fixed issue with triggercards for Continuous mode for Nuki opener.\n* Added instructions in pairing wizard.\n* Added battery percentage for Smart Lock (requires Nuki Bridge firmware 2.7.0 and Nuki Lock firmware 2.8.1).\n* Added triggercard for Opener's ring actions including timestamp token (requires Nuki Bridge firmware 2.7.0 and Nuki Opener firmware 1.5.1).\n* Added Nuki Opener setting for configuring battery powered device. When enabled the battery alarm capability will be available.\n* Added functionality where the Nuki will show as unreachable when it cant be reached." },
  "1.4.0": { "en": "2020-06-15.\n* Added support for the door sensor of the Nuki lock. This requires bridge firmware 2.6.0/1.16.0 which is currently in beta. Please be aware that the Nuki callbacks of the door sensor are not real time. So there will be a delay in response which can also result in missed events." },
  "1.3.0": { "en": "2020-06-01.\n* Added support for Nuki Opener." },
  "1.2.0": { "en": "2020-05-25.\n* Added a manual pairing fallback mechanism, specifically useful for pairing a software Nuki Bridge." },
  "1.1.2": { "en": "2019-12-04.\n* Fixed custom condition card for (un)locked but also deprecated it because it is a duplicate of the default condition cards for the locked capability." },
  "1.1.1": { "en": "2019-11-17.\n* Fix for alarm_battery capability due to a bug in Homey core." },
  "1.1.0": { "en": "2019-11-11.\n* Changed endpoint from /lockState to /list for polling the lock. The /list endpoints gets the cached state from the lock and using this will spare the batteries of the lock.\n* Added the alarm_battery capability and deprecated the previous \"Battery Critical\" trigger card. Please switch to the default \"Battery Alarm\" trigger card as the old one does not work anymore." },
  "1.0.3": { "en": "2019-03-20.\n* Fix: removed code to set the device unavailable when it is not reachable (due to know issue with 503 errors).\n* Fix: only trigger battery critical once until the batteries have been replaced." },
  "1.0.2": { "en": "2019-03-13.\n* Fix: small workaround for random 503 errors from Nuki Bridge." },
  "1.0.1": { "en": "2019-03-13.\n* Fix: small fix for quick action." }
}