HI,
The new drivers are looking good...I don't have the messages in the log file anymore, and everything is working as it should.
Thanks so much for your assistance.
Updated Version(s):
- UnifiProtectAPI.groovy = 0.2.52
- UnifiProtectChild.groovy = 0.1.13
- UnifiProtectChild-Light.groovy = 0.1.8
- UnifiProtectChild-Camera.groovy = 0.1.13
- UnifiProtectChild-Bridge.groovy = 0.1.6
- UnifiProtectChild-Doorbell.groovy = 0.1.15
- UnifiProtectChild-Sensor.groovy = 0.1.6
- UnifiProtectChild-PTZCamera.groovy = 0.1.3
Change(s):
- Additional attributes/events refreshRate and imageUrl (as well as the ImageUrl capability) have been added to camera child drivers (cameras, doorbells, and PTZ cameras) to better support Easy Dashboard.
- A RefreshRate preference has been added to the camera child drivers. This allows you to specify how often you want the camera to be scheduled to take a new picture which will be saved to the Hubitat's File Manager. This defaults to "Manual" but can be configured in a number of increments from 30 seconds to every 3 hours.
- An additional attribute/event has been added for cameras "ImageAsOf" is intended to give you an idea when the image was most recently taken and saved to the File Manager.
- Changes to how all drivers handle event and state variable processing. However, there still seems to be some oddities with the new UI style (2.4.x) and also some strange browser caching (at least evident with Google Chrome on my computer) that impacts State Variables at times (no problems noticed with Events/Current States).
- All child drivers now use the new "Tile" method.
- All attributes with a space in their name should not be used by the drivers anymore (they may "linger" on devices, I did not specifically write code to remove them as the remaining ones would not be present on every device).
Note(s):
- For those that may not have noticed yet, the images saved from the cameras to the Hubitat's File Manager are named "Camera_[CameraID]_Image.jpg". The CameraID is the ID provided by the API and can be found in the device's State Variables named "ID". The reason for this, and not using the DNI or device label, is that the File Manager cannot have spaces in file names. That limited the possibilities for a unique identifier and I did not want to spam the file manager with individual date/time files either.
Updated Version(s):
- UnifiProtectAPI.groovy = 0.2.53
Change(s):
- Corrected a typo in the PostEventToChild function that was causing errors.
I recently implemented these drivers in my setup but can't seem to get "real time" updates from my All In One Sensor. I can manually refresh it and it's updating, but I needed automated updates. I believe this is possible, but must be missing a setting somewhere.
Any recommendations to troubleshoot or setting to confirm would be appreciated! 
I'm trying to set up for the first time and getting the following error when trying to login.
Level
Clear filters
dev:502025-03-29 11:55:45.918 AM
error
java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1 on line 996 (method Login)
@kevin9: Sorry, somehow I never saw that you had posted here. You can get the "live" type of notices by enabling WebSocket Monitoring in the parent device's Preferences. Otherwise it only updates data as it polls for it, but WebSockets are sent right from the controller.
@user588: That error means it did not even provide information because it could not even run the split command to determine what the actual response error was. It is not great that it happens (I will have to make a change to check for that scenario) but it means it was not going to work anyways. Could this be related to the same unauthorized problem you were having with the Network drivers?
I figured out that I needed another firewall rule set up. Now I'm getting the same 401 error that I get in the networking app. My protect app is running on an NVR and yes, It also also has a local account I'm using for the log-in.
So I've still not been successful in getting connection to the protect controller which is a UNVR. Still getting the 401 error. I've tried creating a second local super admin account and have tried setting the device as the UDMP. I've tried ports 7443 and 443. Any other ideas?
It should use the exact same settings as the ones for the Network API portion. The login for that one should work for the Protect as well, and the Preference settings can be the same (the underlying login is the same, it is how they request data and what they provide that made it easier to have two driver sets).
Are you saying I should use the IP address and login for the cloud gateway and not the UNVR?
Hmm... I am used to dealing with one system that provides both Network and Protect APIs (and more, since I have a UDMP). If I remember correctly in this case, Protect runs on the NVR while Network runs on the Cloud Gateway Ultra... so you are correct, they would be different since the Ultra does not support Protect. (I had to look this up, as the Max does, and that is the most recent Cloud Gateway I have talked to someone about I think).
The port should be 443 in this case as I would assume you have the latest version firmware on the NVR. It is likely using the UDMP methods... but you indicated you have already tried that. The NVR has a different admin user than the UCG Ultra, correct? Like with that one for Network, the easiest test is to login directly to the NVR's web interface with the user to make sure it has access.
The
I have confirmed the login works. I do have another http debug line showing up in logs. The NVR is on it's own VLAN but firewall rules look fine and not seeing any blocking happening in the logs. Some screenshots below to help.
I would try setting it to the Unifi Dream Machine controller type, Save Preferences, then do the manual "Login" command on the device's Commands tab... [Fingers Crossed]
So super weird on a few levels.
After trying the Dram Machine type (I had done this before) it gave me the error again but as a debug type. " debug Expected HTTP 101 response but was '401 Unauthorized'". So I tried changing the port again to 7443 and it logged in! Protect did update to the new version over night so maybe this has something to do with it?
The other weird thing I notice right away is that is shows one of my APs under child devices.
The device type name for the NVR is UNVR4 if you want to add that to the firmware. Let me know if you want me to check anything else.
So, I want to confirm a couple things and some responses:
- First and foremost, it is now working for you?
- UNVR with latest firmware requires UDMP controller type AND port 7443? Good to know...
- APs can show up as Bridge devices. You cannot really DO anything with them, but they are reported by the API (it uses Bridges to connect between Bluetooth-only Protect devices and your WiFi). I have long debated about just removing them since the Protect API does not really allow you to do anything with them and their status information is pretty much non-existent.
- Thanks! The Protect drivers do not do much in the way of model recognition (unlike the Network drivers). It just "groups" devices into the same categories that the API provides them as. I had started that bit of recognition in case, but never needed to do anything with it (anything listed as an NVR acts as an NVR). In fact... I think I will remove that going forward for most of them. The only category that needs it is the cameras, to break out which ones have PTZ, are Doorbells, or "plain" cameras.
1 - Yes, confirming it is now working
2.1 - Regarding the controller type, It did require UDMP as the controller type.
2.2 - After changing the UDMP type and saving, it was still erroring out with the debug error and the option was still there for changing the port. After changing the port to 7443, it started working
2.3 - I updated the Hubitat firm ware after getting it all working, and after checking this morning, the port number selection is no longer showing.
Thanks for the other info! Good to know.
@fleetmack: In response to the post on the Network controller project:
- Off the bat, the basics sound correct if it created the child and basic data seems to be coming in. You also have the WebSockets enabled (which is required for such things).
- There is not much logging in the driver for Info or Debug levels. If you switch it to Trace you will get EVERYTHING it is doing (which can get excessive, but could show if something weird is happening at the doorbell).
- What happens when you use the Push command on the doorbell device page? It should trigger an event.
Thanks. I enabled Trace. If I push the "push" button here:
....my rules work. I get notifications, my speakers speak, etc. But pressing the button on the doorbell does nothing.
Do the logs show any WebSocket activity? With Trace logging enabled on the parent device your log should be full of things that start with "WebSocket Data = " and "WebSocketStatus = ".
