Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support access-control-access-point-device device type #133

Open
chrissantry opened this issue Jul 28, 2024 · 2 comments
Open

Support access-control-access-point-device device type #133

chrissantry opened this issue Jul 28, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@chrissantry
Copy link

Is your feature request related to a problem? Please describe.
My residential apartment complex has implemented an alarm.com based gate access control system. Right now this requires use of a local dealer's alarm.com backed app to 'buzz' myself or a guest through the apartment complex gates and various other doors. Realise this is likely an implementation of a business grade alarm system but it would appear several residential apartment complexes in my area have employed the local Alarm.com dealer to do similar installations.

homebridge-node-alarm-dot-com is able to log in to the account I have been allocated but does not generate a HB accessory for any of the available devices.

[28/07/2024, 12:02:26] [Apartment Complex Gates] Initializing Alarmdotcom platform... [28/07/2024, 12:02:26] Loading 13 accessories.

Describe the solution you'd like
It would be great if this alarm.com accessory type was supported as Lock accessory (or perhaps a momentary switch would be better)

Additional context
This is how the devices appear in the https://www.alarm.com/web/api/devices/accessControlAccessPointDevices route:

{ "id": "NNNNNNNNN-NNNN", "type": "devices/access-control-access-point-device", "attributes": { "managedDeviceType": 1, "state": 2, "desiredState": 2, "canBuzz": true, "canLockUnlock": false, "readerAntiPassbackEnabled": false, "apbDelay": 0, "twoPersonAccessEnabled": false, "hasMiwaLock": false, "twoPersonAccessSupported": false, "hasState": true, "canBeRenamed": true, "canBeDeleted": false, "canAccessWebSettings": true, "canAccessAppSettings": false, "webSettings": 505, "canAccessTroubleshootingWizard": false, "troubleshootingWizard": null, "addDeviceResource": 0, "canBeAssociatedToVideoDevice": true, "associatedCameraDeviceIds": {}, "macAddress": "", "manufacturer": "", "isAssignedToCareReceiver": false, "isOAuth": false, "isZWave": false, "supportsCommandClassBasic": false, "isMalfunctioning": false, "isZWaveWakeupNode": false, "unitSupportsRemovingWakeupNode": false, "primaryAssociatedDeviceIds": null, "canBeSaved": false, "canChangeDescription": false, "description": "Front Gate", "deviceModelId": 3315, "canConfirmStateChange": true, "canReceiveCommands": true, "remoteCommandsEnabled": true, "hasPermissionToChangeState": true, "deviceIcon": { "icon": 408 }, "batteryLevelNull": null, "batteryLevelClassification": null }, "relationships": { "system": { "data": { "id": "NNNNNNNNN", "type": "systems/system" } }, "stateInfo": { "data": { "id": "NNNNNNNNN-NNNN-N", "type": "devices/state-info" } } } }

A 'buzz' event generates a call to the following route:

https://www.alarm.com/web/api/devices/accessControlAccessPointDevices/NNNNNNNNN-NNNN/buzz

with the following content

{"statePollOnly":false}

Very grateful for any consideration of this feature request!

@chrissantry chrissantry added the enhancement New feature or request label Jul 28, 2024
@chase9
Copy link
Member

chase9 commented Jul 31, 2024

Very interesting. Thank you for providing such an in-depth issue! Am I assuming correctly that state represents if the door is unlocked? Would it be reasonable for this to be represented as a lock in HK where the unlock motion sends a buzz and makes the lock appear as unlocked for x seconds?

@chrissantry
Copy link
Author

Thanks for the response!

It would appear that 2 is the 'temporary unlock/buzz' state. It would appear there is also a lock/unlock method that would hold the door in state but "canLockUnlock": false does not expose this route to me.

I think your reasoning that this should be a HK lock representation is sound (I have hacked together a POC in Python and homebridge-script2 with hardcoded credentials and routes that presents this as a switch, but this probably isn't ideal).

Note, the way the system is configured in my apartment complex means that the 'default' system is empty (no idea why) so I have to send a POST to web/api/systems/availableSystemItems/{systemId}/selectSystemOrGroup before sending the /buzz request. I realise this puts us into Issue #20 territory which I note is a closed issue. This is a fairly newly configured system so perhaps the configuration will get cleaned up to a single system (since the second system is redundant at present).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants