It only gets motion or smartDetect information via the webSocket capability but those can change fairly quickly. If you select the Events button on the doorbell's webpage you should be able to see a list of Events that have recently changed so you can see if it triggered or not. Or you could enable Trace logging for just that child device and check the logs to see everything it is getting from the parent.
Beyond that, there is some useful information for some people even if they do not use the webSockets.
If you do not mind my asking, what version of the Protect API does your controller have? Ubiquiti has been changing a lot of things lately...
The smart detections aren't working for me either. Every once in a while they show up, but not often. They do show up in Home Assistant. I'm on the EA channel, Protect 5.0.47, Camera 4.72.44
In the trace logs I do get "Doorbell - State: LastWSSAction = smartDetectType" some times, but that's it.
There are some known issues with the newer EA and smartDetect... (and WebSockets more generally) so that might causing some of it... especially if you do not see anything when doing Trace logging (if you have Trace on the parent, with WebSockets enabled... it can get to be pretty overwhelming the number of log entries, but that would definitely indicate what is being received and help show if I am missing something somehow or if it is just not "telling" the Hubitat).
I think they've addressed most of the issues. As I said, Home Assistant is working as expected these days. I turned on the trace for the parent and I don't see anything obvious that should be passed as a smart detect event. It's just a flood of information even if I turn off all the other cameras. I'll send you a PM with some WS screen shots.
I was in the process of doing a bunch of testing with it this afternoon and it definitely looks like things have changed (and not for the better from my perspective). I did a bunch of walking past my G5 PTZ and it detected (and reported) the motion each time from what I could see. However, it NEVER reported it as a person in the WebSocket data. Even when I turned on my full logging, it was just not in the WebSocket data anymore. I watched as the Protect app on my phone would immediately identify a person.
This is with the Early Access Protect 5.0.47.
I do not have Home Assistant to try there to see if they have the same result. I was looking over the it to see if I could understand much, but it is pretty well beyond me. Their main portion appears to be in their data.py which calls out the WebSocket connections... but I am not finding much about how they parse the data out and few references to smartDetect.
I wonder if having 3rd party cameras has any impact on this... I have the G5 PTZ, a G3 Instant (which lacks smartDetection), but I also added a couple 3rd party cameras lately...
Here's a potential source of information. A documentation of the Protect api from the author of the Homebridge plugin. Homebridge is correctly processing the smart detect events.
I am looking at it in more detail... although the WebSocket code in mine is basically a copy (with some additions) to @tomw's, which is based on information that you linked to.
Rework to use newer WebSocket decoding to match @tomw's latest. This seems to have resolved the person detection not working (when testing on my G5 PTZ). The WebSocket connection and decoding portions have always used his code.
Some minor cleanup related to other WebSocket portions.
I used to use homebridge i’m trying to convert to everything on hubitat. The protect cameras are the last thing for me to migrate. Homebridge did the job but i was running it in a container and i had many issue with upgrades blowing up. I also used to use homekit. I’ve migrated everything to hubitat. The only thing i use homekit for now is the siri voice command.
Removing homekit and homebride allows for much more control over the environment and faster responses.
Hmm... not sure why the Doorbell would not be providing those events. Does it provide a notice if the doorbell is rung? That should also be a WebSocket activity.
The Bridge driver is... mostly useless. I have debated about discontinuing them. Basically, it creates a device that represents the Bridges that your controller is using to act as an intermediary for the Protect devices. These will typically be some (not necessarily all) of your Access Points. They provide some VERY limited information... but you can do a lot more with one if you are using my Unifi Network drivers to control them. The Protect API just does not allow for much with a Bridge. I originally added them because they WERE a device being provided by the API (and someone may not be using my Network driver) and I thought maybe Ubiquiti would implement more for them in the future (which has not happened yet).
