ufodone
commented
4 weeks ago The disarm is likely failing BECAUSE it's trying to use your HA password - which will be longer than the EVL will accept as an alarm code. That's probably what's triggering the checksum failure.
HA's alarm control panel entity's disarm functionality accepts an optional code parameter. If it is not provided, envisalink_new will use the code you configured in the setup. It's possible that whatever you are using to trigger the disarm may be erroneously passing your HA password instead of a code. This integration certainly does not use your HA password for anything (nor do I know how it would even get access to it).
You could trying testing disarm using Developer Tools->Actions to issue a Alarm control panel: Disarm action. If you already have your alarm code setup in the envisalink_new configuration you don't need to pass anything for the code parameter.
The yaml would look something like:
action: alarm_control_panel.alarm_disarm
target:
entity_id: alarm_control_panel.home_alarm
data: {}
robin-ellins
I have set up Envisalink_new using HACS and configured it to control my DSC Alarm.
I am able to arm the alarm and change alarm modes (stay / night / away) from HA. Not able to disarm the system.
Turning on logging I discovered that it is trying to disarm the system with my HA password, not the numeric code entered into Envisalink_new. Am I paranoid or is Envisalink_new trying to steal my password?
Here are is a snippet from the logs:
_2024-09-06 17:48:58.244 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] calling handler: handle_command_response for code: 501 with data: 2024-09-06 17:48:58.244 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.dsc_client] Issued command resulted in a checksum failure. 2024-09-06 17:48:58.244 WARNING (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command '040 **MY HA PASSWORD IN CLEAR TEXT**' failed; retry in 3.2 seconds. 2024-09-06 17:48:58.244 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Invoking state change callbacks 2024-09-06 17:48:58.244 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] }--------------------------------------- 2024-09-06 17:48:58.244 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Waiting for data from EVL 2024-09-06 17:48:58.245 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command processor woke up. 2024-09-06 17:48:58.245 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Checking command queue: len=1 2024-09-06 17:49:01.446 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Checking command queue: len=1 2024-09-06 17:49:01.446 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Checking command queue: len=1 2024-09-06 17:49:01.446 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] TX > b'0401***************72' 2024-09-06 17:49:01.446 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Checking command queue: len=1 2024-09-06 17:49:01.450 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] {--------------------------------------- 2024-09-06 17:49:01.450 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] RX < 50196_Can someone please explain why this is happening and should I be worried? Also, how do I fix it to disarm the alarm!
Thank you.