Here are mine which are only access points. I’m traveling Wed (20th) - Tue (26th) so I won’t be able to contribute during that time frame. I have wireless devices such as PCs, Macs, WeMo, iPhones, Androids, Nest, Samsung TV’s, Echo’s, etc. (around 90 devices).
Controller @ Home:
Controller @ Work connected via OH @ Home
Best, Jay
Excellent idea. My network consists of:
We should take care of properly scrubbing the data so no interesting device names, MACs and somesuch gets exposed. I assume the data would be handled confidentally to protect the not-so-innocent 
This was one of my main concerns with asking you guys to help with this but it’s not so easy as the logging happens pre-parsing 
Maybe I need to re-think this as I’m a big privacy advocate myself and don’t want to leak any unnecessary information.
So expanding on my original idea, more specifically what I’m interested in is creating a device thing. Off the top of my head we have two basic categories:
What I really need is a JSON dump of each model so I can properly implement the unmarshalling of the JSON. Furthermore, each of these devices will have various “write” channels (think LEDs for APs, PORT ENABLED for Switches).
Without having access to the equipment, development will be a bit of trial and error.
I have access to the following:
I have on my agenda to purchase the following for my new house but haven’t pulled the trigger yet:
This wiki page shows a table with a list of device types:
https://ubntwiki.com/products/software/unifi-controller/api
You’re gonna love these. I’m really happy with my US-24-250 and US-24 (no PoE). 
Thanks for this! I didn’t know it existed and will try and contribute myself.
So giving this more thought, scrubbing the data will be quite difficult as IPs and MACs appear in a lot of fields in the JSON. Furthermore, the relationships between the clients and devices rely on MAC addresses so “properly” scrubbing them to keep the relationships would prove even more difficult.
I understand if you’re not comfortable sharing your data with me, but if some of you are, I can push a build that will log the initial API calls once to a JSON file. After the initial dump, the logging is disabled internally. This will allow me to “mock” your controller instances which gives me more data to test with going forward with development.
Rest assured the data will be used in confidence only by me and I will provide a means for you to securely transfer the logs to me via my personal server (not via email and not via the community forums).
If anyone is interested, let me know and I will push a test branch with the logging code enabled.
Matthew
Nah, this is not a problem, as I have already shared my setup with you while debugging the SSL setup stuff.
It’s just that you should take care that those files do not end up being checked into git in src/test/whatever to have the mock data available for unit testing. I could understand the temptation to do so, I might be guilty of having done that myself 
here, interested 
Push away!
So there’s some more refactoring I’d like you guys to test - all in preparation of the new site and device things to come soon.
Also, there’s a new reconnect channel - see the updated README
with logging: org.openhab.binding.unifi-2.5.0-SNAPSHOT.jar
without logging: org.openhab.binding.unifi-2.5.0-SNAPSHOT.jar
These are the same builds - just one includes the logging code
Now, to active the logging - this part took forever to figure out (curse you log4j properties files) - stop OH2 and find the following file (it’s in /var/lib/openhab2/etc on Linux with OH2 installed via apt):
org.ops4j.pax.logging.cfg
Add the following to it
log4j2.logger.unifi.name = org.openhab.binding.unifi.internal.api.model.UniFiController
log4j2.logger.unifi.level = TRACE
log4j2.logger.unifi.additivity = false
log4j2.logger.unifi.appenderRefs = unifi
log4j2.logger.unifi.appenderRef.unifi.ref = UNIFI
log4j2.appender.unifi.type = File
log4j2.appender.unifi.name = UNIFI
log4j2.appender.unifi.fileName = ${openhab.logdir}/unifi.json
log4j2.appender.unifi.immediateFlush = true
log4j2.appender.unifi.append = false
log4j2.appender.unifi.filter.threshold.type = LevelRangeFilter
log4j2.appender.unifi.filter.threshold.minLevel = TRACE
log4j2.appender.unifi.filter.threshold.maxLevel = TRACE
log4j2.appender.unifi.layout.type = PatternLayout
log4j2.appender.unifi.layout.pattern = %m
After you restart OH2, you should now have a /var/log/openhab2/unifi.json. Take a look at the file and verify for yourself that the login API call is not logged
Once you have this file, you can stop OH2, remove the above logging configuration and safely install the build without logging. Once I have a copy of your unifi.json file, you won’t need to do this again.
For those of you who take the time to do this, send me a PM and I’ll tell you how to upload the file to my private server.
Thanks in advance!
Matthew
device? is there perchance also something for wiredClient in the works? This would solve a major pain point for me.
There’s also a wiredClient in the works 
Just want to get this blocked / reconnect PR merged (with all the internal API refactoring) and then come the new things!
Guys I have a problem with the Binding. OH #1525 (openhabian).
I’ve just downgraded from #1526, and the Binding stops working. Now the Controller is in “UNINITIALIZED” status. All the configuration is the same as before. The release of the Controller is 4.4.36.5146617.
my unifi.things is:
Bridge unifi:controller:home "UniFi Controller" [ host="192.168.100.253", port=8443, username="openhab", password="xxxxxxx", refresh=10 ] {
Thing wirelessClient andreaPhone "Andrea's iPhone 6" [ cid="20:3c:ae:d6:1a:c1", site="Home", considerHome=180 ]
Thing wirelessClient catePhone "Caty's iPhone 6S" [ cid="48:3b:38:60:c7:86", site="Home", considerHome=180 ]
}
Any suggestion how to fix it?
Thanks
Andrea
SOLVED removing the things file, then re-adding
Hey guys, any feedback on the latest version of the binding?
with logging:
openhab> bundle:list | grep -i unifi
253 │ Active │ 80 │ 2.5.0.201902201715 │ UniFi Binding
without logging:
openhab> bundle:list | grep -i unifi
254 │ Active │ 80 │ 2.5.0.201902201606 │ UniFi Binding
I’m running the one with logging. Have not seen any issues.
There is a new feature request in the forums:
Just thought it best to raise awareness…
Just to be sure I understand this correctly, he’s wanting to enable / disable SSIDs.
Off the top of my head, this might make sense to be a child / associated under a “site” since that’s where the SSIDs are assigned in the controller.
I know there are dynamic channels, but I’d have to look more into those.
Thoughts?
Thanks!
A little improvement to the docs, now that the binding is in master: