You would want Trace enabled on the parent device to be able to see the WebSocket data. Enabling Trace on the child will only have it show when it receives data or has it's preference saved (you can see the result of that from the log). In this case, the child is not even receiving the events to begin with, so that is why we need to see if the parent is getting any data to send to it. Children do not work with the API at all. Everything goes through the parent.
Thank you, as you noticed, I did not have trace enabled on the parent. I have enabled that and am getting websocket responses logged:
still no dice on the doorbell push 
So good news, bad news... Good news that the WebSocket connection is working. Bad news is that the API is not providing ANYTHING on it apparently. Do you have any other Protect-related devices that could be used to see if anything comes back for it at all?
You may want to set it to Trace logging only when trying to check for something, and then turn it back to Info (or Debug) otherwise. Debug will get basically the same information as Info except it also includes information about any "unhandled" data (stuff I have not seen to code to yet).
I do not remember if I asked before, but what type of Doorbell is it (not that this should matter, just curious)?
This is my only protect device aside from the chime. I have g4 doorbell pro POE version
Something weird is going on here... I just checked mine and I am getting the same "lack of response" problem. I even enabled extra (normally VERY excessive) logging on mine... and nothing is coming across at all. Not from any of my cameras or my other devices. Everything else is working normally... I can control the brightness of the floodlight, set the PTZ to move, etc... so all the normal API functions are working. Just the WebSocket is having issues... but nothing has been changed there lately.
Nothing showing in the Release Notes as having impacted it (although there have been multiple updates in Early Access lately so maybe they broke something). What version of Protect are you on?
Same issue for me. UniFi OS 4.2.8, Protect 5.3.41. The tomw integration is successfully receiving doorbell button push events.
1 Like
@bill.d @fleetmack:
Ok, thanks... my WebSocket portion is based on tomw's (much of it is identical, with permission)... so that means I broke something. Although now I need to go digging around to find what since I do not remember changing anything lately in those areas. But that at least continues giving me clues.
EDIT:
Ok, try disabling the WebSocket preference, Save Preferences. Then go back in and enable it and Save Preferences again. I just did that (while trying something else) and now I am getting flooded with activity including the motion and such. I wonder if the connection somehow "broke" during an update or something. I will have to look at a way to reset it regularly. Let me know if this works for either/both of you.
That worked. Thanks.
1 Like
Wish it worked for me but it didn't, boo. I deleted the child device and tried again that way, no dice
The child device would not have impacted it... they are really just a place for data and to help represent things. All the real code and communication happens with the parent device.
I would say you could try removing the parent and starting from scratch with it... this one is becoming more confusing. If that does not work and you are willing, shoot me a personal message and I can try making a custom version of the driver to try to debug it in more detail (and step by step).
I tried removing and re-adding but the same thing occurred. I ended up using the older "Unifi Protect Controller" that I found on another thread instead of the "UnifiProtectAPI" and all is well now
Sorry it did not work out for you, but and least you found one that did. Although I am still curious about why it did not work.
Updated Version(s):
- UnifiProtectAPI.groovy = 0.2.57
- UnifiProtectChild-Doorbell.groovy = 0.1.16
Change(s):
- Additional data handling
- Simplified device categorization
- Added doorbell notification messaging
Hi,
I have only had the g4 doorbell pro for a few days at this point. The previous version of this app the fingerprint scanner was working for a a day before it looked like it just stopped getting data from the doorbell. Seemed like disabling the webscockets and enabling them again would fix it. The new version it seems to be working for me under an hr. Then If I go into the parent app and click login, it works again. Any idea what I might be doing wrong?
It does not sound like you are necessarily doing anything wrong, but like there is an authentication error. The 1 hour mark is odd, because the driver sets an event to login every 10 minutes. Are there any errors in the Logging for it? If it fails to login that should be posted as an error for the parent device.
If you do not mind my asking, what type of Protect Controller are you using and which version is it?
I seem to have these error messages, sometimes just randomly, other times for several hrs in a row:
java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1 on line 1008 (method Login)
I am using a UDM pro, and protect version 5.3.48.
I will say after my initial post, it worked fine for a full day again. Then when I got home from work it was not working. Login did not fix it this time, I hit get protect info, still no good. I then went to the doorbell settings, and clicked refresh there, and it worked fine one time. As I look at the event data on the camera device its self, not only do I not have FingerprintUserID but I have no motion events either. I also just looked at the events for my other cameras, the front one has no motion since yesterday, and the camera in the back has some motion events, but not others.
Updated Version(s):
- UnifiProtectAPI.groovy = 0.2.58
- UnifiProtectChild-Camera.groovy = 0.1.14
- UnifiProtectChild-Doorbell.groovy = 0.1.17
- UnifiProtectChild-PTZCamera.groovy = 0.1.4
- UnifiProtectChild-Sensor.groovy = 0.1.7
Change(s):
- Added handling for smartAudio detections reported by the WebSocket connection. All of the listed child devices have had the SoundSensor capability added in case it is triggered for them.
- Additional data handling, including some new WebSocket types courtesy of information from @KD8GRN.
- Some code simplication and cleanup.
Putting this here as an enhancement request for functionality that was observed as something that could benefit some users.
Add-on driver to make inbound web hook calls to alarm manager configured inbound system web hooks from RM. Inbound web hooks can be configured and maintained in alarm manager and used from more than one system. They can direct ptz cameras to specific presets and patrols. You can do other things as well. For some people maintaining this in alarm manager is ideal.
Inbound web hooks on RM required an Auth header. Today there are work around for that in RM, but I think having this in your driver collection would be really cool for many users. If you had a way to enumerate the alarms in Protect and pick from them it could make configuration easier for users.
Some use cases for this would be to trigger a ptz patrol when a hubitat motion sensor was triggers in the camera area. Trigger a preset when a door or window sensor is opened, but only at night. Trigger a preset of exiting the garage sesnor but ignore if it's a known face. Etc etc.
I have not really thought about the WebHooks too much... So I am not entirely sure how it would work or how they work presently with RM (if you can explain in more detail in a direct message, I would appreciate it).
Presently, if I had a motion event from a known source that registers on a device, I could just use Rule Machine to send the command to a PTZ camera to move to a preset that covers that location.
The drivers already allow triggering PTZ movement (primarily to presets, but more granular control IS possible in them). I do not know of a specific command within how I am accessing it to enable a "Patrol" other than delayed commands to have it swing between presets (which is possible now). I could not find a setting for such a patrol for my G5 PTZ, but maybe it is something I have missed.
Happy to try to work to make this more useful.
