Replies: 1 comment 7 replies
|
Hi, Can you confirm you're using the latest version of Nuki Hub. You say you try to unlatch three times, this means you're sending the command three times in a row? This should not be necessary, and I'd not recommend doing this. You can either:
The messages about tasks are normal and are there to confirm that the tasks arent't stuck. |
7 replies
|
This happens regularly (at least now, since I sent the logs to a MySQL...), there's a "Command failed timeout", but after the Smartlock unlatched (not sure, if this is related) logfile with successSometimes I'll get these, without any lock action before or after: error while querying the battery stateWhat I'm stumbling over is the fact, that if errors occured, than precisely a few msec after Nuki Hub reconnects to the MQTT broker, which to me happens a bit too often? I searched the log and I can't find any instance of an MQTT reconnect without an Smartlock-action beforehand. this was yesterday, and if I remember correctly, my son ended up using the App to unlock... MQTT reconnect while unlatch-actionI attached the info page also. Info Page |
|
The command failed timeout can happen from time to time, it's just failed bluetooth communication. It queries the status until the action has completed, the command timeout refers to the bluetooth command to update that status. I'd observer the uptime node, can you log it? Whenever the ESP reboots it resets to 0. If you can put that log into a chart, you can quite easily see how often your ESP reboots. |
|
I'll persist the uptime topic to have a look on it. But I don't think that's what's happening? right now, uptime is at ~2 days (2840 min), but the last "error" was logged yesterday 10:30, which is around 3300 mins. There was no distinct event at 2840 mins, that I see in the logs...
all corresponding with errors the reboot was somethimes in between. I don't find it in the logs? |
|
I did find it in the logs finally, it's "NTP updated ";) logs with reboot |
|
It's not necessarily a reboot causing the "ignoring lock action", it can be a MQTT reconnect too. The question then would be, why do you get disconnected from MQTT sometimes? Two points:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I'm using Nuki Hub with an "manual integration", meaning I listen to NukiHub topics and send actions to NukiHub topics.
Sometimes the action payloads won't open the Smartlock.
my integrations tries to unlatch the Smartlock three times with a pause of one seconds in between.
that was the case today I tried to enter
As it was not working I used the Nuki App with Bluetooth to open the door, which worked then.
So, I'm not sure, where to start, so that's the MQTT log at the time it didn't work:
MQTT log around the error
Normally, opening looks like this:
The log here shows also, that the query of the lock state fails with timeout (this pattern is repeated on all "successes")
MQTT log around success
Thanks for any help!
bonus: are the multiple "NukiTask is running/networkTask is running" every 2 minutes or so normal?
All reactions