@kutoroff Yes, a restore would also fix it (obviously, the backup needs to be from before the app upgrade was done). One thing I've learned when dealing with custom apps and drivers on HE is to always do a backup before I update anything. I've been bitten too many times by bugs, and the HE restore process is pretty rock solid. I usually use the 'Create new backup and download locally' option which only takes a few seconds, but can save hours of frustration. That way, I don't lose anything I was working on since the last backup was done. One thing I love about HE is the developer community, but we're all humans and prone to errors. Having an 'undo' button is handy.
Thanks,
I already did the restore and as you say, the HE restore option is solid and brought me back to Jan 31 when I made my last HE change and saved it.
I'll update VK in a few days. I just moved my Konnected Pro board to POE and now I am removing the old keypads before I remove the legacy alarm board.
I'll be updating VK soon,
Thanks for the work on it, It has been a fun project to set up and use.
Cheers,
Steve
1 Like
Virtual Keypad
V1.0.16: 2021-02-16
- added support options to child app for getting a summary of versions and keypad settings to help troubleshoot issues
open your child app from the app page:
Then at the bottom of the child app, you can see the child app version, and the Keypad device version. You can also press the button to get a text output of your settings to easily copy/paste into the thread for support.
This should greatly help track down these issues that come up under our differing use cases.
I updated to v1.0.16 and from what I can tell, everything is working. I can arm/disarm/cancel without issues. I also fixed the chime, but I think that was something on my end. The device was a button in the rule, and it just wasn't working, but when I changed it to a switch, it fires every time (yay!). Thanks for the quick code generation. I'm more of a hack when it comes to programming, so I'm enjoying seeing the changes and how they affect the devices in HE. BTW, I'm going to hit you up on another thread about your dashboard. I got a question about how you did your HSM tile. Many thanks!!
Excellent.. good to hear someone else's setup is working 'normally' now on 1.0.16 as I was not able to reproduce some of these errors on my end.
and ya, remember, the button commands are for inputs, and the switches are to trigger outside events to try and keep it consistent.
Let me know if any issues come up or if there are more features you would like. Happy to keep adding features that are in scope to this project (and hopefully wont be breaking it again in future updates like this last week).
hello folks. longtime lurker. generally able to solve things myself with some research and persistence (which is the way I like it)...but. have been messing with virtual keypads to control multiple locks (kevo convert zwave and august pro zwave) - initially using real keypads. thats been working consistently to the point that I am now letting kids going to and coming from school use them as primary access to the house.
now. I have added the virtual keypad from @mbarone using nyckelharpa from @arnb -- thanks to both of you. while puttering about, found i preferred the css/formatting from @arnb. somewhere along the line I seemed to have messed up the feature that resets the input display after entering the code and hitting one of the arm/disarm buttons.
everything still works, and i can just hit the clear button, but seems a bit less elegant.
been scouring for the code that resets the inputdisplay after entering code but can't find it.
thanks in advance for what I presume will be a simple (and apparently easily overlooked) answer.
Hey @steevm,
just to confirm, the customization was only on the dashboard using css correct? Or did you modify any of the virtual keypad code?
Can you enable debug logging on the virtual keypad device and also the child app that configures the keypad.
Then open the log window and run through some pins/commands on the keypad and let me know if any errors come up in the logs.
Also, if you scroll up a few posts, there is a gif that shows you how to copy the settings and version info from the child app, and paste it here so I can see how you configured your keypad.
There should be a few second timeout after a successful command before the input display resets.. ill take a look and see if I can find an edge case where it wont reset.
Also, after 20 or 30 seconds after any input, the input display should reset if no other actions happen. Is this still working for you?
Just tried my Virtual Keypad and Disarm is not working. The Away, Night and Home arming buttons function normally. I've not changed this since it was initially tested, so I'm unsure what is occurring.
Update: I have the keypad set to ignore/not use pincodes for arming. Disarm requires a pin and pin code verification seems to be failing.
Failing line 154
state.alertOnFailedAttemptsCount = state.alertOnFailedAttemptsCount + 1
Have a bunch of these errors in the log
Using Virtual Basic Keypad driver 0.0.2
I can confirm that mine is working, but I'm on the latest version of VK.
Virtual Keypad Child - V0.0.8
Virtual Keypad Device - V1.0.16
Virtual Keypad Manager - 0.0.4
@mbarone has made a few changes over the past couple of weeks to support some new features, so you may want to try upgrading (download a backup first of course). That may remedy the issue.
Virtual Basic Keypad Driver remains at V0.0.2
https://raw.githubusercontent.com/michaelbarone/hubitat/master/drivers/virtualBasicKeypad.groovy
the Virtual Basic Keypad has not been updated (as you pointed out) since 0.0.2, so nothing should have changed on this end. Might be due to a platform update on hubitat, and I may have fixed the issue on the main Virtual Keypad without realizing it when I did the recent updates.
That error is only an issue if you are trying to use the alertOnFailedAttempt trigger. If you go into the Virtual Basic Keypad device and save the preferences, it will create that state, and the error should go away. I should build a check in to set the state variable if it doesnt exist, but it will properly get created in the updated() function when you save the preferences.
Are there any errors in the log when it comes to pin/disarm issues?
Ah, my bad. I didn't catch that you were using the Basic Keypad.
Saving the device's preferences eliminated the error. However, it always gives an 'Input Denied" message when disarming.
Then I noticed I no longer had pincodes set for the device likely causing the "input Denid" for a bad pin.
Attempting to set a pin code always throws the following error
Yes, this is a known issue with setting new codes from the device itself. This started with the 2.2.4 update from hubitat. The issue is in the keycode capability, the input variables were re-arranged to have the "name" entry first, but in the actual function that sets the code, it expects this order: setCode(codeNumber, code, name = null).
For now, using 'lock code manager' will set codes properly on the keypad devices.
@bravenel Im not sure who on the hubitat team to direct this to.
There is additional information about this starting in this post of this thread:
Hmm, it looks like there is a space between the 1 and 2 in your error line.
Line 141 basically compares the code you entered against all "code" values in the lockCodes array. It will convert them to an Integer first before comparing to make sure its not a string != number issue.
But it looks like an error is thrown because it cant convert the blank space to an integer:
"1 234".toInteger()
When you input the code, it should show in plain text in the "State Variables" area of the virtual basic keypad device. Is this showing your correct input without spaces?
I noticed that on the error message, thought it was odd.
Did the following on the virtual keypad.
- clicked the Star icon in lower left to clear the input area
- clicked 1234 (did not click any arming code)
- looked state fields and it is 1 234 with a space
- So I tried 4567 and that is OK
- edited the dashboard definition for the 1 key removing the space following the 1, that fixed the 1space issue
- Retried arming and disarming and all is now working as expected.
Thank you for your help and assistance.
Happy to help, glad that was an easy fix and not something I bumbled in the code.
One of the downsides of this addon is the button commands need to be exact and are the end users' responsibility to setup properly on the dashboard.
I should add better debug logging to help with troubleshooting as there are many more ways to use the keypad than I use daily, and some edge cases dont get tested by me as much as they should.
Updated my virtual keypad definition on Github. @steevm please verify your 1 key definition is 1, not 1space.
that was easy...working as elegantly as can be now.
1 Like
