AlarmDecoder AD2Pi Network Appliance

I believe I did although it’s been a while - I think I followed the instructions on the github page. Will try that

*edit - that did the trick. Must have been some old stuff lingering out there. Thanks!

Yeah, cool. That should fix your updater notifications too as it goes by the git commits, not whatever is on pypi.

1 Like

I was noticing that one of my zones was being reported as a different zone. I have no idea why, but I did some playing around and found that AlarmDecoder had the right zone but for some reason the smartthings device was wrong. I decided the easiest thing to do was to uninstall the service manager from smartthings and reinstall it to make sure I hadn’t messed up the original configuration.

Anyway, now when I try to install the service manager in the simulator on the website, I get

java.lang.NullPointerException: Cannot invoke method minus() on null object

Error log looks like this:

`ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:42 PM: trace locationHandler: description=register

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:42 PM: trace locationHandler

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:42 PM: error java.lang.NullPointerException: Cannot invoke method split() on null object

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:42 PM: trace locationHandler: description=null

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:42 PM: trace locationHandler

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:41 PM: error java.lang.NullPointerException: Cannot invoke method minus() on null object

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:41 PM: trace addExistingDevices, devices.find=uuid:97487987-b220-11e7-9ba8-b5672e8fd4f7={port=1388, ssdpUSN=uuid:97487987-b220-11e7-9ba8-b5672e8fd4f7, devicetype=04, mac=B827EB6C0227, hub=54a142d6-34b8-444f-a2d5-960dc05ea1ce, ssdpTerm=urn:schemas-upnp-org:device:AlarmDecoder:1, ip=C0A80B95}

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:41 PM: trace devices=[uuid:97487987-b220-11e7-9ba8-b5672e8fd4f7:[port:1388, ssdpUSN:uuid:97487987-b220-11e7-9ba8-b5672e8fd4f7, devicetype:04, mac:B827EB6C0227, hub:54a142d6-34b8-444f-a2d5-960dc05ea1ce, ssdpTerm:urn:schemas-upnp-org:device:AlarmDecoder:1, ip:C0A80B95]]

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:41 PM: trace addExistingDevices, getChildDevice(C0A80B95:1388)

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:41 PM: trace addExistingDevices: C0A80B95:1388

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:41 PM: trace initialize

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:41 PM: debug Installed with settings: [selectedDevices:C0A80B95:1388, shmIntegration:false, defaultSensorToClosed:true, shmChangeSHMStatus:false]

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:30 PM: trace locationHandler: device already exists… checking for changed values

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:30 PM: trace locationHandler: description=devicetype:04, mac:B827EB6C0227, networkAddress:C0A80B95, deviceAddress:1388, stringCount:04, ssdpPath:, ssdpUSN:uuid:97487987-b220-11e7-9ba8-b5672e8fd4f7, ssdpTerm:urn:schemas-upnp-org:device:AlarmDecoder:1, ssdpNTS:

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:30 PM: trace locationHandler

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:30 PM: trace locationHandler: device already exists… checking for changed values

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:30 PM: trace locationHandler: description=devicetype:04, mac:B827EB6C0227, networkAddress:C0A80B95, deviceAddress:1388, stringCount:04, ssdpPath:, ssdpUSN:uuid:97487987-b220-11e7-9ba8-b5672e8fd4f7, ssdpTerm:urn:schemas-upnp-org:device:AlarmDecoder:1, ssdpNTS:

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:30 PM: trace locationHandler

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:29 PM: trace discover_alarmdecoder

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:29 PM: trace discover_devices: [port:1388, ssdpUSN:uuid:97487987-b220-11e7-9ba8-b5672e8fd4f7, devicetype:04, mac:B827EB6C0227, hub:54a142d6-34b8-444f-a2d5-960dc05ea1ce, ssdpTerm:urn:schemas-upnp-org:device:AlarmDecoder:1, ip:C0A80B95]

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:28 PM: trace locationHandler: device already exists… checking for changed values
ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:28 PM: trace locationHandler: description=devicetype:04, mac:B827EB6C0227, networkAddress:C0A80B95, deviceAddress:1388, stringCount:04, ssdpPath:, ssdpUSN:uuid:97487987-b220-11e7-9ba8-b5672e8fd4f7, ssdpTerm:urn:schemas-upnp-org:device:AlarmDecoder:1, ssdpNTS:

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:28 PM: trace locationHandler

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:28 PM: trace locationHandler: Adding device: uuid:97487987-b220-11e7-9ba8-b5672e8fd4f7

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:28 PM: trace locationHandler: description=devicetype:04, mac:B827EB6C0227, networkAddress:C0A80B95, deviceAddress:1388, stringCount:04, ssdpPath:, ssdpUSN:uuid:97487987-b220-11e7-9ba8-b5672e8fd4f7, ssdpTerm:urn:schemas-upnp-org:device:AlarmDecoder:1, ssdpNTS:

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:28 PM: trace locationHandler

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:28 PM: trace discover_alarmdecoder

ea563cc1-b2e1-469e-9f07-401fb95da0a1 4:45:28 PM: trace discover_devices: subscribe to location`

