Looks like I have some improvements to make.
Ugh, that is not good. This looks very much like what you had happening before (back in September, why did it have to be OK for almost 2 months then come back), and at that point it seemed to be the cookie timeout. I assume that you did get it upgraded to 0.2.11?
Not sure about that handshake error, I have NEVER seen that one before although that is going to my website for the driver version check. Maybe my server was being flaky?
Did you try doing a manual refresh?
Using -0.2.11 driver:
Turned on debug logging and clicked Refresh:
UDM-Pro UniFi OS v1.12.22
Network v7.1.66
Protect 1.21.6
Did you click refresh in the parent device or the Controller child device?
I clicked Refresh on the UniFiProtectAPI device.
Sorry, the "UniFi Controller" Device isn't your code. I should have stripped that from the logs.
Device 1315 is the UniFiProtectAPI device.
So since I clicked Refresh yesterday I haven't see the same errors:
Looks like my UDM-Pro was borked? I rebooted it. Will let you know if these errors reappear.
Thanks. Are you running one of Ubiquiti's Early Access versions or just the normal stuff. Wonder if there was something weird there.
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.
