Open chrissantry opened 3 months ago
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?
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).
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!