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.

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.

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.

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:

mgbowman:

I was trying to do something with the signal, noise and rssi values but I'm not exactly sure how they all relate. It's easy enough to include them, but I'm not sure if they will be useful. For example (testing with my phone), from the API I get the following values:

signal = -70noise = -99rssi = 29

And in the controller UI (under Statistics) it shows Signal: 54% (-68dBm). I have no idea how this percentage is calculated, but I'd be happy to include these numbers if someone finds them interesting.

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?

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.

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.

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.

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

mgbowman:

Care to share how you were planning on using the RSSI values in your setup?

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.

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.

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.

@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

Did you try restarting OH2? I'm not 100% those console commands are the correct update procedure.

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

mgbowman:

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

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,

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...