You seriously think that I didn’t think to do that?
Unfortunately the REST sensor, believe it or not, doesn’t provide a result status http code. So if that’s not available, you can’t even retry the call, and with the bridge limitation of 1 call, retrying is not the recommended approach. Broken json response is due to the failure of the rest call.
Bridges are all the same, make sure you’re on latest firmware, and if you can, post the /log output of the bridge so we can take a look at the timings. The 503 error is well known and documented, it has to do with multiple commands run at the same time to the bridge. So if you want to sniff the network to understand what’s happening, try to catch which client is sending commands to the bridge.
I have created an automation to send a notification if the door is unlocked whilst my alarm is armed away.
This works fine however if I understand automations correctly I believe this is checking the status of the lock at frequent intervals (I don’t know what the default value in HA is?) and therefore waking the smart lock more frequently, thus consuming more battery. If there a way to set this up without HA constantly checking the status of the lock?
Hi,
this integration is reporting the status of the lock to HA a couple of seconds after it changed. There is IMO no need to check (poll) the status from the lock/bridge.
The status is reflected in lock.nuki_lock_action - in your automation you’d check if this changes from locked to unlocked.
Nope, when the state of the lock changes the lock reports that via callback to HA, the automation is monitoring and reacting on a change of lock.nuki_lock_action
This integration/automation has been created exactly because the official integration relied on polling the bridge to get the lock status every X seconds, so notifications were significantly delayed. The battery is not an issue also for official integration, because the bridge communicates with the lock via BT/BLE, then caches its status, so when you query the bridge, even through polling, you never communicate with the lock, but with the bridge.
The Nuki Card leverages the bridge callback functionality: when an event happens, the bridge notifies HA, and we intercept this through an automation trigger. So we never poll the bridge.
For the rest, Joerg has answered to your questions.
This is not technically correct: the nuki card creates and updates lock.nuki_lock_action status.
Basically, it receives the callback, analyzes it, and updates the template lock, the door sensor, etc.
Joerg, thanks for all the support you give to users while I’m not around, I appreciate it.
Than please let me know…
As said I was referring to his automation:
“if my alarm is armed and the lock state changes from locked to unlock (by checking lock.nuki_lock_action) send me a notification”
the automation is monitoring and reacting on a change of lock.nuki_lock_action
is technically not correct. But really, it’s not important, I just wanted to explain that all the sensors are created and managed by the automation, and updated through the info received from the bridge callback.
I was not talking about the automation of the nuki card.
But as said please enlighten me - i feel we talk past each other.
This automation is checking if the value of lock.nuki_lock_action changes, no?
alias: Nuki was unlocked
description: ''
trigger:
- platform: state
entity_id: lock.nuki_lock_action
from: locked
to: unlocked
condition: []
action:
- service: notify.events
data:
message: Nuki was unlocked
title: Nuki was unlocked
mode: single
Ok, I understand now you were referring to his automation, not to Nuki Card. When you wrote “the automation” I thought you were referring to Nuki Card.
