It´s alot better… About 3 minutes to discover I was away.
That’s really odd as I see the “is_wired” : false in the Exception’s output 
I’m guessing the cause of the error is further down in the JSON response.
I really need to see the JSON to help. Please setup TRACE logging to a unifi.log file - see my previous post on how to do this. I sent you a PM on how you can share it with me so I can get to the bottom of this.
Side note: I’m running 5.4.11 (need to update) but I doubt this has anything to do with it.
Hey Kim,
Glad it’s working for you!
Keep in mind that if your controller is actually updating the lastSeen channel more frequently, you can lower considerHome to have it mark you away even quicker.
For example, I’m running 5.4.11 and I get updates to lastSeen every refresh interval (10 seconds). So theoretically, I could use considerHome = 60 and it’ll mark me away after 1 minute. It’s up to you.
Hey guys,
I pushed version 2.2.0.201709210443 (build #53) which fixed @havaak’s problem. He already tested it, but I’d like if all of you guys could update and report any problems.
Assuming everything is ok, I feel confident the binding is ready for a PR to finally get merged into the master branch.
Happy Friday!
1 Like
How do I turn on debug logging
log:set DEBUGunifi.handler.UniFiControllerHandler
?
I updated to OH2.1 today and the latest snapshot, and I’m not getting any presence updates…but I’m not getting any errors or anything in the logs either (the old null state), nada.
I’m finding with the latest version just uploaded a few hours ago I am getting an issue where none of the devices are being detected - I’m not sure why this has changed.
2017-09-22 18:06:04.364 [UniFiController ] - JSON content from URL: https://192.168.1.57:18443/api/s/default/stat/sta
{
“data” : [ {
"_id" : “598f81a1e4b0539cbaf907eb”,
"_is_guest_by_uap" : false,
"_last_seen_by_uap" : 1506067556,
"_uptime_by_uap" : 8697,
“ap_mac” : “f0:9f:c2:f0:",
“assoc_time” : 1506058579,
“authorized” : true,
“bssid” : "f2:9f:c2:f1:”,
“bytes-r” : 2,
“ccq” : 720,
“channel” : 11,
“essid” : “2",
“first_seen” : 1502577056,
“hostname” : "android-6c85e95ee4b2",
“idletime” : 12,
“ip” : “192.168.1.79”,
“is_guest” : false,
“is_wired” : false,
“last_seen” : 1506067556,
“latest_assoc_time” : 1506058859,
“mac” : "84:38:38:b7:92:”,
“noise” : -107,
“oui” : “SamsungE”,
“powersave_enabled” : true,
“qos_policy_applied” : true,
“radio” : “ng”,
“radio_proto” : “ng”,
“rssi” : 23,
“rx_bytes” : 2256669,
“rx_bytes-r” : 2,
“rx_packets” : 18764,
“rx_rate” : 24000,
“signal” : -84,
“site_id” : “595cb597e4b0429ab0cbd680”,
“tx_bytes” : 6567867,
“tx_bytes-r” : 0,
“tx_packets” : 7689,
“tx_power” : 40,
“tx_rate” : 132620,
“uptime” : 8977,
“user_id” : “598f81a1e4b0539cbaf907eb”,
“vlan” : 0
}… etc
However, straight afterwards I get these lines:
2017-09-22 18:06:04.391 [UniFiController ] - Found 8 UniFi Client(s):
2017-09-22 18:06:04.404 [UniFiController ] - UniFiClient{mac: ‘84:38:38:b7:92:**’, hostname: ‘android-6c85e95ee4b2****’, wired: true, device: UniFiDevice{mac: ‘f0:9f:c2:f0:****’, name: ‘null’, model: ‘U7LT’, site: Site{name: ‘Home’, path: ‘default’}}}
This seems to be saying although it is not wired in the JSON response, in the log file it then changes this to say the mobile phone is now wired?
017-09-22 18:06:33.571 [UniFiController ] - JSON content from URL: https://192.168.1.57:18443/api/s/default/stat/alluser
{
“data” : [ {
{
"_id" : “598f81a1e4b0539cbaf907eb”,
“duration” : 2349062,
“first_seen” : 1502577056,
“hostname” : “android-6c85e95ee4b2****”,
“is_guest” : false,
“is_wired” : false,
“last_seen” : 1506030050,
“mac” : "84:38:38:b7:92:",
“oui” : “SamsungE”,
“rx_bytes” : 2891458735,
“rx_packets” : 21224784,
“site_id” : “595cb597e4b0429ab0cbd680”,
“tx_bytes” : 38300666906,
“tx_packets” : 30660389 }…etc
2017-09-22 18:06:33.572 [UniFiController ] - Found 4 UniFi Insights(s):
2017-09-22 18:06:33.572 [UniFiController ] - UniFiClient{mac: '84:38:38:b7:92:’, hostname: ‘android-6c85e95ee4b2****’, wired: true, device: null}
2017-09-22 18:06:33.573 [UniFiClientHandler ] - Refreshing channel = unifi:client:c384e799:online
2017-09-22 18:06:33.573 [UniFiClientHandler ] - Could not find a matching client: mac = 84:38:38:b7:92:**, site = null
I am guessing there is logic to not gather client info when the device is detected as a wired connection, but these devices are wireless as shown in the json data returned from the API.
Is anyone else experiencing the same logic issue where a wireless device is being interpreted as a wired client?
@mgbowman, this binding is really FUN! Thank you for making it available.
To take it one step further; if I wanted to check the presence of “wired” devices or even Unifi equipment, how would I do that? Just bringing it up as a thing leeds to “Could not find a matching client”
cheers
Han
Ahh now I’m getting which AP its connected to.
But in terms of the online propterty, should that be a switch or a contact? If it’s a switch I’m not getting it switched over any more…but I’m noticing the icon change, confusing.
EDIT: I just turned off wifi on the phone, saw the AP go away and then when it came back on I saw the rssi and ap change, but not the online status:
09:59:33.424 [INFO ] [marthome.event.ItemStateChangedEvent] - unifi_Ugluk_AccessPoint changed from AP-Cupboard to UNDEF
09:59:33.429 [INFO ] [marthome.event.ItemStateChangedEvent] - unifi_ugluk_rssi changed from 23 to UNDEF
09:59:43.435 [INFO ] [marthome.event.ItemStateChangedEvent] - unifi_Ugluk_AccessPoint changed from UNDEF to AP-Cupboard
09:59:43.438 [INFO ] [marthome.event.ItemStateChangedEvent] - unifi_ugluk_rssi changed from UNDEF to 23
Has something changed in this area?
Yes the online channel is now a Contact
There’s more info in the Thing Configuration section of the README as well as a Full Example
1 Like
I have ben using the binding for some time now. In my opinion it is ready for a pull request.
With the last enhancement, it detects clients going offline Quick and smooth.
Good work. @mgbowman,
If nobody else reports any problems with the last update, I’m in agreement. It’s time to get this into the master branch as it’s been over a year since I started this thread 
4 Likes
That long already? Then let’s go ahead and remove the “WIP” from the pull request title, maybe it could already be part of 2.2.0 
I’ve had a chance to test this now and it is working as expected - I’m happy to say to go ahead and release it!
Latest version looking good from my perspective. I have the binding running in each of two openHAB instances, each openHAB instance running in a different site, both sites sharing a Unifi controller running in one of the sites.
The latest enhancement that added considerHome works very well for me. 
Thanks for the superb binding! Works very well for me and my UAP-AC-Lite + some iPhones 
I would be interested in knowing which values you guys chose for considerHome. I guess setting it too low may trigger false positives, i.e. the binding will report a device as absent when it is in fact not (low delay, low accuracy).
Setting it too high will lead to longer wait times until the binding correctly identifies a device as absent (high delay, high accuracy).
Has anyone experimented with the setting and can share the “sweet spot”? 
(Although the ideal setting may highly depend on the specific devices and their energy saving modes, I guess…)
For me the sweet spot is 60. I Think you mustang experiment. And find your own sweet spot.
@hoalex I think it’s more of a personal preference in what your trying to achieve with the automation and less of a general purpose “sweet spot”. It all comes down to how quickly you want to take action when your device (or all your devices) are offline.
For me personally, the difference between 60s and 180s is minimal when it comes to triggering the automation rules. The whole point of the considerHome parameter was to give us a predictable way of marking a client offline because waiting for the controller to do it was taking upwards of 10 minutes in some cases.
Best of luck!
1 Like
Hi,
great Work! But I couldn’t get it to work 
I’m currently running on: openHAB 2.2.0 Build #1054
All configuration done through PaperUI except the Sitemap.
Controller ist showing up online (used a read only user, but already tried admin account)
When configuring UniFi Wireless Client it shows following error:
“Status: OFFLINE - CONFIGURATION_ERROR You must choose a UniFi Controller for this UniFi Wireless Device.”
2017-10-03 12:01:24.632 [INFO ] [unifi.handler.UniFiControllerHandler] - UniFi Binding v2.2.0.201709220819
2017-10-03 12:01:24.634 [hingStatusInfoChangedEvent] - 'unifi:controller:a7b06734' changed from UNINITIALIZED to INITIALIZING
2017-10-03 12:01:25.663 [hingStatusInfoChangedEvent] - 'unifi:controller:a7b06734' changed from INITIALIZING to ONLINE
2017-10-03 12:03:19.448 [hingStatusInfoChangedEvent] - 'unifi:client:979d1f8d' changed from UNINITIALIZED to INITIALIZING
2017-10-03 12:03:19.452 [hingStatusInfoChangedEvent] - 'unifi:client:979d1f8d' changed from INITIALIZING to OFFLINE (CONFIGURATION_ERROR): You must choose a UniFi Controller for this UniFi Wireless Device.
Don’t know if this Build und Binding should work together. If you wan’t me to test something?
Regards
