Well, I went back to my code and everything works just fine.
If you want to start from scratch with Hubitat's original code, you can find it here
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.
Forget about 'my app', lol. It works just fine. This is about the keypads. They need to work independently of any app first.
Hopefully I can look at your new code tonight.
Thanks
1 Like
@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.
sendEvent(name:"armingIn", value: state.keypadConfig.armHomeDelay, data:[armMode: armingStates[0x0A].securityKeypadState, armCmd: armingStates[0x0A].hsmCmd], isStateChange:true) // Event HSM Subscribes too
'Event HSM Subscribes too', this is a very odd attribute to use as a trigger??
This is actually straight from Bruce on how to control HSM from another app:
"This is the line of Maker API that sets HSM status:
sendLocationEvent(name: "hsmSetArm", value: id.toString())"
I'm going to work on this today and see what I can come up with.
New version available...
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.
1 Like
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
Yes. It is being worked on but not getting anywhere with it.
Thanks
Not seeing the (Ring Keypad Sync) with your bundle manager. Am I missing something?
Doh! Found it. Thanks! I was looking in another place.
1 Like
@bptworld do you know if the announcement volume and siren volumes are correctly implemented? It seems no matter what volume I choose for announcements & siren, they are the same. Keypad tones work fine, but at volume "4" the keypad tones are significantly louder than announcements or sirens.
Any tips? Just getting around to setting up HSM and love that this driver works with HSM natively. Thanks again for all the amazing work on this driver.
Scratch that!! I had to disable the proximity sensor now it works fine. I guess pulling the air gaps couldn't hurt but as soon as I turned the proximity sensor back on poof.
NM the problem was on my end. I fixed it by disconnecting power to all repeating devices. Started working right away. Man ZWAVE Hurts! Air gaps are awesome BTW
I just bought 3 of these a few days ago. They get one way zwave communication. I can get them working temporarily if I mess around a lot. Maybe it's because they shipped with a new firmware not sure. Same problem if you use this driver or built in driver. They work perfect with Home Assistant so yeah I don't know. I've seen other closed posts on the forum with the same issue with no solution. No it's not a ghost thing or non s2. Might want to take it off the compatibility list. Video of the issues, I get it working around 4:00 set it to 4k so you can see
Few questions.
Are those the hubs right next to it. May want to seperate them by a little distance? Could you try seperating them by about 1m. It is my understanding to close can cause a issue.
Have you upgraded the Zwave radio to the latest firmware?
By chance do you have any zwave devices that do power reporting?.
The fact you can get it working on and off to me seems like either the device itself is locking for sone reason or there is a radio problem with communication. My keypad does lock occasionally, but they are few and far between.
1 Like
They normally sit in the server rack just threw them on the desk for the video. The've never been a meter apart lol everything else works really well. One runs my Zwave one runs zigbee.
I have plenty of wave devices that can power report but the reporting is turned off.
I agree but my zwave actually works really well. I could make a video of that but that be even more boring then this video. Trust me things happen instantly, well um instantly as zwave can be. The keypad is direct not using any repeaters and as you can see in the zwave log there's no weird traffic going on.
The zwave log reports some stuff. But may not show all wonkyness.
The Zooz zen25 is a great example of a device that is know for causing strange Zwave issues and not showing anything strange in the Zwave logs. Folks can turn off power reporting, pair it without security and it will cause issues.
1 Like
