nutechsoftware / alarmdecoder-smartthings Goto Github PK

I updated the alarmdecoder-smartthings smartapp and device handlers.
Now Smartapp does not reflect the correct status. AlarmDecoderr (AD2) device shows an NOT ready.

I have not been successful in Enabling SmartThings Integration in the Webapp. The version of webapp running on my device does not allow the creation of Notification Type 'UPNP Push'

When you arm the alarm, the arming mode changes to the type of arming selected (e.g., STAY). For example, when I arm my alarm to STAY, the panel_armed_stay booleans flips to true even though the panel is not truly armed. When you press an arming mode the alarm goes into a countdown so the alarm is not armed until the end of this countdown.

Checking the bit field, position 3 flips to 1 immediately after pressing the arming button

10000001000000003A ready
00110301000010003A arming button pressed
00100001000010003A countdown complete, armed

Seems the only thing that notates actual arming is the keypad message

When arming, the Alphanumeric Keypad Message shows ARMED INSTANT You may exit now

After the countdown is complete, the Alphanumeric Keypad Message shows ARMED INSTANT

Not sure this is doable but wanted to ask. I guess people can assume that the alarm is armed after they press the arming button (eg, Night, Away, Stay, etc.) even though the countdown is not done.

02bd3f45-3ca3-4066-9e18-5850abccca58 6:48:46 PM: error There was an error (org.springframework.dao.CannotAcquireLockException: Could not execute JDBC batch update; SQL [insert into device (version, completed_setup, component_label, component_name, date_created, device_network_id, error_state, firmware_version_id, group_id, handler_version, hub_id, is_component, join_fingerprint_id, label, last_updated, location_id, name, parent_device_id, parent_smart_app_id, previous_handler, previous_zigbee_id, primary_tile_name, profile_id, profile_type, protocol_connection, raw_description, sort_order, type_id, virtual_smart_app_id, zigbee_id, id) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)]; nested exception is org.hibernate.exception.LockAcquisitionException: Could not execute JDBC batch update) when trying to addZone 10

At Step 9 under installing SmartApp i get the following error.

physicalgraph.app.exception.UnknownDeviceTypeException: Device type 'AlarmDecoder action button indicator' in namespace 'alarmdecoder' not found. @line 1079 (doCall)

I have had my AD2Pi network appliance working with my Vista20p setup since mid-2018 or so and it has been working without much complaint. It was integrated with SmartThings, although it was an arduous process ... mostly because I'm really need that techy.

However, between me messing around with the new SmartThings app and getting my wife (a new member to the hub) added and her account being used on and off with the ST classics app and the new app, I've had to start from scratch ... I've removed all integrated devices and re-added them all back into the Classic app. The only thing that I am still having issues with is my AlarmDecoder setup.

I've re-added all the contacts/sensors back into SmartThings, but for whatever reason, none of them receive any updates (i.e., I open the front door, I walk by motion sensors, etc. ... none of that is recognized in the ST app). These are all recognized on my panel and everything there functions as normal, it just seems like there is a missing link between it and ST.

I've gone through the process of deleting all the devices from the ST classics app, then going to the IDE to perform updates from the repo for the device handlers, etc. and re-installing from the ST classics app again, but still no change. In case anyone asks, yes i did go into the WebApp to obtain the key to input into the classics app.

Smarthome monitor arms, and stay arms the panel but the disarm functionality appears to be broken.

This started after I updated to the most recent version of the webapp and smartthings integration.

• Does smart app receive SHM event? Yes
• Does smart app attempt to disarm alarm decoder device? Nope

In the below sequence I set the SHM to Stay and then Off. From the (improved) log we can see the last alarm decoder status was never set to stay, thus the disarm command was never sent.

trace shmAlarmHandler -- off, lastSHMStatus stay, last alarm decoder status off
trace shmAlarmHandler -- off, lastSHMStatus stay, last alarm decoder status off
debug getChildDevices(true), children=9
trace shmAlarmHandler -- stay, lastSHMStatus off, last alarm decoder status off
debug getChildDevices(true), children=9
trace shmAlarmHandler -- stay, lastSHMStatus off, last alarm decoder status off

It'd be great if there were a way to add motion sensor zones in addition to contact sensors.

SmartThings wants the contact sensor to default to closed and switch to open when tripped

I know there is a generic smoke detector that triggers if the alarm detects fire. However, if I setup a zone for my smoke and CO zone #s, even though it'll show up as a contact sensor, will it properly report smoke/CO?

