HAI OmniLink Bindings HELP

Hi Brian,

Ya, been meaning to implement that the initiation of zones and areas.

Send me over the PR and I will get it in.

thanks,
craig

@craigh -
PR submitted. You see my questions above on the room in Omnilink2 driver? It is unclear to me how to convert that from the 1.x style to the new style.

Brian,

Merge committed. The latest build should be avail at the s3 url, or marketplace.

I donā€™t believe the scene handling has been coded yet for rooms. I have to take a look at rooms again because I donā€™t remember the state of the integration. I will try and take a look later today or tomorrow.

thanks for the pr.

craig

Thanks @craigh,

It looked as if each scene is a separate channel? But, there is no channel for on/off. And each room scene is a separate channel, I am not sure how that would be conveyed into a sitemap where usually a scene is a selection of some sort that you would to send to one channelā€¦

That being said, I am not an expert in sitemaps or openhab2 channels, so maybe its possible as separate channels, but I am not sure how it would look.

Brian,

I did a little more for Rooms in the latest build/commit. handleCommand still needs to be implemented within RoomHandler.

I hope the current state shows you how I think the Rooms can work. Basically there should be a button for each scene which can set to on. Does off in scenes make sense too? I use scenes with my insteon lights, but havenā€™t done much with my omnilink lights/rooms. Also and on/off switch for all the units within the room.

For the scenes within the sitemap, youā€™d want to implement a switch with autoupdate=false so that it operates like a button. However, related to my question in previous paragraph, if you had use for Off command for scene you would omit the autoupdate-false within the sitemap.

hope that helps.

For HAI style scenes does a separate button for each scene work? Because they are exclusive per room. In other words, if you execute scene b in a room, then that room is in ā€˜scene bā€™. For HAI its less of a ā€˜buttonā€™ and more of a ā€˜selectionā€™ type model.
For an HAI style ā€˜Roomā€™, there are really six scenes that exist with the following names:

  1. On
  2. Off
  3. Scene A
  4. Scene B
  5. Scene C
  6. Scene D

When any of these scenes are activated, the omni polls each device in that room to get its state.

When I attempt to mentally model the omni room, its really a single switch that can have 6 different states to select between.

I believe the way it is currently modeled will work. There is an on/off channel for the room, and then a separate channel for each scene that you can set to on.

We could do a switch which has 6 states as you mentioned, but I donā€™t quite think that will work. Question within omni, say you have triggered scene b for a room. At a later time can you ask the room what ā€˜stateā€™ it is in, and it will say B? I donā€™t think so, because someone could have slightly adjusted one of the units within the room. You canā€™t ask the room for status in terms of scenes. The on/off switch just states whether at least 1 unit is not off, or not. Is that how you understand it?

Question within omni, say you have triggered scene b for a room. At a later time can you ask the room what ā€˜stateā€™ it is in, and it will say B?

It will say B still. I just tested this. I was on Scene ā€˜Onā€™, then I turned off openhab (with the v1 driver). Then I set it to scene B, then turned on OpenHab. The omnilnik driver polled the omni and set it in the sitemap to Scene B. Now, you are right, it doesnā€™t properly track the fact that a change has been made ā€˜out of sceneā€™, in other words, if I adjust a light, it still thinks its in Scene B. The keypad on the wall that it is emulating doesnā€™t track this either.

The on/off switch just states whether at least 1 unit is not off, or not. Is that how you understand it?

This is partially true. ā€˜Onā€™ is a scene in the omni. For example my ā€˜Onā€™ scene in my kitchen is the overhead lights at 100%, the island at 90%, and the undercabinet lighting at 100%. The sink, cook hood, kitchen table and breakfast nook lights are off. The ā€˜Offā€™ scene does trigger all lights in the kitchen to turn off (although it doesnā€™t necessarily have to) AND the omni pro does seem to automatically set the scene to off if it does determine all the lights in the room are off.

I uploaded a picture of my kitchen scene switch in case that helps visualize it:

As you can see in this case my ā€˜Onā€™ button is labeled ā€˜Kitchenā€™ on the actual switch.

Brian,

Are you seeing any log messages when you select one of those kitchen scenes on your Omni switch?

@craigh -
Follow up question. Should we be having this sort of discussion here? Or should we do this in the github issues tracker for your fork?
The benefit of using the issue tracker is that its clear when an issue is closed, etc.

