Did the DSC Alarm Item Binding format change with OpenHab2?

I’m new to openHAB and just got yesterday’s Open Snapshot 2.0.0 setup with binding-dscalarm - 2.0.0.SNAPSHOT

In my log file I see events like this:

[marthome.event.ItemStateChangedEvent] - dscalarm_zone_192_1_1_60_zone5_zone_status changed from CLOSED to OPEN

I have my item file setup like this based on the documentation:

Contact ZONE5_GENERAL_STATUS "2nd Floor Doors" (DSCAlarmZones, Upstairs) {dscalarm="zone:1:5:zone_general_status"}
Number ZONE5_BYPASS_MODE "2nd Floor Doors Bypass Mode" (DSCAlarmZones) {dscalarm="zone:1:5:zone_bypass_mode"}
String ZONE5_ALARM_STATUS "Alarm Status : [%s]" (DSCAlarmZones) {dscalarm="zone:1:5:zone_alarm_status"}
String ZONE5_FAULT_STATUS "Fault Status : [%s]" (DSCAlarmZones) {dscalarm="zone:1:5:zone_fault_status"}
String ZONE5_TAMPER_STATUS "Tamper Status : [%s]" (DSCAlarmZones) {dscalarm="zone:1:5:zone_tamper_status"}
Switch ZONE5_IN_ALARM (DSCAlarmZones) {dscalarm="zone:1:5:zone_in_alarm"}
Switch ZONE5_TAMPER (DSCAlarmZones) {dscalarm="zone:1:5:zone_tamper"}
Switch ZONE5_FAULT (DSCAlarmZones) {dscalarm="zone:1:5:zone_fault"}
Switch ZONE5_TRIPPED (DSCAlarmZones) {dscalarm="zone:1:5:zone_tripped"}

It doesn’t seem the like sitemap is updating and when I try to run a rule like below, it isn’t triggered:

rule "Zone updated"
    Item ZONE5_GENERAL_STATUS received update OPEN
    sendNotification("my-email@gmail.com", "1st Floor Door Zone Opened")

If I change ZONE5_GENERAL_STATUS to dscalarm_zone_192_1_1_60_zone5_zone_status the rule does run and I get a notification.

rule "Zone updated"
    Item dscalarm_zone_192_1_1_60_zone1_zone_status received update OPEN
    sendNotification("my-email@gmail.com", "1st Floor Door Zone Opened")

Do I need to configure the Items file differently and change the {dscalarm=“zone:1:5:zone_general_status”} to something that has the ip address in it (the way it shows up in the logs)?


Hello @RichP,

Yes the format has changed in version 2.0. Go here for a description of the .items file. Items are linked to channels in the new format, so your item description would look something like this:

Contact ZONE5_STATUS "2nd Floor Doors" (DSCAlarmZones, Upstairs) {channel="dscalarm:zone:192_1_1_60:zone5:zone_status"}

In this case it appears you are using discovery to find the DSC Alarm and it’s components, so the use of a .thing file isn’t needed as shown in the description. In discovery the bridge name will be different because it is self generated and based on the IP address. You would use that name instead of say ‘tcpbridge’ as described in the documentation. Hope this helps.

1 Like

Thanks Russell, this helps immensely!

I was following the old binding version Wiki instructions but edited that page with a note about 2.0 bindings in hopes it helps someone else: https://github.com/openhab/openhab/wiki/DSC-Alarm-Binding

Next on my list is to stop these discovery errors:

16:15:03.463 [ERROR] [ernal.discovery.IT100BridgeDiscovery] - discoverBridge(): No Message Read from Serial Port '/dev/tty.Bluetooth-Incoming-Port'
16:15:21.522 [ERROR] [ernal.discovery.IT100BridgeDiscovery] - discoverBridge(): No Message Read from Serial Port '/dev/cu.Bluetooth-Incoming-Port'

16:14:48.569 [ERROR] [.discovery.EnvisalinkBridgeDiscovery] - discoverBridge(): Socket Exception! [] - java.net.ConnectException: Connection refused
16:14:48.571 [ERROR] [.discovery.EnvisalinkBridgeDiscovery] - discoverBridge(): Socket Exception! [] - java.net.ConnectException: Connection refused
16:14:48.585 [ERROR] [.discovery.EnvisalinkBridgeDiscovery] - discoverBridge(): Socket Exception! [] - java.net.ConnectException: Connection refused

