Hi.
Is it possible to ad the uptime value of a connected client as a new channel ?
I need to know now long a client has been there and the value is there in the Unify controller?
Or add the last seen value (to get beter results) in presence detection?
Thanks.
Agreement here as well. 
I was originally planning on needing to rely on an aggregate of several sensors to get reliable data, but so far there doesn’t seem to be a need. Admittedly I haven’t started to actually use the presence data for anything, but I have never seen it be inaccurate.
Any way in which it might fail, other methods are just as, if not more, susceptible to. Wifi being turned off, device left behind, etc.
Reducing the time for reporting as away would be a nice improvement for future versions. As it stands now though this binding is pretty sweet.
Here you go…
Please checkout the updated README
Noteworthy changes:
The online channel was changed to a Contact - The normal (state) of the Contact can be configured on the Thing definition allowing you to change the polarity*.
Added an uptime channel (Number) - This is the time, in seconds, the wireless client has been connected to the controller. The UniFi Controller UI displays this value in the UPTIME column.
Added a lastSeen channel (DateTime) - This is the date & time the wireless client was last seen by the controller.
* Since I couldn’t decide what the normal Contact state should be for absent vs present states, I added a Thing Configuration parameter contactType so you get to decide 
Please update to the latest build org.openhab.binding.unifi-2.2.0-SNAPSHOT.jar and report back if you guys have any issues.
For now, I’m leaving the binding purely stateless. We will just have to live with the delay introduced by the controller when it comes to marking a client as absent. Maybe in the future I will find a simple way to support some kind of binding specific timeout.
Looking forward to feedback.
I can give you one of my use cases that may switch on a lightbulb (no pun intended… ok maybe a little)
I track my wife and I’s iPhones. I have a “It’s Bedtime” scene that is trigged when the living room’s harmony switches off in the evening. All the lights along the path to the bedroom dim up and both of our bedside table lamps turn on.
When both bedside table lamps turn off, this means “we’re in bed” and all the lights in the house turn off.
What does this have to do with presence detection?
My wife travels a lot for work so when she’s not home, her bedside lamp doesn’t come on - I only have to turn mine off. I got annoyed having to roll over every night and turn hers off whenever she was away. Am I lazy? Yes, yes I am! 
This is the main valid reason for all automation 
I need to ask, why is this method better than others, e.g. the normal network binding dhcplisten+ping method? Seems to me both have the same benefits and restrictions…
I can’t speak for Android but you cannot ping an iPhone that’s asleep. However, iOS maintains the wireless association to the access point (unless it’s in low power mode) and remains visible in the UniFi controller.
This means no additional battery drain as there is absolutely no additional traffic to or from the iPhone outside of the ordinary behavior of iOS.
Understood. That’s a pro indeed. Regarding the leaving of a device: Did you do measurements how long it takes to detect a device left the network, e.g. after turning off the iPhone?
It varies but usually it’s less than 10 minutes. Not a huge inconvenience, but another use case for caching the client’s online state is sometimes the controller can return an empty response and / or a specific client is missing from the list of connected devices. You could get a short blip where some (possibly all) devices are suddenly offline and on the next refresh they’re back online. Depending on your rules, this could result in a false positive trigger.
I’m going to monitor the newly added lastSeen channel and see if I could use this as a way to implement a more controllable timeout period.
I just updated the Full Example in the README. Hopefully it helps everybody with the new channels.
This is great! All looks good, except that when a phone disconnects, lastSeen changes to UNDEF. How would I retain/display the actual last time the phone was seen?
Thank you so much for the new channels (uptime, lastseen).
Working perfect !
Nothing wrong with that. If you’re anything like me, the effort put into “simplifying” things would have gone a long way towards just getting up and switching it though haha. It’s one of my cheaper hobbies though so it’s all good.
Now that I have my door sensors, I was going to have the lights turn on to a low level if someone arrives home and then the door opens. Debating whether to have it happen only if the house was completely vacant initially, or any time either my wife or myself arrives.
Couldn’t you just base the status on (current time - last seen) > user configurable time-out? Or am I over simplifying the problem here?
EDIT:
I upgraded to the latest 2.2.0 snapshot. Thought I would add a couple observations.
I had to delete and readd my client things for the additional channels (uptime, last seen) to show up. I didn’t see this mentioned so just an FYI.
The change to a contact for the online channel seems to have broken the dynamic presence icon. I’m not sure why since the docs say that dynamic icons are based on the mapped value, not the raw state. In the default icon set they are called “present” and “present-off” though so my assumption is that is what’s going on.
EDIT 2:
Another thing to be aware of. Binding an item to last seen will litter your event log. Pretty obvious after the fact, but not something I thought about until I saw it.
I’ll fix this in the next update. The initial version of the binding just set everything to UNDEF but I think uptime should default to 0 and lastSeen should stay as it’s last value.
I have it setup exactly the same way and I do it every time the door opens - the only guard condition is whether it’s Day or Night (using the astro binding). I tried it where it only triggered if the house was completely vacant but if the wife was upstairs, it would remain dark when I walked in the front door. More often than not, you will want the lights to turn on vs. them turning on and you not needing them.
This is exactly my thinking - you’re not over simplifying it at all. I will try keeping a map of mac addresses to lastSeen timestamps and see if I can manage it that way.
I should of mentioned this. It depends on if you had configured your things through the Paper UI or you defined them via a unifi.things. Paper UI configured things needed to be removed and re-added for the new channels to appear. Sorry about that.
Good catch! It looks like it’s expecting an ON | OFF state for present and not an OPEN | CLOSED state.
You can see this by trying the following URLs:
http://openhab2:8080/icon/present?state=ON&format=svg
http://openhab2:8080/icon/present?state=OFF&format=svg
http://openhab2:8080/icon/present?state=OPEN&format=svg
http://openhab2:8080/icon/present?state=CLOSED&format=svg
I’ll dig deeper and see if there’s an easy fix for this.
Could you elaborate? I just get the expected events:
2017-09-02 08:18:03.887 [ItemStateChangedEvent ] - MatthewsPhoneLastSeen changed from 2017-09-02T08:17:48.000+0300 to 2017-09-02T08:17:58.000+0300
2017-09-02 08:18:13.888 [ItemStateChangedEvent ] - MatthewsPhoneLastSeen changed from 2017-09-02T08:17:58.000+0300 to 2017-09-02T08:18:09.000+0300
2017-09-02 08:18:23.886 [ItemStateChangedEvent ] - MatthewsPhoneLastSeen changed from 2017-09-02T08:18:09.000+0300 to 2017-09-02T08:18:23.000+0300
If you’re referring to the frequency, this is simply an artifact of the refresh interval on the binding. Really no way to avoid this.
Will do a little more work on the binding and will push an update shortly.
I manage to fix it with the following (using a NO contact):
mgbowman@openhab2:~$ curl -o /etc/openhab2/icons/classic/present-closed.svg "http://openhab2:8080/icon/present?state=ON&format=svg"
mgbowman@openhab2:~$ curl -o /etc/openhab2/icons/classic/present.svg "http://openhab2:8080/icon/present?state=OFF&format=svg"
Even though the Dynamic Icons docs say:
If you watch the network traffic, it still uses the OPEN | CLOSED states and not those defined by the MAP. Possible bug?
Fixed!
Whenever a client goes offline, the uptime will fallback to 0 and lastSeen will retain its last value.
Please update and let me know if you have any issues.
This sentence is wrong and must have slipped my pen when last editing this page.
In order to define your own icons for presence based on the contact item, you need to define three files:
mypresence-open.svgmypresence-closed.svgmypresence.svgThe default icon presence.svg is reserved for states that were not provided specifically (Normally this icon would cover NULL/UNDEF for example). So while your OPEN state would implicitly be covered, I’d recommend to provide all three for future flexibility. Good luck
Edit: It would be possible to provide OPEN and CLOSED with the default iconset provided by the distribution. Maybe something we should consider.
I was thinking you wouldn’t even need to store anything. On each refresh simply do the calculation based on the current lastSeen value.
No problem at all. Just a heads up for others.
It was easy enough to fix by making a copy of the default present icons in icons/classic and renaming the present-off to present-open. Would be nice to retain the ability to use default icons, but not a deal breaker
That’s exactly what I mean. Like I said, it’s obvious that it’s going to happen when you think about it, and not really something that can be fixed. I wish there was a way to limit the logging of certain events.
Once again, great work Matthew!
Once a client goes offline, you no longer get the lastSeen value from the controller.
IIRC from OH1 design principles, bindings should not access (what was) the ItemRegistry to determine the current state of an item. Following this, I figure a simple lookup table of mac to lastSeen values would be the easiest solution.
very nice stuff!
I tested build#41 (https://jenkins.otr.mx/job/openhab2-unifi-binding/) and it works fine! Thanx Matthew!
question:
Is the Thing optional on the client line?
Bridge unifi:controller:home "UniFi Controller" [ host="unifi", port=8443, username="$username", password="$password" ] {
Thing client matthewsPhone "Matthew's iPhone" [ mac="$mac", contactType="NO" ]
}
That was copy and paste from my unifi.things so I guess it is?
I’ll add it in the example just for clarity.