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 
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
Didnāt even know about UoM 
After reading that page, I donāt think itāll convert how youāre thinkingā¦
Letās say uptime = 3661 (1 hour + 1 minute + 1 second), I think youād get the following:
Number:Time uptimeSeconds "Uptime [%d s]" => 3661 (1 hour + 1 minute + 1 second)
Number:Time uptimeMinutes "Uptime [%d min]" => 61 (1 hour + 1 minute)
Number:Time uptimeHours "Uptime [%d h]" => 1
Number:Time uptimeDays "Uptime [%d d]" => 0
Number:Time uptimeWeeks "Uptime [%d week]" => 0
Meaning the conversions wouldnāt be dependent on one anotherā¦ āonly show 1 second because itās the remainder of 1 = 3661 - 3600 (1 hour) - 60 (1 minute)ā
I think itās a lot easier to trigger a rule based on āsecondsā changing to 301 or something like that vs. a string that says ā5m 1sā like itās shown in the controller UI. Your format string is simply a visual representation of the raw value seconds.
I am in the process of adding UoM support to my (sensebox), and I have to say, it is pretty easy 
Just look at all the PRs implementing UoM, in most cases it is two lines in the META-INF file and a bit of tweaking in the channels definitions.
I also would argue in favor of keeping the uptime channel as a raw number. Channels can be created for the other representations.
IMHO, if the 2.4 release is just a couple weeks away, wouldnāt it make sense to keep changes to a minimum and focus on getting the binding into the build.
Honestly I had no idea when 2.4 was scheduledā¦
I will do my best to get it ready, but I wouldnāt hold my breath the PR will get approved before 2.4
UoM was fairly easy to implement but the conversions are wrong:
8 h = 60 x 60 x 8 = 28800
28013 < 28800
Yet the internal UoM conversion is showing 8 hoursā¦
I think itās because of the decimal conversion format [%d h]. I would think it would round downā¦ with time conversions, but it seems to be doing bankers rounding.
Using [%.1f h] gives the partial valuesā¦
Anyways, Iāll look at rebasing asap and re-igniting the PR.
Correct!
@mgbowman I would forget about my requestā¦ itās superficial anyway since we can do the same with the rule!
ETA: 17/Dec/18 openHAB Milestone builds - #140 by Kai
Itās very short timeā¦
48 hours later: all is good
OH 2.4.0.S1451
Unifi Controller v5.6.40 (not the latest due to EoL of AP-AC Outdoor)
org.openhab.binding.unifi 2.3.0.201812040910
So I made a lot of progress on the PR but some critical parts of the binding changed so PLEASE PLEASE PLEASE update and test the latest build out ASAP so we can try and get this merged!
org.openhab.binding.unifi-2.4.0-SNAPSHOT.jar
YOU HAVE TO UPDATE YOUR CONFIGS AGAIN (sorry)
In preparation for wired client support, the thing ID has changed to wirelessClient (instead of client)
See the Full Example of the README
GO GO GO ā¦ TEST TEST TEST
Just updated my two sites. Looks good so far.
OH 2.4.0 S1451
Unifi Controller v5.6.40
org.openhab.binding.unifi 2.4.0.201812061741
Had to clear tmp&cache and all look good now
Without clearing tmp&cache you get:
2018-12-06 21:18:12.692 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.unifi-2.4.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.unifi [254]
Another singleton bundle selected: osgi.identity; type="osgi.bundle"; version:Version="2.3.0.201812040910"; osgi.identity="org.openhab.binding.unifi"; singleton:="true"
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]
2018-12-06 21:18:12.703 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.unifi-2.4.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.unifi [254]
Another singleton bundle selected: osgi.identity; type="osgi.bundle"; version:Version="2.3.0.201812040910"; osgi.identity="org.openhab.binding.unifi"; singleton:="true"
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]
Hmm. I didnāt see this. Maybe because I removed the 2.3 version of the binding from addons before adding the 2.4 version?
I did the same:
stop OH2
remove old 2.3 *.jar from addons, wget new 2.4 *.jar
start OH2
maybe there were some leftovers in tmp&cacheā¦ I didnāt really checkā¦ I just went ahead and wiped them both
Ok. I didnāt stop/start OH. Just deleted 2.3 binding, then added 2.4.