Nest X Yale lock resets to default room

[robjampar]

I have a Nest X Yale Lock and it often resets to the default room (and resets entirely - reenabling the homekit lock/unlock notifications which I want to keep disabled).

I think it might be to do with homebridge restarting or possibly the plugin crashing(?) - I have my homebridge set to reboot every day. I have stopped it from restarting now and will see if it happens less often and report back.

I also have a large number of Nest protects that are linked with this same plugin - and none of those reset.

I am on the latest version for everything.

[adriancable]

@robjampar - things like rooms, notifications, automations are parts of the HomeKit / Apple Home UI and are invisible to, and not managed by, Homebridge or plug-ins.

HomeKit uses UUIDs to keep track of devices, and Homebridge stores these in the ~/.homebridge/persist directory. If the contents of this directory are lost, so will the UUIDs and so HomeKit will think it's a new accessory, move it back to the Default Room, etc.

So in your case you are losing the ~/.homebridge/persist directory somehow. The most common reason is that you're running in a Docker container or something else without a persistent filesystem. But there are many other possible reasons and this is the kind of think you are best placed to debug on your own system.

A Homebridge restart shouldn't cause this but, why are you restarting Homebridge every day? It should be 24/7/365 stable. If it isn't, figure that one out first.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[robjampar]

that makes perfect sense - but then why would it only be happening to this one device?

[adriancable]

Let’s say that the lock ends up being the last accessory to be published by the plug-in (because it happens to be listed last in the list of devices provided by the Nest API). And therefore the last device whose UUID is written to Homebridge’s persist cache.

It’s plausible, then, that if your machine crashes, this last UUID write is the only one that hasn’t been flushed to your storage. So when your machine comes back up again, there’s no UUID for the lock in the file.

You can probably think of other routes to the same destination, and I can’t say for certainty this is the explanation, but it’s plausible.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[TristanBrotherton]

I also have this issue, its also with a Nest x Yale lock, and it often moves to the default room losing all the automations which causes security issues. This only occurs with the lock however, and not any of the other Nest accessories. My homebridge server is not crashing, and the issue is intermittently happening at least once every two weeks.

[adriancable]

@TristanBrotherton - do you have continuous logs available, i.e. covering the time period, along with the actual time window when this happened? If you have logs + a statement like "the lock moved to the default room between X PM and Y PM yesterday" then I have a chance of seeing what might be happening. Feel free to send these directly to me at adrian.cable@gmail.com. Thanks!

[TristanBrotherton]

@adriancable I'd be happy to set that up, as I mentioned because its intermittent I only notice it after failure so I can work on narrowing that period of time down by checking it every couple of hours. Could you be specific about any log settings you'd like me to setup so I can have the best chance of capturing good data for you?

[adriancable]

@TristanBrotherton - possibly no additional settings are needed, but running Homebridge in debug mode (i.e. homebridge -D) is always better if you can do that.

[robjampar]

yeah I still get this occasionally and its only this lock that resets

[robjampar]

Yeah defo still happening for me - no restart or anything this time just happens randomly. I can't see anything at all in the logs, will run in homebridge debug mode and see if i can catch it.

also looks like other people have had potentially similar issues

https://github.com/homebridge/homebridge/issues/2689 https://www.reddit.com/r/homebridge/comments/lavnbp/homebridge_randomly_resets_room_assignments_and/

[robjampar]

I think perhaps this line is causing the problem https://github.com/chrisjshull/homebridge-nest/blob/master/lib/nest-lock-accessory.js#L19

from what I can see other devices use the serial number here, the nest x yale has both a serial number and a device ID.

perhaps the device ID changes periodically?

edit: i think perhaps that value should not be specified

[TristanBrotherton]

I have another theory here - could it be related to when / if the lock goes offline for a period of time?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[TristanBrotherton]

This should stay open, it's an active issue we just haven't figured out how... I'm trying to get more interesting logs.

[robjampar]

this has not happened to me for a few weeks now. The last time it did happen I checked the device ID and serial number and neither of them changed so that is not the problem.

will post any updates if it happens again

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[TristanBrotherton]

This happened to me again this morning. Is there a simple way to increase logging so we could get more information?

[adriancable]

@TristanBrotherton - what I need is a log of the two Homebridge start-ups immediately before the lock disappears. My hypothesis is that for some reason, a Homebridge start-up occurs where the lock is not detected. At this point it then gets removed from the HomeKit accessory list. Then, on the next Homebridge start-up the lock is detected again, so it's re-added, but since HomeKit thinks it's a new device, the room association is lost and it ends up back in the Default Room. Seeing these two start up logs would confirm that's the case.

I don't have any direct evidence this is happening, but it's the only explanation I can think of that fits the observations.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.