MQTT support for denied access events and advanced local time-based controls

Feature Request

Please add MQTT support for denied access events, including cases where access is blocked due to time profiles, invalid keypad codes, or authorization restrictions.
Right now, only actions that are actually executed are published via lockActionEvent. When access is refused (e.g., outside a time window), no MQTT message is sent, making it impossible for local systems to react.

Reasoning

  • When Nuki operates without cloud access, the device may lose its internal time, which reduces reliability of built-in time profiles.
  • If denied attempts were published via MQTT, Home Assistant or other local systems could:
    • log rejected access attempts,
    • send push notifications,
    • enforce complex or custom schedules (e.g., “every second week after 18:00”),
    • enable temporary access via Home-Assistant variables for contractors, guests or service personnel,
    • improve security auditing by showing all attempts, not only successful ones.

Requested additions

  1. Publish a new MQTT event whenever access is denied, including a reason code:
  • time-profile violation
  • invalid keypad code
  • disabled/expired authorization
  • keypad/fob/button attempt outside allowed hours
  1. Alternatively, extend lockActionEvent with a status field indicating that an action was attempted but blocked.

Additional comments

The goal is only to expose already existing local events so that local automation systems can react accordingly.

This would significantly improve offline reliability and enable advanced access-control logic without altering the intended scope of the MQTT API.