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.
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
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
Matthew
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:
- MAC address (preferred)
- IP address
- Hostname
- 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:
- MAC address :
String
- 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
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)
edit: Ps: You have a PR pending 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
Is it too much to ask you to do these calculations within the binding with regards to the uptime channel?
(so I can get rid of the rule and the secondary String item… yeah I know I am lazy )
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 ?
Same principal…
uptimeString
or something similar
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
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
I haven’t used the Time unit yet
Should be possible