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"
when
Item ZONE5_GENERAL_STATUS received update OPEN
then
sendNotification("my-email@gmail.com", "1st Floor Door Zone Opened")
end
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"
when
Item dscalarm_zone_192_1_1_60_zone1_zone_status received update OPEN
then
sendNotification("my-email@gmail.com", "1st Floor Door Zone Opened")
end
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)?
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:
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.
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.
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.
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.
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.
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.