Ubiquiti Unifi Binding Feature Discussion

Hi,

first of all, thanks again for the quick update and the nice work on the unifi binding. I found it being the only reliable presence detection for iPhones, which works for me. :+1:

Since I’m on 2.3.0-SNAPSHOT, the communication to the controller seems to be cut for a short period of time, which is causing the below errors being reported in my logs:

==> /var/log/openhab2/openhab.log <==

2018-04-03 17:18:50.058 [WARN ] [unifi.handler.UniFiControllerHandler] - Error refreshing the UniFi Controller unifi:controller:home - Could not communicate with the UniFi Controller

==> /var/log/openhab2/events.log <==

2018-04-03 17:18:50.075 [hingStatusInfoChangedEvent] - 'unifi:controller:home' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Could not communicate with the UniFi Controller
2018-04-03 17:19:01.497 [hingStatusInfoChangedEvent] - 'unifi:controller:home' changed from OFFLINE (COMMUNICATION_ERROR): Could not communicate with the UniFi Controller to ONLINE

Clients connected to the bridge also go offline and come back online when communication to the controller is established again.

Kurt

mgbowman…
Nice to hear you´re house construction is going forward … Wondering if we´re able to follow the constrution, which I assume will include lots of automation as well? :slight_smile:

Let’s just say the wife wants to kill me :rofl:

Of course there’s a lot of automation. The core of the house will be based on KNX but there are a lot of other technologies in play. Once everything is complete, I’ll share some pictures of my wiring closets.

2 Likes

Yeah, I feel your pain. I just went through that on a major house renovation project. :cry:

That’s why almost everything still can be controlled manually. The only thing I didn’t bother to do was wire the controllers for the zoned audio. The zoned audio can be controlled only through the UI.

I opted against hardwired controls as the audio systems / technologies are bound to change - I found the most important thing was running the speaker wire. I’m implementing a Sonos Connect based system and deploy iPort xPESSS keypads where needed.

Hey guys, just a little update.

First of all, I want to thank all of you who have helped in the testing of this binding.

I just pushed some major changes that I’d like you guys to test. The Gson branch has been merged so no more need to test that specific build.

Please update to the latest build: org.openhab.binding.unifi-2.3.0-SNAPSHOT.jar

Please checkout the updated README and the updated full example

The most notable changes (that will break your configs) are as follows

  1. The client’s online channel has been changed to a Switch
  2. There is no more contactType parameter on the client
  3. The considerHome parameter was moved from the controller to the client

Please test this build and let me know either way how it works out.

Thanks!

mgb

3 Likes

Just updated to this, 2 minutes to search/replace all the changes from contact to switch and all is well!

Works as expected - thank you!

I did notice though that the AP, site etc items went from “xxx” to UNDEF when my phone dropped off the network. Not sure if this was like this before?
Maybe allow a default in the config? Not the end of the world though as it can be mapped.

thanks again

Thanks for the feedback!

I didn’t change anything in regard to state updates so this should be exactly as before.

This version looks good to me.

is this the build #71?

in any case, it works like a charm here :slight_smile: thank you!!!

Yep. If you notice the url has lastStableBuild which always points to the latest on Jenkins :wink:

Glad to hear it!

1 Like

It’s working very nicely and I see no error messages in my logs anymore.

thanks,
Kurt

Hi Matthew,

works great! Thanks :wink: .
what I have noticed is that in the PaperUI the client’s online channel still shows “contact”. also after clear OH cache and reboot.

You have to delete and re add the thing.

Hey guys… back again with (hopefully) one of the last updates before we get this binding merged.

Talking with @martinvw there was some wonky code (that I wrote a very long time ago) that needed to be refactored for the sake of maintainability moving forward (whether by myself or someone else). Therefore I’ve pushed a new build (from a different branch) that I’d like you guys to test before I merge it into the active PR.

openhab2-unifi-binding-v2 : org.openhab.binding.unifi-2.3.0-SNAPSHOT.jar

Not only is the code much cleaner, it’s much more robust in dealing with controller errors (invalid credentials, expired sessions, communication errors, etc…)

Please help us out in testing this before it gets merged - let us know either way how it works out.

Thanks!

mgb

3 Likes

it works perfectly for me :slight_smile:

question: how can I transform the “uptime” in a more readable format?

thanks
Andrea

Here is my rule to do just that.

rule "Format Joe's Phone Uptime"
when
    Item JoesPhoneUptime changed
