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.
Oh really? I just assumed that since the web interface of the controller shows the last seen values for 24 hours that it would get returned. Seems kind of odd that it doesn’t.
Now I understand what you mean. You’re referring to the ‘Insights’ tab of the controller UI. This also could be an option but I’m wondering if it’s even necessary.
Let TB = The timeout defined in the binding
Let TC = The time it takes the controller to report a client as offline
Since the goal of the binding timeout is to declare a client offline before the controller reports it offline, the controller will continue reporting lastSeen - assuming TB < TC.
On the other hand, it we want to support TB > TC, I would either need to interface with the ‘Insights’ data, or keep a lookup table (as previously mentioned).
Honestly, both approaches would work:
I would like to know what you guys think before I add support for this timeout.
Hopefully this will be the last enhancement and we can still make the 2.2 release.
Keeping the binding correct would be my priority, as quick hacks tend to stay forever (“it already works, why change?”).
Even if you don’t make the 2.2 release the binding is still on the Eclipse marketplace, so people can find and install it. Kai is working on improving the automated release procedure, so I believe even if we don’t make it in time for 2.2, a 2.3 version will come more quickly 
I agree. I will work on interfacing with the Insights data to realize the timeout.
Can someone tell me exactly how to install this binding?
I´ve placed the .jar file ind the addons folder, but yet there is no binding in the PaperUi??
Greets
Kim