Ubiquiti Unifi Binding Feature Discussion

ubiquiti
unifi
Tags: #<Tag:0x00007f51efa8eb00> #<Tag:0x00007f51efa8e998>

(Mr. Wiseman) #786

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:

  • Unifi AP
  • 2 x Unifi AP-AC-PRO

Controller @ Work connected via OH @ Home

  • Unifi AP-AC-PRO

Best, Jay


(Hakan Tandogan) #787

Excellent idea. My network consists of:

  • a few UAP-AC-Lite access points, two on mains power, two on PoE
  • a few US-8-60W switches
  • an USG gateway
  • a Cloud Key (first generation, UC-CK)
  • and the usual plethora of wired and wireless clients in a typical home automation system :grin:

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 :smile:


(Matthew) #788

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 :frowning:

Maybe I need to re-think this as I’m a big privacy advocate myself and don’t want to leak any unnecessary information.


(Matthew) #789

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:

  1. Access Points
  2. Switches

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:

  • UAP (original model)
  • UAP-AC-PRO
  • US8 (non PoE model)

I have on my agenda to purchase the following for my new house but haven’t pulled the trigger yet:

  • UAP-AC-IW-PRO
  • US-48-500W
  • US-16-150W

(Patrik) #790

This wiki page shows a table with a list of device types:
https://ubntwiki.com/products/software/unifi-controller/api


(Mark) #791

You’re gonna love these. I’m really happy with my US-24-250 and US-24 (no PoE). :+1:


(Matthew) #792

Thanks for this! I didn’t know it existed and will try and contribute myself.


(Matthew) #793

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


(Hakan Tandogan) #794

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 :blush:

here, interested :smile:


(Mark) #795

Push away!


(Matthew) #796

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


(Hakan Tandogan) #797

device? is there perchance also something for wiredClient in the works? This would solve a major pain point for me.


(Matthew) #798

There’s also a wiredClient in the works :wink:

Just want to get this blocked / reconnect PR merged (with all the internal API refactoring) and then come the new things!


(Andrea Riela) #799

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


(Matthew) #800

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

(Mark) #801

I’m running the one with logging. Have not seen any issues.


(Hakan Tandogan) #802

There is a new feature request in the forums:

Just thought it best to raise awareness…


Unifi binding feature request:
(Matthew) #803

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?


(Crispin) #804

Thanks!


(Hakan Tandogan) #805

A little improvement to the docs, now that the binding is in master: