Normal versions. Usually one down-rev.
Very strange. Historically the "weirdest" interactions anyone has had with the Unifi drivers (Network or Protect) has been when on early access.
Well, let me know if anything crops up again. I will try to remember the "have you rebooted your UDMP lately" recommendation.
Is it possible to get people and vehicle motion detection from G5 bullet and G5 dome cameras?
I do not have either so I do not know for sure. I checked Ubiquiti's help and found the answer, according to this page, appears to be no. It says only the G4 and AI (except Instants) can do smart detection. But maybe that page has not been updated for the G5.
Sorry I cannot be more helpful on that.
The G5 dome and bullet can and do have person and vehicle detection. I've tested both,
Are you supporting it for the G4? If so it's probably reasonable to assume that the API is the same for the G5.
Ah, THAT was your question. Sorry, I misunderstood.
Right now it should be receiving the alert and treating it as a normal motion. I do not have trace log samples of when the websocket response comes from the Unifi Controller when it is a smart detection (since I do not have any camera capable of that) so I do not know how it is formatted to identify it.
If you could enable Trace logging, cause a couple smart detections, then send me the logs in a message, I should be able to look at them and see what is different about it to make the notices more specific.
Will try to do that later today. Thanks.
1 Like
I have trace logging enabled in all the devices. Don't see any raw info in the logs, just this:
The only other thing that seems relevant is the "Bootstrap" data, which has entries for "person" and "vehicle":
-- deleted --
I will look over this information (please remove it now, per my message).
You should not need to enable Trace logging for all the child devices, all that data flows through from the parent device anyways. Also, do you have the WebSocket Monitoring enabled? That would be more useful for the motion detection than the bootstrap.
However... I just reviewed my code and found I do not have good Trace logging for the WebSocket portion. That might be why you did not find anything useful from it. I will add some in and get a new version posted shortly.
Updated Version(s):
- UnifiProtectAPI.groovy = 0.2.13
Change(s):
- Added Trace logging to the WebSocket's parse section so that samples can be captured from there for anyone that wants to send me a message with data samples so I can better implement what the API is allowing people access to.
Yes
I'll update later on this evening. Thanks.
1 Like
Updated Version(s):
- UnifiProtectAPI.groovy = 0.2.14
- UnifiProtectChild.groovy = 0.1.6
- UnifiProtectChild-Camera = 0.1.5
- UnifiProtectChild-Doorbell = 0.1.4
Change(s):
- Added smartDetectType in so that it should list what was detected. As this field appears to return an array I am putting it in as a string. This should handle cases where a camera (or doorbell) returns more than one thing detected at the same time.
- Made changes to how LoginRetries and WebSocket Failures were being handled and reset. They both reset if Preferences are saved OR if a manual login is successful (WebSocket Failures only if WebSockets are enabled).
- Camera and Doorbell child drivers have had an attribute added to receive the smartDetectType.
- The generic Child driver has had the camera & doorbell specific attributes (including smartDetectType) added to it. I realized that if an unsupported device is detected and assigned the generic child driver, there is still the chance that it might want to use some of those "known" attributes until such a time as someone sends me a sample and a proper child driver can be made.
Device 1315 is UniFiProtectAPI. I'm running the latest versions of all drivers.
I also just noticed that only one of my two WAPs is listed as a Component Device:
So couple things here:
- WebSocket use is going to cause a lot more events and can potentially generate warnings from Hubitat. These are NOT error logging from the drivers but rather Hubitat stating that the device is being "too chatty" you could say. You can up those limits in the device settings (the ones for the device itself, not the Preferences). The WebSocket is purely driven by what the controller is sending out. With multiple different cameras (from what you show) I would expect a lot of traffic. That said, I AM working to try to cut down on the Events in the version I am working on now by getting rid of the WebSocket status portions, and just leaving the actual motion or other events.
- That COULD be perfectly reasonable because you can tell Protect not to include certain APs as Bridge devices on the Unifi controller. In which case it likely would not include it in the data. However, that is not the default so I would expect both to be in here. Can you send me a message with Trace logging when you perform a manual "GetProtectInfo"? I want to make sure what it is sending for Bridges. To be honest, I am still debating if there is any VALUE in providing the Bridge listings in my Protect driver. There is not really anything anyone can do with them. I added them more for "completeness" of what the API provides.
If anyone has thoughts on removing the Bridge child devices... Let me know.
Updated Version(s):
- UnifiProtectAPI.groovy = 0.2.15
Change(s):
- Most WebSocket status information has been commented out... It really did not have much value. This does not effect WebSocket Events being returned from the controller (motion events, lights, etc...) just the "is the WebSocket open, closed, failed, etc..." type of stuff.
- Changes to handling of WebSocket Events. After further review of some of the samples sent to me it appears that some WebSocket data is "new" and some is an update on a previous event. While the "update" labeled data actually appears to be the primary piece sometimes it returns null data which needs to be related to the previous "add" portion. So I am trying something new with the handling. This is not really apparent with my simple system but it will likely be more relevant for those with newer cameras that can do smartDetect.
- General attempts to minimize number of Events posted. I am not sure what Hubitat appears to have changed but even my devices are getting the "Excessive..." error now. Even after deleting devices and upping the limits for events. There is more I need to do but for now I have done some cleanup.
- Correction to the parent device's GetSnapshot command. The function was looking for two inputs but the command was only providing one. This is now handled properly.
I do not know what is causing this. The method itself is very simple and reused on MANY of my drivers and has never caused an error before. I wonder if Hubitat has changed something that is now causing these to crop up (right or wrong).
@bobbyD: Any idea why these errors might be cropping up when they have not in the past? The ProcessEvent method has not changed for quite some time.
My guess is the frequency these calls are occurring (many times a second).
I'll try to have a look at it later today.
I found the trouble maker, or at least a cause for many refreshes to be performed. It got stuck into the WebSocket area... So the WebSockets were calling for Login and refreshes if they were initialized, which apparently just happens a lot as is.
Update coming in a few minutes.
Updated Version(s):
- UnifiProtectAPI.groovy = 0.2.16
Change(s):
- Removed portion of code that called for Login and refresh to be performed from within the WebSocket initialization. This should reduce the driver's workload.