The reason I am asking is, there are several other features that are missing that are going to prevent me from moving to 2.0 until they are resolved. I am happy to pitch in and help code them. But I wanted to get them out of my head and put them somewhere.

@craig -
On the 1.x driver:

2017-05-28 13:06:42.550 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - Received Status Notification ObjectStatus (  )
2017-05-28 13:06:42.550 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - updateDeviceStatus 25 class com.digitaldan.jomnilinkII.MessageTypes.statuses.UnitStatus
2017-05-28 13:06:42.551 [DEBUG] [binding.omnilink.internal.model.Unit] - Unit state 3
2017-05-28 13:06:42.551 [DEBUG] [binding.omnilink.internal.model.Unit] - updating string type Scene B
2017-05-28 13:06:42.552 [DEBUG] [binding.omnilink.internal.model.Unit] - Unit state 3
2017-05-28 13:06:42.552 [DEBUG] [binding.omnilink.internal.model.Unit] - updating percent type 100
2017-05-28 13:06:48.029 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - Received Status Notification ObjectStatus (  )
2017-05-28 13:06:48.029 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - updateDeviceStatus 26 class com.digitaldan.jomnilinkII.MessageTypes.statuses.UnitStatus
2017-05-28 13:06:48.030 [DEBUG] [binding.omnilink.internal.model.Unit] - Unit state 1
2017-05-28 13:06:48.030 [DEBUG] [binding.omnilink.internal.model.Unit] - updating percent type 100
2017-05-28 13:06:48.930 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - Received Status Notification ObjectStatus (  )
2017-05-28 13:06:48.930 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - updateDeviceStatus 27 class com.digitaldan.jomnilinkII.MessageTypes.statuses.UnitStatus
2017-05-28 13:06:48.930 [DEBUG] [binding.omnilink.internal.model.Unit] - Unit state 1
2017-05-28 13:06:48.930 [DEBUG] [binding.omnilink.internal.model.Unit] - updating percent type 100
2017-05-28 13:06:49.928 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - Received Status Notification ObjectStatus (  )
2017-05-28 13:06:49.928 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - updateDeviceStatus 28 class com.digitaldan.jomnilinkII.MessageTypes.statuses.UnitStatus
2017-05-28 13:06:49.930 [DEBUG] [binding.omnilink.internal.model.Unit] - Unit state 1
2017-05-28 13:06:49.930 [DEBUG] [binding.omnilink.internal.model.Unit] - updating percent type 100
2017-05-28 13:06:50.898 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - Received Status Notification ObjectStatus (  )
2017-05-28 13:06:50.898 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - updateDeviceStatus 29 class com.digitaldan.jomnilinkII.MessageTypes.statuses.UnitStatus
2017-05-28 13:06:50.900 [DEBUG] [binding.omnilink.internal.model.Unit] - Unit state 1
2017-05-28 13:06:50.900 [DEBUG] [binding.omnilink.internal.model.Unit] - updating percent type 100
2017-05-28 13:06:51.891 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - Received Status Notification ObjectStatus (  )
2017-05-28 13:06:51.891 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - updateDeviceStatus 30 class com.digitaldan.jomnilinkII.MessageTypes.statuses.UnitStatus
2017-05-28 13:06:51.893 [DEBUG] [binding.omnilink.internal.model.Unit] - Unit state 1
2017-05-28 13:06:51.893 [DEBUG] [binding.omnilink.internal.model.Unit] - updating percent type 100
2017-05-28 13:06:53.418 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - Received Status Notification ObjectStatus (  )
2017-05-28 13:06:53.418 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - updateDeviceStatus 31 class com.digitaldan.jomnilinkII.MessageTypes.statuses.UnitStatus
2017-05-28 13:06:53.420 [DEBUG] [binding.omnilink.internal.model.Unit] - Unit state 0
2017-05-28 13:06:53.420 [DEBUG] [binding.omnilink.internal.model.Unit] - updating percent type 0
2017-05-28 13:06:53.859 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - Received Status Notification ObjectStatus (  )
2017-05-28 13:06:53.859 [DEBUG] [ng.omnilink.internal.OmniLinkBinding] - updateDeviceStatus 32 class com.digitaldan.jomnilinkII.MessageTypes.statuses.UnitStatus
2017-05-28 13:06:53.860 [DEBUG] [binding.omnilink.internal.model.Unit] - Unit state 0
2017-05-28 13:06:53.860 [DEBUG] [binding.omnilink.internal.model.Unit] - updating percent type 0

