AD2Pi and SmartThings integration error

[michaelpmaley]

I am having a problem installing the service_manager.groovy smartapp into SmartThings.

I just purchased and installed the AD2Pi for my 20p panel. Updated the webapp, the libraries, and the firmware to V2.2a.8.8. Scanned for devices - had to manually fix zone 10’s zone_id due to “Zones page has an error: ValueError: invalid literal for int() with base 10: '1\x03’” and manually add one zone. After that, everything seems to be working fine.

Next, I attempted the SmartThings integration using https://github.com/nutechsoftware/alarm ... martthings. I did manually update device_type.groovy and service_manager.groovy per https://community.smartthings.com/t/ala ... e/61902/61 thread entry. The error is on step 20 “Click Install”.

Code: Select all

ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:56:06 PM: error java.lang.NullPointerException: Cannot invoke method minus() on null object
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:56:06 PM: trace addExistingDevices, devices.find=uuid:bcaeac05-0e52-11e6-8ca3-b827ebddb2da={port=1388, ssdpUSN=uuid:bcaeac05-0e52-11e6-8ca3-b827ebddb2da, devicetype=04, mac=B827EBDDB2DA, hub=bfde61bc-f43b-4d52-946d-8729e44e256d, ssdpTerm=urn:schemas-upnp-org:device:AlarmDecoder:1, ip=0A00011F}
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:56:06 PM: trace devices=[uuid:bcaeac05-0e52-11e6-8ca3-b827ebddb2da:[port:1388, ssdpUSN:uuid:bcaeac05-0e52-11e6-8ca3-b827ebddb2da, devicetype:04, mac:B827EBDDB2DA, hub:bfde61bc-f43b-4d52-946d-8729e44e256d, ssdpTerm:urn:schemas-upnp-org:device:AlarmDecoder:1, ip:0A00011F]]
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:56:06 PM: trace addExistingDevices, getChildDevice(0A00011F:1388)
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:56:06 PM: trace addExistingDevices: 0A00011F:1388
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:56:06 PM: trace initialize
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:56:06 PM: debug Installed with settings: [selectedDevices:0A00011F:1388, shmIntegration:true, shmChangeSHMStatus:true, defaultSensorToClosed:true]
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:55 PM: trace locationHandler: device already exists.. checking for changed values
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:55 PM: trace locationHandler: description=devicetype:04, mac:B827EBDDB2DA, networkAddress:0A00011F, deviceAddress:1388, stringCount:04, ssdpPath:, ssdpUSN:uuid:bcaeac05-0e52-11e6-8ca3-b827ebddb2da, ssdpTerm:urn:schemas-upnp-org:device:AlarmDecoder:1, ssdpNTS:
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:55 PM: trace locationHandler
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:55 PM: trace locationHandler: device already exists.. checking for changed values
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:55 PM: trace locationHandler: description=devicetype:04, mac:B827EBDDB2DA, networkAddress:0A00011F, deviceAddress:1388, stringCount:04, ssdpPath:, ssdpUSN:uuid:bcaeac05-0e52-11e6-8ca3-b827ebddb2da, ssdpTerm:urn:schemas-upnp-org:device:AlarmDecoder:1, ssdpNTS:
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:55 PM: trace locationHandler
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:55 PM: trace discover_alarmdecoder
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:55 PM: trace discover_devices: [port:1388, ssdpUSN:uuid:bcaeac05-0e52-11e6-8ca3-b827ebddb2da, devicetype:04, mac:B827EBDDB2DA, hub:bfde61bc-f43b-4d52-946d-8729e44e256d, ssdpTerm:urn:schemas-upnp-org:device:AlarmDecoder:1, ip:0A00011F]
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:54 PM: trace locationHandler: device already exists.. checking for changed values
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:54 PM: trace locationHandler: description=devicetype:04, mac:B827EBDDB2DA, networkAddress:0A00011F, deviceAddress:1388, stringCount:04, ssdpPath:, ssdpUSN:uuid:bcaeac05-0e52-11e6-8ca3-b827ebddb2da, ssdpTerm:urn:schemas-upnp-org:device:AlarmDecoder:1, ssdpNTS:
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:54 PM: trace locationHandler
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:54 PM: trace locationHandler: device already exists.. checking for changed values
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:54 PM: trace locationHandler: description=devicetype:04, mac:B827EBDDB2DA, networkAddress:0A00011F, deviceAddress:1388, stringCount:04, ssdpPath:, ssdpUSN:uuid:bcaeac05-0e52-11e6-8ca3-b827ebddb2da, ssdpTerm:urn:schemas-upnp-org:device:AlarmDecoder:1, ssdpNTS:
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:54 PM: trace locationHandler
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:54 PM: trace discover_alarmdecoder
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:54 PM: trace discover_devices: [port:1388, ssdpUSN:uuid:bcaeac05-0e52-11e6-8ca3-b827ebddb2da, devicetype:04, mac:B827EBDDB2DA, hub:bfde61bc-f43b-4d52-946d-8729e44e256d, ssdpTerm:urn:schemas-upnp-org:device:AlarmDecoder:1, ip:0A00011F]
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:52 PM: trace locationHandler: device already exists.. checking for changed values
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:52 PM: trace locationHandler: description=devicetype:04, mac:B827EBDDB2DA, networkAddress:0A00011F, deviceAddress:1388, stringCount:04, ssdpPath:, ssdpUSN:uuid:bcaeac05-0e52-11e6-8ca3-b827ebddb2da, ssdpTerm:urn:schemas-upnp-org:device:AlarmDecoder:1, ssdpNTS:
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:52 PM: trace locationHandler
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:52 PM: trace locationHandler: device already exists.. checking for changed values
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:52 PM: trace locationHandler: description=devicetype:04, mac:B827EBDDB2DA, networkAddress:0A00011F, deviceAddress:1388, stringCount:04, ssdpPath:, ssdpUSN:uuid:bcaeac05-0e52-11e6-8ca3-b827ebddb2da, ssdpTerm:urn:schemas-upnp-org:device:AlarmDecoder:1, ssdpNTS:
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:52 PM: trace locationHandler
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:52 PM: trace discover_alarmdecoder
ea456a3d-2b22-4f36-9f39-60ebc9c2ff37 9:55:52 PM: trace discover_devices: [port:1388, ssdpUSN:uuid:bcaeac05-0e52-11e6-8ca3-b827ebddb2da, devicetype:04, mac:B827EBDDB2DA, hub:bfde61bc-f43b-4d52-946d-8729e44e256d, ssdpTerm:urn:schemas-upnp-org:device:AlarmDecoder:1, ip:0A00011F]


