The Status column on the device list is based on what you set in the device's "Status attribute for Devices/Rooms" Preference. That is a built-in thing that Hubitat added and the drivers do not control it. So if you want to see a value for other devices, you need to go into that device, set the attribute in that dropdown (and it only shows ones that are populated on the "Current States" list, not all the driver might have) then Save Preferences.
Thank you!
All, I am getting a commStatus error in the app. In the logs, I see "groovyx.net.http.HttpResponseException: status code: 429, reason phrase: Too Many Requests on line 604 (method refresh)". How can I fix this?
1 Like
Same here… Getting this commStatus: error since August, 3rd.
Found my issue, In protect that particular camera has the Encoding changed to Enhanced and its not compatible with snapshots. Change it back to Standard and now it works.
3 Likes
My issue was related to 2FA being enabled, the workaround is to create a local user on ubiquiti controller so that 2FA is not required to login.
I updated to Protect 4.1.5.3 last night and noticed 2 of the cameras were no longer reporting smart detect events on hubitat. I recreated all the child devices hoping this might help but after this none of the cameras were then reporting smart detect events. Habitat is on 2.3.9.1.7.6 and there are no errors when debug is enabled just web socket open. Also have 1.4.6 of the controller code. Wondering if anyone else is seeing this?
Also normal motion events are working fine via Hubitat
in the protect app i would turn the motion sensing setting way down so it will trigger less. rely more on detection of people, animals or autos. they are more accurate. if you really need a motion event try the cross a line trigger.
keep in mind not all cameras support all the functions i just listed.
Thanks, I increase the "Seconds of motion needed to trigger event" from 1s to 3s.
We'll see if that helps.
I'm having the same issue. Looks like the new "alarm manager" broke something. Anyone find a solution?
Does it make sense to switch to webhooks now?
The new Protect version has broken the alert trigger so it sends the event via the API and Alarm/Webhooks at the end of the event rather than the start.
3 Likes
Respond from Ubiquiti support below regarding this new behaviour
UI Support (Ubiquiti Help Center)
Sep 6, 2024, 18:42 MDT
Hi,
Thank you for your time and patience. I have discussed this with my team, and it is expected behavior for the camera to push notifications only after the detection event is completed. If you have any additional queries or concerns, please feel free to reach out to us.
Best,
UI Support
Ubiquiti Inc.
1 Like
That seems to be a major issue.
Good to have the "official" response about it though...
Thanks for asking them @andrew.moyle.
As @kamransiddiqi1998 stated that seems to big issue even if it is "working as designed".
My question would does it send out a notification that the event is over? If it does then the "working as designed" answer makes no sense.
I am new to these cameras and not sure what the answer is to that question. I just managed to get a order for a G4 Instant camera so i will know soon enough.
I think that the WebSocket is very "chatty". I am not familiar with other ones so I do not know if this is normal behavior, but with the Unifi Protect it is always sending "something". Most of the time those are nulls (basically a notice of no activity).
But when it does have something it usually puts a bit more into it. But for motion in particular:
When the WebSocket sends a notice of motion, it puts an ID on that activity. It will then close out that ID with another notice, which implies that activity is done. In my experience that is not necessarily the case though. It can trigger and send a notice, close it, and then open another (and so on), all within a couple seconds.
Now, please note... I do NOT have a bunch of Protect devices. I have a Floodlight, G3 Instant, Sensor, and a G5 PTZ Camera. Most are not in "final" locations (even to this day) and are still being used for alternative purposes or testing. So maybe my experience with them is not normal.
I agree with you. I would assume this is either an unintentional change in behavior for the events or an intentional design decision by someone too far removed from how users actually expect this to work.
I assume it was unintentional because it became an issue at the same time as their Alarm Manager (with webhooks) was added, and an event notification only after the event ends is effectively useless.
Hopefully they correct or improve this based on the feedback they're hearing.
3 Likes
This is a interesting observation. I wonder what is the tolerance on the hub for how chatty it can be. I have killed my dev hub with very chatty TCP communication from Node-Red. My goal at this point is to replace my aging Arlo setup that has many EOL devices now. I just managed to snag a G4 Instant in the last batch that came in. When it comes in I am going to start to test it to see how well it will replace the Arlo's and I am sure it will be much better than my old Arlo Pro 2's. They are basically useless now with them being EOL'd by Arlo.
One thing I noticed is that it doesn't' look like based on the information online that it uses PIR for motion detection and simply leans on pixel based changes to determine motion. That could explain the chatty motion detection and quick activate/deactivate cycle.
Sounds like I will be adding to that as soon as my G4 comes in and I begin testing.
