Ubiquiti Unifi Binding Feature Discussion

Keep up the good work!

Well I managed to make some progress on just getting things “up to date” as it has been quite a while since I’ve done any development:

  1. My repo and binding branches are up to date with master
  2. Have a fresh “functional” IDE so I can start developing again
  3. Updated my Jenkins build server to properly build the latest codebase

I spent around 4 hours just doing the above. :tired_face:

Need to take care of a few more urgent things around the house and then I’ll have more free time in the evenings for the binding.

Will keep you all posted.

Matthew

5 Likes

I think this binding is super! Thanks for continue to work on that.
I just spend 10min finding this issue:
2019-09-18 21:23:25.982 [DEBUG] [i.internal.api.model.UniFiController] - Could not find a matching client for id = 172. 6.5.12
and I propose to make this a warning, not a debug :smiley:

The feature I would want to ask for is.

  • auto discovery (where the mac address is the thing-id)

Keep up the awesome work and congratz to the new place!

Thanks, it’s finally nice to have a place of my own!

Now on to the progress of the binding…

So @lexusburn got me motivated with a PR, to start development again and I’ve managed to implement LED toggling at the site level. Eventually once hardware devices like APs and Switches are added to the binding, you should be able to toggle the LEDs on a per-device basis.

Before I push my latest code, I want to ask how many are running at least 2.5.0.M2+ ???

Since the code reshuffling in master has taken place, I 99.99% sure the binding is no longer 2.4 compatible :frowning:

If there’s enough of you “living on the edge”, I will push my code for testing. :smiley:

Cheers!

Matthew

I don’t see changes that would make it incompatible. It depends on gson, which would need to be installed separately in a 2.4 installation. But you can work around it by including the gson jar in a lib folder specifically in a jar for 2.4.

There may be issues when using 2.5.0 add-ons on 2.4.0 because the XML namespaces changed from ESH to OH.

See:

I’m on 2.5M3 :slight_smile:

LED toggling would be awesome! Any chance to change the LEDs to white? I’m doing this now by pushing SSH scripts with rules, so it’s clunky, but works. Of course, this isn’t a big deal either way, would just be a cool thing to have.

“Productive”: M3

Test installations: latest beztezt nightly builds

both dockerified of course.

@papaPhiL

If this was a warning, any time a client was not online nor found in the “historical” insights data, this message would spam the log every refresh interval - hence the reason it’s a debug


@roy_liao

I’m not sure what you’re referring to here. The new led channel toggles this in the controller:

I’ve never seen anything about turning them white.


I will spin up a fresh 2.4 and try the binding and report back. Either way, I’ll update the docs later today and push the new builds for fresh testing.

Next on my list is adding AP devices. What channels would you like to see?

  • totalClients
  • wirelessClients
  • wiredClients (not sure if this is possible but I’ll look into it)
  • guestClients
  • led

As usual, will update you all once the builds are up.

Happy Friday!

Matthew

ah, sorry, I wrote the rule so long ago I forgot it was a hack, instead of something supported in the Unifi Controller. I was thinking the controller had an option to change to white colors. Basically, this is it: https://www.reddit.com/r/Ubiquiti/comments/8plxpo/change_ap_ac_lite_led_color_to_white/

The hack requires SSHing into each access point, so definitely outside the scope of the binding.

There’s a space in the ip address between 172. and 6. I don’t know how the matching is done, but if it just compares 172.6.5.12 with 172. 6.5.12 then they will not match.

I’m running OH 2.4 with this version of the binding which I think you made it work for 2.4 by removing some code.

Been working flawlessly with a local controller and a controller across the Internet.

openhab> list -s | grep unifi
198 │ Active   │  80 │ 2.5.0.201903071727     │ org.openhab.binding.unifi

Best, Jay

My functional request would be the following:

  • WiFi experience level (0 - 100%) on a device - channel needed
  • Send a “Reconnect” command on a device - channel needed

I have 79 WiFi devices and 3 AP at home and I find that those that fall below 49% on WiFi levels - I can select Reconnect and the client’s WiFi experience (9x out of 10) will increase above 50%.

I would like to automate this a bit hence the request.

Best, Jay

This is already supported by the latest version of the binding that I’ve published!

See Wireless Client Channels

As far as the “WiFi experience level”, I’ll have to look through the controller UI and see exactly where this is coming from. Will report back!

1 Like

Hi Marcel, yes, thanks! But the device was not there at all, i changed the IP a while back ago.

I wanted to add this because it was a log statement on “DEBUG” level and I would have fixed that way sooner/earlier if it would be a WARNING.

As you might take requests, I have a similar Issue with my Devices. I have a DoorBird that sometimes freezes. I would be able to detect that to power cycle it, as soon as your binding supports power cycling a PoE Port Switch :smiley:

2 Likes

I keep getting these offline messages, what could be wrong?

2019-10-17 14:00:42.379 [hingStatusInfoChangedEvent] - 'unifi:controller:home' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Error communicating with the UniFi controller
2019-10-17 14:00:42.381 [hingStatusInfoChangedEvent] - 'unifi:wirelessClient:home:DuangchaisPhone' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
2019-10-17 14:00:42.387 [hingStatusInfoChangedEvent] - 'unifi:wirelessClient:home:DannyPhone' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
2019-10-17 14:01:12.779 [hingStatusInfoChangedEvent] - 'unifi:controller:home' changed from OFFLINE (COMMUNICATION_ERROR): Error communicating with the UniFi controller to ONLINE
1 Like

We just had a discussion about turning off WIFI at night to safe us from the dooming electro smog. If we would be able to use the switch-profile-override from within the binding, we could realize a “sleeping-mode” that would turn of the PoE-access points .

if the API does not allow that, maybe turning off the wifi bands within the access points itself is an option?

Hi

I just tried to download the jar file from the link you provided, but it isn’t available.

Is it possible to share a new link please?

Many thanks,

Stuart

****** Update ******

My apologies, I think I’ve found a more appropriate link

What version of openHAB are you running? The binding has been part of the distribution for a while now.

Edit: It was added to the distribution in December 2018.

1 Like