On the 2.x driver:

2017-05-28 13:09:22.354 [DEBUG] [nilink.handler.OmnilinkBridgeHandler] - Other event otification, type: 55
2017-05-28 13:09:22.355 [DEBUG] [nilink.handler.OmnilinkBridgeHandler] - First notification: 1111110100010110
2017-05-28 13:09:24.009 [DEBUG] [nilink.handler.OmnilinkBridgeHandler] - received status update for unit: 25, status: 3
2017-05-28 13:09:24.009 [DEBUG] [binding.omnilink.handler.RoomHandler] - need to handle status updateUnitStatus ( number = 25    status = 3    time = 0     )
2017-05-28 13:09:27.294 [DEBUG] [nilink.handler.OmnilinkBridgeHandler] - received status update for unit: 32, status: 0
2017-05-28 13:09:27.295 [DEBUG] [ding.omnilink.handler.UpbUnitHandler] - need to handle status updateUnitStatus ( number = 32    status = 0    time = 0     )
2017-05-28 13:09:27.295 [DEBUG] [ding.omnilink.handler.UpbUnitHandler] - handle Unit Status Change to: 0
2017-05-28 13:09:29.020 [DEBUG] [nilink.handler.OmnilinkBridgeHandler] - received status update for unit: 26, status: 1
2017-05-28 13:09:29.020 [DEBUG] [ding.omnilink.handler.UpbUnitHandler] - need to handle status updateUnitStatus ( number = 26    status = 1    time = 0     )
2017-05-28 13:09:29.020 [DEBUG] [ding.omnilink.handler.UpbUnitHandler] - handle Unit Status Change to: 100
2017-05-28 13:09:29.237 [WARN ] [rm.AbstractFileTransformationService] - Could not transform '-' with the file 'kitchen.map' : Target value not found in map for '-'
2017-05-28 13:09:29.965 [DEBUG] [nilink.handler.OmnilinkBridgeHandler] - received status update for unit: 27, status: 1
2017-05-28 13:09:29.966 [DEBUG] [ding.omnilink.handler.UpbUnitHandler] - need to handle status updateUnitStatus ( number = 27    status = 1    time = 0     )
2017-05-28 13:09:29.966 [DEBUG] [ding.omnilink.handler.UpbUnitHandler] - handle Unit Status Change to: 100
2017-05-28 13:09:29.971 [WARN ] [rm.AbstractFileTransformationService] - Could not transform '-' with the file 'kitchen.map' : Target value not found in map for '-'
2017-05-28 13:09:30.874 [DEBUG] [nilink.handler.OmnilinkBridgeHandler] - received status update for unit: 28, status: 1
2017-05-28 13:09:30.874 [DEBUG] [ding.omnilink.handler.UpbUnitHandler] - need to handle status updateUnitStatus ( number = 28    status = 1    time = 0     )
2017-05-28 13:09:30.874 [DEBUG] [ding.omnilink.handler.UpbUnitHandler] - handle Unit Status Change to: 100
2017-05-28 13:09:30.982 [WARN ] [rm.AbstractFileTransformationService] - Could not transform '-' with the file 'kitchen.map' : Target value not found in map for '-'
2017-05-28 13:09:31.753 [DEBUG] [nilink.handler.OmnilinkBridgeHandler] - received status update for unit: 29, status: 1
2017-05-28 13:09:31.753 [DEBUG] [ding.omnilink.handler.UpbUnitHandler] - need to handle status updateUnitStatus ( number = 29    status = 1    time = 0     )
2017-05-28 13:09:31.753 [DEBUG] [ding.omnilink.handler.UpbUnitHandler] - handle Unit Status Change to: 100
2017-05-28 13:09:31.905 [WARN ] [rm.AbstractFileTransformationService] - Could not transform '-' with the file 'kitchen.map' : Target value not found in map for '-'
2017-05-28 13:09:32.673 [DEBUG] [nilink.handler.OmnilinkBridgeHandler] - received status update for unit: 30, status: 1
2017-05-28 13:09:32.673 [DEBUG] [ding.omnilink.handler.UpbUnitHandler] - need to handle status updateUnitStatus ( number = 30    status = 1    time = 0     )
2017-05-28 13:09:32.673 [DEBUG] [ding.omnilink.handler.UpbUnitHandler] - handle Unit Status Change to: 100
2017-05-28 13:09:32.719 [WARN ] [rm.AbstractFileTransformationService] - Could not transform '-' with the file 'kitchen.map' : Target value not found in map for '-'
2017-05-28 13:09:33.660 [DEBUG] [nilink.handler.OmnilinkBridgeHandler] - received status update for unit: 31, status: 0
2017-05-28 13:09:33.660 [DEBUG] [ding.omnilink.handler.UpbUnitHandler] - need to handle status updateUnitStatus ( number = 31    status = 0    time = 0     )
2017-05-28 13:09:33.660 [DEBUG] [ding.omnilink.handler.UpbUnitHandler] - handle Unit Status Change to: 0

