HAI omnilink binding for Openhab 2.0

Add-ons Bindings
, ,
106

I have had to forego my KwikSet lock functionality with the OH Z-Wave binding but it had always worked well using OmniLink. If I’m understanding this post correctly, I’d like to think I could use this bridge to go back to using my OmniLink Z-Wave connections instead.

If so, using this bridge could I get rid of the OH Z-Wave binding and use the Z-Wave connections I have used successfully in the past inside OmniLink?

Also, I’m behind on MQTT. Is this just a bridge install and no other programming in OH needed?

Thanks.

107

My early testing with the bridge is that you could replace the binding with it. It uses HA MQTT standards and the devices populated correctly on my test setup. I have not done much work beyond that.

108

Thanks for the info. It would be nice to get my locks back in the fold.

I’ll give it a try and let you know how it works out.

1 Like
109

Thanks, I’ll give it a try and see if I can get it working

110

The binding supports units (I use UPB). I would need to double check if we have to code specifically for unit type.

What issue are you seeing?

111

Hi I am running openhab 2.4 and have installed the binding from the marketplace and got it to work.

On my omni console temperature is reported in 0.5 degree C increments. But when I add the temperature sensor to openhab as a thing I only see 1 degree C increments eg 26.5 on the console will be displayed as 26.0 in openhab.

using the following in the in the items file.
Number Inside_Temperature “Inside Temperature [%.1f °C]” <temperature> {channel=“omnilink:temp_sensor:b5e56fa9:2:temperature”}

am I doing something wrong?

*edit I see someone else had the same issue

113

I’m out of town until Saturday so I may get the terms wrong, but I have relays connected to the voltage output units 385-392. These don’t seem to be detected by the binding. I tried adding a manual thing but that didnt seem to work either. You probably know that Z-Wave units don’t seem to work either. This weekend I will either try to install the 1.9 binding or use @mjcumming’s suggestion to use MQTT. We’ll see how adventurous I get. Thanks for any help you may offer. I’m pretty eager to get this up and running.

Thanks,
Jerry

115

Quick question. What are you doing with the outputs and what sort of functionality are you driving? I usually drive my outputs with Buttons.

116

I have the outputs connected to relays which turn on/off landscape lights. It really isn’t anything more than an on off switch. I have one output driven through a button. That’s for my garage door and it just requires a simple contact and release to activate the remote. The only reason I used a button there was to prevent me from tapping on the SnapLink UI for outputs too many times and leaving my garage door in a bad state. The button is more deliberate and has an extra UI confirmation. But using buttons for the other outputs (other than for OpenHab) seems unnecessary. I want to be able to see state (On/Off). The outputs show state in SnapLink and stay on when the lights are on and off when the lights are off, buttons don’t show state. And for a simple switch the button has an extra click that is necessary for the garage door but really annoying when you just want to turn a light on or off. The button doesn’t seem to add anything to the solution if OH were not in the picture. But this is another good idea that I will consider to get everything working in OH. Thank you.

Jerry

117

Thanks everyone – I wound up creating flags in my Lumina for all the Z-Wave and Output Units. Its a ton of extra programming but it keeps the configuration in OH straight forward and easy to troubleshoot. If the Omnilink binding ever supports ZWave or Output Units its easy to revert. Thanks for all the suggestions.

Jerry

118

I am going to work on generic units (zwave)/outputs and also the ability to turn on a unit/output for a specific duration.

1 Like
119

Thanks @broconne! That would be fantastic.

120

Hi

Any feedback to my post above regarding the Temperature displayed?

121

The binding reports the correct values - so something must be happening when convert F to C. A work around would be to create a virtual temperature item and use a rule to set that value when the actual temperature item changes.

122

It shouldn’t be converting F to C. The binding returns the temp in whatever format the panel is set to (C or F).

123

Brian, if the binding is converting the omni temperature format to the C or F based on the panel setting, perhaps its just returning an integer?

124

I assumed that the Binding was dropping the .5 degrees
see snip from Paper UI below. The “Temperature” Channel does not report any decimal points.

Capture

125

The core jOmniLink library returns temperatures as an int. Good thought @mjcumming.

If someone wants to open an issue here I can tackle it at some point.

126

Hi! New to OpenHab and trying to get things working with my Omni system. I was pleasantly surprised to see the great support for audio and locks via Omni but puzzled about the current state of Units? No longer working with version 2?

I’m running a mix of old Lightolier Compose and Z-Wave devices. I couldn’t find release notes but have tried using things support for UPB, ALC, Rooms and PLC to see if I can get things working. I can use UPB to do simple on/off control but can’t find a way to access lighting scenes with Compose. Any tips or hints?

Looking through posts I see others looking to use non-UPB lighting systems and Brian’s recent posts about working on Units support. From a past life, I was familiar with the Omnilink protocol and I’ve read a bit through the jOmnilink code. Lighting was pretty genericized and it seems like working unit that would allow passing an integer for state would control dimming, as well as scene based lighting system via the Omni without need to do much specialized. Is this something that might be coming? (Or could be incented with a bounty?)

Any help or future roadmap infor would be appreciated.

127

Hi - I am still working on generic units support, but it will require some refactoring. I don’t have Lightoiler on the agenda currently. Once we have generic support we can look at how hard it is to add specific lighting subsystems.