Try this link: https://openhab.ci.cloudbees.com/job/openHAB1-Addons/ws/bundles/binding/org.openhab.binding.omnilink/target/
Thanks for the 1.9.0 SNAPSHOT tip. I was getting this error running omnilink-1.8.3 under openhab2. Swapping out the jar file for the 1.9.0 version made the errors go away.
21:55:11.578 [ERROR] [org.openhab.binding.omnilink ] - [org.openhab.binding.omnilink.binding(0)] The deactivate method has thrown an exception
java.lang.IllegalMonitorStateException
at java.lang.Object.notifyAll(Native Method)[:1.8.0_101]
at org.openhab.binding.omnilink.internal.OmniLinkBinding$OmniConnectionThread.setRunning(OmniLinkBinding.java:324)
at org.openhab.binding.omnilink.internal.OmniLinkBinding.deactivate(OmniLinkBinding.java:123)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.8.0_101]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)[:1.8.0_101]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)[:1.8.0_101]
at java.lang.reflect.Method.invoke(Unknown Source)[:1.8.0_101]
at org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:222)
at org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37)
at org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:615)
at org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:499)
at org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:295)
at org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:342)[34:org.apache.felix.scr:2.0.2]
at org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:157)[34:org.apache.felix.scr:2.0.2]
at org.apache.felix.scr.impl.manager.SingleComponentManager.ungetService(SingleComponentManager.java:913)[34:org.apache.felix.scr:2.0.2]
at org.apache.felix.scr.impl.manager.SingleComponentManager.ungetService(SingleComponentManager.java:902)[34:org.apache.felix.scr:2.0.2]
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$2.run(ServiceFactoryUse.java:260)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$2.run(ServiceFactoryUse.java:1)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_101]
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryUngetService(ServiceFactoryUse.java:258)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.ungetService(ServiceFactoryUse.java:160)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.ungetService(ServiceConsumer.java:50)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.ungetService(ServiceRegistrationImpl.java:581)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.ungetService(ServiceRegistry.java:540)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at org.eclipse.osgi.internal.framework.BundleContextImpl.ungetService(BundleContextImpl.java:661)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at org.apache.felix.cm.impl.helper.BaseTracker.ungetRealService(BaseTracker.java:207)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:161)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.provide(ConfigurationManager.java:1444)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1400)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)[7:org.apache.felix.configadmin:1.8.8]
at java.lang.Thread.run(Unknown Source)[:1.8.0_101]
Hi Steve,
Unfortunately I have not been working lately on the 2.0 build. I really like using jython for my rules and that isn’t ready in 2.0. I have reverted back to 1.8 for now.
As for locks, flags, and temperature control unit. I do not have locks for thermostats hooked up to my omnipro, so not sure I would be able to do much work. As for the flags, I will take a look to see if I am using flags, and if i can put something together.
regards,
craig
Thanks @craigh.
Flags alone would be a big help. To your point about your rules engine preferences, I have found that I can build some functions easier from within the omnipro programming environment vs. openhab. Having flags would give me the ability to have openhab monitor flag changes programmed in the omni and have openhab react via a rule.
As for locks, I currently use Haiku as a control app and I can see there are other complications around locks and security, such as the ability to use user codes to lock or unlock doors and arm/disarm the security system. The current OH binding is primarily geared toward controlling units and some very basic security integrations but nothing around knowing who disarmed the alarm or unlocked a door via user code integrations.
Currently (as a test), I can control my zigbee door locks (via the omnipro) with openhab but I had to write a program on my omni that basically turned the lock controls into a switch (unit). The switch shows up as a light switch that I can control the lock/unlock from openhab but it definitely isn’t an ideal solution.
Another use for flags is measuring duration of my climate control system “on time”. I have my Rainforest EAGLE smart meter energy monitor working in OH2 but I’d like to measure my electricity usage against the big ticket items that are running, such as my A/C units and pool pumps. The current binding won’t tell me if my A/C (or heat) is current active, but a flag could be programmed in the omni to provide that on/off information.
Thanks for the response, Craig. Any assistance you can offer is greatly appreciated!
@smk,
I had the same luck with the 1.8.x binding with OH2 and 1.9.0 has been pretty flawless for me.
I’m using most of the current functionality the binding has to offer (units, thermo control, buttons, and basic security) and all seems to work well. As with most of the home automation solutions I’ve experimented with, however, there are still a few more functions that would be helpful in the binding, such as the ability to enter user codes to arm/disarm the alarm, integration of door locks controlled via the omnipro, and the ability to read flag settings triggered within the omnipro.
Overall, though, I’ve been very happy (with much learning) with the abilities built in to OH2. It has definitely expanded my ability to integrate more “stuff” and use a single interface to control all.
I’m just getting started with OH + Omni but I’m battling an annoying problem present under OH and OH2: My outside temp won’t update posted here. Do you have an outside temp sensor, and if so, is it updating? @digitaldan said his worked just fine. I’m going back trying to run Dan’s jOmnilinkII example code to see if I can figure out where the source of the problem is.
Sam,
I do have a couple of aux sensors that I hadn’t set up until now, and mine don’t seem to be updating either.
I would have expected to see a log entry pop up for the aux sensors periodically like the thermostat’s but no log entries for the aux sensors except on start up.
Thanks for confirming. At least now I know where not to look. I tried running Dan’s example ‘main’ in his jomnilink.jar. It runs, but then dies like this at the end. I guess I’ll get ant setup and try to learn some Java 
.
eadBytesEncrypted2: Omni message Length 1
readBytesEncrypted2: Additional bytes to read 0
RX: 0x21 0x01 0x02 0x80 0x51 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
readBytesEncrypted2: Data still available after read 0
readBytesEncrypted2: Bytes available for reading: 0
com.digitaldan.jomnilinkII.OmniInvalidResponseException
at com.digitaldan.jomnilinkII.Connection.reqObjectStatus(Unknown Source)
at com.digitaldan.jomnilinkII.Connection.reqObjectStatus(Unknown Source)
at com.digitaldan.jomnilinkII.examples.Main.main(Unknown Source)
Message:2
Dan,
I was taking a look at getting notifications for flags within the omnilink. Do you recall if this is supported within your jomnilink project? I looked at the Message class, specific the OBJ_TYPE constants and didn’t see anything.
thanks,
craig
never mind Dan. After a little more investigating, I think the flags are showing up as Units.
sorry for the bother.
Steve,
I think there is support for flags already.
Within my items file, I have this: (my flag within omnilink is ‘DisarmedLite’. Within PC Access, it shows under the flags section, with ID 394.
Dimmer Lights_DisarmedLite_Switch “DisarmedLite [%d%%]” (Lights) {omnilink=“unit:394”}
This would have been created automatically by Dan’s script to generate the items file, found within the cfg file.
So I believe that flags can be watched and set within openhab by setting up a Dimmer.
Give it a shot and let me know.
craig
Well, look at that…it worked. It’s always the easy stuff that gets me! Might be a good mention in the wiki since flags are a meat and potatoes programming tool for the omni board. Thank you @craigh!
My only other questions are around heating/cooling current run status (Cooling/Heating, Idle, or Off) but I can do that easily with flags, if needed.
Any ideas on if there might be a way to pass an alarm code to the panel or a way to retrieve user codes used to arm/disarm (events) from the omni?
And final question; what would be needed to get the 1.9.X binding added to the 2.0 compatible bindings list? I’ve been using 1.9.0 for some time now and it’s been very reliable. My only issues have been around expanding functionality.
Steve,
How did you figure out the unit #? Did you use the auto-generate feature?
I ask because I am trying to think of how to explain in the wiki for the next person.
I used PC Access. My flags didn’t auto generate back when I first set up OH. Units tied to lighting, zones, buttons, basic security, and thermostats auto generated but nothing else.
Another item that didn’t auto generate for me was AUX temp sensors, although they are covered in the current wiki.
Hello. Im trying to figure out how t install this binding rather then just copy my old v1 jar. Is this in a distribution yet?
There is a OH2 version in the Marketplace but it isn’t as functional (yet) as the v1 binding. For the record, I’ve been using version 1.9.0 for some time in OH2 and it’s been reliable. A new binding is in work, though, if you want to wait.
I just built a new Openhabian install and the easy stuff is in place. I did add the marketplace and install the new Omni Binding. What are my next steps. My Omni Config is in place but has not built a site map yet. Is that possible like it was in OH1?
Thanks
Oakguy
New question. Do you define your rooms so that the Apple Homekit add-on can see them? Also how would you define rooms and omnilink buttons for the Homekit?
Thanks
Guy
@craigh what should the location setting under configure omnilink controller in OH2 be? is it a place, or a number, or leave it blank?
can’t figure this partciular setting out.
thanks
You can leave that blank. That is a setting inherited from Openhab. I don’t use it myself.