Not sure if this is a similar issue, but I got my Nest Doorbell working, but I get no events from it. Logbook below. Even though I get notifications from the Nest app. I get no events in Home Assistant. Why is that?
Camera events do not currently show up in the log book, though that is an interesting/useful feature request to consider.
1 Like
Yes, and I also found that there are in fact still event triggers. So, all good. Now I can turn on my front door light only when a person is detected.
Great news, I have had an automation for months that would send me an alert if my Nest Hub max detected motion/person/sound, and it had never triggered until today. It seems to be triggering reliably reflecting exactly the events in the Nest app. Seems like the Google team finally made their way down the queue to correcting this bug. Thanks @allenporter for all your work with this integration.
1 Like
I have seen a lot of progress in a fix, and expect to hear more in a week.(my impression is everyone is not fixed)
I can also confirm that I started receiving events from my Nest hub max today at 5:19 pm EST 
1 Like
@allenporter
Hope you are doing great.
This is with regards to not all person detection activities pop up.
(unfortunately not all the activities in the activity feed comes through)
This is because Google is limiting what the notify us.
Because of this, even we receive less notifications and this is not helping us use out of box features for automating lights in zones when person is detected.
How do we overcome this? I suggest we can overcome this if we find a way to export all activities in Google home.
Any other way??
Thanks in advance.
Rishi B S
Hello! The home assistant nest integration on supports the events delivered over the SDM API: Smart Device Management API  | Device Access  | Google Developers
@allenporter Yes. I understand! But what am trying to say is, I believe Google home notifications are also pushed from SDM API and not all activities that detects pop up as triggers but however are in the activity feed.
****GOOGLEâs DOC((((((( Updateable notifications
Notifications based on resource events can be implemented in an app, such as for Android or iOS. To reduce the number of notifications sent, a feature called updateable notifications may be implemented, where existing notifications are updated with new information based on subsequent events in the same event thread.
Select events feature support for updateable notifications and are tagged as Updateable in documentation. These events have an additional field called eventThreadId in their payloads. Use this field to link individual events together for the purpose of updating an existing notification that has been surfaced for a user.
An event thread is not the same as an event session. The event thread identifies an updated status for a previous event in the same thread. Theevent session identifies separate events that relate to each other, and there can be multiple event threads for a given event session.
For notification purposes, different types of events are grouped into different threads.
This thread grouping and timing logic is handled by Google and is subject to change at any time. A developer should update notifications based on the event threads and sessions provided by the SDM API.
Thread state
Events that support updateable notifications also have an eventThreadState field that indicates the state of the event thread at that point in time. This field has the following values:
- STARTED â The first event in an event thread.
- UPDATED â An event in an ongoing event thread. There can be zero or more events with this state in a single thread.
- ENDED â The last event in an event thread, which may be a duplicate of the last UPDATED event, depending on the thread type.
This field can be used to track the progress of an event thread and when it has ended.
Event filtering
In some cases, events detected by a device may be filtered out from publishing to an SDM Pub/Sub topic. This behavior is called event filtering. The purpose of event filtering is to avoid publishing too many similar event messages in a short amount of time.
For example, a message may get published to an SDM topic for an initial Motion event. Other messages for Motion after that will be filtered out from publishing until a set period of time passes. Once that period of time passes, an event message for that event type may be published again.
In the Google Home App (GHA), events that were filtered will still show in the userâs event history. However, such events do not generate an app notification (even if that notification type is enabled).
Each type of event has its own event filtering logic, which is defined by Google and subject to change at any time. This event filtering logic is independent of the event thread and session logic.)))))******
Thatâs causing the issue. Basically, whatever notifications pop on my Google home, those notifications only come as triggers on home assistant because both notifications are part of SDM API
This is being a huge blocker which otherwise can be a room to huge amount of tasks.
Not all person/motion detected triggers are available on Nest cam (battery)
Imagine, a person is detected and an automation to turn on my light for 5 mins is in place and post 5 mins it still checks if the person is detected or not and applies a logic whether to turn on light or off. Or imagine a person detected in one zone is now moving to an another zone, so whether lights in that zone can be turned on or off.
How do we solve such issues?
Hi,
Home is not using sdm API, but it may share some infra underneath.
Anything supported by the sdm API I will add support for in home assistant.
You can see the nest debug docs to see how to turn up debug logging or view the sdm raw feed to see all of the events published by the sdm topic.
@allenporter As seen above, at least if you could give us support for entities such as âStarted/Updated/Endedâ for an event trigger to monitor the thread, it could help us identify if the zones are updated as well which could help us in identifying if the lights stay on/off for a zone.
I recommend using a template binary sensor that turns on/off based on the events. In the future this could be a built in home assistant feature but thatâs my suggestion for now.
@allenporter I could see the last_updated timestamp flagâs values being changed in the trigger event payload which is different to the trigger timestampâs value.
Could we have that used in our automation. If so, do we have an api to query for changes in the last_updated time, so we can decide whether to turn on/off lights in zones.
What we possibly could do now is add last_updated_time and event_created_time atleast as an attribute to solve this issue
But, the binary sensor template also wonât serve its purpose, to be honest. Correct me if am wrong or suggest me ways.
Many Thanks.
You can access âtrigger dataâ in the automation and use it however you want, e.g. store the value using a template sensor.
@allenporter but the trigger data is static correct ??? It isnât dynamic. At the time of event trigger what data is available, that wonât change.
What we possibly could do now is add last_updated_time and event_created_time atleast as an attribute for the entity/device to solve this issue.
You can use template sensors to store whatever you want?
@allenporter Sorry that I dint explain properly.
What am trying to actually say is,
In the trigger data below,
The last_updated is static and it doesnât change. Itâs is just one or two seconds greater than the last_triggered.
In order to achieve this, we need be able to use the UPDATEABLE NOTIFICATIONS feature of Google SDM API as below.
{
âeventIdâ : âfc25fa92-0b39-413e-8797-daa24ef66f52â,
âtimestampâ : â2019-01-01T00:00:01Zâ,
âresourceUpdateâ : {
ânameâ : âenterprises/project-id/devices/device-idâ,
âeventsâ : {
âsdm.devices.events.CameraPerson.Personâ : {
âeventSessionIdâ : âCjY5Y3VKaTZwR3o4Y19YbTVfMFâŚâ,
âeventIdâ : âcpwRFG-0N-BjZgCY6krxEkclUzâŚâ,
}
}
}
âuserIdâ : âAVPHwEuBfnPOnTqzVFT4IONX2Qqhu9EJ4ubO-bNnQ-yiâ,
âeventThreadIdâ : âd67cd3f7-86a7-425e-8bb3-462f92ec9f59â,
âeventThreadStateâ : âSTARTEDâ,**
âresourceGroupâ : [
âenterprises/project-id/devices/device-idâ
]
}
We need to be able to use the above eventthreadid and eventthreadstate
FYR:
Also, we need to find a way to disable âeventfilteringâ
- We definitely will not be adding any entity state timestamps for this. Not sure how to say this any more clearly that this is not a solution that will happen. Letâs keep the discussion to event payloads.
- Definitely canât work around the API limitations. It seems like an odd thing to suggest atter I mentioned we canât do this a couple times.
- It may be possible to expose more detail in events or additional events, Iâm just not sure that (1) you will actually see the events you need and (2) that itâs worth the API complexity and possibly to keep backwards compatible to not break existing users. Letâs start by looking at an actual series of events captured that are published with the info you need.
But really⌠this interaction hasnât been super fun given you emailed me directly, then filed multiple GitHub issues on me after I said we should discuss here. 
@allenporter Am sorry if that hurt you. But my intention wasnât that.
I thought if I could post as an issue, one of the contributors would be able to address that and get it working quickly.
Only 1 or 2 events are being notified every half an hour where as we have around 10 events in the Google home activity feed.
eventThreadIdâ : âd67cd3f7-86a7-425e-8bb3-462f92ec9f59â,
âeventThreadStateâ : âSTARTEDâ, **
What could actually help is having the above added as attributes/payload/entities.
If added as payload, how would we be able to query the âeventthreadstateâ and check if the value has moved from âupdatedâ to âendedâ ?
Please help me in solving this! I assure it would be a groundbreaker for many.
Many Thanks and sorry ! 
Consider this separately:
- What is the granularity of the events published in the sdm feed
As youâve pointed out, what is happening in google home app doesnât matter because the feed is different. Stop talking about google home What matters it the events published by the SDM feed. So what are you seeing? If you are seeing the feed actually publish something useful at a granularity that you canât see today via home assistant, show me an example of the messages received and the deltas in timestamps.
-
How to get notified via event payload
I discussed the caveats for this, and why even if #1 is useful why its a challenge for existing events. But lets stop talking about this for now and focus on #1. -
How to store the state?
As i mentioned before a few times, there will be no new state added, and you should use template sensor to store whatever you want from the event payload. There is nothing else to discuss about this that hasnât already been said a couple times already.