then	
	var int days = ((JoesPhoneUptime.state as DecimalType).intValue / (86400))
	var int hours = (((JoesPhoneUptime.state as DecimalType).intValue / 3600) - (24 * days))
	var int minutes = (((JoesPhoneUptime.state as DecimalType).intValue / 60) - ((1440 * days) + (60 * hours)))
	var int seconds = (((JoesPhoneUptime.state as DecimalType).intValue) - ((86400 * days) + (3600 * hours) + (60 * minutes)))
	var String result = ""
// days
	if (days > 0) {
		result = result + days + " Day / "
	}
// hours
	if (hours > 0) {
		result = result + hours + " Hours / "
	}
// minutes
	if (minutes > 0) {
		result = result + minutes + " Min / "
	}
// seconds
	if (seconds > 0) {
		result = result + seconds + " Sec "
	}		
	JoesPhoneUptimeFormatted.postUpdate(result)
	logInfo("system.rules", "Uptime updated to " + JoesPhoneUptimeFormatted.state)
end
2 Likes

that’s excellent, thanx!
(edit): It works fine ! (I forgot the [%s] at the String Item description :stuck_out_tongue:)

Glad it works, of course I just modified someone else’s to make it work, it all about sharing to make our home smarter.

1 Like

I updated to 2.3.0 a coupple of days ago. And I have had a hell with my Openhab2 system ever since…

I´m not sure if I did something wrong, but I DL the 2.3.0 snapshot, placed it in my /usr/share/openhab2/addons folder. Renamed the old 2.2.0 to .old
And the problems felt all over me.

  1. OpenHab2 would no load 2.3.0. and kept telling me, it could parse 2.2.0 file, (ofcuse cause I renamed it).
  2. Read somewere to clear the cache and tmp folders. So I did. Made some changes, as I now run the 2.3.0 Unif binding.
  3. If I try to install something (another binding, service etc) the “old” problem returns where Openhab says it can´t run the 2.2.0 binding.
  4. For a few minutes ago, I try to update some files from the openhabian-config console. After that I rebooted the system… And now I get this when i reboots:
2018-05-06 23:16:02.809 [WARN ] [ig.xml.osgi.XmlDocumentBundleTracker] - The XML document '/ESH-INF/binding/binding.xml' in module 'org.openhab.binding.unifi' could not be parsed: The XmlConfigDescriptionProvider must not be null!
java.lang.IllegalArgumentException: The XmlConfigDescriptionProvider must not be null!
	at org.eclipse.smarthome.core.binding.xml.internal.BindingInfoXmlProvider.<init>(BindingInfoXmlProvider.java:60) [117:org.eclipse.smarthome.core.binding.xml:0.10.0.b1]
	at org.eclipse.smarthome.core.binding.xml.internal.XmlBindingInfoProvider.createDocumentProvider(XmlBindingInfoProvider.java:141) [117:org.eclipse.smarthome.core.binding.xml:0.10.0.b1]
	at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.acquireXmlDocumentProvider(XmlDocumentBundleTracker.java:181) [113:org.eclipse.smarthome.config.xml:0.10.0.b1]
	at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.addingObject(XmlDocumentBundleTracker.java:206) [113:org.eclipse.smarthome.config.xml:0.10.0.b1]
	at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.parseDocuments(XmlDocumentBundleTracker.java:350) [113:org.eclipse.smarthome.config.xml:0.10.0.b1]
	at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.processBundle(XmlDocumentBundleTracker.java:336) [113:org.eclipse.smarthome.config.xml:0.10.0.b1]
	at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.access$3(XmlDocumentBundleTracker.java:331) [113:org.eclipse.smarthome.config.xml:0.10.0.b1]
	at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker$2.run(XmlDocumentBundleTracker.java:307) [113:org.eclipse.smarthome.config.xml:0.10.0.b1]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]

And this one:

2018-05-06 23:16:39.391 [ERROR] [org.openhab.binding.unifi           ] - FrameworkEvent ERROR - org.openhab.binding.unifi
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.unifi [239]
  Another singleton bundle selected: osgi.identity; type="osgi.bundle"; version:Version="2.3.0.201804221805"; osgi.identity="org.openhab.binding.unifi"; singleton:="true"
	at org.eclipse.osgi.container.Module.start(Module.java:444) [?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1620) [?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1600) [?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1571) [?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1514) [?:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) [?:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]

Funny thing is… It does work and run using the 2.3.0 shapshot.

Now… what to do??