@bptworld and @jkister is there any chance folks would integrate this with two different solutions like HSM and something else for security at the same time.
I have tweaked the driver again and here is a link to the results.
This new driver is basically a combination of the old driver and the changes I made earlier with a few more tweaks.
The Changes.
I added a switch in the configuration that is simply there for the purpose to flag if you want to use the device to drive everything, or do you want to allow applications to subscribe to armingIn event. This is specifically there for apps like HSM that want to treat this like a traditional keypad.
I removed all entries of sendLocationEvent (name: "hsmSetArm", value: "xxxXxxx"). These are used to control HSM from another application and really aren't well used in drivers from what I can tell. Every occasion where this was in if it made since i added the appropriate lines to trigger the armingIn event or the keypadUpdateStatus. This will enable any application to use this device as a keypad going forward.
The switches were added in various places needed so that these new routines could coexist with the legacy code. Simply put if you want the way the driver worked previously just turnoff the switch.
Last comment to expand on what I said in item 2 above. Those removals also include the legacy code so it wasn't completely untouched. Let me know if that causes a problem. The idea being for HSM if you want to integrate with that app or really any app they should use the event based method of integration.
I am also would also like it if we had a better way to describe what the switch does. I just couldn't think of something better at the moment.
I changed over to your driver and flipped the switch on. All my stuff seems to work the same as it used to (20 min usage).
The button should default to on since anyone upgrading to this version could have their previous behavior broken.
I re-read your initial issue --and am curious-- how are you using HSM /without/ the button enabled?
If I use your updates to the driver (with the disabled button) with HSM, arming works from the keypad (including keypad sync) but disarm (via keypad+device page button) doesnt work.
I have corrected the issue with Disarm. The disarm route only had a command to trigger when it the event switch was activated. Removing that should allow that command to run regardless now.
I have corrected the issue with Disarm. Looks like I had one command isolated to only run with the new event driven code and it should of run reguardless.
This does highlight a problem/concern and question I have though. Should HSM work without being controlled by events. I would say it shouldn't really. It looks like i left the Arming events in the routine for the physical actions when the switch is turned off. I would argue that it shouldn't be, but it doesn't really hurt anything to be there.
I know it could be considered putting the geniee back in the bottle, but just because we can doesn't mean we should you know.
Are you using HSM or something else for delay. Has your code previously used the state.keypadConfig.armHomeDelay value for the delay or something else.
It is really strange because with the switch off should be running your code and bypassing all of my additions. I have also removed my keypad from HSM and tried arming and disarming it a few times myself. My ArmAway counts down and triggers fine, my arm home arms immediately as expected as it has never had a arming delay.
I found two copy/paste issues this morning in the armHome Routine that I have corrected. These were only for the new code. I still don't see what is causing the issue with your activation @bptworld. I have armed and disarmed mine multiple time with different delays. It just works every time.
I just noticed something though when testing. When testing the with switch off I don't get a Armed Home Message. What is app:9970 and what is it subscribed to on the keypad to know what it is doing. Does that application call armHome or armAway commands at times. It looks like your app does subscribe to the armingIn event as that is the only way it would get notified about the arming of the keypad with the swtich on.
Here is what I see just from the keypad during a successful arming of ArmHome with the switch off.
If the issue is specific to your Saftey.Net application can you provide me some details about how it works or maybe just a copy so i can try to make the driver work with it.
I just updated the driver again to add back in the one item I removed from @bptworld's code. Please try it again and let me know if this works for you @bptworld.
If this doesn't work I am at a loss without seeing your code for app:9970. I don't mind looking at it, but i don't think i can resolve this without looking at the logic it is following.
I think I have pieced together what is happing with your app. When you tested the app with the switch off initially the combination of the sendEvent and the armHome command created some strange results that ended up zeroing out the delay value. Then when you tested it with the switch on that carried over and caused that test to give unexpected results.
One thing that the logs you provided showed is that your app does subscribe to the armingIn event. This means you need to run your app with the switch on. It also showed that it called armHome after it saw the event. The delay event if that value didn't get screwed up is still handled by the driver.
Please test it again and run the "Set Arm Home Delay" command from the UI to ensure the value is set for what you want before testing. I have gone around in circles with modifying the driver trying to figure out what you are experiencing. Please download the latest copy from github to test with.
@mavrrick58 ,
Sorry, I still can't support your code. By trying to control HSM the way you are, it is limiting the use of the keypad to just HSM. This keypad can be used in many other ways.
1.2.6 - 08/05/22 - Adjusted for use with HSM. To sync keypads without using HPM, a separate app will be available in Bundle Manager (Ring Keypad Sync).
The "//Event HSM Subscribes too" was my additional comment as I was figuring out what does what. That is the command include in the original driver provided by bcopeland
I think you are confusing "device driver to app" communication with "App to app" communication. I have no doubt that between apps using the "sendLocationEvent" command is the way to do it. I developed and maintained a app called ADT Tools for a few years in Smartthings and that is exactly how the integration worked there with SHM. But devices drivers really should be focused on updating their own attributes and states. Not sending any commands out for applications. By using the sendEvent command and updating the "armingIn" state any application can subscribe to that attribute on that device and know when the device is starting to arm. I believe they can also decipher the data values and then react accordingly.
Nothing about my code change is HSM specific. If anything it is removing HSM specific code. That said there is nothing preventing a app from subscribing to the location event for HSM arming regardless of whether HSM is installed. That is why the sendLocationEvent works. The problem with using it is that it leads to redundancy that is causing extra calls and creates conditions with HSM that makes it unreliable to use for triggers.
The most recent changes disable the ability to control the alarm state from the device page in the HE UI. You either have to do it from the keypad device, or from alarm app now.
Is this something you'll be figuring out how to do soon, or is this something that's intended going forward?
I see how the UI makes the keypad change status but doesn't change HSM. Doesn't make sense to me if this is the intended behavior. Unless you're expecting to set up some RM rule to monitor the keypad status and change HSM appropriately ? But then having a trigger for 'X keypad was armed' will trip when physical buttons are pressed, even though the physical button presses already change HSM. hmm.
Appreciate the work being done. Did I miss if there was created a set arm mode light config button so we can set it be on (never, set time amount, all-the-time) as described in the manual listed above on Page 9 of the 12?
Also, should I be able to arm disarm from the keypad? So far it does not work for me. I can get status to change from HSM and reflect on keypad, but not the keypad to change HSM status. Even with the toggle set to be able to arm without entering code.
@bptworld are you using 1.2.6? it seems to work for me except for arm/disarm via the device page UI (it changes the status of the keypad but does not change HSM).
wondering if i should go back to 1.2.4 until that's fixed or some good solution
The delay isn't working...
