I know this is likely to get some facepalms here. But how on earth do you configure this to actually arm your system? I had added it to my system and if I go into the driver I can arm and disarm the keypad. I can even activate the siren. I added a code using the lock manager as well. But when I press the buttons to arm on the keypad, it does nothing. if I type the code, nothing happens.I have searched in the forums and I have can't find any clear answers.
I have a DSC alarm with Envisalink 4 , I added this keypad to HE and I want to arm and disarm the DSC using this keypad. Im clearly missing some basic set of instructions here. Can anyone point me in the right direction?
Do you have some kind of integration between DCS and HE.
I use HSM and when setting up the Arming options you have the ability to select your keypad device.
As far as DCS goes I would think it would need some kind of integration with HE and in that integration it should ask what keypad devices to link to.
@mavrrick58
Not sure what the new stuff broke but I can't arm my system tonight with this new update. Rolled back to my driver and everything works great again.
The old version can be found using the history button on Github for anyone who needs it until the updated version can be debugged.
Thanks
1 Like
This is the basic expected usage workflow of the keypad. A code is always required to disarm.
I can’t use it either way. With or without a code, nothing happens. Wonder if it’s a new firmware issue???
I responded to you in a different thread. I suspect your problem is similar to why my updates broke @bptworld Safety Net application. Can you go into the integration app details and post what it is subscribed to on the keypad.
I currently have nothing subscribed to the keypad. I am currently focused on simply getting activity in the log from the keypad. Currently only sending commands seems to work. I can generate a key code and everything just fine. But keypresses on the keypad do nothing except beep boop bop. Basically the keypad functions as a siren and a notifier of the hsm state only (the keypad will arm and disarm when I connect to hsm and arm or disarm hsm) Zero input capability on the keypad itself.
Is the keypad added to HSM as a arming device.
The physical button presses send and event that HSM subscribes to. If HSM isnt setup to use it properly physical key presses wont do anything.
Sorry,, it didn't break any app but rather the Keypad itself isn't working correctly. It won't go into 'Arm Home' when pressing the 'Arm Home' button. The keypad itself should still work regardless of what it is trying to control.
I haven't had time to look at your changes yet, hopefully I can this afternoon.
1 Like
It looks to me that the changes are dependent on certain behavior embedded in HSM, e.g. the driver sends the armingIn event, which starts the countdown in HSM, then relies on HSM to send the armedXXX event (XXX is Home, Away, etc) and callback to the keypad when the countdown completes.
Not sure of the best way to handle both cases (with/without HSM) - one option is another preferences toggle on the device side to "Use HSM" (which would take the new logic routes)
That tends to be how I have seen these setups work in the past.
Generally you have a device state that the security app is subscribed to to trigger it to update. In this case that is the armingIn event. Then the security app calls the standard armHome, armAway, and disarmed commands to send information to the keypad. It is all about what is initiating the update. In theory as long as everyone agrees that armingIn is a good event to monitor for the keypad initiated event then anything can use it.
The HSM specific code are the lines with the line below. It is scattered throughout the code to tell hsm to arm certain states.
sendLocationEvent (name: "hsmSetArm", value: "armHome")
I will run back through my regression testing to verify it is still working and i didn't somehow screw something up when getting it into github for the pull request.
One possible option would be to change which of the two redundant calls to comment out. Right below the armingIn send event is a another command which just calls the armHome, armAway, or disarm commands in the driver. I commented that line out, but possibly the answer is to switch it.
I just tested the Armed/Home button and it worked fine in my setup with HSM.
Agree, it works fine with HSM - but your changes do not fully arm the keypad without HSM (or some other app performing the countdown/final arming).
Previously the driver performed those functions in addition to HSM, causing the duplication you observed (but also allowing it to operate independent of/without HSM) - this latter item is what is now broken for other users.
Without spending some more time testing/tinkering, I can't really declare the best way to handle both cases
I am looking at the driver right now thinking about the changes I made. I may have a solution for what you are talking about. Here is my concern though. If the keypad isn't being told what state it should be in by the security software, what is really maintaining the record. My point above was that any application can send the event to the keypad and tell it to arm to a state. The armHome, armAway and disarm commands are not just for HSM, but for anything interacting with the device. Why wouldn't they tell the keypad what state they are in after arming.
I believe some folks currently use the driver itself as that "security software" - i.e. they send an "Arm" command and want everything else to just happen.
I get your point - perhaps there's an argument to be made for keeping the two separated as Driver and App - just trying to fill in the gaps that some people's use cases don't currently have both.
1 Like
Biggest thing to NEVER do when updating a driver... Don't take away functions that already work. Adding new features is great but only if it doesn't break anything that already exists. Also, remember, this has to work with multiple keypads, not just one.
I'm going to roll back the Github until it's fixed.
Thanks
edit:
1.2.4 - 08/01/22 - Rollback to working version
So after thinking about this a bit I think this issue is being triggered by the fact that the physical button presses are depending on the HSM to respond and send the status back to the keypad to update states.
Fortunately I think with some slight tweaks the code I submitted is still useable. I am testing a driver update now were all i have basically done is swapped the action from the physical button press from the armingIn to simply running the armHome, armAway, and disarm commands. Then a few tweaks to the new code in each of those commands seems to successfully kept the calls to a minimal level for each action. I will run this updated code for a while and see how it goes. If it continues to work fine I will create another pull request.
1 Like
Just for giggles I went ahead and removed my keypad from HSM. I tested it without HSM setup and it worked. One problem though. This driver has always had several entries of the command shown below. That command means it is still controlling HSM regardless if it is configured to do so.
- sendLocationEvent (name: "hsmSetArm", value: "armAway")
I'm using HSM and RM with multiple keypads. I can beta test your code if you'd like.
Thanks i am actually starting to wonder if i should try to just fork and go our own way so that we can have it properly use the subscribed event for everything. I think trying to make the panel work as it's alarm may be problem. This would also mean I wouldn't keep breaking bptworld's driver with the functionality he has set it up to do. It may be good for him as well as it may give this driver for flexability to not worry about HSM and needing it's commands everywhere.