I’m running the network appliance with Raspian Stretch and the Docker version of the webapp.

Jason

Just FYI- looks like the AlarmDecoder developer is now aware of an issue due to changes in SmartThings. http://www.alarmdecoder.com/forums/viewtopic.php?uid=1554&f=3&t=636&start=10#p2861

Just an FYI, they pushed a fix to the alarmdecoder-smartthings code to fix v2 hubs

I have the same thing appear, too. However, it also appears on my panel appear, too. However, it also appears on my panel. At one point I asked nu tech what they thought it might be. They thought there might be a short in a device in my home security system. However, my security technician says that is not the case. They suggested disconnecting the device from my system. Any update on this?

I should mention that my Siren went off and the Central dispatch was notified. I then had to say there was no fire and calm my dog down from the loud indoor siren.

Thanks. It fixes the issue.

Jason

So is this thing stable now? Ready to buy an AD2USB for my Pi and set it up, but not if it’s still going thru some growing pains.

Everything is working well for me.

Jason

Have the AD2Pi version. Everything seems to be working for me, except I found I had to use the virtual relay option to emulate a relay to get the messages from the system while in armed mode. Easy fix but then I found the smartthings app doesn’t support the relay changes and the relay notifications option doesn’t work either. I opened a ticket with support and they haven’t responded in a few weeks. It’s a great product but the software is lacking a bit and looking around their support site, forums, and such it seems support is kinda dead with a few users hanging on helping each other.

SOLVED - Had to disconnect from GitHub and reconnect.

Ok, I’m going thru the setup, I deleted all the RedLoro stuff I was using and now I can’t get passed the GitHub integration. I get the following error when I try to add the new repository.

“You don’t have access to nutechsoftware/alarmdecoder-smartthings”

Any ideas on this?

Ok, now I have an error when I try to setup the ios app.

“deviceNetworkId must be unique”

I’ve literally wiped out all the settings I could find, redid the setup and still get same error.

Everything appears to be working, so I’ll ignore for now.

1 Like

New Push Notification AlarmDecoder SmartThings App and new virtual Smoke alarm sensor for better Smart Home Monitor support. I also now send full Contact ID reporting if available to ST so additional logic can be used to trigger events. If you have an LRR radio the messages will be sent already if you do not then you can enable Emulation on the AD2* for Long Range Radio LRR support and program report codes you want transmitted. For DSC panels LRR is enabled by default and Zero conf is needed to get messages.

I have been working on a rewrite of the AlarmDecoder Smartthings integration with the AD2 WebApp for a few weeks now. The current work can be found on our dev branches on the AlarmDecoder github page.

This requires an update of the Python API, The WebAPP and the ST code.

Best
Sean M
@ AlarmDecoder.com

3 Likes

Thanks, Sean. I’ll check it out.

Jason

I also have this same error "deviceNetworkId must be unique". I was able to install via the IDE simulator, but I cannot manage or view using the mobile client smartApp.

What step did that error happen on?

I presume you had removed all existing AlarmDecoder devices first. I found this to be difficult especially if I integrate them into SHM. I was hoping to find a way to “force” removing during the “Uninstall()” process but so far I have not found any ST docs on how.

The “deviceNetworkId must be unique” error message is displayed in the Mobile alarmdecoder SmartApp after I followed the steps to integrate in the Simulator, uninstall from simulator and then install via the marketplace in the ST mobile client.

I have doubled checked all the devices and DTH and only the new “virtual contact sensor” and “network appliance” DTH are installed per the master github integration to ST.

Ok, I decided to completely delete the alarmdecoder SmartAPP and all DTH’s and add them back via github integration and from the master branch. No devices showing in Things or the IDE My Devices page.

