search

tkleijkers / homebridge-visonic-powerlink3

MIT License
1 stars 3 forks source link

When arming plug in initially triggers disarm #12

Open witchdrash opened 2 years ago

witchdrash commented 2 years ago

This is something that is consistently occurring, if your system is disarmed and you arm it via home kit (not the panel or fobs) the plug in will initially trigger a disarmed state, this means any automations linked with disarm will execute, using our system as an example, to give you an example of the issues please consider the 4 automations that execute in our system:

  1. Alarm Disarmed Low Light

    • Trigger event: Alarm Disarmed
    • Trigger conditions: Lux less than 25
    • Turn on front & drive lights, set all to 100%

  2. Alarm Armed For Stay After 20:00

    • Trigger event: Alarm armed to home
    • Trigger conditions: Current time equal to or later than 20:00
    • Turn off all front, drive and garden lights

  3. Lower Outside Lights After 19:30

    • Trigger condition: Time is 19:30
    • Condition: Alarm Disarmed & Outside Lights On
    • Turn off garden lights, Turn off drive lights, Reduce front door lights to 25%

  4. Outside Lights On If Before 19:30 & Low Light

    • Trigger Event : Lux is less than 25
    • Trigger Conditions : Time is between 16:00 and 19:30
    • Turn on Outside Front Lights & Garden

So what should happen (and used to): 1 - 16:00 lights come on. 2 - 19:30 the garden lights switch off, the drive lights switch off and the front-door lights reduce, 3 - we arm the system at 20:30 all lights go out.

What actually happens: 1 - 16:00 lights come on. 2 - 19:30 the garden lights switch off, the drive lights switch off and the front-door lights reduce, 3 - We arm the system at 20:30 and home kit receives a system disarmed notice, this causes the front lights to return to full brightness and the drive lights to switch on, 4 - 30 seconds later home kit receives a system armed notification and all the lights switch off (most of the time)

Usually it's only a minor annoyance as the lights switch off, but effectively the front of our property flares to full brightness for 30 seconds before switching off, occasionally the automations appear to clash and the second isn't run requiring us to manually switch them off, although this occurs infrequently.

tkleijkers commented 2 years ago

Great automation :)

We have to find out why the disarmed state is triggered before arming and if this can be fixed. I will look into it when I have some time but I cannot promise that this is very soon.

witchdrash commented 2 years ago

Thanks, as I said not usually a major issue but an odd set of circumstance!

tkleijkers commented 2 years ago

I pushed a small update which might fix the problem. Please try.

witchdrash commented 2 years ago

Unfortunately I'm still getting the initial "Alarm was disarmed" notification.

It does seem to only occur when you first re-start home bridge or if the plug in appears to have been idle for some time, I'll leave it for an hour and see if it's only happening on initial homebridge start now, and see if the idle has been fixed.

witchdrash commented 2 years ago

Tried it a few times today, including just now as the final arm for tonight and it didn't send the initial notification, apart from the first arm after homebridge rebooted. Thanks for sorting this out

tkleijkers commented 2 years ago

I still see the 'old' status being pushed when changing the alarm status. So I don't think this is resolved.

witchdrash commented 2 years ago

Actually was going to come back and say I was wrong as I got it again this morning when turning off the alarm

tkleijkers commented 2 years ago

I think I solved it now. When setting the state, HomeKit directly requests the new state and because the update to PowerLink is still in progress first the 'old' state is returned to HomeKit and it takes some time before the new state is returned. To prevent this from happening I now return the 'requested' state to HomeKit while the change is still in progress.

EyalRotem commented 2 years ago

Hi, as of now- I still have this issue too. Was this fix pushed and released to the stable version? If not, how can I update to the version with the fix?

EyalRotem commented 2 years ago

I think I solved it now. When setting the state, HomeKit directly requests the new state and because the update to PowerLink is still in progress first the 'old' state is returned to HomeKit and it takes some time before the new state is returned. To prevent this from happening I now return the 'requested' state to HomeKit while the change is still in progress.

I'm not sure if the version that's in the npm is the latest, but i have 1.3.6 installed in homebridge and still encounter many times during arming/disarming a jump back to the previous state. when this happens i found that a line in the log appears - State was externally set to: home maybe it can help diagnose the issue, here a part of the log were i disarm using homekit, it disarms for a second, and then rearms:

[7/19/2022, 5:51:17 PM] [Visonic Alarm] Setting security system state to: off [7/19/2022, 5:51:17 PM] [Visonic Alarm] powerLinkStatus to set: disarmed [7/19/2022, 5:51:18 PM] [Visonic Alarm] Response from getUserToken HTTP call: [7/19/2022, 5:51:18 PM] [Visonic Alarm] error: null [7/19/2022, 5:51:18 PM] [Visonic Alarm] response: {"statusCode":200,"body":{"user_token":"xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"},"headers":{"server":"nginx","date":"Tue, 19 Jul 2022 14:51:18 GMT","content-type":"application/json; charset=utf-8","transfer-encoding":"chunked","connection":"close","x-frame-options":"SAMEORIGIN, SAMEORIGIN","x-xss-protection":"1; mode=block, 1; mode=block","x-content-type-options":"nosniff, nosniff","content-security-policy":"default-src 'self'; style-src 'self' 'unsafe-inline' https://*.googleapis.com; font-src 'self' data: https:; connect-src 'self' ws://visonic.tycomonitor.com wss://visonic.tycomonitor.com; script-src 'self' https://*.google.com https://*.googleapis.com 'unsafe-inline' 'unsafe-eval'; img-src 'self' data: https://*.gstatic.com https://*.google.com","strict-transport-security":"max-age=31536000"},"request":{"uri":{"protocol":"https:","slashes":true,"auth":null,"host":"visonic.tycomonitor.com","port":443,"hostname":"visonic.tycomonitor.com","hash":null,"search":null,"query":null,"pathname":"/rest_api/9.0/auth","path":"/rest_api/9.0/auth","href":"https://visonic.tycomonitor.com/rest_api/9.0/auth"},"method":"POST","headers":{"Content-Type":"application/json","accept":"application/json","content-length":104}}} [7/19/2022, 5:51:18 PM] [Visonic Alarm] body: {"user_token":"xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"} [7/19/2022, 5:51:18 PM] [Visonic Alarm] Got user-token: xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx [7/19/2022, 5:51:18 PM] [Visonic Alarm] Executing request https://visonic.tycomonitor.com/rest_api/9.0/set_state [7/19/2022, 5:51:18 PM] [Visonic Alarm] Setting status (1) [7/19/2022, 5:51:18 PM] [Visonic Alarm] Response from getRawState HTTP call: [7/19/2022, 5:51:18 PM] [Visonic Alarm] response: {"statusCode":200,"body":{"process_token":"xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"},"headers":{"server":"nginx","date":"Tue, 19 Jul 2022 14:51:18 GMT","content-type":"application/json; charset=utf-8","transfer-encoding":"chunked","connection":"close","x-frame-options":"SAMEORIGIN, SAMEORIGIN","x-xss-protection":"1; mode=block, 1; mode=block","x-content-type-options":"nosniff, nosniff","content-security-policy":"default-src 'self'; style-src 'self' 'unsafe-inline' https://*.googleapis.com; font-src 'self' data: https:; connect-src 'self' ws://visonic.tycomonitor.com wss://visonic.tycomonitor.com; script-src 'self' https://*.google.com https://*.googleapis.com 'unsafe-inline' 'unsafe-eval'; img-src 'self' data: https://*.gstatic.com https://*.google.com","strict-transport-security":"max-age=31536000"},"request":{"uri":{"protocol":"https:","slashes":true,"auth":null,"host":"visonic.tycomonitor.com","port":443,"hostname":"visonic.tycomonitor.com","hash":null,"search":null,"query":null,"pathname":"/rest_api/9.0/set_state","path":"/rest_api/9.0/set_state","href":"https://visonic.tycomonitor.com/rest_api/9.0/set_state"},"method":"POST","headers":{"Content-Type":"application/json","Session-Token":"xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","User-Token":"xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","accept":"application/json","content-length":33}}} [7/19/2022, 5:51:18 PM] [Visonic Alarm] body: {"process_token":"xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"} [7/19/2022, 5:51:19 PM] [Visonic Alarm] getCurrentState [7/19/2022, 5:51:19 PM] [Visonic Alarm] Response from getUserToken HTTP call: [7/19/2022, 5:51:19 PM] [Visonic Alarm] error: null [7/19/2022, 5:51:19 PM] [Visonic Alarm] response: {"statusCode":200,"body":{"user_token":"xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"},"headers":{"server":"nginx","date":"Tue, 19 Jul 2022 14:51:19 GMT","content-type":"application/json; charset=utf-8","transfer-encoding":"chunked","connection":"close","x-frame-options":"SAMEORIGIN, SAMEORIGIN","x-xss-protection":"1; mode=block, 1; mode=block","x-content-type-options":"nosniff, nosniff","content-security-policy":"default-src 'self'; style-src 'self' 'unsafe-inline' https://*.googleapis.com; font-src 'self' data: https:; connect-src 'self' ws://visonic.tycomonitor.com wss://visonic.tycomonitor.com; script-src 'self' https://*.google.com https://*.googleapis.com 'unsafe-inline' 'unsafe-eval'; img-src 'self' data: https://*.gstatic.com https://*.google.com","strict-transport-security":"max-age=31536000"},"request":{"uri":{"protocol":"https:","slashes":true,"auth":null,"host":"visonic.tycomonitor.com","port":443,"hostname":"visonic.tycomonitor.com","hash":null,"search":null,"query":null,"pathname":"/rest_api/9.0/auth","path":"/rest_api/9.0/auth","href":"https://visonic.tycomonitor.com/rest_api/9.0/auth"},"method":"POST","headers":{"Content-Type":"application/json","accept":"application/json","content-length":104}}} [7/19/2022, 5:51:19 PM] [Visonic Alarm] body: {"user_token":"xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"} [7/19/2022, 5:51:19 PM] [Visonic Alarm] Got user-token: xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx [7/19/2022, 5:51:19 PM] [Visonic Alarm] Executing request https://visonic.tycomonitor.com/rest_api/9.0/status [7/19/2022, 5:51:20 PM] [Visonic Alarm] Updating status (1) [7/19/2022, 5:51:20 PM] [Visonic Alarm] Response from getRawState HTTP call: [7/19/2022, 5:51:20 PM] [Visonic Alarm] body: {"connected":true,"connected_status":{"bba":{"is_connected":true,"state":"online"},"gprs":{"is_connected":true,"state":"online"}},"discovery":{"completed":true,"stages":11,"in_queue":0,"triggered":null},"partitions":[{"id":-1,"state":"HOME","status":"EXIT","ready":true,"options":[]}],"rssi":{"level":"good","network":"Unknown"}} [7/19/2022, 5:51:20 PM] [Visonic Alarm] State was externally set to: home [7/19/2022, 5:51:23 PM] [Visonic Alarm] setTargetState: 3