good idea, maybe switch over to the issue tracker. could you create the ones you know of now, and I can take a more organized look?

I was talking about 2.0 on the scene messages, but if you have both handy that might help too.

Hi @craigh , thanks for carrying the torch for the omnilink binding. So I finally gave up on my Honeywell panel that came with my new house and just ordered a Omnipro LTe panel (I really only need it for security). So I am planning on going back and getting my omnilink library up to date as well as well as helping out where i can.

I have not been following this thread, can you summarize how your effort is coming along with the 2.0 port? Is there anything I can help with?

Hi Dan,

That you are back in the fold sounds like great news for the binding.

Iā€™d say weā€™re getting there with the 2.0 binding. We now have support for units, zones, flags, buttons, rooms and areas. This means discovery, and the appropriate events for them all.

There is not yet support for thermostats, nor audio. Brian created a couple issues over on my GitHub fork for those items, and has stated he can take a look at thermostat support.

There is also some general lifecycle management work I need to get working better. The thing-types file also has to be fixed up to use more standard categories, labels, all that good stuff.

Iā€™ve never got a binding migrated into the main repositories so there will be quite a few deficiencies around copyright, and all that stuff.

The marketplace has proved great for allowing me to do quick iterations and get them out to people.

FYI, I use the shippable website to do automated builds when I make commits, and the jars are getting sent to an S3 bucket of mine for sharing with others.

Maybe if you could poke around a little and offer suggestions of where you think your contribution time would be best spent, I would really welcome your input to get this to a really good state, and hopefully merged into the main repository.

cheers,
Craig

Having a build pipeline is awesome, nice work. I think the best thing to do right now is work off your github repo, Iā€™ll move the technical discussion to issues there so we have one place to track dev conversations. I will probably take a look at the thing xml first. I find that getting this solid first really helps on complex bindings as is sets the stage for how a system is modeled, the code kinda then just follows naturally. Although thatā€™s easier said than done, the omni protocol is complex and not easy to work with.

While I donā€™t have HAI thermos or my russound systems anymore, my old house had 9 thermos and 12 zones of audio, so I have enough old configs where I can probably help there. Do we have any audio users, or is thermos the main need here?

My panel arrives today, so I know what I will be doing this weekend :slight_smile: Once thats up and running I will be eager to get my system talking to it.

Iā€™m pretty sure Brian has audio requirements.

I have russound at my house, but I have also been adding the legacy
protocol (rnet) to the russound binding. My omnilink and russound units
are far apart, and maybe out of ignorance I donā€™t see the benefit of having
the russounds hooked up to the omnilink if I have the 2 bindings avail
within OH.

I have zigbee omnistats and would love to help test. Iā€™m not a developer but have a full understanding of how to manipulate my omnipro and have no issues navigating around the bilges of OH2.

Are locks and security control (down to user codes) out of the question?

Welcome back @digitaldan!

I do plan to tackle thermostats. I had hoped to get to it this weekend, but I instead needed to add then debug a zwave front door lock and write some rules around that.

As for audio. I am on the fence. I have a NuVo system which does not appear to have a driver in Openhab, so I was controlling it through the omnilink driver. However, audio was never really ā€˜cleanā€™ in the v1 driver because it requires one to poll for updates. I have not yet taking a look at what sort of complexity that will add to the overall architecture of the V2 driver.

I canā€™t speak for @craigh or @digitaldan but I donā€™t think either of those are out of the question. I personally donā€™t use them, so harder for me to test.
@craigh - how should we handle this? Should users ask for features here or on github? I prefer github so we can track the request.

I agree GitHub would be better.

@swamiller would you mind creating an issue(s) for the things you are looking for?

Also, @swamiller depending what you mean by security control, I believe it has now been implemented for Areas within the binding.

I am going to release the binding via the marketplace shortly, Iā€™ll keep you posted.