search

home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
69.74k stars 28.91k forks source link

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

Open andornaut opened 3 weeks ago

andornaut commented 3 weeks ago

The problem

Envisalink integration + alarm-panel card displays keypad unnecessarily.

Expected behavior (core-2024.5.5 and earlier):

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

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[bot] commented 3 weeks ago

envisalink documentation envisalink source

madsci1016 commented 3 weeks ago

Can confirm the issue.

Chewbucka commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

I just reverted all my automations to not specify a code and they do still work since I have a code specified in the configuration.yaml.

I would still like the ability to not specify a code when arming, but require a code when disarming when the UI is used.

On Tue, Jun 11, 2024, 21:11 Bill Porter @.***> wrote:

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?

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/119443#issuecomment-2161969224, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALKNBMADSLXGDRXA3KKVPP3ZG6U5DAVCNFSM6AAAAABJFLAD4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRRHE3DSMRSGQ . You are receiving this because you commented.Message ID: @.***>

jypsilantis commented 3 weeks ago

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 commented 3 weeks ago

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

ausfas commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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.

shawnhaywood commented 2 weeks ago

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

shawnhaywood commented 2 weeks ago

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

sixdollarman2nd commented 1 week ago

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 commented 1 week ago

I switched to the new one and it works better. No more configuration.yaml code needed after you migrate the first time. No keypad pops up when you have the code saved.

On Wed, Jun 26, 2024, 08:43 sixdollarman2nd @.***> wrote:

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...

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/119443#issuecomment-2191736736, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALKNBMCDOTP37D7P5APFDVLZJLAPRAVCNFSM6AAAAABJFLAD4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJRG4ZTMNZTGY . You are receiving this because you commented.Message ID: @.***>

tivo65 commented 1 week ago

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 commented 1 week ago

Keep all you existing configuration until after you run the new plug-in for the first time. After all the settings are imported, you can remove them from the configuration.yaml file.

You also have the option to create bypass switches which are very helpful. In addition, you can easily toggle the chime now.

On Wed, Jun 26, 2024, 11:51 tivo65 @.***> wrote:

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.

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/119443#issuecomment-2192195422, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALKNBMEKZONNF2HBTKXHKBTZJLWQZAVCNFSM6AAAAABJFLAD4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJSGE4TKNBSGI . You are receiving this because you commented.Message ID: @.***>

sixdollarman2nd commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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