Results:

  1. I’m guessing that you have us install the smartapp via the IDE simulator to get at the secret and endpoint, which are not displayed when installing the smartAPP from the Marketplace ST mobile client APP.
  2. However, after obtaining the secret and endpoint from the simulator, and thus go to uninstall, all the of the devices disappear (I know this is documented).
  3. If I try a fresh install fresh from the MarketPlace mobile client SmartAPP, I get the ““deviceNetworkId must be unique””. I am certain that I have deleted all Alarmdecoder devices from “My devices” page.
  4. I doubled checked the AlarmDecoder API key and Notifier settings and they are correct. I am running the latest version of the Alarmdecoder Python code v0.8.0-10-g0b754de.

So for now, I have it installed via the simulator, and most of the functionality is present except it appears for the children sensors, they do not show color changes in the mobile client when their recently log shows that they are being open/closed.

The log shows plenty of activity, but the sensors are always green/closed status.

Sorry to be such a pain, just trying to install this great APP. Any directions would be appreciated.

Ok the AlarmDecoder needs to be on the dev branch as well as the AlarmDecoder WebApp.

ssh into your pi and in /opt/alarmdecoder and /opt/alarmdecoder-webapp be sure you are on dev and then restart your Pi or reload gunicorn via ssh using sudo gunicorn restart.

This can also be done via the AlarmDecoder web app but I do not think it will update the the API in /opt/alarmdecoder

My current dev version.
© 2014 · AlarmDecoder · Help · Terms · v0.8.0-24-gc856baa

Thanks @f34rdotcom,

I am able to SSH into Pi, but I am little confused how to switch the main branch to dev. Here is what those directories have for files:

ll /opt/alarmdecoder
total 44
drwxr-xr-x 5 pi   pi      4096 Nov 25 07:30 alarmdecoder
drwxr-xr-x 2 root root    4096 Oct 31  2014 alarmdecoder.egg-info
drwxr-xr-x 2 pi   pi      4096 Aug  8  2017 bin
drwxr-xr-x 3 pi   pi      4096 Oct 31  2014 docs
drwxr-xr-x 2 pi   pi      4096 Aug  8  2017 examples
-rw-r--r-- 1 pi   pi      1100 Oct 31  2014 LICENSE
-rw-r--r-- 1 pi   pi       100 Oct 31  2014 MANIFEST.in
-rw-r--r-- 1 root dialout 2333 Feb 10 03:20 README.rst
-rw-r--r-- 1 root dialout   29 Aug  8  2017 requirements.txt
-rw-r--r-- 1 root dialout 1604 Jan  4 04:25 setup.py
drwxr-xr-x 2 pi   pi      4096 Feb 10 03:20 test

ll  /opt/alarmdecoder-webapp
total 1944
drwxr-xr-x 20 pi   pi         4096 Jan  4 04:26 ad2web
drwxr-xr-x  3 pi   pi         4096 Nov 14  2016 alembic
-rw-r--r--  1 pi   pi         1117 Nov 14  2016 alembic.ini
-rw-r--r--  1 pi   pi      1815692 Nov 14  2016 bcprov-jdk15on-146.jar
-rw-r--r--  1 pi   pi           46 Nov 14  2016 CHANGES
drwxr-xr-x  6 pi   pi         4096 Aug  8  2017 contrib
-rw-r--r--  1 root dialout    3353 Aug  8  2017 fabfile.py
drwxr-xr-x  6 pi   pi         4096 Apr 10 19:38 instance
-rw-r--r--  1 pi   pi         1100 Nov 14  2016 LICENSE
-rw-r--r--  1 pi   pi         1452 Nov 14  2016 LICENSE.fbone
-rw-r--r--  1 pi   pi         2200 Nov 14  2016 manage.py
-rw-r--r--  1 pi   pi          507 Nov 14  2016 MANIFEST.in
-rw-r--r--  1 root dialout    3903 Aug  8  2017 README.md
-rw-r--r--  1 root dialout     854 Aug  8  2017 requirements.txt
-rw-r--r--  1 pi   pi       101732 Nov 14  2016 screenshot.png
-rw-r--r--  1 root dialout    1412 Nov 25 07:30 setup.py
drwxr-xr-x  2 pi   pi         4096 Nov 14  2016 tests
-rw-r--r--  1 pi   pi         1015 Nov 14  2016 wsgi.py
-rw-r--r--  1 root dialout    1128 Nov 14  2016 wsgi.pyc

Also, I found the area in the WebAPP to switch code, but it appears that dev is not an option.

Is it possible to just fall-back and install the older stable “production” version of Alarmdecoder so I do not have to update my Alarmdecoder Raspberry Pi to a development version?