@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.
Strange.
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.
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.
In ControllerHandler, I see that cancelRefreshJob and 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.
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.
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.
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
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).
now @mgbowman, I have a question regarding updates sent by the binding:
When I am writing a rule as follow
rule "Phone updates"
when
Item StefansPhone received update
then
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?
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.