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.

Sign up for GitHub

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

Jump to bottom

Envisalink integration + alarm-panel card displays keypad unnecessarily #119443

Closed
andornaut opened this issue Jun 12, 2024 · 24 comments · Fixed by #125256
Closed

Envisalink integration + alarm-panel card displays keypad unnecessarily #119443

andornaut opened this issue Jun 12, 2024 · 24 comments · Fixed by #125256
Labels
integration: envisalink

Comments

@andornaut
Copy link

The problem

Envisalink integration + alarm-panel card displays keypad unnecessarily.

Expected behavior (core-2024.5.5 and earlier):

  • alarm-panel card does not display a keypad if envisalink.code is specified in configuration.yaml

Actual behavior (as of core-2024.6.0 to core-2024.6.2):

  • alarm-panel card does display a keypad if envisalink.code is specified in configuration.yaml

dashboard

Related to #118668

What version of Home Assistant Core has the issue?

core-2024.6.2

What was the last working version of Home Assistant Core?

core-2024.5.5

What type of installation are you running?

Home Assistant Container

Integration causing the issue

Envisalink

Link to integration documentation on our website

https://www.home-assistant.io/integrations/envisalink/

Diagnostics information

No response

Example YAML snippet

envisalink:
  host: !secret envisalink_host
  user_name: !secret envisalink_username
  password: !secret envisalink_password
  code: !secret envisalink_code
  evl_version: 4
  panel_type: DSC

Anything in the logs that might be useful for us?

No response

Additional information

Dashboard YAML:

type: alarm-panel
states:
  - arm_home
  - arm_away
entity: alarm_control_panel.home_alarm
name: Alarm
@home-assistant
Copy link

envisalink documentation
envisalink source

@andornaut andornaut mentioned this issue Jun 12, 2024
Closed
@madsci1016
Copy link

Can confirm the issue.

@Chewbucka
Copy link

I would add that in addition to the keypad appearing, the code_arm_required and code_disarm_required need to be exposed in the configuration.yaml so that we can control the behavior in the UI and any automations.

@madsci1016
Copy link

I would add that in addition to the keypad appearing, the code_arm_required and code_disarm_required need to be exposed in the configuration.yaml so that we can control the behavior in the UI and any automations.

All my automations prior to this mess have gone back to work as intended even though i never messed with my config or automations, so i never touched "code_arm_required" or the like. It's only the keypad on the card thats left as a bug for me.

Are your automations not working?

@jypsilantis
Copy link

jypsilantis commented Jun 12, 2024 •
edited
Loading

I have noticed this issue as well. In my case, the disarm control exposed by Homebridge to my HomeKit installation no longer works. I have configured the optrional "Code" tag in HomeAssistant's yaml file.

Up until recently, it has been possible to arm and disarm via Homekit and Homebridge. Now it is only possible to arm. Attempting to disarm via Homekit is silently ignored. If I observe the widget on Home Assistant, it remains armed until I manually enter a valid code via the keypad.

It is almost as if the Code tag is now being ignored, given that the keypad always appears on Home Assistant, regardless of the presence of a Code tag. I first noticed anomalies with Core v 2024.6.1

@Chewbucka
Copy link

Chewbucka commented Jun 12, 2024 via email •
edited
Loading

@jypsilantis
Copy link

Further to my last comment, I tried removing and reinserting the Code tag, and restarting the core followed by a couple of reboots of my Home Assistant server. The Homebridge path is now working as expected - it is possible to arm and disarm via HomeKit.

A similar sequence may fix broken automations that rely on envisalink.

There does seem to be some kind of issue, but my installation is now working again. However, the keypad still appears in Lovelace.

@tivo65
Copy link

tivo65 commented Jun 12, 2024 •
edited
Loading

