First of all, thank you for working on this binding! I just installed the binding on a test system and it seems to work well for units. I have tested a couple of different units with dimmers and some on/off and both types seem to work okay.
I currently do use “rooms” to group units. With the OH discovery service it would be a time saver to have the room attribute associated with the unit. I use the Haiku app as my reference application of rooms. I can open a room and select a scene letter that I programmed into the omni. For the record, I use UPB for my lighting control.
Another useful grouping would be for “flags”. I have quite a few flags in my omni that I use for programming, many of which would be useful for rules in OH.
I know this is still in early development, but are you also planning on adding thermostat functionality? If so, one item that is missing from the current legacy binding is “current heating/cooling mode or status”. I know the attribute is available because i have other apps that use it.
Also, any chance of getting user codes added for alarm functions? Omni lock control would be another useful function (with security via user code).
Again, thank you for working on this! Let me know how I can help test.
ok, should be support for reading flags now in the omnilink v2 binding. It may have been there before, but now there is an actual thing type flag.
Currently flags are read-only from the omnilink. I can’t seem to figure out the command to set a flag to a particular value on the omnilink. If anyone knows the params/call to make please let me know.
@craigh, thank you! I’ll get this loaded to my test server and let you know how it goes. Being able to set flags from OH is definitely a new and improved function!
@craigh
Successfully loaded the latest posted version.
Improvements: Unit light dimmers are responsive, seem to operate much more smoothly than before. GUI accurately follows manual actuation of wall switches. Nice improvement!
Some areas of opportunity, I’m having problems linking Things to my omnilink.items file. It seems like the link list is being filtered when I try to manually link items related to flags or buttons. Many non-omnilink items are listed and the omnilink items seem to be filtered.
In my current set up, I have a momentary “button” that I use to trigger my garage door. The OH2 omni binding finds the omnipro’s button but won’t show the associated omilink.items file button listing when I try to set up a link. I tried matching the naming convention in the Paper UI thing listing but that didn’t seem to have an effect. Creating a new Link in the Paper UI creates a switch type item that does work but sends a momentary “on” command with each position, on and off. Is there a way to make this a momentary contact type device?
Also, in OH 1 the binding flags were treated as units with unit numbers with associated on/off switches (just like light switches). I was able to turn flags on and off and trigger programs in my omnipro using a switch type item. New binding only allows a number change. Changing the number from 0 to 1 did not have the same effect on the omnipro program as switching from “on” to “off”. Although some flags need to increment, the omni system only recognized on (>0) or off (0). Is there a way to offer both settings, incremental number and on/off switch?
I have not used the things/items files for the 2.0 bindings thus far. I expect I will migrate to that, but I have been testing the bindings I have been working on so much that I need to test the discovery stuff a lot. Maybe someone else can help you with that.
As for your momentary button…again, I tend to avoid using the UIs as much as possible. Something tells me you might have luck with autoUpdate=false within the guis, but not sure that works with paper ui.
As for your third point…I think I could just create an alternate channel with is a switch instead of a number. Then you could link that channel instead. I’ll get that in soon.
Ok, latest build introduces a new channel for flag called switch. Link this to a switch and I believe you will get the behavior you are looking for. Let me know it works out.
@craigh - Are you building against the latest jominlink library? My PR that fixed the ominilink thread from dying in certain situations got merged in middle of February.
Taking a quick look at the jomnilink code - buttons presses should be reported as notifications.
@craigh - Following up on the above note about buttons. I dove a bit deeper. Those should show up as as other event notifications. The body of that method in the ominlink addon is empty.
You are correct, I do get a notification when the button is pressed.
The type is MESG_TYPE_OTHER_EVENT_NOTIFY. Do you know if only button presses would cause and event with that type? I notice the notification is 2, which I presume is the button number, have to test some more.
A lot of different events will fire that notification. Do you have the OmniLink protocol spec?
Each event notification is identified by a unique 16-bit event number. The encoding of these events is shown below. The encoding is shown in binary, with the most-significant bit to the left.
USER MACRO BUTTON 0000 0000 bbbb bbbb b = button number
At some point, we should probably see what @digitaldan wants to do here… I know he no longer has an Omnipro. I am not sure if he wants to own merging PRs and releasing binaries for a system he doesn’t have?
Hi all, I don’t mind merging PR’s since I plan on being part of the OH community for a long time, I also don’t mind granting others the ability to do merges and help maintain as well. The important thing for me is that the library has a single place where it is maintained as people come and go from the project for as long as its still useful. If you have a PR, please submit it.
Have you had a chance to move the latest jar into your build? I need to add support for synching the omnipro clock from OpenHAB (my OP clock is awful).
I was going to do it on your 2.0 fork, but can’t consume it until it has the latest jomnilink jar.
Yes, added the jar in 9 days ago according to GitHub.
Here is link to my repo (omnilink-binding is the branch to use)
Would you mind sharing how you think you will accomplish that feature? I ask because I actually have pondered feature myself. My idea was to hook in a fresh job which ran every day or x hours, and get the system info, which includes the omni system time. Then you’d be able to write a rule when that item changes, and compare to system time on the openhab. Then you could decide to write the time if it the difference was over a threshold. The thinking being that you don’t need to know the time of the omni all that often, and the value read is only valid for that instant you read it.
Something tells me there is already a method in the omnilinkbridgehandler which can retrieve the system info…it just isn’t called currently, nor hooked up to channels etc. But not sure.
