I upgraded my system today from 2.5.0 to 2.5.9 and had three issues, two of which I have fixed: email TLS change to STARTTLS and added my command scripts to the new misc/whitelist. However, I have lost the DSC alarm system binding. The binding had been working for about a year and I can still ping the device and I have power cycled both the device interface and the openhab host.
Is there another new “binding whitelist” that I need to create? Or, is there a recommend method (or log) for watching the binding process? I don’t see errors in events.log or in openhab.log. I end up with all null values for the alarm parameters.
Did I maybe post this in the wrong category? Or maybe left out some of the important problem details? Or maybe the description was vague? I would really like to get my alarm system back on line!
Other DSC users on 2.5.9 now?? This is the EyezOn Envisalink card. It had been working nicely for approximately a year.
I need so pointers where to beginning looking into the broken binding. Openhab and the alarm interface are on different subnets (same setup as when it worked in 2.5.0, not sure if red hearing!), but pings to the card still work. No network/firewall updates. I updated openhab and lost the binding.
I don’t know anything about the DSC binding in particular, but are you sure the binding has loaded? When you look at the things in the GUI, what are their statuses?
Under Configuration -> Things the Panel and Partition-1 show up as uninitialized. There are a number of other components that also show up as uninitialized, but the thing list seems to be just a subset of all the alarm components that exist.
Is there a spot where I should be listing the bindings that should be loaded? I’m -thinking- that sense this used to work, that the load is being attempted and failing.?.? Is there a log that captures the loading process?
Some bindings announce start up actions in openhab.log
You could look in your old logs to find out.
If you set debug logging for the binding,it will surely say something if it is being started.
You should check in the GUI to see what the staus of your bridge thing is (which looks like envisalink from the config file above). If that is unitialized, you should check to see if the binding is loaded.
Go in to the openhab console and issue the command bundle:list | grep -i dsc .
It should return something like this (this example uses the Lutron binding):
openhab> bundle:list | grep -i lutron
231 x Active x 80 x 2.5.8.202008152308 x openHAB Add-ons :: Bundles :: Lutron Binding
If the binding has loaded properly, you should get back 1 line, and the status (in the second column) should be “Active”.
I’ve just upgraded from 2.5.6 to 2.5.9 to test this. The DSC binding is working for me.
The easiest way to start checking the logs for a specific binding is to turn on debug logging. To do so:
Go into karaf console for openhab
Run the following: log:set debug org.openhab.binding.dscalarm
Once debug logging is on, you can see any connection errors which might come up
While you’re in karaf console, you can also check the status of the binding as noted above and even restart the binding with the following command bundle:restart [binding ID].
Binding ID is the 1st column when you run bundle:list command.
The binding was in the “waiting” state and I also put dscalarm into debug output. Restarts didn’t help and they didn’t generate much output. I have had the openhab.log open and reviewing the messages since Friday, but somehow I had missed this:
Blockquote
[ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing ‘openhab-ui-restdocs, openhab-binding-exec, openhab-binding-dscalarm, openhab-persistence-rrd4j, openhab-ui-basic, openhab-binding-mail, openhab-binding-ntp, openhab-binding-astro, openhab-transformation-exec, openhab-transformation-regex, openhab-ui-habpanel, openhab-ui-paper’: Unable to acquire the state change lock for the module: osgi.identity; type=“osgi.bundle”; version:Version=“2.5.0”; osgi.identity=“org.openhab.core.boot” [id=137] STOPPED [STARTED]
Blockquote
There was a single occurrence of this message immediately following the upgrade and it was never repeated again after any of the reboots.
I cleared this with:
$ sudo openhab-cli stop
$ sudo openhab-cli clean-cache
(which failed)
$ sudo /bin/systemctl stop openhab2.service
$ sudo openhab-cli clean-cache
$ sudo reboot
$ openhab-cli console
Failed with: Logging in as openhab. Failed to get the session.
$ sudo openhab-cli reset-ownership
$ openhab-cli console
openhab> bundle:list | grep -i dsc
Blockquote
224 x Active x 80 x 2.5.9 x openHAB Add-ons :: Bundles :: DSCAlarm Binding
Blockquote
The GUI is populating and the correct email messages are arriving.
Well, … it’s very consistent or maybe I have something consistently setup wrong, but I needed the same procedure I posted above (my October 12 post) after upgrading from 2.5.10 to 2.5.11. Same symptoms and same solution. I will give v3 a few weeks to settle and then join everyone there.