Good idea. Thanks.

Those errors are probably not going to be easy to eliminate as they are generated during the discovery scan and result when an IO exception happens. You can pretty much ignore them.

On the documentation it uses the following in items:

Contact ZONE1_STATUS "Tamper Switch" (DSCAlarmZones) {channel="dscalarm:zone:tcpbridge:zone1:zone_status"}

But in the sitemap it uses:


Trying to figure out which one is correct.

ZONE1_GENERAL_STATUS seems to work fine.

The sitemap example was pretty much just copied from the openHAB 1 wiki. You would use whatever name you used in the .items file, in this case ZONE1_STATUS. Now l’m not sure how sitemaps are going to work with version 2 or if they work at all yet (https://www.eclipse.org/forums/index.php/m/1715906/?srch=Sitemap#msg_1715906). You will need to experiment for sure.

Sitemaps are working in 2!

Thanks again for your help!

Glad it is working. Looks great!

I was having an issue with high CPU usage with OH2 and have narrowed it down to the DSC Alarm 2.0 Binding.

It would get so high the computer would often not respond. (over 300% on my quad core iMac)

I have been disabling and enabling bindings to narrow it down and DSC seems to be the culprit.

With the DSC Bundle stopped, cpu usage for OH2 is less than 1%

Currently running version | DSCAlarm Binding

Also had the problem with the snapshot from last week.

Are there any settings that might cause this?

Is there a different DSC 2.0 binding I should try?

I’ll try removing all the DSC lines from Items and Sitemaps and placing them back a few at a time.

You can see the “bump” when i activate the bundle and then a few minutes later it starts to trend up in CPU usage.

And now it’s been solid at over 300% CPU

I couldn’t get the the CPU usage down with the 2.0 DSC Alarm Binding so I went back to OpenHab 1.8.2.

Now my cpu usage for OH is 0.3%

I’ll try OH2 again in the near future as in general I did like it better.

Hello Rich,

Sorry I haven’t gotten with you about this yet. I would like to try and troubleshoot it, but haven’t had a lot of time. I use version 1.8 for my home system so it requires me to setup version 2.0 from scratch. I have done some preliminary testing through the Eclipse IDE, but can’t seem to duplicate the issue. Of course this is just a minimal setup at best. I will move forward on it as time permits. Thanks Rich.

Russel, I can fire up my OH2 install if there is something you want me to test or look for.

How did it go with eliminating lines from your Item and Sitemap files? Any changes?

No different.

I can’t say exactly why, but my spider sense makes me think it has something to do with Discovery in OH2.

Your spider sense might be right. I had some difficulty with discovery when I was testing in the IDE. I will look at that a little closer. Thanks.

Is there any easy way to remove the Discovery code and test it without it?

I’ll fire OH2 back up for this.

Hello Rich,

Could probably comment out a few statements in DSCAlarmBaseBridgeHandler.java which would essentially disable running the threads whenever the Discovery service is called. Probably commenting out the if blocks in the startBackgroundDiscovery() method.

protected void startBackgroundDiscovery() {
logger.debug(“Start DSC Alarm Bridge background discovery”);

if (envisalinkBridgeDiscoveryJob == null || envisalinkBridgeDiscoveryJob.isCancelled()) {
envisalinkBridgeDiscoveryJob = scheduler.scheduleAtFixedRate(envisalinkBridgeDiscoveryRunnable, 0, refreshInterval, TimeUnit.SECONDS);

if (it100BridgeDiscoveryJob == null || it100BridgeDiscoveryJob.isCancelled()) {
it100BridgeDiscoveryJob = scheduler.scheduleAtFixedRate(it100BridgeDiscoveryRunnable, 0, refreshInterval, TimeUnit.SECONDS);

The first if block starts the Envisalink discovery thread, the second if block starts the IT-100 discovery thread. Are you running this from the Eclipse IDE? It would be easy to test it from there if you are. If not the binding would need to be exported as a .jar file and inserted in the openHAB2 directory structure.

I am not using the Eclipse IDE nor do I know how to export a .jar.

That said I am willing to learn to help out!

I am assuming I can’t just edit DSCAlarmBaseBridgeHandler.java with a Text Editor.

Hello Rich,

I have been looking at the code and there is a logical bug that prevents the IT-100 bridge from connecting. I will try to work on it this weekend.

1 Like