@Bert Hmm. That’s interesting that you also see it with the weatherunderground binding. Did you try to stop/start the binding? Did you get the same result as I did?
@lolodomo See my post above. Have you ever seen this occur in the weatherunderground binding?
What’s really odd is that the Unifi controller handler’s
dispose method is being called when OH is starting up. So, the binding must be initializing, then disposing, (then maybe initializing again?).
But the scheduled refresh job is not being canceled when the handler is disposed. Then, when the refresh job runs, it tries to update the controller Thing’s status, which generates the warning that it’s trying to update the status after the handler has been disposed.
I wonder if there’s a race condition in the scenario where the handler is rapidly initialized, disposed, and initialized.
I’ll do my best to look into this and see if there’s anything I can do - unfortunately I’m still super busy with my own house so I can’t make any promises of when I’ll get around to this.
Will keep you posted.
Thanks. I know you’re busy with your remodel. Hopefully, it’s going well.
In the meantime, I think I’ll put the binding into debug mode and log to it’s own file. That way if the problem happens again I’ll have better forensics about what happened.
I also should migrate to the latest version of the binding. I’ve been delinquent in switching because I’ve been too lazy to make the switch from Switch to Contact…
Yes, uninstalled the binding, restarted openhab, installed the binding again.
At first I saw the right values in the basic UI, but 5 minutes later nothing there??
@mgbowman A couple things I wanted to mention for when you get a minute to look at this.
I originally thought I might be on an older version of the binding. But after looking at my environment, I think I’m running a pretty current version. Since the version I’m running uses Switch instead of Contact, it must’ve been built against a pretty current source tree.
ControllerHandler, I see that
scheduleRefreshJob are called in
initialize, and that
cancelRefreshJob is called in
dispose. If in fact the framework is rapidly calling
initialize-dispose-initialize (just a theory on my part), is there a potential to lose the reference to refreshJob? This possibly might explain why a refresh job continues to run even after the binding is stopped.
The problem doesn’t always occur at startup, which would argue in favor of a timing and/or race condition.
I’ve enabled debug logging with the logs going to a dedicated log file. Hopefully at some point, if this happens again, I’ll have more info on what’s actually happening.
Hope this helps.
I just installed this binding after I finally got my Unifi controller up and running. I must say it works very well so far. I think it will be much better presence detection than the network binding.
Is it possibly to get the status of my AP on OH2, i tried to link the online status of the ap but it seems not to work.
Is there a way of pulling the alerts off the unifi controller using this binding?
@Peter_van_hanegem,@psyciknz - unfortunately the answer to both of your questions is no
I’m still busy with my house, but I promise after it’s all done, I’m going to give this binding some polishing using all your suggestions as possible improvements.
There are PoE improvements that I have to implement for my own personal WAF.
I promise I haven’t disappeared and I have every intention on picking back up where I left off when I can.
I did look at dipping my toes into the homekit binding, but that might be above me…but this one inmight be able to sink my teeth into…
Thanks for answering, its not really a big thing, if it works cool, if it does not, also cool.
The strangest thing is, i had a crash 2 weeks ago and had to install all again, before i could add an AP as an item and it openhab could read the status.
Well, let us now if you have figured something out to make it work. Good luck on the house
@mgbowman How are things going with your house?
It’s going… should be moved in by November. The “finishings” stage is by far the most stressful.
As for the automation, I’ve finished 1 panel and have 2 more to go.
Some stats on the first panel / floor (each electrical circuit is wired directly to the panel - speakers, network, alarm and echo dots are wired to a central room in the basement):
20 Lights ON / OFF
4 Lights 0-100% Dimmable
20 Outlets ON / OFF
4 Outlets ON / OFF with current monitoring
8 Exterior Shutters
8 Sets of RGBW LED Strips / Spots
11 Exterior Door / Window Sensors (every sensor is its own alarm zone)
8 Interior Door Sensors
8 Interior Motion Sensors (every sensor is its own alarm zone)
3 Temp / Humidity Sensors (bathrooms to automate the ventilation)
8 Underfloor Heating Zones
4 AC Zones
8 Thermostats (supports Heating + Cooling in rooms with both)
5 In-Ceiling Audio Zones (probably will be Sonos)
4 In-Ceiling PoE powered Echo Dots (which are fed into the In-Ceiling speakers using a ducking mixer - I don’t use the built-in speaker)
Wife says I went overboard… I disagree
I have 2 more panels to wire, but they’re not nearly as complicated at this one was (I started with the hardest one first).
First @mgbowman, thank you very much for your effort in doing the binding.
Your binding was actually the main reason for me to setup a standalone unify controller
Using the PI3 for the unify controller
For those who don’t want to buy a unify cloud key and rather install the unify controller to a raspberry pi, I recommend going for a PI3 (don’t try Pi2 or below - it will fail due to missing 64 Bit and believe me, I tried for hours…) and follow this explanation: https://dougrathbone.com/blog/2018/03/31/configuring-a-ubiquiti-unifi-controller-to-run-on-raspberry-pi
It worked exactly as described!
Binding Updates in rules
now @mgbowman, I have a question regarding updates sent by the binding:
When I am writing a rule as follow
rule "Phone updates"
Item StefansPhone received update
I get updates every other 10 seconds
2018-09-14 08:10:56.789 [INFO ] [smarthome.model.script.Phone updates] - Stefan's Phone OFF
2018-09-14 08:11:07.141 [INFO ] [smarthome.model.script.Phone updates] - Stefan's Phone OFF
2018-09-14 08:11:17.623 [INFO ] [smarthome.model.script.Phone updates] - Stefan's Phone OFF
2018-09-14 08:11:27.948 [INFO ] [smarthome.model.script.Phone updates] - Stefan's Phone OFF
2018-09-14 08:11:38.360 [INFO ] [smarthome.model.script.Phone updates] - Stefan's Phone OFF
Is there a way to suppress the updates only if the state has actually changed ? Or do you recommend to cater for that in the rule by statically remembering the last state and compare to it to the current and check if there was actually a transition between ON and OFF?
You can define filters on your rule triggers
rule "Phone updates"
Item StefansPhone changed from ON to OFF
See more details from https://www.openhab.org/docs/configuration/rules-dsl.html#event-based-triggers
Thanks @pauli_anttila for reminding me. Stupid me… Sure I have seen this before!
Glad there are people who find it useful! Makes the effort that went into it mean that much more
This is due to the fact that a “properly” implemented binding does not keep any sort of “state” of Items nor should it keep an internal “cache” of sorts. Bindings should only act as a communication channel between OH2 and the external system.
In the case of this binding, it simply reports the state as viewed by the controller.
Makes sense to me.
Thanks for clarifying this, Matthew.
I’d be lost without it! Thanks!