So I received a SuperLink and Environment sensor I managed to get ordered. First glances:
The Protect API (even though I was already on EA) needed an update on my Unifi Controller.
The SuperLink adopted without any fanfare.
The Environment sensor tried NOT to be adopted. I had to reset it 3 times before it finally adopted successfully. Even then it took quite a while and in all cases it was not identified correctly in the app BEFORE adopting (said it was Unknown) but it shows afterwards.
Now for my drivers... The SuperLink is automatically recognized as a bridge. This means it has no real functions at all in the driver. Which is not really far from the truth here as the only thing you can do within the Unifi interfaces (app or controller) is turn on/off the LED on it. Not something I think I will make driver changes for.
The Environmental sensor was ALSO automatically recognized, as a Sensor. Up until now there have not been any other sensors so it was all based around what my UP Sense device did/could do. The Environmental sensor is very similar but has a COUPLE less features that the current driver allows you to control within Preferences. All the data seems to come back fine. So I am not sure if I need to do much for this one at this time.
The trouble here is that as more sensors are identified (as people send me data samples as I do I cannot afford to buy any more) there may be the need to break out the types of sensor, and thus create a bunch of different child device drivers. Obviously, I have LOTS of experience with that from my Network driver... but I was happy this one stayed smaller. I know what data fields to look at to distinguish them, so when the time comes I will have an idea how to break them apart. But until then, all I can say is HOORAH! SuperLink and Environmental sensors work!
Fix for isRtspEnabled possible error if the streams the value is contained in are null.
Change to the login array handling.
A large number of additional data handling has been added as the result of significant numbers of changes from the Unifi API side. Most of these are being added as State Variables because their value is not known yet. However, there is a "smokeStatus" that is now showing up as well as implications for a glass break (only settings at this time, no data, unlike the smoke).
Sensor child driver had attributes added for smoke and a placeholder attribute for glass breakage. The smoke is only a string attribute at this time and does not use the Hubitat capability for a smoke detector because I have not yet seen any data on it (mine reports a null value) to know how it should be converted to what Hubitat's capability expects. But, it is laying the ground work at least and will show a value if it comes in.
Hello, I’ve had some issues with motion detection. It always seems to work for a couple of days then stops doing anything. I always notice that web sockets is closed when it stops working.
Is this a websockets issue? Is there a way to keep web sockets open? Am I biting off on the wrong thing?
The WebSocket will open/close "naturally" over time (it will spam the log with it if you have Trace logging on). In the parent device can you check the State Variable for "Web Socket Status" and whether there are any "Web Socket Failures"? If it has failed 5 times in a row then it will be disabled and you SHOULD have been able to reset it by running a manual Login (selecting the Login command). Except I just found a flaw in the Login where it was not writing the correct name of the variable... so it was resetting one that most of the rest of the code was not looking at... In the meantime, Save Preferences will reset it properly.
I have a new version coming soon but it only had data handling additions. I fixed the variable just now but want to test it for a bit to make sure it is good again.
Fix for WebSocket failures variable not being reset properly when it should be upon Login and other methods. This could cause the WebSocket to stop operating after it hit the failure limit (5) without it being reset upon Login like it was supposed to.
Additional data handling for new variables being returned by the API.
Howdy, struggling a bit and not completely sure why. Hubitat C8-Pro (version 2.4.3.176). I have a UNVR running Protect (version 6.2.72). I have a G4 doorbell pro connected through WiFi with two different fingerprints registered, each to a different user. I'm trying to get the fingerprint reader on the doorbell to unlock a Schlage lock (connected through Z-wave to the Hubitat). I'm using your drivers, @snell . The virtual main protect driver sets up and pulls in my devices just fine. I will say the doorbell driver displays version 0.1.10, but I'm fairly sure that's an error in the code and it's up to date on version 0.1.20. Maybe I'm mistaken and I just can't figure out how to update it?
Anyways, the fingerprintuserID field will only update with the opposite fingerprint. It will not update any "null" fingerprints or the same fingerprint. If fingerprint (1) is currently listed on the fingerprintUserID state, no event will trigger for a null fingerprint or fingerprint (1) itself. As a consequence of this, it seems like it will only trigger my rule to unlock the lock if the last fingerprint was the opposite one of the one stored in the current state.
I'm hoping I'm just missing something? But I can't figure it out myself.
So, the easiest part is that the version is wrong in the driver. For some reason (typo I assume) it says it is 0.1.10 but it should be 0.1.20, so you have the latest. I have already fixed that and it will be for "someday" when I publish an update.
For repeated FingerprintUserID, that is a Hubitat behavior. When you send an event with the same value it does not raise it again. I used to have code to "force" events to act as new, but it was recommended I change that because it is not the way Hubitat is designed to run.
For FingerprintUserID not showing null... the code IS meant to provide nulls if the system sends back a dataPayload that includes fingerprint data. If the fingerprint.ulpId is null, it will set the FingerprintUserID to null. Otherwise it will set it to the ID provided. If no fingerprint data is provided, it will not know to set it null.
If you set the parent device to DEBUG logging, you would see a log entry that has "No userID found: ..." (and continues with the dataPayload info). This happens any time the fingerprint.ulpId is null.
If it is set for DEBUG, you would also likely get spammed with entries starting with "No fingerprint metadata found: ..." and "No metadata for fingerprint found:" which are stages of the dataPayload missing expected fingerprint information.
If you check over those and it seems like it is missing something that should be triggering the null, let me know and I can try to correct for it.
Adjusted how the PTZ functionality works to base it on seconds of change, not milliseconds. Also set a minimum of 0.5 seconds within the code to keep cameras from stuttering or the API from having issues (it seemed that small values were not catching the stop command in time to be processed properly). Accordingly, the child driver had the command descriptions changed to say seconds.
Minor changes to the driver version checking in both (other drivers will be updated as they are otherwise modified, it is not something I am forcing out) to match my newest method.
Note(s):
PTZ functionality still does not appear to work with 3rd party cameras. I have one... and the controller appears to become unhappy (my Protect app apparently rebooted, ie: became nonfunctional but then started working again after a time) if PTZ commands are sent for a 3rd party camera even if the API shows that it is a PTZ camera. My Ubiquiti PTZ still works just fine.
Update
3rd party PTZ IS supported, if you remove the cameras and re-adopt them with the latest release of Protect. I have added support for this into my driver.
Original Post
Yes, I was trying to make that point. Sometimes things can work behind the scenes, without it being officially published (to minimize official complaints or problems). Since my 3rd party camera is listed as having PTZ capabilities according to the API's responses, every once in a while I change it to a PTZ driver and try the commands to see if it works. So far, no luck. But I wanted to make sure I specifically mentioned it not working in case anyone saw the State Variables mentioning it had PTZ and thought it might.
Added support for detecting 3rd Party PTZ cameras. This WAS added into the Ubiquiti Protect API, however it requires removing and re-adopting the camera(s) from within Protect first so it can now detect them as PTZ. This is why mine was never working with it properly. So if you already have 3rd Party PTZ cameras, you can try removing them from your Protect console, and re-adopting them to see if it recognizes them. Within Hubitat you should remove the existing child device and let it be re-created using the correct child driver AFTER it has been adopted back into your Protect system.
Additional data handling was added in the parent driver.
When preferences are saved for the Camera, Doorbell, and PTZCamera child devices it will create image-related URL information for the device. This had a typo previously on the Camera and PTZCamera, and was missing from the Doorbell driver.
Minor changes to driver version checking.
Note(s):
3rd-party cameras are still a work-in-progress within the Protect system itself. For example: My 3rd party camera no longer properly takes snapshots (it gets an error when attempting it, even within Protect itself) and does not support preset locations, so the home and preset commands do not work. But it does allow controlling it using the PTZ commands provided. My non-PTZ 3rd party camera is working normally, including snapshots. So obviously things are still in a bit of flux on Ubiquiti's side (I am on the Early Access schedule).
I have a SuperLink and a USL Motion sensor that I wanted to get into my automations. Webhooks in the alarm manager won't do because 1) it takes a little too long to get the message to habitat (about three seconds, not super long, but long enough to be annoying) and 2) because they have no "inactive" trigger so it is impossible to know when the motion stops.
So, I wanted to use your driver. But I found that it wasn't triggering right away, much longer than the webhook. I found that it isn't triggering via the socket. It only goes active or inactive when the api controller does a Stats Refresh every 15 minutes or I do a manual refresh. I am assuming that this is not your intent and that maybe there is something missing. I have Enable WebSocket Monitoring on and cameras report motion right away.
I just think that, at least for this sensor, it isn't updating via the WebSocket.
Thanks for your time.
You have 80 Unifi sensors? That is impressive. I assume that is for a business.
Anyway, are any of them the ULS Motion sensor? And they are using this driver?
I completely deleted the drivers and started over again only to have the same result.
What am I doing wrong? I can't find any other settings that should be different.
So, I did the same thing with Protect, Webhooks, and MakerAPI. The problem is knowing when the motion ends to turn off a light. The Webhooks only trigger on motion, not on end of motion.
I am not sure how you get the webhook to report motion instantaneously as zigbee and zwave sensors are reporting quicker to hubitat for me.
But regardless, without the triggering of lack of motion, its a non-starter.
I created a custom driver for the environmental and motion sensors. The entry sensors required nothing additional. I have the motions set, for the most part, to become inactive after about 2 minutes without another activation. This works well for my use case.
I replaced all of my aging switches in addition to replacing my zigbee and Z-wave sensors. The cumulative effect before and after replacement has been very noticeable. Everything, at least for me, has been very responsive, no complaints.
Reliability and responsiveness were the two things that I was chasing with my upgrades. I feel that I achieved that.
Good luck!
Edit - Thinking about the timing issue a bit more. The USL sensors did require different mounting location considerations. They are pet immune which also affects mounting location. As I think about my locations, I don’t think any ended up where the zigbee/z-wave sensors were. I did relocate a few even more after initial setup to achieve desired results. For example, they won’t see you straight on when mounted vertically and horizontally changes the range.