Here is my scenario - updated to HA core Ver 2024.6.2. I am bridging dsc alarm from HA to homekit to arm and disarm alarm from iphone homekit menus. have automations that arm and disarm dsc alarm within HA. With the ha core update to 2024.6.2 all the above is working again. from homekit on iphone it properly arms and disarms. i have not changed any configurations or automations, bridging to homektit or configuration.yaml, meaning it is the same as when running HA 2024.5 and before. My outstanding issue is when I arm or disarm from my HA dashboard it prompts with a keypad , i just hit the green check and it works (don't enter any code).

from configuration.yaml
envisalink:
host: x.x.x.x
panel_type: DSC
user_name: xxxx
password: xxxx
code: "1234"
port: 4025
evl_version: 4
keepalive_interval: 60
#zonedump_interval: 30
zonedump_interval: 0
timeout: 10

@jaym25 jaym25 mentioned this issue Jun 13, 2024
Closed
14 tasks
@gjohansson-ST gjohansson-ST mentioned this issue Jun 14, 2024
Closed
20 tasks
@ausfas
Copy link

ausfas commented Jun 15, 2024

I don't want to see the key pad when my code is already set in the configuration file as it was before.

# Envisalink
envisalink: 
  host: 192.168.1.x
  panel_type: HONEYWELL
  user_name: !secret envisa_username
  password: !secret envisa_password
  code: !secret envisa_code
  port: xx
  evl_version: 4
  keepalive_interval: 60
  zonedump_interval: 30
  timeout: 100
  panic_type: Police
  zones:
    02:
      name: 'Zone 2'
      type: 'motion'
    03:
      name: 'Zone 3'
      type: 'motion'
    04:
      name: 'Zone 4'
      type: 'motion'
    05:
      name: 'Zone 5'
      type: 'opening'
    06:
      name: 'Zone 6'
      type: 'opening'
    09:
      name: 'Zone 9'
      type: 'garage_door'
  partitions:
    1:
      name: 'Partion 1'
    ```

@shawnhaywood
Copy link

I don't want to see the key pad when my code is already set in the configuration file as it was before.

# Envisalink
envisalink: 
  host: 192.168.1.x
  panel_type: HONEYWELL
  user_name: !secret envisa_username
  password: !secret envisa_password
  code: !secret envisa_code
  port: xx
  evl_version: 4
  keepalive_interval: 60
  zonedump_interval: 30
  timeout: 100
  panic_type: Police
  zones:
    02:
      name: 'Zone 2'
      type: 'motion'
    03:
      name: 'Zone 3'
      type: 'motion'
    04:
      name: 'Zone 4'
      type: 'motion'
    05:
      name: 'Zone 5'
      type: 'opening'
    06:
      name: 'Zone 6'
      type: 'opening'
    09:
      name: 'Zone 9'
      type: 'garage_door'
  partitions:
    1:
      name: 'Partion 1'
    ```

It appears this is already a known problem being worked on.

@andornaut
Copy link
Author

andornaut commented Jun 15, 2024 •
edited
Loading

This workaround works for me. It extracts the essential changes from #119557.

In homeassistant/components/envisalink/alarm_control_panel.py, replace:

        self._attr_code_format = CodeFormat.NUMBER

With:

        self._attr_code_format = None if code else CodeFormat.NUMBER
        self._attr_code_arm_required = not code

This Python module is located at the following path in the official Home Assistant Docker image: /usr/src/homeassistant/homeassistant/components/envisalink/alarm_control_panel.py

The location may vary depending on your installation method.

Hope this helps tide folks over until an official fix is released.

Here's an Ansible task to apply this workaround to a running Docker container.

@pergolafabio pergolafabio mentioned this issue Jun 17, 2024
Closed
@shawnhaywood
Copy link

shawnhaywood commented Jun 17, 2024 •
edited
Loading

Trying this fix on a non-docker install, but can't locate the file. Any one know where it's at?

@shawnhaywood
Copy link

Anyone looking for an alternate custom integration might enjoy this. Works great for me.
https://github.com/ufodone/envisalink_new

@sixdollarman2nd
Copy link

Just chiming in here to ask a question - what's going to happen to this issue?

From what I can ascertain, two different people put in commits to update the HA codebase, but both were rejected (?) because they didn't "align" philosophically what HA was striving to achieve?

So what are our options now? Do we need to go in and modify the codebase ourselves to make the keypad go away as a workaround, only to have it wipe out with each successive HA update?

I see someone posted a link to an alternate Envisalink integration. Does this one make the keypad go away and then some?

Having the keypad show up when I don't want it there is really undesired.

Thank you...

@Chewbucka
Copy link

Chewbucka commented Jun 26, 2024 via email

@tivo65
Copy link

tivo65 commented Jun 26, 2024

I also switched to the envisalink_new. Not sure why i had been putting it off. works great and gives you so many more entities to manage from. migration was pretty straight forward. you do need to install envisalink_new from hacs.

@Chewbucka
Copy link

Chewbucka commented Jun 26, 2024 via email

@sixdollarman2nd
Copy link

This is all great info about the new Envisalink integration. Is anyone promoting this or letting people know in the main HA forums?

This thread on github is a very specific corner case regarding the "old" Envisalink integration.

@Disgruntled-Duck
Copy link

Disgruntled-Duck commented Jun 26, 2024 •
edited
Loading

I made the switch to envisalink_new and love it so much. For anybody else making the switch (I think what people were eluding to above), after it is installed in HACS, don't add the integration through settings > devices & services. Just go right into your config yaml and rename envisalink: to envisalink_new: and then restart.

After making this change it will auto import all of your settings exactly how it was with the default envisalink and then you can remove the section from your config after. The only thing I had to do other than that was go through my automations yaml and do a find & replace for envisalink.alarm_keypress > envisalink_new.alarm_keypress

Highly recommend anybody on the fence to try it out. Don't think I will be going back unless something breaks. Thanks everybody that recommended it in this thread.

@sixdollarman2nd
Copy link

sixdollarman2nd commented Jun 27, 2024 •
edited
Loading

Just made the switch to Envisalink Refactored (aka envisalink_new). I used the configuration.yaml migration path.

Easy peasy. Everything still works. Most importantly (for me), the keypad annoyance went away.

Thanks to all those that chimed in, and particularly to ufodone for working on this integration. HA is not possible without the support of its many contributors...

@slampton
Copy link

I've migrated as well. It's a much better solution overall; I wish I knew about it sooner.

@patrickwasp

This comment was marked as off-topic.

Sign in to view
@isuee94
Copy link

isuee94 commented Aug 27, 2024

Can confirm this issue as well. Most alarm systems do not require a code for arming. The keypad should not be displayed unless needed by the alarm system. This needs fixed. Migrating to the envisalink_new codebase that is not part of the core should not be the solution.

@ausfas
Copy link

ausfas commented Aug 28, 2024

Absolutely 💯 agree with your statement.

@gjohansson-ST gjohansson-ST mentioned this issue Sep 4, 2024
Merged
19 tasks
@github-actions github-actions bot locked and limited conversation to collaborators Oct 4, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
integration: envisalink
Projects
None yet
Milestone
No milestone