i removed the drivers and re installed the drivers. i got a doorbell smartdetecttype for person.
i cant explain why. im going to test some rules. ill let you know if its working.
after removing the drivers and re installing them things started working for the doorbell.
i successfully tested detecting a person and the rule detected it and took action.
im noticing a delay between the detection and the action. when i was running the tomw driver the motion event triggered the lights almost instantaneous. these drivers take about 3-5 seconds to turn on the lights.
the protect app reports the event 3-5 seconds before the rule action happens.
the rule im using is the same rule as the motion detect. the only change is the trigger event.
Doorbell reports smartDetectType(person) ≠ none
First, glad it is working for you... although I am not sure why reinstalling the drivers helped.
As for the delay, again, no idea why that would be. I do not see a similar effect on mine and the only pause in the entire driver now is when it is closing the webSocket (a 0.5 second pause to let it close). The only thing I can think of is that it (the Hubitat) might be having a delay if you have tomw's AND my drivers installed, because it is having to have both of them parse through every webSocket response. Not sure if there is an order there. The other way to check would be to see when the device's smartDetectType is updated per the Events page to confirm if there is a delay there or if it is being posted by the driver right away.
when it wasn't working. every time i checked the device stats the device was at 67% all the rest of the devices were below 12%
since the reloading of the drivers the Unifi driver is at 0% load.
One feature that I had when i was using homebridge was when someone pushed the doorbell it would ring all phones and all homepods. is this something that could be done?
currently it only rings the phones. This is probably coming via the unifi protect app.
so this function worked without an issue since yesterday. today there was a hub update. I applied the update to fix the Generic RGB light issue. I don't know if it's related but now the logs don't show smartDetectType again.
is there some addtional logs that would help identify the issue?
Maybe try rebooting the Hubitat? Not sure what logging I have that would show when an Event was supposed to occur... but the device did not record it. The closest thing would be to turn on Trace logging for the device (Doorbell) itself AND the parent... Then comparing the two... but that would be huge. Just turning on the Doorbell logging would show if the device was getting it or not.
ill turn on trace. when the events dont show up in the logs the protect app still gets the alerts.
after i turned on trace the smartDetectType showed up again. how can that be related?
before i change the setting of the logging the % of busy was 0.0. now the % of busy is 60
the next highest is 10%.
- should it be as high as 60
- at 0.0. i assume it wasn't doing anything before i changed the logging.
Im still seeing it work sometimes and other times not work.
My HE does not have any wifi configured. its hard wired into my network.
my WIFI router is maybe 15 feet from the doorbell.
the connectivity is excellent.
Any ideas what might be causing my issues.
its been a day with no issues. i think i may have solved the problem. in the beginning it was configuration issues i had wrong. and a re install of the drivers. but the reason it was working and then not and then working again without any changes was the wifi AP the doorbell was connected to is also on the same side of the house as my neighbor. i did a channel scan and they were on the same channel. I moved my channel and boosted my signal on that AP and since then i have not had an issue with the doorbell reporting its status.
if you dont hear from me in a few days you can consider this my solution.
2 Likes
Interesting... so maybe the channel congestion was interfering with the messages through the bridge? Such a thing should impact the Ubiquiti app since the doorbell status would not be getting to the controller itself.
I still hope it is resolved though...
I have found the exact issue. After doing a lot of testing i found the issue only showed up when it was dark out. The channel and signal may have been just a coincidence.
I found many references of cameras with AI that don't detect at night. The issue isn't tied to just Ubiquity.
To validate this i tested at night with the lights on and the lights off. When lights are on the AI detection works every time. When off it sometimes works.
1 Like
Updated Version(s):
- UnifiProtectAPI.groovy = 0.2.44
- UnifiProtectChild-Doorbell.groovy = 0.1.13
Change(s):
- Initial attempt to read in fingerprint data received from a doorbell webSocket. This is an EA feature on Ubiquiti's side so it could change. What the parent driver attempts to do (when this notice is received) is put the userId provided into the doorbell child device as an event (attribute) named "FingerprintUserID". Please note: the userID is a unique character string and has no relation to the user's name or such in the system (it is an "internal" ID uses within the controller). As such, you will likely have to try it out and see what the results are so you could copy the value to a Rule or such. As I do not have a doorbell myself, this feature is an initial attempt. If it does not work, please message me with Debug logging (currently it will provide debug log entry data if it does not get the needed values).
Updated Version(s):
- UnifiProtectAPI.groovy = 0.2.45 0.2.46
Change(s):
- Setting the FingerprintUserID to null when an invalid fingerprint is identified. Basically, the API reports that a fingerprint was identified but it gives no userId information (it returns null itself).
- Changed some of the webSocket responses (including FingerprintUserID) to be FORCED events. So even if the value is the same as one before, it should still be published with "isStateChange: true".
Hi Snell
After getting onto your excellent Unifi network app, I thought I would give your Unifi Protect a try. Hitting some errors around authorisation even though I have confirmed the logn via a laptop off the same network.
Here are the errors I get:
And the details of the output
FYI I am running a UNVR with protect version 5.1.57
Cheers
Blair
You are using the UNVR to run Protect and not the UDMP?
Since the UDMP runs Protect, all the settings should be exactly the same as you used for the Network device. Although you need to make sure that the local account also has Full Management for the Protect app as well.
Hey
I have a seperate UNVR and have created a local account for protect - still the same error though
