Then why is the OH instance in MD pointing to the controller’s NJ site? The things in both OH instances would only reflect whether you’re at NJ.
Ugh. Because my terminology is still wrong. LOL
The Unifi Bridge in OH instance 1 is configured with:
- Hostname = IP address of Unifi Controller in location 1
- Site = NJ
The Unifi Bridge in OH instance 2 is configured with:
- Hostname = IP address of Unifi Controller in location 1
- Site = MD
That makes much more sense.
In your use case and my current code, the wireless client things would show as ON in both OH instances regardless of which site you where at. However, the things now have a site channel which would change between NJ and MD so you would still be able to tell where you were.
Maybe I should add an optional site parameter to the wireless client thing configuration which would make the binding only look for the thing in a particular site. I believe this satisfy what you’re trying to achieve.
1 Like
Yes, this really would be helpful. 
Otherwise, all the rules become more complex because you now need to check the site in addition to checking ON/OFF state.
Having compiled the binding from your current github sources ( https://github.com/mgbowman/openhab2-addons/tree/unifi-binding ), I cannot get the rssi values to work:
unifi.things:
Bridge unifi:controller:home "Unifi Controller: Home" @ "Other"
[ ... as in your example above ]
{
Thing client hakans_s6 "Unifi: Hakans S6" @ "Other" [ mac="mac-of-my-mobile" ]
}
unifi.items:
Switch hakans_s6 "Hakans S6 [%s]" <present> (gUnifi) { channel="unifi:client:home:hakans_s6:online" }
Number hakans_s6_rssi "Hakans S6 rssi [%s]" (gUnifi) { channel="unifi:client:home:hakans_s6:rssi" }
The “online” status is shown correctly, and if I turn debugging on, I can see that my device data is fetched correctly, but putting that data into an Item I cannot get to work:
from the debug log:
UniFi Client: android-foobar (mac = my-secret, essid = my-other-secret, ap = null, rssi = 47)
Do you have any idea or example?
Hi Hakan,
I’m at the same stage as you, but how do I turn on debugging to see that data?
not quite the official way, but search for a file called
org.ops4j.pax.logging.cfg
in your installation, and then add
# unifi logger
log4j.logger.org.openhab.binding.unifi = TRACE, unifi, osgi:*
log4j.additivity.org.openhab.binding.unifi = false
# File appender - unifi.log
log4j.appender.unifi=org.apache.log4j.DailyRollingFileAppender
log4j.appender.unifi.layout=org.apache.log4j.PatternLayout
log4j.appender.unifi.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss.SSS}
[%-5.5p] [%-36.36c] - %m%n
log4j.appender.unifi.file=${openhab.logdir}/unifi.log
log4j.appender.unifi.DatePattern='.'yyyy-MM-dd
log4j.appender.unifi.append=true
log4j.appender.unifi.maxFileSize=10MB
log4j.appender.unifi.maxBackupIndex=10
at the end of that file.
The official way is decribed at http://docs.openhab.org/administration/logging.html and does a bit of “log:set”, but this is my way and my way works for me 
Well there’s your problem 
What’s on github doesn’t have RSSI support - I haven’t pushed any of my latest work as I’ve been cleaning it up and thoroughly testing it. Also, I always rebase my branch off master before pushing (forcefully) so the commit history will be completely overwritten. Just saying this as a warning if you’re cloning my repo and thinking a git pull will update to the latest code. I mainly push to github as a backup of my work.
I’ve done a little more work tonight and will do my best to finish the README and publish another build on my github tomorrow morning - it’s Friday and time for some 
Regarding RSSI, did you see my comments about the odd values reported in the API:
I’m happy to include these if they’ll be useful, but how the controller is deriving the Signal: 54% (-68dBm) is beyond me. I tried figuring it out but gave up as I don’t see any value of these numbers from an automation perspective.
Care to share how you were planning on using the RSSI values in your setup?
Just finished this. Now you can set an optional site parameter on the wireless client thing configuration and it will match both the mac address and site name (and you can use either the random string from the URL or the friendly site name).
If the site parameter is left blank, it will search for the wireless client in any site that’s defined on the controller.
Will report back tomorrow once I have the next build ready.
Cheers
Actually, I have just set up a jenkins job which does a clean clone of your repo and branch. It should pick up the forced push, so I’ll just wait for you and see what happens
Actually, I just wanted to keep them in influxdb over a few days to get a feeling for how my reception changes as I walk around in the house. And to derive a decision from that whether I should invest in a second Unifi Light AP… Basically just collecting data and see later what I can use it for.
Totally agree with you on that! Thanks for all your work on this binding!!!
Once you push a new version, I’ll give it a try in my multi-site environment.
My latest work is now published. Still needs a little more testing when the controller is offline during startup / configuration and when the controller disappears after previously being online. Will work on that tomorrow.
First and foremost, please checkout the README
The biggest breaking changes are on the controllers’ configuration parameters:
-
sitehas been removed (it’s no longer needed at the controller level) -
refreshIntervalwas renamedrefreshto be more in line with other bindings
You will more than likely have to recreate your things after updating.
Here’s the easiest way I found to update - access your OH2 console and do the following:
URL for the bundle:update command below: org.openhab.binding.unifi-2.1.0-SNAPSHOT.jar
(let me know if you have issues accessing this URL)
openhab> bundle:list "UniFi Binding"
START LEVEL 100 , List Threshold: 50
ID | State | Lvl | Version | Name
-------------------------------------------------------
209 | Active | 80 | 2.1.0.201701251046 | UniFi Binding
openhab> bundle:update "UniFi Binding" https://jenkins.otr.mx/job/openhab2-unifi-binding/lastSuccessfulBuild/artifact/addons/binding/org.openhab.binding.unifi/target/org.openhab.binding.unifi-2.1.0-SNAPSHOT.jar
openhab> bundle:list "UniFi Binding"
START LEVEL 100 , List Threshold: 50
ID | State | Lvl | Version | Name
-------------------------------------------------------
209 | Active | 80 | 2.1.0.201704081435 | UniFi Binding
Notice the version bump from 2.1.0.201701251046 to 2.1.0.201704081435
A footnote about future updates:
If you notice that binding URL references the .../lastSuccessfulBuild/... in Jenkins so from now on whenever I publish, my Jenkins server will automatically rebuild and that URL will point to the latest version.
Whenever I push an update, I’ll post here with the most current bundle version so everybody knows they’re running the latest code.
Thank you @hakan for inspiring me to setup Jenkins 
Latest Version: 2.1.0.201704081435
2 Likes
I have to thank you, sir, for creating this binding, which made me install the unifi AP which was collecting dust for the last few weeks
I have updated my OH to the current version linked in the topic.
When an update occurs, I get the following Exception:
2017-04-08 22:20:45.415 [WARN ] [org.apache.karaf.services.eventadmin] - EventAdmin: Exception during event dispatch [org.osgi.service.event.Event [topic=openhab/update/hakans_s6_ap] {bridgemarker=true, item=hakans_s6_ap, state=null} | {org.osgi.service.event.EventHandler, org.osgi.service.cm.ManagedService}={event.topics=openhab/*, service.pid=org.openhab.mqtt-eventbus, component.name=org.openhab.binding.mqtt.eventbus, component.id=199, service.id=364, service.bundleid=220, service.scope=bundle} | Bundle(org.openhab.binding.mqtt_1.10.0.201703270110 [220])]
java.lang.NullPointerException
at org.openhab.binding.mqtt.internal.MqttEventBusBinding.receiveUpdate(MqttEventBusBinding.java:128)[220:org.openhab.binding.mqtt:1.10.0.201703270110]
at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:38)[226:org.openhab.core.compat1x:2.1.0.201703270625]
at org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415)[6:org.apache.karaf.services.eventadmin:4.0.8]
at org.apache.felix.eventadmin.impl.tasks.HandlerTask.run(HandlerTask.java:90)[6:org.apache.karaf.services.eventadmin:4.0.8]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_111]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_111]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_111]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_111]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_111]
The item is defined as follows:
String hakans_s6_ap
"Hakans S6 AP [%s]"
(gUnifi)
{ channel="unifi:client:home:hakans_s6:ap" }
And I have the mqttbus-binding activated, but this caused no trouble until now.
@hakan Bummer you’re having issues all of a sudden. Did you try restarting OH2? I’m not 100% those console commands are the correct update procedure.
Up until now, I’ve been developing / testing with Item Linking in “Simple Mode” so I’m not 100% up to date on the syntax of the .things files yet - hence the TBD in the README examples - so I’m not sure how to read unifi:client:home:hakans_s6:ap.
TBH, I finally setup my new always-on instance of OH2 yesterday and will slowly begin the migration process of my OH 1.8.x instance 
I will tinker with my new OH2 instance later today and try and setup MQTT to see if I can recreate this issue. Either way, MQTT will help with the transition from 1.8.x to 2.0
Actually, yes, I did restart it. Also, I downloaded the jar into my own addons directory so it would always be updated. I’ll track that problem a bit more during the next few days.
I try to keep as much of my setup as possible in *.things and *.items files so I can always start a fresh installation or set up a debugging instance on another box withough being the other folks in the house being angry at me for playing around with a vital service 
If you install the Paper UI and go to “Things”, and then select your Thing for your client, it will show you the channel string. Very helpful
Welcome to the brave new world
I am sure that you will enjoy what OH2 will bring, One thing I learned after wasting too much time is that MQTT is a wonderful tool to have in your hands. Instead of having wires running through all the house, and wondering what happened whenever one of them fails, I have just a few Raspberries and a few more ESP8266 nodes, and all talk perfectly to the main OH2 instance in the cellar of the house. The wonders of modern networking
So, after some more debugging, and creating items both through the Paper UI and through items files, I am sure that the NullPointerException only occurs on the “ap” channel. Interestingly, when looking at the unifi debug log,
UniFi Client: android-bc4716d91793d6e5 (mac = this-is-secret, essid = gshome-u, rssi = 37, ap = null)
“ap” is the only null value. Could it be that you set the value of this channel directly to null instead of undefined?
UnDefType.UNDEF@hakan update and try again. I added some additional logging and changed the unknown states from UnDefType.NULL to UnDefType.UNDEF
Binding URL: org.openhab.binding.unifi-2.1.0-SNAPSHOT.jar
Latest Version: 2.1.0.201704091001
I was hoping someone would make a binding like this 
I’m trying to get it to work with a 5.4.11 controller.
I added things manually, and configured the debug logging as above. But I don’t seem to get any data.
The log file stays empty and the items I linked to the channels of the things don’t seem to get values.
I have updated the binding, but it is still not fully functioning yet… When I activate the “ap” channel though the Paper UI, I am still getting the NPEs, and cannot see the logging statements that should come if I read your code change correctly…
openhab> bundle:list | grep -i unifi
240 | Active | 80 | 2.1.0.201704091001 | UniFi Binding