Thanks to @Busthead for pointing out that I somehow did NOT publish the 0.2.11. It is now posted (and validated). Not sure how I managed to close the window without actually uploading it...
All errors, including those ~2 AM, have ceased.
1 Like
Awesome news! Thanks for confirming. It really looks like at some point (of course I do not know what Unifi versions) they changed the cookie timeout. Well, the disadvantage with using an "unofficial" API. Thanks for pointing it out and bearing with me on a fix.
The updated driver has eliminated the errors that I was seeing too.
I have both your driver and tomw's driver installed and have been comparing the events that are captured on both. When I go through the motion events for example for both of your drivers, tomw's matches the motion events I see in the Unifi Protect console. The motion events captured by your device driver during the same time frame are far fewer and do not align with the timestamps in the Unifi Protect console.
Let me know if you would like additional logs. Thanks
I will have to look into it, there should not be much difference but obviously there is for some reason.
My websocket section is actually BASED on @tomw's after his recommendation about it. I originally did not websocket at all because I was focusing on other aspects of the API.
Let me know if you need me to provide some logs from my environment.
1 Like
Any plans to monitor smartDetect events?
Updated Version(s):
- UnifiProtectAPI.groovy = 0.2.12
Change(s):
- Changes to the WebSocket section to try to make certain aspects more in line with @tomw's design. Including additional status information specific to the WebSocket as well as reinitialization (and an overhaul of the original initialization routine).
@mjarends: Hopefully this helps with the missing events you had, although I do not have sufficient Protect-related devices (I only have a floodlight and a single G3 Instant) to see any real difference on my system. Let me know if this improves it or not please.
@brian.cline2: Not sure if any changes would specifically be needed. This feature appears to be image-based motion detection, so if it triggered a motion event it should show up. Unfortunately I do not have any G4 cameras (which appear to be required) to try this out with. Of course, if there is something I am missing I am happy to work with you (or anyone for that matter) to try to make improvements.
1 Like
Thanks for the update.
I verified the motion events against tomw's driver and I am seeing the exact same events from both drivers. I then compared the motion events in Hubitat against the events in the Protect UI and I found that one event was missing from the 10 motion events that were received since the update. I will continue to check throughout the day to see how the two compare.
If you need some data from G4 cameras let me know. I have a few G4's and a G3 camera in my environment.
Checking for understanding -- are you saying that both mine and @snell's drivers are now showing one fewer event than you see in the Protect UI?
If so, I would like to send you an instrumented version of my camera driver with some additional logging to try to track that down.
Anything special about the one event that is not showing up?
As for the G4 data... if you see anything that crops up that does not work or such, let me know. I am also not sure how the smartDetect events would be any different than normal ones, so if you have that at all please let me know if they show up (or not) so it will answer @brian.cline2's question.
Also... I try to build in whatever control features I can that the device(s) are able to do via the API (like how I have the Floodlight turn on/off). If you have any device(s) that you would like to be able to DO something that they can do via the Unifi Protect webpage (on the controller itself) let me know and we can work to get the sample(s) needed and try to get the feature working for you.
Yes. Both Hubitat drivers match each other but they are showing less events than what I see in the Protect UI. I saw the same behavior again this morning, but unfortunately the events had scrolled out of the logs when I went back to take a screen capture. I have set the number of events higher for the devices to try to capture the behavior.
Not that I noticed. Unfortunately it had scrolled out of the event log by the time I went back to analyze the other events that surrounded it. Time wise it was minutes apart from other motions events that had occurred.
I have adjusted the settings on one of my devices to only capture smart detect events. I don't believe these show up as normal motion events though. In tomw's driver, the two different events are captured as different event types (motion vs smart detect). I will let you know my findings later.
Here's how the smart detect show up in Unifi Protect vs the drivers. Let me know if you need more info.
Protect:
snell's driver:
tomw's driver:
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.
