Did the DSC Alarm Item Binding format change with OpenHab2?

rsstephens · April 23, 2016, 8:14pm

Hello Rich,

I have a JAR file saved here if you want to test it. Let me know what you think. Thanks.

RichP · April 24, 2016, 2:07pm

I manually set up my DSC Partition/Zones using a dscalarm.things file but it’s still doing the discovery and CPU utilization is still pretty high.

https://www.evernote.com/l/AAvXSbvDT6hFdJ_5ZE8QNf1w6GYeo_yG9SIB/image.png

I’ll test it through the day and see if the CPU goes down at all.

rsstephens · April 24, 2016, 2:59pm

Hello Rich,

I basically concentrated on getting the the binding connected to the IT100 which became a priority. I did put in a 30 second delay for the bridge background discovery scheduler. What you are seeing in the logs isn’t the bridge discovery, but the device discovery. As the binding receives messages from the panel it determines if the device is one of it’s own things, or needs to be added to the discovery inbox. That can’t be changed. I have put a version out that turns off background discovery here, if you want to test that. Of course the only way to do a bridge discovery will be through the PaperUI now, which may not be a bad idea.

RichP · April 24, 2016, 3:56pm

Thanks for the additional info.

CPU usage has stabilized down to about 3% so I’ll let it run through the day with the jar you sent me yesterday!

tinuva · May 9, 2016, 2:22pm

rsstephens:

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.

@Override
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.

Would it be possible to add a setting that we can use to disable discovery, sortof like commenting it out?

RichP · May 9, 2016, 2:39pm

I wound up going back to OpenHab 1.8.2 because I had High CPU utilization with most of the OH2 builds when using the DSCAlarm Binding. I’m not even sure if this is related to Discovery or not (but that was my hunch)

The one OH2 build that didn’t have high CPU issues wasn’t firing off rules

I occasionally download a new OH2 build and test but think this issue needs to get fixed first: Error “Script interpreter couldn’t be obtain” #191

tinuva · May 12, 2016, 1:35pm

@RichP you using it with an it100 or envisalink?

I currently use it with the it100 and don’t have high cpu usage. I do have a scheduled rule that triggers a status update, but even with that my cpu load is 0.00 on a KVM VPM, which has 2 cores and 512MB ram only.

RichP · May 12, 2016, 3:22pm

I just moved OpenHab 1.8.2 to a RPi 3 and so far it’s running really well.

I will try to get OH2 running on it the RPi as well and see the high cpu reappears…maybe it’s related to running OH2 on a mac.

RichP · May 14, 2016, 2:13pm

Installed the latest OH2 Snapshot Build #293 on my iMac (quad core)

Shortly after enabling the DSCAlarm binding from within PaperUI, CPU usage for Java goes from about .4% to 300%+

I’ll let this run for a few hours and see if it stabilizes.

Either way, I’ll figure out how to move this install to my Raspberry Pi 3 and see if it behaves the same.

https://www.evernote.com/l/AAuLOIW2UedFB4fuXCKYGdVjEto-F8qZKpMB/image.png

RichP · May 14, 2016, 2:17pm

Good news! Moved OH2 to the RPi3 and I do NOT see the same high CPU usage with the DSCAlarm binding!

Must be related to something specific on OSX.

This screenshot is after OH2 has been running for about 18 hours.
https://www.evernote.com/l/AAvoFNCKlOhCO4WRTaA_7b97OFmV9aS6Sz8B/image.png

rsstephens · May 14, 2016, 3:01pm

Good to hear. I tried to duplicate your issue on my Windows based OH server but couldn’t. As you say, it must be an OSX problem. Glad it is working.

RichP · May 17, 2016, 2:55pm

Yeah, I am pretty happy and it’s been rock solid for a few days now with the same low CPU utilization.

I originally got the RPi3 for a robot project but I guess I will be “forced” to purchase another one now