Ubiquiti Unifi Binding Feature Discussion

and how do the devices (e.g. Access Points) in these remote sites communicate with the Unifi Controller? (or they don’t?)

They perform a kind of call home via an “inform” command to an open port on the controller. But this is nothing any binding on the OH2 platform can use to reach these remote networks.

1 Like

Ok, got it… so they are on a remote Private LAN and they initiate the connection to the Unifi Controller using notify over WAN (Internet) to its public IP.

No open ports in the remote internet gateway to allow incoming connections and no VPN to allow IP routing to the internal LAN hosts.

Do these remote devices show up as “Wired” on the Unifi Controller?

Correct.

They show up on the controller, dont know about “wired”. I guess they will.

nah, my bad… the wired/wireless story applies only to the Clients, not to the Devices. These are Devices :slight_smile:

Sorry I’ve been quiet for a while, I had a SSD issue with my laptop that I’ve finally resolved. I’ve gotten my OH2 dev environment back up and running and I’m going to pick back up on getting this binding merged.

Over the next few nights, I plan on implementing the identifier property discussed previously as well as look at how hard it would be to add basic online support for wired clients (I think it will be fairly simple).

After that, I want to rebase the current code on top of master and do whatever is necessary to get things merged before the 2.4 release.

Will report back when I have another version to test :wink:

Matthew

3 Likes

:clap::clap::clap:

:clap::clap::clap:

i’m seeing a lot of this:

2018-12-03 15:15:11.326 [hingStatusInfoChangedEvent] - 'unifi:controller:home' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Error communicating with the UniFi controller

2018-12-03 15:15:31.382 [hingStatusInfoChangedEvent] - 'unifi:controller:home' changed from OFFLINE (COMMUNICATION_ERROR): Error communicating with the UniFi controller to ONLINE


2018-12-03 15:16:31.475 [WARN ] [.handler.UniFiControllerThingHandler] - Unhandled exception while refreshing the UniFi Controller unifi:controller:home - Unknown HTTP status code 500 returned by the controller

==> /var/packages/openHAB/target/userdata/logs/events.log <==
2018-12-03 15:16:31.476 [hingStatusInfoChangedEvent] - 'unifi:controller:home' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Unknown HTTP status code 500 returned by the controller


2018-12-03 15:16:51.542 [hingStatusInfoChangedEvent] - 'unifi:controller:home' changed from OFFLINE (COMMUNICATION_ERROR): Unknown HTTP status code 500 returned by the controller to ONLINE



it stays online for a while then goes away, then reconnects

any direction on sorting this out?

this was happening on the april and november release. debug logging shows nothing interesting. just device status updated. nothing related to this error

Hi Gents!

So I managed to find a little bit of free time to work on this and I’ve managed to implement the new universal client identifier cid.

org.openhab.binding.unifi-2.3.0-SNAPSHOT.jar

READ BEFORE UPDATING

If you defined your clients using…

  • a .things file
    • you must update your configs
  • the Paper UI
    • you must delete and re-create your things

Sorry, but you will have to do one or the other!

CONFIGURATION CHANGES

Now your client should be configured using a cid parameter:

Bridge unifi:controller:home "UniFi Controller" [ host="unifi", port=8443, username="$username", password="$password", refresh=10 ] {
	Thing client matthewsPhone "Matthew's iPhone" [ cid="$cid", site="default", considerHome=180 ]
}

Where $cid can be any of the following:

  1. MAC address (preferred)
  2. IP address
  3. Hostname
  4. Alias

I feel this will cover almost every use / edge case when it comes to “identifying” a client from the controller and you’re at your leisure to use whichever you prefer.

See the updated configuration section of the README for more info

NEW CHANNELS

In making progress towards supporting wired clients, I added two new channels:

  1. MAC address : String
  2. IP address : String

Hopefully somebody finds these useful.

See the updated channels section of the README for more info

ROADMAP

I will work on adding support for wired clients before I do a rebase and push to get this merged into 2.4

In the meantime, please update your bindings and configs and give this build a spin. Please report back even if you’re not having any problems - at least I’ll know everything is working.

Cheers!

Matthew

2 Likes

All is good!

OH 2.4.0.S1448
Unifi Controller v5.6.40 (not the latest due to EoL of AP-AC Outdoor)
org.openhab.binding.unifi 2.3.0.201812040910
(by the way: you should renumber it to 2.4.0.datetimestamp) :slight_smile:

edit: Ps: You have a PR pending :stuck_out_tongue: Update README.md by AngelosF · Pull Request #1 · mgbowman/openhab-addons · GitHub
Now it’s outdated and I will close it, but you should add the NULL option in the map file

That’ll happen as soon as I do a rebase… I’m still developing on an ooooooold openhab2-addons clone :upside_down_face:

1 Like

Is it too much to ask you to do these calculations within the binding with regards to the uptime channel? :stuck_out_tongue:

(so I can get rid of the rule and the secondary String item… yeah I know I am lazy :blush:)

Would you like to see a channel for each?

  • uptimeSeconds : Number
  • uptimeMinutes : Number
  • uptimeHours : Number
  • uptimeDays : Number

If so, question…

What is the value of uptimeSeconds when uptime = 61?

Logic would say this…

uptime = 61
uptimeSeconds = 1
uptimeMinutes = 1

What about a fast & dirty String Channel Type where you just dump a pre-formatted text ? :slight_smile:

Same principal…

uptimeString or something similar :smiley:

I would say: 1m 1s

(similar method like the rule does it)

What should the channel be?

If you are going to keep the existing unifi:client:home:matthewsPhone:uptime Channel as a Number (and maybe add UoM support and switch it to: Number:Time :stuck_out_tongue: and Number:Dimensionless for the rssi)
I would say:

unifi:client:home:matthewsPhone:uptimeDuration as a String Type

but… why keep the Number one? better change the existing Channel type to String and keep the same UID: unifi:client:home:matthewsPhone:uptime

edit: I don’t know if using UoM and keeping using Number:Time will be useful to format in the Item label the seconds into other formats… I am not using UoM so much to say if this is possible.

@vzorglub : Do you know if I have a Number:Time Channel Type with values in seconds and an Item linked to it: Can I use formatting in the label to display hh:mm:ss ?

The state of the Item would be: 23454 (seconds) and I would like to display this in another way… is this possible with UoM? (or the Channel needs to be a DateTime type?)

Relevant for UoM: KNX Binding, Sitemap: Number Item is not send to bus

2 Likes

I haven’t used the Time unit yet
Should be possible

1 Like