Missing where_name from some devices



I’ve noticed that one of my devices (specifically a Nest Protect) does not return a ‘where_name’ when I make a request for the device (/devices/smoke_co_alarms/device_id/). Additionally if I look for the device’s ‘where_id’ in the structure its not present.

The specific where_name that is missing happens to be “Garage”.

I believe that this problem is caused by the fact that I also have a Nest Secure in the same structure. When I added the Nest Secure via the iOS app it enabled an additional set of “wheres” and the app allowed me to change the where of existing non-Nest Secure devices to one of these new “wheres”, in my case, “Garage”.

It would seem that either there is a bug in the iOS app/private API that the app uses that allows devices to be assigned to “wheres” that are not scoped for that device type, or the public API that we have access to needs to be updated to return the complete list of “wheres” available in a structure even if it doesn’t yet show us the Nest Secure devices.

As proof, here is the JSON returned for the device in question:
‘smoke_alarm_state’: ‘ok’,
‘last_connection’: ‘2018-02-21T18:25:41.159Z’,
‘name’: ‘Garage’,
‘software_version’: ‘3.1.4rc3’,
‘locale’: ‘en-US’,
‘ui_color_state’: ‘green’,
‘co_alarm_state’: ‘ok’,
‘is_manual_test_active’: False,
‘battery_health’: ‘ok’,
‘where_id’: ‘QppQneO-z2cz9COo8BnMtVUbyIPvAKnlz98AaHyplzpwwWuODm4-3g’,
‘is_online’: True,
‘last_manual_test_time’: ‘2018-01-22T04:13:08.000Z’,
‘name_long’: ‘Garage Nest Protect’,
‘structure_id’: ‘12NXWLUKkpXH-ILxCJIm0B7QhKS5ze04zZmC92To-4m-yH7PfYYXUw’,
‘device_id’: ‘ah63qxPK6RTrf54y1wUfsGqVg9Tng4re’

I apologize if this is the wrong forum for this type of report but it wasn’t clear to me the proper place to report something that appears to be a bug like this. Perhaps a nester, or someone with more knowledge, could point me in the correct direction.




So to confirm, you are saying that before you added the Nest Secure to your account, the Protect’s “wheres” information returned correctly, but after adding the Secure you chose a new “wheres” for the Protect and that new “wheres” name doesn’t return in the API?

Was the Protect’s where name set to “Garage” before adding the Nest Secure?


I didn’t use the API to pull data until after I added the Secure and moved the Protect to a where of “Garage” so I can’t say for sure it worked. The Protect’s where name was not “Garage” before adding the Nest Secure I know that.

What I can is move that particular “Protect” to a “where” that I know is visible via the API, wait for it to update, and try and pull it via the API again. Then I can move it back to “Garage” and re-test.

Would have be of value to you?


Yes, since you already have the device setup in place, it would be extremely useful if you could test that.


OK I’ll run the tests and post back once I have the results. Not sure how long it takes the Protect to update its where. I know its not immediate, but not sure how long it takes.


OK here is what I did:

I did notice that when I selected Garage as a “where” (note I selected it from the list) it did tell me that Nest can’t say custom wheres and what did I want to to say instead so I choose downstairs.

It probably did that the first time I didn’t notice and/or forgot.

So given that, would this be expected behavior then for “custom” wheres? Even though its not custom for Guard but is for Protect (which is why I was confused). The API doc seems to imply it should be present if its a custom where.


And now the final link to the data for the move back to the garage.



Hey cfb, sorry for the delay in responding. We are looking at this but I have no ETA on a resolution/fix. But definitely seems to be something to do with the new where names that were added to the app in preparation for our new products (Secure, Hello, Yale Lock).


No worries. I’ve submitted a patch to python-nest that has been accepted and released and I’m working on getting home assistant to update to the latest python-nest so I’ve worked around it for now. Thanks for looking into it and working on a fix.