In smartthings tiles must be statically declared. Since the number of zones varies from panel to panel it does not make sense to show zones on the alarm decoder device. Further more the UX weird at the moment, the most used buttons (arm, stay, disarm) are the smallest. Meanwhile the least used buttons, panic, aux, and fire are the biggest.

Below is what I propose it be changed to

    tiles(scale: 2) {
        multiAttributeTile(name: "status", type: "generic", width: 6, height: 4) {
            tileAttribute("device.panel_state", key: "PRIMARY_CONTROL") {
                attributeState "armed", label: 'Armed', icon: "st.security.alarm.on", backgroundColor: "#ffa81e"
                attributeState "armed_stay", label: 'Armed (stay)', icon: "st.security.alarm.on", backgroundColor: "#ffa81e"
                attributeState "disarmed", label: 'Disarmed', icon: "st.security.alarm.off", backgroundColor: "#79b821", defaultState: true
                attributeState "alarming", label: 'Alarming!', icon: "st.home.home2", backgroundColor: "#ff4000"
                attributeState "fire", label: 'Fire!', icon: "st.contact.contact.closed", backgroundColor: "#ff0000"
                attributeState "ready", label: 'Ready', icon: "st.security.alarm.off", backgroundColor: "#79b821"
                attributeState "notready", label: 'Not Ready', icon: "st.security.alarm.off", backgroundColor: "#e86d13"
            }
        }

        standardTile("arm_disarm", "device.panel_state", inactiveLabel: false, width: 2, height: 2) {
            state "armed", action:"lock.unlock", icon:"st.security.alarm.off", label: "DISARM"
            state "armed_stay", action:"lock.unlock", icon:"st.security.alarm.off", label: "DISARM"
            state "disarmed", action:"lock.lock", icon:"st.security.alarm.on", label: "AWAY"
            state "alarming", action:"lock.unlock", icon:"st.security.alarm.off", label: "DISARM"
            state "fire", action:"lock.unlock", icon:"st.security.alarm.off", label: "DISARM"
            state "ready", action:"lock.lock", icon:"st.security.alarm.off", label: "AWAY"
            state "notready", action:"lock.unlock", icon:"st.security.alarm.off", label: "DISARM"
        }

        standardTile("stay_disarm", "device.panel_state", inactiveLabel: false, width: 2, height: 2) {
            state "armed", action:"switch.off", icon:"st.security.alarm.off", label: "DISARM"
            state "armed_stay", action:"switch.off", icon:"st.security.alarm.off", label: "DISARM"
            state "disarmed", action:"switch.on", icon:"st.Home.home4", label: "STAY"
            state "alarming", action:"switch.off", icon:"st.security.alarm.off", label: "DISARM"
            state "fire", action:"switch.off", icon:"st.security.alarm.off", label: "DISARM"
            state "ready", action:"switch.on", icon:"st.security.alarm.off", label: "STAY"
            state "notready", action:"switch.off", icon:"st.security.alarm.off", label: "DISARM"
        }

        standardTile("panic", "device.panic_state", inactiveLabel: false, width: 2, height: 2) {
            state "default", icon:"st.alarm.alarm.alarm", label: "PANIC", nextState: "panic1", action: "panic1"
            state "panic1", icon: "st.alarm.alarm.alarm", label: "PANIC", nextState: "panic2", action: "panic2", backgroundColor: "#ffa81e"
            state "panic2", icon: "st.alarm.alarm.alarm", label: "PANIC", nextState: "default", action: "panic", backgroundColor: "#ff4000"
        }

        standardTile("refresh", "device.refresh", inactiveLabel: false, decoration: "flat", width: 6, height: 2) {
            state "default", action:"refresh.refresh", icon:"st.secondary.refresh"
        }

        main(["status"])
        details(["status", "arm_disarm", "stay_disarm", "panic", "refresh",])
    }

Hi there,

I have followed the install to a tee. the zone states are not updating (both hardwired and wireless) in the smart things app. I have uninstalled rebooted (both hub and pi) and re-installed with no luck. Webapp does update and is reflective of zone faulting.

Just uninstalled a former version from smart things and did not encounter any issues with the former version previously loaded.

My alarm decoder almost always reports as Not Ready. I don't know if it's an async timing issue or what. My AD2 Ready device reads "Open" and my AD2 says "Not Ready." This even happens when I arm. It will briefly switch to an "Armed" status but then in a few minutes it's "Not Ready" again.