It seems to me, the problem is the “urn-= “http://“ line because newDevice.value.ssdpPath is null per the log output above. Is this indicative of a deeper problem or should I just hardcode a value and if so, what.

service_manager.groovy

Code: Select all

def addExistingDevices() {
    log.trace "addExistingDevices: ${selectedDevices}"

    def selected_devices = selectedDevices
    if (selected_devices instanceof java.lang.String) {
        selected_devices = [selected_devices]
    }

    selected_devices.each { dni ->
        def d = getChildDevice(dni)
        log.trace("addExistingDevices, getChildDevice(${dni})")
        if (!d) {
            log.trace("devices=${devices}")
            def newDevice = state.devices.find { /*k, v -> k == dni*/ k, v -> dni == "${v.ip}:${v.port}" }
            log.trace("addExistingDevices, devices.find=${newDevice}")

            if (newDevice) {
                // Set the device network ID so that hubactions get sent to the device parser.
                state.ip = newDevice.value.ip
                state.port = newDevice.value.port
                state.hub = newDevice.value.hub

                // Set URN for the child device
                def urn = newDevice.value.ssdpPath
                urn -= "http://"
                state.urn = urn

                // Create device and subscribe to it's zone-on/off events.
                d = addChildDevice("alarmdecoder", "AlarmDecoder Network Appliance", "${state.ip}:${state.port}", newDevice?.value.hub, [name: "${state.ip}:${state.port}", label: "AlarmDecoder", completedSetup: true, data:[urn: state.urn]])
            }
        }
    }
}


I appreciate any help.

Thanks,
Michael

[kevin]

That would indicate that it is not discovering your device for some reason. If your router does not support upnp then it might have issues... please also check your logs on the device itself to see if it is broadcasting

[michaelpmaley]

My router is an Apple Time Capsule. A quick search showed a bit of confusion regarding TC and UPNP. There is nothing in the Alarm Decoder Log > App. The Alarm Decoder seems to be working just fine. Not sure I understand how it is not being discovered when the MAC and IP shown in the SmartThings error trace are correct. Are there steps/instructions to follow somewhere?

Thanks,
Michael

[kevin]

Instructions are in the readme here https://github.com/nutechsoftware/alarm ... martthings

This is a unique error to me, not seen it, so I'm unsure - maybe the guys at Nu Tech can figure it out, try emailing support?

[michaelpmaley]

I emailed support last weekend before trying the forum, but haven't heard back. I I have been tracing the code and checking the logs, but haven't found anything. I used the client.py test script from another forum post and that worked. I ended up changing service_manager.groovy script to have a hardcoded ssdpPath value so that the code would work. If someone could tell me what they have in graph.api.smartthings.com > My Devices > AlarmDecoder for the Data field, I would have to validate my guess. I went with "http://alarmdecoder.local:5000" since the groovy script is attempting to strip "http://". That did something. Everything should up in SmartThings, but I am getting no communication in either direction.

Thanks,
Michael

[jmontana]

I am also experiencing the same error.
The AD2PI appliance i have is brand new running the latest firmware.
UPNP is enabled on my router.

Similar troubleshooting done as michaelpmaley. The ssdpPath is returning null so the code is blowing up trying to parse. I was able to work around the discovery/install phase by using a mac,ip,port data set instead of urn. It just moves the root issue into another area. Notification does not work correctly now since the Smartthings is not able to fill in the host field. I have manually set the Https://IP:port host and it will atleast communicate on refreshes but its not able to match up the faults returned from the alarmDecoder.
This seems to just snowball from whatever root cause is causing the ssdpPath to not be set.

[kevin]

You guys will really have to email support - I no longer work for Nu Tech and don't have access to the smartthings equipment anymore - support is better course of action here.

[jasonsf]

I'm having the same issue. And since Kevin mentioned upnp, that is relevant to me since I recently turned that off for my router for security reasons. I'll turn it back on and see if that fixes the issue.

Jason

[mathewss]

Looks like this all started with a recent update from SmartThings. I will build a test environment and do some debugging of the code this week. I have had our HUB off for a while I presume it will need some updates.

Best
Sean M.

Some light reading.
http://docs.smartthings.com/en/latest/c ... nager.html

[mathewss]

Can someone do the following. This will get me what I need to try and narrow down the issue.

Code: Select all

#Login to raspberry pi@alarmdecoder.local
sudo apt-get update
sudo apt-get install tcpdump
sudo tcpdump -i eth0 -n -s 1500 -w /opt/alarmdecoder-webapp/ad2web/static/smartthings.cap
# Attempt the discovery process and wait for the error then use CTL+C to stop capture on raspberry pi.
# Download the file local to email to us at ad2usb@support.nutech.com
https://alarmdecoder.local/static/smartthings.cap


This file will not take up much room if you run the capture for 10 or 20 minutes depending on activity.

Best
Sean M