Minor change... I now made it so all MAC addresses submitted for Presence (manual or in Preferences for automatic checks) and MAC Exists checks will be submitted to the controller in all lowercase and the response handled as such. This eliminates a potential failure point.
Different Topic(s):
Still working on the abilities to archive alarms and initiate a speed test. These commands exist and it should be possible to get a status of how the speed test is running also however I have not figured out quite the right structure yet. Rather than continuing to hold off longer I felt it was better to get this minor update out and keep working on it.
For those of you using this... is there anything in particular you might be interested in seeing from your controller or being able to tell it to do from your Hubitat? I have a couple more ideas... but they are pretty low priority to me. Otherwise the majority of features I could need are already here (I do not even need/want the speed test, just thought it might be nice to provide).
I think the CheckAlarms is bringing my hub to halt. I had polling set to 5 minutes. Then at some point, my hub locks up. After 5 minutes of loading, the devices page comes up, but then the Unifi API driver device wont open. I have to reboot and delete the device right after restart in order to get the hub back. I have turned polling to manual, and things work fine, but wondering if i have a high number of alarms or something causing this. I have just commented out that function and will resume 5minute polling to see if the same thing happens.
Let me know if that was the cause. There is a query for just a count of alarms. I could not see the point but maybe you stumbled on it. If there is some X number I could exclude pulling them in.
I have noticed some functions can take a noticeable amount of time if there is a lot of data coming in. Things like checking all the devices the controller has ever seen, or logs... So I try to avoid those.
Well i guess i always just ignored them. I just went into the unifi app and archived them all. I still set it up to run the latest version without alarms hopefully all good now. Will report back if i notice anything strange. Thanks!
Thanks to @jschlote for point out I had forgotten to get the toLowerCase in the Responses (I missed the two spots there after focusing on what got sent for it). Plus the note about runEvery2... I thought there was one. Oops.
Updated Version(s):
UnifiAPI.groovy = 0.2.3
Change(s):
toLowerCase has been corrected in the responses for MAC Exists and Presence detection. Now it should not matter what you enter for manual checks or automatic ones.
Changed the runEvery# lines around automatic Presence Checking into schedule items instead. I think I will just go with those in general, easier to deal with. Plus while there I made it so if you enter more than 10 MACs for automatic Presence Checking it not only gives you an error in the log but will pop a Status event so there is a greater chance of people seeing it.
The child devices will always register with their MAC addresses because it is the most likely to be unique on the Hubitat. You can enter a name in the label... but... when it receives a successful response from the controller to an automatic Presence Check it is supposed to put the name provided by the controller in the label for the device. Of course, this assumes that the controller has a name.
If you do not mind, could you send me a trace log from when one of them is successfully detected with the presence? You can cut out all the MAC and other stuff you may want, but I want to see why the label is not being populated. I am populating it from the "name" field that is returned, which corresponds to the Alias on my UDMP apparently (one of my test MACs is the Hubitat I am using to develop this, so I know it will be online, another MAC is my cellphone which usually is NOT listed as online because it is not to a Unifi AP).
My Hubitat got it's label right away (because the controller says it is online) but my cellphone has not because the controller is saying it is offline (incorrectly, but I can only work with what the API tells me for this).
Not sure if this is the correct location, but since the lastest update to HE 2.2.5.120 I am having issues with the UNIFI controller login. I did get this every few days but would just go and click login and it would work again. Now this does not seem to work?
I am not having this with mine (on 2.2.4 or 2.2.5) so let me ask a couple questions:
Nothing has changed about your Unifi password? You can login normally to the controller itself?
Have you upgraded to the latest version of the UnifiAPI driver (0.2.3)? Did this happen before the upgrade or after?
I will have to change the logging a bit regardless to try to give more detail when there is an exception like that... but the overall problem should not be happening of course.
Yes I can login to the unifi controller fine. Yes mine is updated and was working okay, every few days I would have to go in and click login and it would work fine again.
Now it wont login at all. I am on the latest Unifi controller version 6.0.45 running on a raspberry pi 4b 4GB