Renaming envisalink_new to envisalink

[ufodone]

Hi all,

My original intent for this repository was to upgrade the stock envisalink integration in Home Assistant and contribute it back. While I think the integration is now in a good enough state to move back into HA, there have been some unexpected difficulties in getting the changes contributed back that will require a significant amount of time on my part which I unfortunately do not expect to have available in the foreseeable future. As a result, this integration will likely stay separate for quite some time (potentially indefinitely).

With that in mind, and given I've been seeing more people finding it and starting to use it, I've been considering renaming the integration back to just envisalink. I believe this will make adopting the integration much simpler as it should just require people to install it via HACS and restart HA. No more renaming things in configuration.yaml and having to get the exact steps done in the correct order.

But I realize that a rename will have an impact on everyone currently using and I still need to do an assessment of what that would mean. But in the meantime, I thought I'd poll everyone using it to get some feedback. Please vote for you preference and add any commentary. Thanks!

[rct]

Maybe there are things I haven't considered, but I think renaming the integration back to envisalink will be best in the long run.

The downside is that those who have taken to time to move over and test the updated integration will have some work to do if they want to get updates after you do the rename. But it shouldn't be that big of a deal, It won't be a breaking change until they pull in the update.

There are a number of potential benefits:

• It will be much easier for anyone who wants to switch from the bundled integration
• There will be less need for support resulting from mistakes made when switching the configuration over.
• It should help if at some point the updated integration does make it through the PR process to become part of hass core again.

EDIT: I forgot to add, Thank you for all the work you've done on this and the time you have put in to get the integration to where it is.

[larry-glz]

i’m willing to put up with some pain on my part to support the proper naming of this component. I’m ok with the switch as it seems use and maintenance will be simplified for the long run.

[greggitter]

For all the hoops most of us jump through to make HA work the way we want, I think some additional minor tweaks here are perfectly fine. I'm super grateful for all the work you did, and continue to do for us envisalink users. Thanks! :)

[sheyman1]

I'm extremely grateful for all the work you've put into this. I don't mind a little extra work for the greater good of the project. Thanks again for all you do on this!!!

[garyak]

I don't use HACS to manage critical components. If I have to tweak a few things, no problem. If using a similar name to the native component doesn't cause any issues, go for it.

[wptracy]

The stock envisalink integration in Home Assistant didn't work and it's unsupported.
https://community.home-assistant.io/t/envisalink-integration-cant-arm-disarm-from-control-panel-card/644081

I switched to envisalink_new, and it worked out of the box. Configuration was easy.

I'll stick to the HACS envisalink_new.

Lets keep the name invisalink_new, so not to confuse with the homeassistant load that doesn't work.

[djeuch]

I was trying for the past couple days to get the built-in working and stumbled on this one. It works perfectly! I have a EVL4 and a Honeywell Vista 20P and so far everything is looking good. Thanks for your work on this!

[sg1888]

I echo the comments made by others. Thank you for your efforts in getting the original integration fixed up. I did have an initial gripe that sensors couldn’t be assigned to areas (since they were entities and not devices), so I just made template sensors and hid the original sensor for the UI. Problem solved.

Been using this integration for a few weeks and so far so good!

[nickb24]

What is the latest on this discussion? I'm looking into migrating from the HA integration to this new one, but it looks like the efforts to convert the name from 'envisalink' to 'envisalink_new' in all my scripts and automations is going to be time consuming. Is there an easier way? Also, if my current HA version is working perfectly, is there any major benefits to switch over to this new version?

[grunthos503]

There shouldn't be any impact on your scripts or automations by this rename. None of your scripts or automations should reference the integration name itself. They should all reference the entity names of the zones. As long as you make your zone entities the same as prior, this will have no impact.

…

On June 3, 2024 6:15:03 AM PDT, Nick ***@***.***> wrote: What is the latest on this discussion? I'm looking into migrating from the HA integration to this new one, but it looks like the efforts to convert the name from 'envisalink' to 'envisalink_new' in all my scripts and automations is going to be time consuming. Is there an easier way? Also, if my current HA version is working perfectly, is there any major benefits to switch over to this new version? -- Reply to this email directly or view it on GitHub: #71 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[nickb24]

One example is for service calls to 'invoke_custom_function' or 'alarm_keypress'. Currently they are calling 'envisalink.invoke_custom_function' with the rename it will be 'envisalink_new.invoke_custom_function'.

[ufodone]

@nickb24 I would still like to do the rename at some point. I just haven't had time to think about how to best do it and minimize disruption to people while also not needing to end up supporting two versions.

Honestly. I don't anticipate getting to this for a while yet.

but it looks like the efforts to convert the name from 'envisalink' to 'envisalink_new' in all my scripts and automations is going to be time consuming. Is there an easier way?

Whenever I need to make changes to a bunch of automations, dashboards, etc. I typically just search and replace in the yaml files directly (automations.yaml, scripts.yaml, the lovelace dashboards in the .storage/ directory, etc.) It's typically much quicker than trying to find and change them all via the UI.

Also, if my current HA version is working perfectly, is there any major benefits to switch over to this new version?

There are a lot of bug fixes and enhancements in this version that aren't in the stock version but that may not be relevant to you if the stock version is working fine for you. Given all the feature requests, etc. that I've seen come in, I've discovered that I'm a pretty basic user of the integration so I'm maybe not the best person to comment on the value of switching.

[jhenkens]

You can also write scripts that wrap the envisalink_new. commands. I have one specifically to send a command with the alarm code prefixed. I don't use it anymore now that chime is built in... but I used to use it to toggle the chime.

script:
  send_alarm_command_with_pin:
    fields:
      command_after_pin:
        description: "The command to send after the pin"
    variables:
      alarm_code: !secret alarm_code
    sequence:
      - service: envisalink_new.alarm_keypress
        data:
          entity_id: alarm_control_panel.home_alarm
          keypress: "{{ alarm_code }}{{ command_after_pin }}"
      - delay:
          milliseconds: "1000"