Konnected - Beta Add support for Alarm Panel Pro

So i have a new beta version of the binding that i have been working on. I will make sure that this makes its way into openhab 3.0. But for those running 2.5.9. Here is a version to test out. If you have an alarm panel pro i would greatly appreciate it.

Note this is only needed for those that have an alarm panel pro. There is no need to update from the binding that comes with 2.5.9 if you do not have an alarm panel pro.

Here is a link to the file

Konnected Beta - Alarm Panel Pro - 2.5.x

Konnected Beta - Alarm Panel Pro - 3.0.x

Word of caution this will require you to delete and recreate things with the new binding.

This seems to be able to connect to the alarm panel pro, but there are a few things that I think should be worked out-

  • If a zone is configured as a a contact, it shouldn’t be called a “switch.” OpenHab has an item type that is specifically designed for this purpose. The type should be “Contact.”
  • This binding should support text based configuration, even in the beta stage. I’m not sure how you’re testing this binding, but it’s pretty labor intensive to have to configure everything through PaperUI every time there’s a binding change. Right now, it seems like items can be configured via text based configuration files, but the thing and the channels can’t. So, 12 zones is a lot of channels to configure over and over. This is largely why text based configuration exists.

Ok so a few things.

As for the semantics of the naming of the switch channel vs the actuator channel. It has been awhile since i did the initial binding development but this particular discussion came up with the openHAB team during the initial submission. And i think i did actually have it set as a contact at first and then, and there was a decision made that the item type should be a switch and not a contact. I would have to go back and look at the discussions in the pull request to recall why that decision was made. But i think it has something to do with even though it is a read only channel with how the contact item is handled differently from the switch item.

The binding does support text based configurations. While i haven’t updated them for the modifications made with the pro. The only relevant change which was made was the change made the the thing type name. In the prior binding they were all called module. Now they are wifi-module and pro-module respectively. If you make the relevant change in the sample things file referenced in the binding readme below the things file should work.

So the thing should be Thing konnected:pro-module:generic …

Regarding the contact type-
If it’s a switch, I can click it in a sitemap and it stays changed until the next update. In other words, the state of a zone can be manipulated by something other than the zone. While I understand this isn’t a “real” security system, we should at least try to get close. I don’t know what the openHAB team was up to, but it seems like this recommendation is out of left field-

Those types clearly list the contact type. It was purpose built exactly for this application. It even says, “e.g. door/window contacts.”

Regarding the text based Thing-

Do you mean that the Thing definition should contain the literal word “generic?” When the thing is autodiscovered, it uses the module ID instead of “generic.”

For what it’s worth, it throws more errors if I use the word “generic” instead of the actual 0xMODULEID.

However, I’m not able to get it to accept text based thing configurtion here’s what I get:

2020-11-11 14:14:31.889 [hingStatusInfoChangedEvent] - 'konnected:pro-module:0xxxxxxxxx' changed from UNINITIALIZED (HANDLER_INITIALIZING_ERROR) to UNINITIALIZED (HANDLER_MISSING_ERROR)

2020-11-11 14:14:31.906 [hingStatusInfoChangedEvent] - 'konnected:pro-module:0xxxxxxxxx' changed from UNINITIALIZED (HANDLER_INITIALIZING_ERROR) to INITIALIZING

2020-11-11 14:14:31.935 [hingStatusInfoChangedEvent] - 'konnected:pro-module:0xxxxxxx' changed from INITIALIZING to UNKNOWN

2020-11-11 14:14:31.970 [hingStatusInfoChangedEvent] - 'konnected:pro-module:0xxxxxxxxx' changed from UNKNOWN to UNINITIALIZED (HANDLER_INITIALIZING_ERROR)

2020-11-11 14:14:31.972 [me.event.ThingUpdatedEvent] - Thing 'konnected:pro-module:0xxxxxxx' has been updated.

No generic is a filler example that should be replaced with the moduleID

I found the chat from the original binding development… It had to do with treating it as a pure binary of either on or off. It is still a read only channel as opposed to the actuator channel which handles commands.

I think you were correct in your original assessment. I think you got some bad advice back then.

A Contact, or Switch for that matter, is Open/Closed, 1/0, On/Off. It all means the same thing. The Open/Closed doesn’t refer to a door or window being physically open or closed. Open/Closed refers to the circuit being open or closed. In other words, “open” means that the circuit is open, or doesn’t pass current. Closed means that the circuit is closed, or passes current. Open/Closed is pure binary information and doesn’t carry any other connotation.

I agree that the binary sensors should be “Contact” type, and not a switch. This is consistent with our implementations on other platforms and IMO is exactly what the Contact type is for.

I had some time to work through this some more. I got all my zones connected and I can confirm they all trigger.

However, text based configuration does not work for THING configuration. Text based ITEM configuration works fine.

Lastly, the konnected pro module supports 24 channels total. 12 onboard and 12 via two 6 zone interface modules. When you’re doing configuration, I only see 12 channels listed.

@Rich_Mayfield i will look into the interface modules. Do you have them to test?

Also as for the thing configuration with text files. Can you make sure debug loggings is turned on and then upload the debug logs.

Also include your thing files here.

The interface modules do not add 12 additional zones. The Pro supports 12 zones only. They can either be sensors directly wired to the Pro board terminals, or wired-in parallel to zones on a traditional panel via the Interface module. Not both simultaneously.

Thanks for your work on the APPro.

I need concise instructions on how to add your new bindings to my OH project. I have wandered around the OH web site, tried a few of the methods described but have not had any luck.

Downloaded and pasted org.openhab.binding.konnected-2.5.11-SNAPSHOT.jar into my c:\openHab2\addons directory. Uninstalled 2.5.9 with Paper UI. Stopped and restarted runtime.

The inbox shows ‘Konnected Pro’. I click on it and select ‘add as thing’ and get an error "Error:409-conflict’.

I have OH installed on a W10 NUC at c:\openHab2\ .

Your guidance is appreciated.

@estuber can you turn debug logging on and upload your log file.


Zachary, I would also suggest making org.openhab.binding.konnected-2.5.11-SNAPSHOT.jar file available via direct link. There is no easy way to wget it from the location you currently have it.

I have removed 2.5.9 and copied 2.5.11 to my addons location. PaperUI can autodetect my Konnected Alarm Panel pro but when I add it as a thing it comes up as uninitialized. I also cannot delete the thing without forcing it. Any recommendations?

I would like clear and concise instruction on how to install 2.5.11. I am not using an IDE. I am new to OH and statements like “remove 2.5.9” do not have much meaning unless I know what exactly to remove. I presume some thing gets deleted but it is not clear what. I would appreciate some help with this , thanks. Ed

Can you turn on debug logging and upload the log files. Are you saying that the binding autodetects the things? But then when it was added it was unintilized?

@estuber if you have installed the binding previously via the paperui you need to first uninstall that binding. You will also need to remove all things (to be clear just the konnected things need to be removed and any things for other bindings can remain) that were created with that version of the binding as the new binding has a different thing structure.

This file above is then placed in the addons folder per the instructions for a manual addon as indicated on this page.