@bcopeland thank you very much for looking into this. 
1 Like
No problem.. It won’t be until tomorrow though.. I’m tied up tonight..
I don't use HSM.
Going from memory, since I inserted the refresh() workaround in all of my RM rules that interact with it and haven't fiddled with it much since...
Mine beeps indefinitely when I arm it. This is true when I arm via the keypad or when I execute the arm commands in RM (which I assume take the same codepath in the driver).
I am pretty sure that the behavior is the same for both arm home and arm away, but I am not 100% certain of that. I could test again to confirm that, if others have difficulty reproducing the issue for further characterization and debugging.
The refresh() workaround felt hacky, but it worked for me and I didn't dig deeper to try to really try to figure it out.
Keypad code
1 Like
@anon61068208 I have tried this deiver but there is one problem with this driver when using with Xfinity keypad. If you arm night, the light will blink at the arm night for a few times first and then end up with arm home light. If motion is detected, the arm home will light up although HSM is still at arm night. This causes confusion in my house since my arm night and arm home are significantly different. If you go through the previous posts you will see that people who use the XHK1b version (Xfinity version of the Centralite keypad) have this problem all along.
Have you tried the Centralite Keypad driver?
@Ryan780 yes, that is when the keypad beeps nonstop in the arm night mode. (only arm night is executed using anything other than the keypad.
Do you have an arming delay for Night mode? If so, why? You don't need an exit delay for night mode.
No arm delay or exit delay.
Same problem here. Any solutions? I can send a Keypad to Hubitat HQ if that would help since I really prefer stock drivers.
No, I have not received any update or solution. It annoys the hell out of me. The battery also runs out in about 8 months due to this.
Could never get this to work and it was super annoying. I never really know how to formally file a bug in these cases. Do I contact support? Workaround was to install the Nyckelharpa App and keypad device driver:
Tusen tack @arnb 
2 Likes
No. Not a reply from HE and my offer to send them a free keypad, and the Nyckelharpa driver has been working fine so oh well... HE should just remove their buggy driver since it's not really useful with the beeping.
@bcopeland @mike.maxwell
bump up this thread. I recently started to use this device, and got random beeping as well.
also the battery has been forever 100%.
It has 4 AA Batteries, I don't think the raw value/10 is volt.
[info]Centralite Keypad battery is 100%
[dev:250]2021-04-09 07:29:27.848 pm[debug]getBatteryResult: 68
other info
- endpointId: 01
- application:
- driverVersion: 1.0.3
- model: URC4450BC0-X-R
- manufacturer: Universal Electronics Inc
Thats not one of the models that we have tested compatable.
It's not possible for us so support every device, particulary those that aren't that common or are very much vendor specific.
So it's unlikely that we will provide a driver for this device, but there's nothing preventing the community from doing so.
My Nyckelharpa app with the required Centralite_Keypad driver supports the UEI keypad.
For the record: the Centralite_Keypad driver requires the Nyckelharpa app and does not work directly with HSM, however the app functions as an extension of HSM.
As @mike.maxwell mentioned, it should be a relatively easy task to make a standalone UEI driver by combining the UEI logic from my keypad driver with the system provided Iris V3 sample driver available on Github. (I have no plans to do this. Also the Iris V3 is "fugly" hardware and the driver reflects this issue, not the code, but the gyrations needed to support the V3).
2 Likes
