Status not correct on restart, always initializes to off / disarmed

[dkerr64]

On startup the plugin assumes that the alarm is in off state (disarmed)

This is easy to reproduce, arm the alarm (from either the alarm panel or from Homebridge / Homekit). Note that the status in Homebridge/Homekit now correctly reflects that the alarm is armed. Now restart homebridge (or just the child bridge that this plugin is running within). Now note that the status in Homebridge/Homekit shows as off / disarmed.

This is not correct and means that automations that depend on correct alarm arm/disarm status cannot be relied upon. When the plugin starts it needs to query the envisalink and establish the current arm/disarm state.

I have not tested... but the state of any contact sensors should also reflect actual state and not assume closed when the plugin starts.

[dkerr64]

Problem is in partitionAccessory.ts where the code is not handling 'troubleledoff' status and is assuming that any unrecognized status means that the system is disarmed. Debug log shows the system correctly set to armed state, then handling of troubleledoff wrongly sets it to disarmed.

[1/28/2023, 9:47:38 AM] [homebridge-envisalink] Partition 11 is Armed
[1/28/2023, 9:47:38 AM] [homebridge-envisalink] Inside partitionUpdate: {
  "evtType": "partitionUpdate",
  "partition": 1,
  "code": "652",
  "status": "armed",
  "armMode": "stay"
}
[1/28/2023, 9:47:38 AM] [homebridge-envisalink] Restoring existing partition accessory from cache: Home
[1/28/2023, 9:47:38 AM] [homebridge-envisalink] Setting accessory details for zone: {
  "name": "Home",
  "number": 1,
  "enableChimeSwitch": false,
  "chimeCommand": "0711*4",
  "pin": "1234",
  "status": {
    "shortCode": "652",
    "longCode": "652",
    "description": "Partition Armed",
    "text": "armed",
    "action": "updatepartition",
    "verbSuffix": "is Armed",
    "mode": "stay"
  }
}
[1/28/2023, 9:47:38 AM] [homebridge-envisalink] Partition 1: armed, mode: stay.
[1/28/2023, 9:47:38 AM] [homebridge-envisalink] Setting current state to 0
[1/28/2023, 9:47:38 AM] [homebridge-envisalink] Setting target state to 0
[1/28/2023, 9:47:38 AM] [homebridge-envisalink] Home is Armed
[1/28/2023, 9:47:38 AM] [homebridge-envisalink] Partition 2 is Busy
[1/28/2023, 9:47:38 AM] [homebridge-envisalink] Trouble LED of Partition 1 is OFF
[1/28/2023, 9:47:38 AM] [homebridge-envisalink] Inside partitionUpdate: {
  "evtType": "partitionUpdate",
  "partition": 1,
  "code": "841",
  "status": "troubleledoff"
}
[1/28/2023, 9:47:38 AM] [homebridge-envisalink] Restoring existing partition accessory from cache: Home
[1/28/2023, 9:47:38 AM] [homebridge-envisalink] Setting accessory details for zone: {
  "name": "Home",
  "number": 1,
  "enableChimeSwitch": false,
  "chimeCommand": "0711*4",
  "pin": "1234",
  "status": {
    "shortCode": "841",
    "longCode": "841",
    "description": "Trouble LED Off",
    "text": "troubleledoff",
    "action": "updatepartition",
    "verbSuffix": "is OFF"
  }
}
[1/28/2023, 9:47:38 AM] [homebridge-envisalink] Partition 1: troubleledoff, mode: undefined.
[1/28/2023, 9:47:38 AM] [homebridge-envisalink] Setting current state to 3
[1/28/2023, 9:47:38 AM] [homebridge-envisalink] Setting target state to 3
[1/28/2023, 9:47:38 AM] [homebridge-envisalink] Home is OFF

[dkerr64]

See pull request #213

[dkerr64]

Thanks for taking my pull request. I have installed the beta version and look forward to when it becomes mainline.

[dustindclark]

I've noticed several instances on the beta version where disarming the panel is not updating the state in HomeKit. I don't see any associated logs until I try to disarm again in HomeKit. Are you able to recreate this behavior?

[dkerr64]

I've noticed several instances on the beta version where disarming the panel is not updating the state in HomeKit. I don't see any associated logs until I try to disarm again in HomeKit. Are you able to recreate this behavior?

I do not see this. Arming or disarming from any of my panels is working reliably for me. There is a 60 second delay on arming (exitdelay) before the state changes in Homekit, but that is expected (it would be interesting to try an handle that by setting target state).

If you turn on debug/verbose logging then you can observe all the messages coming in from envisalink. See if that gives you any clues.

I have observed Apple Home app getting out-of-sync with homebridge from time-to-time. Does not seem to be related to any one plugin and I have not seen it with envisalink. But things can get messed up for some reason, especially if another plugin is slow to respond (I run envisalink plugin, and many others, in their own child bridge -- that helps).

[ericanderson]

Hello. I have updated to the beta to fix the issues with the system restarting and the PR referenced/beta did indeed resolve that. I also attempted to turn off at the panel and observed homekit updating correctly, like dkerr64. Cannot reproduce issue raised by you @dustindclark.

[readylmay]

#181 comfirmed resloved. I am not seeing any inconsistency in status now. Thank you.