Wanted to suggest adding a field or fields that provides the countdown status when arming as well as countdown when you enter during AWAY or STAY status and have to disarm.

If the MAC address changes the code currently will ignore the AD2Pi Web appliance PUSH messages. It is still possible to PULL(refresh) to update the phone app.

locationHandler is where some code exists that was designed to repair a changing IP address but no case for a change of MAC address and the IP change code is questionable. I have been looking at this code and reading various security white papers and it seems the only reasonable way to deal with this is to allow the user to re-link the AD2Pi Web appliance manually. This leaves the security to the user to pick the correct device on the network.

I will be adding a new screen to update the data section of the AlarmDecoder UI device by allowing a UPNP scan on the network to detect the active AD2* devices on the network and let the user select one and update with that selections details.

I am willing to keep the DNI update code for now with better logging but IMHO that seems like a security issue as well. Best to better document that it is expect that the device have a fixed ip or a reservation on DHCP.

The current data stored in the device.
ssdpPath ex /static/device_description.xml
urn ex 192.168.1.2:5000
ssdpUSN ex uuid:11a5f1f0-c510-12e3-9547-b827fb40c401
mac ex AABBCCDDEEFF

Maybe this is expected but thought I would bring it up.

This morning I updated the webapp which then restarted it. After that I just realized I am not getting status updates in smartthings. I have to refresh manually to get an update.

I did go into settings and click save and that seems to work. I thought there was a process for regrabbing the notifications? It was like this all day so it isn't a time thing.

Thanks!

Because the translation of zones to virtual zone device numbers is limited to 20 that are typed into the settings page of the Network Appliance device handler and that section is not possible to make dynamic I need to find a better way. Having to modify code to go beyond 20 is a pain and adding 40 zones so enough are created to trap any zone number is not good when 90% of the devices will be not used.

It is also not very intuitive on how the ZoneTracker preferences work. It would be better to allow the user to create individual virtual zones on demand and not provide some mass input screen for all the tracked zones.

Click 'Enable OAuth in Smart App'
Click Publish -> For Me <---- All I see is an "Update" button nothing said publish.

when trying to install the smartApp I am unable to get my ADWebApp to be discovered. I have them on the same network as hub, the WebApp is operating fine in the browser, but when I try Send UPNP Discovery in the SmartApp simulator no devices are found. Any suggestions?

Many panels have the option of setting of Instant arming mode (e.g., Night) which is basically where it only arms the perimeter sensors and bypasses the internal motions, etc.

Could we add an "Instant" GUI panel if that state is detected?

trying out the latest code release. I believe I have everything updated and had to redo all devices.

When I open a door I instantly see the red circle with the faulted zone in the alarmdecoder device. The matching device does not change to "open" though.

If I click refresh in the alarmdecoder device then the zone tracker sensor udpates and shows open.

Ideas?

For DSC panels smart things shows "Armed" when panel is in "Stay".

// Stay Arm
!KPM:[01010011000000000D--],008,[000200000000000000000000000000],"Exit Delay In Progress "
// Away Arm
!KPM:[01010001000000000D--],008,[000200000000000000000000000000],"Exit Delay In Progress "

Are there any thought/plans to support the new smartthings app? Specifically some kind of UI for showing zone status like the old one?

Current API reports zones that are faulted but nothing is reported about zones that are bypassed. It would be great if the bypassed zones were reported like the zones faulted.

Just realized after the latest updates I Am not getting any updates to my ST setup. I can manually refresh but don’t get status changes or zone updates. Looked at all the usual but not exactly sure where else to look.

Zones do not update open/close status in smartthings. Alarm decoder web app's virtual keypad shows open zones (Secure System Before Arming <> > Open Zones Scroll to View <> >Zone 07 <>)

Is there anyway to detect whether or not the alarm was armed in night mode vs. away/stay?

Is there a way to remove / re-install just the SHM integration portion? I've been running the setup on a raspberry pi with absolutely no issues for quite some time. As of a few days ago, if I disarm the system via SHM, the alarm system does not disarm. Arming via SHM works fine. Webapp and libraries are both up to date. Any suggestions?

When trying to add the Virtual Motion Sensor from the repository I get the following message:

Updated 0 devices and created 0 new devices, 0 published (1 skipped due to errors)

I am able to add it manually, though. Doing so does not link to the repo and then will not update. You can change the repository that it belongs to but am unsure if it will update when needed.