Non-contiguous zones not working

[ufodone]

@ufodone Not sure if this is by design or a problem, but I now have 10 (of 20) zones that were renamed to generic names "alarm_zone_xx" where xx is some number. At first I thought I can check those zones and manually rename them to what they were prior, but it seems it used numbers that were not in use, that is, zones that don't exist (first one is alarm_zone_3 but I have no zone 3). So I'm not sure how I'd identify each of those zones to figure which is which (some are low temp for example).

Looking for a pattern, they seem to be random sensors/zones, my front door is one, but other doors show fine and correct. Some smoke detectors are renamed while others are fine. I don't see anything in the naming scheme, some are single word, others are multiple.

[ufodone]

@greggitter

The code currently assumes that the zones in use are contiguous starting from one.

I'll get a change in to fix that and adjust the maximum number of zones based on the largest zone you have configured in your configuration.yaml. This will still result in creating zones to "fill in the gaps" using the alarm_zone<n> syntax but it should get all your actual zones positioned and named correctly.

Could you paste your configuration.yaml here so I have a reference to test against?

[greggitter]

Ah, that's what it did. In honeywell, wired zones are something like 1-16 and wireless are above that range, with other special ones gapping higher again (like key fobs, but I'm going on memory here...not 100%). Here's my config:

host: <ipaddr>
panel_type: HONEYWELL
user_name: xxxx
password: xxxx
#code:
port: 4025
evl_version: 3
keepalive_interval: 60
zonedump_interval: 30
timeout: 10
panic_type: Police
zones:
  01:
    name: "Smoke Basement/Bdrm 1"
    type: "smoke"
  02:
    name: "Garage"
    type: "opening"
  04:
    name: "Patio"
    type: "opening"
  05:
    name: "Basement Motion"
    type: "motion"
  06:
    name: "Basement Windows"
    type: "vibration"
  07:
    name: "Den Motion"
    type: "motion"
  08:
    name: "Glass Dining Room"
    type: "sound"
  16:
    name: "Glass Kitchen"
    type: "sound"
  17:
    name: "Foyer Motion"
    type: "motion"
  18:
    name: "Smoke Kitchen"
    type: "smoke"
  20:
    name: "Low Temp Kitchen"
    type: "cold"
  21:
    name: "Front Door"
    type: "opening"
  22:
    name: "Smoke Den"
    type: "smoke"
  23:
    name: "Low Temp Den"
    type: "cold"
  24:
    name: "Smoke Master BR"
    type: "smoke"
  25:
    name: "Low Temp Master BR"
    type: "cold"
  26:
    name: "Smoke Bedroom 2"
    type: "smoke"
  27:
    name: "Low Temp Bedroom 2"
    type: "cold"
  28:
    name: "Smoke Bedroom 3"
    type: "smoke"
  29:
    name: "Low Temp Bedroom 3"
    type: "cold"
partitions:
  1:
    name: "Home Alarm"

[ufodone]

Thanks for the config. I'll try and get an update out tonight after work.

I've been trying to think about how to determine the zones to create without need to explicitly configure them via the config flow. While explicit configuration is okay for a configuration.yaml approach, it's pretty clunky for config flow UI and sort of goes against how I think HA wants entities to be managed. Unfortunately I can't think of a way to automatically discover the zones in use which led me to just specify the total zones in the config. In your case, that will result in some additional entities being create (e.g. for zones 9-15). Maybe that's not a huge problem though.

[greggitter]

I'm missing why you need to create extra zones. If they aren't defined in the yaml (for those converting), then why not just skip them? If extras are created, it doesn't seem like a big effort do a multi-delete of course...I'm just not seeing the limitation...and maybe it's not worth explaining further lol. I just hope the night stay is fixed with honeywell! :) Will watch for an update later today. Thx!

[jl-678]

Just to clarify, I have the 39 zones. 1-5 are hardwired and 9-43 are wireless. I mapped all of those zones to actual device names in the envisalink yaml file. Are we suggesting that all of this will change with the "new" version?

My mappings were all aligned with the ID assigned by the panel. It seems like that is the simplest way to handle this versus renumbering everything.

[ufodone]

The intention is definitely to honour the numbering and naming in configuration.yaml. It's a bug that it isn't working right now.

My point is that for UI based configuration, my intention is to create the necessary zone/partition entities with default naming initially and then people should use HA's native support for entity renaming to provide the same functionality as how the configuration.yaml way works (as I believe that's how it's intended to be done in HA).

My problem is that there isn't any way that I can figure out to determine automatically which zones people are using. Right now, it requires a "number of zones" configuration to be chose and will create entities from 1 to num_zones. This will result in potentially creating zones that aren't in use. I don't think that will cause any functional problem though as the unused zone entities won't do anything other than just "exist".

Another option could be that I allow zone ranges in the config (e.g. 1-2,16-29) as a simplified way to create only the needed zones.

@greggitter The night stay issue isn't fixed yet but this refactor of the code will open the door to me fixing that. Happy to work with you on that once we get the basics up and running. Maybe create a separate issue for it here so I don't lose track.

[greggitter]

I prefer the latter, zone ranges or just enter each zone number individually comma delimited even with the zone name/type...a much cleaner (in the end) implementation IMO. That's a one time effort...compared to time spent in yamls and other stuff, that's trivial. I wouldn't personally want fake entities that can't be deleted, I think it adds confusion and clutter.

As a work-around, I decided to add placeholder zones in my config to get it working. It mostly worked, but one zone is still missing and nothing I do gets it to show...zone 8...and get dummy entries for 8 and 9. Here's the hacked configuration. (I used to work in IT so...old habit...looking for bugs by doing dumb user stuff).

host: <ipaddr>
panel_type: HONEYWELL
user_name: xxxx
password: xxxx
#code:
port: 4025
evl_version: 3
keepalive_interval: 60
zonedump_interval: 30
timeout: 10
panic_type: Police
zones:
  01:
    name: "Smoke Basement/Bdrm 1"
    type: "smoke"
  02:
    name: "Garage"
    type: "opening"
  03:
    name: "NA"
    type: "opening"
  04:
    name: "Patio"
    type: "opening"
  05:
    name: "Basement Motion"
    type: "motion"
  06:
    name: "Basement Windows"
    type: "vibration"
  07:
    name: "Den Motion"
    type: "motion"
  08:
    name: "Glass Dining Room"
    type: "sound"
  09:
    name: "NA"
    type: "opening"
  10:
    name: "NA"
    type: "opening"
  11:
    name: "NA"
    type: "opening"
  12:
    name: "NA"
    type: "opening"
  13:
    name: "NA"
    type: "opening"
  14:
    name: "NA"
    type: "opening"
  15:
    name: "NA"
    type: "opening"
  16:
    name: "Glass Kitchen"
    type: "sound"
  17:
    name: "Foyer Motion"
    type: "motion"
  18:
    name: "Smoke Kitchen"
    type: "smoke"
  19:
    name: "NA"
    type: "opening"    
  20:
    name: "Low Temp Kitchen"
    type: "cold"
  21:
    name: "Front Door"
    type: "opening"
  22:
    name: "Smoke Den"
    type: "smoke"
  23:
    name: "Low Temp Den"
    type: "cold"
  24:
    name: "Smoke Master BR"
    type: "smoke"
  25:
    name: "Low Temp Master BR"
    type: "cold"
  26:
    name: "Smoke Bedroom 2"
    type: "smoke"
  27:
    name: "Low Temp Bedroom 2"
    type: "cold"
  28:
    name: "Smoke Bedroom 3"
    type: "smoke"
  29:
    name: "Low Temp Bedroom 3"
    type: "cold"
partitions:
  1:
    name: "Home Alarm"

[tinuva]

I may also be affected by this bug. This is my config:

envisalink:
  #-
  #                  _           _ _       _
  #   ___ _ ____   _(_)___  __ _| (_)_ __ | | __
  #  / _ \ '_ \ \ / / / __|/ _` | | | '_ \| |/ /
  # |  __/ | | \ V /| \__ \ (_| | | | | | |   <
  #  \___|_| |_|\_/ |_|___/\__,_|_|_|_| |_|_|\_\
  #
  #
  #- from github.com/tinuva/home-assistant-config
  host: !secret evl_host
  panel_type: DSC
  user_name: !secret evl_user
  password: !secret evl_pass
  code: !secret evl_pin
  port: 4025
  evl_version: 4
  keepalive_interval: 60
  zonedump_interval: 30
  timeout: 10
  panic_type: Police
  #create_zone_bypass_switches: true
  partitions:
    1:
      name: 'Home Alarm'
  zones:
    1:
      name: 'Front Door'
      type: 'door'
    2:
      name: 'Lounge PIR'
      type: 'motion'
    3:
      name: 'Kitchen PIR'
      type: 'motion'
    4:
      name: 'Study PIR'
      type: 'motion'
    5:
      name: 'Babyroom PIR'
      type: 'motion'
    6:
      name: 'Main Bedroom PIR'
      type: 'motion'
    7:
      name: 'Ensuite PIR'
      type: 'motion'
    8:
      name: 'Front Garage Door/Window'
      type: 'garage_door'
    9:
      name: 'Lounge Window'
      type: 'window'
    10:
      name: 'Kitchen Window'
      type: 'window'
    11:
      name: 'Sculllery Window'
      type: 'window'
    12:
      name: 'Scullery Door'
      type: 'window'
    13:
      name: 'Study Window'
      type: 'window'
    14:
      name: 'Babyroom Window'
      type: 'window'
    15:
      name: 'Main Bedroom Window'
      type: 'window'
    16:
      name: 'Panic'
      type: 'safety'
    17:
      name: 'Spare Bedroom PIR'
      type: 'motion'
    18:
      name: 'Braai-room PIR'
      type: 'motion'
    19:
      name: 'Back Garage PIR'
      type: 'motion'
    20:
      name: 'Back Garage Door'
      type: 'garage_door'
    25:
      name: 'Front Beam'
      type: 'motion'
    26:
      name: 'Back Beam'
      type: 'motion'
    42:
      name: 'Box Tamper'
      type: 'tamper'

[ufodone]

Could you send me the config entry for this? It would be in config/.storage/core.config_entries. Search for envisalink_new in there and grab the full entry and paste it here. Please remove your password and alarm code from the entry first though before you paste it!

[greggitter]

Here ya go...looks like some have leading zeroes for zone numbers.

      {
        "entry_id": "0008841aa5643a14d38ab1c639d1d19e",
        "version": 1,
        "domain": "envisalink_new",
        "title": "alarm",
        "data": {
          "host": "<ipaddr>",
          "port": 4025,
          "user_name": "xxxx",
          "password": "xxxx",
          "evl_version": 3,
          "panel_type": "HONEYWELL",
          "zones": {
            "1": {
              "name": "Smoke Basement/Bdrm 1",
              "type": "smoke"
            },
            "2": {
              "name": "Garage",
              "type": "opening"
            },
            "3": {
              "name": "NA",
              "type": "opening"
            },
            "4": {
              "name": "Patio",
              "type": "opening"
            },
            "5": {
              "name": "Basement Motion",
              "type": "motion"
            },
            "6": {
              "name": "Basement Windows",
              "type": "vibration"
            },
            "7": {
              "name": "Den Motion",
              "type": "motion"
            },
            "08": {
              "name": "Glass Dining Room",
              "type": "sound"
            },
            "09": {
              "name": "NA",
              "type": "opening"
            },
            "10": {
              "name": "NA",
              "type": "opening"
            },
            "11": {
              "name": "NA",
              "type": "opening"
            },
            "12": {
              "name": "NA",
              "type": "opening"
            },
            "13": {
              "name": "NA",
              "type": "opening"
            },
            "14": {
              "name": "NA",
              "type": "opening"
            },
            "15": {
              "name": "NA",
              "type": "opening"
            },
            "16": {
              "name": "Glass Kitchen",
              "type": "sound"
            },
            "17": {
              "name": "Foyer Motion",
              "type": "motion"
            },
            "18": {
              "name": "Smoke Kitchen",
              "type": "smoke"
            },
            "19": {
              "name": "NA",
              "type": "opening"
            },
            "20": {
              "name": "Low Temp Kitchen",
              "type": "cold"
            },
            "21": {
              "name": "Front Door",
              "type": "opening"
            },
            "22": {
              "name": "Smoke Den",
              "type": "smoke"
            },
            "23": {
              "name": "Low Temp Den",
              "type": "cold"
            },
            "24": {
              "name": "Smoke Master BR",
              "type": "smoke"
            },
            "25": {
              "name": "Low Temp Master BR",
              "type": "cold"
            },
            "26": {
              "name": "Smoke Bedroom 2",
              "type": "smoke"
            },
            "27": {
              "name": "Low Temp Bedroom 2",
              "type": "cold"
            },
            "28": {
              "name": "Smoke Bedroom 3",
              "type": "smoke"
            },
            "29": {
              "name": "Low Temp Bedroom 3",
              "type": "cold"
            }
          },
          "partitions": {
            "1": {
              "name": "Home Alarm"
            }
          },
          "alarm_name": "alarm",
          "yaml_options": {
            "num_zones": 29,
            "num_partitions": 1,
            "panic_type": "Police",
            "keepalive_interval": 60,
            "zonedump_interval": 30,
            "timeout": 10
          }
        },

[schmuy]

I've been trying to think about how to determine the zones to create without need to explicitly configure them via the config flow.

I don't know if it's possible, but it might be nice to have the option to explicitly configure. In the Config/Options window where you specific number of zones, is it possible to have a toggle for "advanced setup" which would lead to a second window. This second window would show zones 1-max, each with a checkbox to enable, and a textbox to provide a name? Renaming entities one by one in the entities HA page is annoying, especially when there's double for zone bypass.

[ufodone]

I'm new to the config flow stuff but from what I've seen so far, it seem somewhat limited in terms of how flexible the UI it generates can be so I suspect doing something you're suggesting could end up being pretty clunky. If there are any other integrations you're aware of that do something similar, let me know and I can take a look at how they are doing it.

I don't think this renaming would be necessary for people coming from the existing integration since it would just import the definitions from configuration.yaml. Bulk changes are likely a one-time activity for a new user who's starting fresh via the UI.

One approach for bulk changes might be to use the configuration.yaml mechanism that HA provides for entity customization described here. This would provide a convenient way to make the updates in a non-integration-specific way.

[ufodone]

Regarding the bypass switches, it might also be possible to name them automatically based on the name of their corresponding binary_sensor entity.

[schmuy]

@ufodone oops... I missed the part about auto importing the config from yaml and had commented that out before setting up the integration.

[ufodone]

I've pushed a new release that I hope will fix the issues discussed here. Please have a read through the release notes before upgrading.

Release v0.2.0

[greggitter]

Thanks!

I couldn't delete devices without removing the integration. So I figured I'd remove it and start from scratch (with the original yaml without the placeholders). Added the integration again and this time it seemed to ignore the yaml and just created generic names. Unfortunately, they don't correspond to my actual zones so I am not sure how I would be able to determine what's what. Example, I don't have a zone 3 but it shows a zone 3 entity. Sorry...I'm confused.

Edit: Re-reading the instructions...I think I skipped the restart HA part...trying again. Restarted twice and same as above...strange.

[ufodone]

Hmmm... you shouldn't have had to remove the integration to delete it the device. The important part is to ensure that the config entry is deleted before installing the new version (which should happen when you delete the device). This would ensure that the config entry is removed.

Are you able to check the config/.storage/core.config_entities file and look for any entries with:

domain: "envisalink_new"

If it exists, could you also check the options section contains a num_zones parameter and/or zone_set? That would help determine if the entry was deleted and re-created during the upgrade. I did try with your configuration when testing and it worked for me so I'm not quite sure what's happening here.

Usually there is support for migrating between schema versions but I didn't implement that for this early version which is why it's important to delete the old config entries first.

[greggitter]

My current state...I removed envisalink_new again and re-enabled envisalink while waiting to test something more. Now in this current setup, checking core.config_entities, I see nothing for envisalink_new...so it appears HA cleaned it up properly.

[ufodone]

Okay, sounds like you've got a "clean" setup now. Have you tried switching back to envisalink_new using the v0.2.0 release with this setup? If that's still not working, when you get a chance, could you post the config entry from core.config_entries as well as some debug logs so I can get a better idea of what's going wrong?

(It seems I erroneously typed core.config_entities rather than core.config_entries in an earlier post but I assume you figured out my typo since the former file does not exist. 😄 )

[greggitter]

Yeah I used auto-complete so didn't even think about the folder name.

How can I verify I have the new version? Is it enough to delete and re-add the addon? Reason I ask is I still see mixed leading-zeroes in the first 8 zones.

[ufodone]

I can't seem to find an simple way to check the version but if you go into HACS and then click on the "Envisalink Refactored" integration there should be a hash value shown in the top left of the screen (if you mouse over it it should say "Version Downloaded"). You can match that up against the hash shown on the releases page to see what version you have.

If you don't have the latest version, HACS should also automatically figure that out and provide an "Update" button.

Where are you seeing the mixes leading zeroes for zones 1-8?

[greggitter]

OK, that was the problem. My bad...I am relatively new to HA, not that that's an excuse, but I assumed removing/adding the add-on was magically refreshing the copy. As soon as I read HACS (oops)...it struck me...going there told me there was an update.

OK, so things look good now...all my zones are there, named properly along with type. I was able to remove the fillers entities...that's not so bad at all.

The zone list that replaces number of zones is very nice. 👍

Edit: Checking core.config_entries, it looks perfect, no problems that I see.

[ufodone]

Great to hear it's working now!

When you say you removed the fillers, I assume you mean from the configuration.yaml?

[greggitter]

No, they were lingering fillers before updating properly to the new version. After I posted that I then saw the new interface in configure…so didn’t get a chance to use that.

[greggitter]

@ufodone OK, not sure how but the problem is back. After everything was working, there was an update for HA and I applied it. Now, somehow, it appears the old code is back and the problems I experienced early have rendered several of my entities (zones) missing or not available.

So what I tried was this. Deleted the envisalink new from HACS. Then removed the alarm device, verified the config was cleared from .storage/core.config_entries. Then re-added via HACS to make sure the latest version was present...appears to be (but also appeared to be prior). Added the device in settings, went through the configuration (zone list, etc). Let it configure, checked, all generic names (apparently hadn't processed the yaml). Restarted HA and it still doesn't have the names as defined in the yaml.

At this point I'm not sure what's going on. When I checked the /storage/core.config_entries earlier, my zones were all perfect, after the HA update, it seems to have reverted (I can tell because most zones 1-9 don't have a leading zero but for some reason zone 8 does). NOW, I don't get any names pulled over from the yaml. Bizarre...what can I try?

A couple screen shots....

[greggitter]

And here's a truncated section of /.storage/core.config_entries...the leading zero problem is back (see zone 8) with 0.2...? So even though these zones are all named properly and present here, the names are not reflected above.

      {
        "entry_id": "2fb9f35f45bdb6379749788d70d3d3e7",
        "version": 1,
        "domain": "envisalink_new",
        "title": "Home Alarm",
        "data": {
          "alarm_name": "Home Alarm",
          "host": "",
          "port": 4025,
          "user_name": "xxxx",
          "password": "xxxxxxx",
          "panel_type": "HONEYWELL",
          "evl_version": 3
        },
        "options": {
          "zone_set": "1-8, 16-18, 21-29",
          "partition_set": "1",
          "panic_type": "Police",
          "keepalive_interval": 60,
          "zonedump_interval": 30,
          "timeout": 10
        },
        "pref_disable_new_entities": false,
        "pref_disable_polling": false,
        "source": "user",
        "unique_id": null,
        "disabled_by": null
      },
      {
        "entry_id": "ac32e68b6e015a53709eba906c62ebbc",
        "version": 1,
        "domain": "envisalink_new",
        "title": "alarm",
        "data": {
          "host": "",
          "port": 4025,
          "user_name": "",
          "password": "",
          "evl_version": 3,
          "panel_type": "HONEYWELL",
          "zones": {
            "1": {
              "name": "Smoke Basement/Bdrm 1",
              "type": "smoke"
            },
            "2": {
              "name": "Garage",
              "type": "opening"
            },
            "4": {
              "name": "Patio",
              "type": "opening"
            },
            "5": {
              "name": "Basement Motion",
              "type": "motion"
            },
            "6": {
              "name": "Basement Windows",
              "type": "vibration"
            },
            "7": {
              "name": "Den Motion",
              "type": "motion"
            },
            "08": {
              "name": "Glass Dining Room",
              "type": "sound"
            },
            "16": {
              "name": "Glass Kitchen",
              "type": "sound"
            },
            "17": {
              "name": "Foyer Motion",
              "type": "motion"
            },
            "18": {
              "name": "Smoke Kitchen",
              "type": "smoke"
            },
            "20": {
              "name": "Low Temp Kitchen",
              "type": "cold"
            },
            "21": {
              "name": "Front Door",
              "type": "opening"
            },
            "22": {
              "name": "Smoke Den",
              "type": "smoke"
            },
            "23": {
              "name": "Low Temp Den",
              "type": "cold"
            },
            "24": {
              "name": "Smoke Master BR",
              "type": "smoke"
            },
            "25": {
              "name": "Low Temp Master BR",
              "type": "cold"
            },
            "26": {
              "name": "Smoke Bedroom 2",
              "type": "smoke"
            },
            "27": {
              "name": "Low Temp Bedroom 2",
              "type": "cold"

[ufodone]

It looks like you've added two devices to your setup. If you have a definition in configuration.yaml, you shouldn't explicitly add it via the Devices & Services page as it will automatically be picked up and added when HA starts (after you have the envisalink_new integration installed via HACS).

You can see the two entries in that second screenshot you posted. The imported one defaults to "alarm" so I assume "Home Alarm" is the one you explicitly added via the UI. Try and delete that one and see if that fixes the issue.

You may need a restart after you've deleted the extra entry.

[greggitter]

I definitely did not install two devices. I installed envisalink_new...when it prompts for a name, I enter the name Home Alarm and then that's what I end up with. "alarm" is the default name, I enter Home Alarm over it and I get two. Home Alarm has all the entities, alarm just has one. OK...so I removed "Home Alarm" and then renamed "alarm" to "Home Alarm" and restarted. So maybe that was a bug or just confusion. Do not change the name when doing the initial configuration?

Looking at core.config_entries again, the snippet looks the same as above. My dashboard entities all need to be reset except one seemed to not be affected. A minor detail. The entity names have all changed..."binary_sensor.basement_motion" became "binary_sensor.home_alarm_zone_5"...less descriptive. Is this intentional? Again, just trying to do some thorough testing.

[ufodone]

You definitely have two devices defined based both on the screenshot (showing "alarm" and "Home Alarm") as well as the core.config_entries snippet you pasted. Based on the config entry, "Home Alarm" is the one you added explicitly via the UI and "alarm" is the one that got imported automatically when HA started up based on your configuration.yaml.

I haven't tested any rename scenarios so I don't know what will happen there but I'll add that to my list of things to look at.

I'm not quite following what you did based on your last post. But if you were starting "fresh" with no config entries and the envisalink_new integration not installed, then this would be the steps:

1. Install envisalink_new via HACS
2. Restart Home Assistant so it can load the new integration and one of the following will happen:
   1. If you already had the envisalink_new: section in your configuration.yaml then it will automatically import the configuration on startup.
   2. If you had removed or commented out that section from your configuration.yaml then at this point you should re-add/uncomment it and then restart HA and it will auto import at startup.
3. At this point you will see your EVL in Settings->Devices & Services named as alarm.

There is no need to explicitly click the Add Integration button in Settings->Devices & Services. This is only required if you don't plan on using configuration.yaml.

If at this point you delete the alarm device via Settings->Devices & Services then it will be removed but will automatically be re-added when you restart HA. This is because it will always import from configuration.yaml if config exists.

Arguably, once you have done that first import, you might just remove the configuration.yaml entries and manage the device from the UI going forward (it will still retain all your config from the import). I believe this is ultimately the direction the Home Assistant devs want things to go. Some info on that here in case you're interested.

[greggitter]

That’s the confusion…I did explicitly add the integration rather than just restarting and letting it pull in the yaml. I’m mobile at the moment but will comment further tomorrow when I’m in front of it. Thx!

[ufodone]

Sounds good. As an added bonus, I've added the change so "arm_night" will now use 33 instead of 7 by default and I added an option in the config UI to switch it to Instant(7) for those wishing the old behaviour. I tested it as best I could but don't have a Honeywell system so would appreciate it if you could take a look and let me know if things are working.

The change is in the newly posted v0.2.1 release.

[greggitter]

Another problem (?). Opened HA, went to hacs, updated envisalink_new, restarted. Now I no longer have a keypad for the UI and status says "unavailable". Thought maybe I should comment the envisalink_new in config, did that, restarted and same.

Odd though, all the zones are reported correctly...appears to be just the keypad. Thought I should check the configuration...everything looks correct. Turned on debug logging, got this:

Side note: I did notice the ip address is not available for modification in "configure", if that changed, is the process remove and re-add the device? I would expect that to be fine as this is a rare event.

Edit: Add clarity

[ufodone]

The alarm panel entity not being created was due to a bug I introduced as part of the "arm night" changes. I've published a v0.2.2 release with a fix.

Regarding the IP address change, in your case where you have everything in configuration.yaml, you'd just need to update the configuration.yaml with the correct IP address (or hostname) and restart HA and it will re-import the change into the config entry.

I'll have to investigate the best way to handle this for a UI configured system. I've created #6 to track that.

[greggitter]

Updated via hacs. Keypad now shows, but it doesn't do anything. Here's what I'm seeing in the logs. This is after doing a restart and NOT interacting with the keypad (additional errors were caused by interaction). These lines are repeating.

2023-01-13 11:22:40.596 ERROR (MainThread) [custom_components.envisalink_new] Could not establish a connection with the Envisalink- retrying
2023-01-13 11:22:40.599 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] The server closed the connection.
2023-01-13 11:22:40.602 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Reconnection attempt in 30s
2023-01-13 11:23:21.100 ERROR (MainThread) [custom_components.envisalink_new] Could not establish a connection with the Envisalink- retrying
2023-01-13 11:23:21.104 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] The server closed the connection.
2023-01-13 11:23:21.106 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Reconnection attempt in 30s
2023-01-13 11:24:01.104 ERROR (MainThread) [custom_components.envisalink_new] Could not establish a connection with the Envisalink- retrying
2023-01-13 11:24:01.107 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] The server closed the connection.
2023-01-13 11:24:01.109 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Reconnection attempt in 30s
2023-01-13 11:24:41.109 ERROR (MainThread) [custom_components.envisalink_new] Could not establish a connection with the Envisalink- retrying
2023-01-13 11:24:41.112 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] The server closed the connection.
2023-01-13 11:24:41.113 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Reconnection attempt in 30s

[ufodone]

Phew... I really need to find a way to be able to test Honeywell systems.

The The server closed the connection error typically means that something else it already connected to the EVL. The EVLs only support a single concurrent connection unfortunately. Any chance you have multiple entries again or have accidentally re-enabled the official envisalink integration?

[greggitter]

No worries...I'm glad to help. Definitely not two devices connected. Also verified by checking core.config_entries to make sure something wasn't hiding in there. Everything looks fine, it was just an update via hacs and it started.

[ufodone]

Could you turn debug logging on, restart HA, let it startup up (and fail to connect) and then send me the logs? (Be sure to scrub your password and alarm code if necessary.)

Logging config should look like:

logger:
  default: info
  logs:
    homeassistant.components.envisalink: debug
    pyenvisalink: debug
    custom_components.envisalink_new: debug

[greggitter]

In my configuration, I have not configured the alarm code in the settings, in case that's related. Here are the logs:

2023-01-13 12:13:58.455 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Starting read loop.
2023-01-13 12:13:58.456 INFO (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Started to connect to Envisalink... at 172.20.100.211:4025
2023-01-13 12:13:58.460 INFO (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Connection Successful!
2023-01-13 12:13:58.460 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Waiting for data from EVL
2023-01-13 12:13:58.463 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] ----------------------------------------
2023-01-13 12:13:58.463 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] RX < Login:
2023-01-13 12:13:58.463 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.honeywell_client] Data received:Login:
2023-01-13 12:13:58.464 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] calling handler: handle_login for code: Login: with data:
2023-01-13 12:13:58.464 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Invoking callback: callback_login
2023-01-13 12:13:58.465 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.alarm_panel] Callback has not been set by client.
2023-01-13 12:13:58.465 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] ----------------------------------------
2023-01-13 12:13:58.466 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Waiting for data from EVL

Some additional messages as it's been up for a while:

2023-01-13 12:23:28.484 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Reconnection attempt in 30s
2023-01-13 12:23:58.487 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Starting read loop.
2023-01-13 12:23:58.487 INFO (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Started to connect to Envisalink... at 172.20.100.211:4025
2023-01-13 12:23:58.490 INFO (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Connection Successful!
2023-01-13 12:23:58.491 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Waiting for data from EVL
2023-01-13 12:23:58.491 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] ----------------------------------------
2023-01-13 12:23:58.491 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] RX < Login:
2023-01-13 12:23:58.491 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.honeywell_client] Data received:Login:
2023-01-13 12:23:58.491 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] calling handler: handle_login for code: Login: with data:
2023-01-13 12:23:58.492 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Invoking callback: callback_login
2023-01-13 12:23:58.492 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.alarm_panel] Callback has not been set by client.
2023-01-13 12:23:58.492 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] ----------------------------------------
2023-01-13 12:23:58.492 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Waiting for data from EVL
2023-01-13 12:24:08.480 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] ----------------------------------------
2023-01-13 12:24:08.480 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] RX < Timed Out!
2023-01-13 12:24:08.480 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.honeywell_client] Data received:Timed Out!
2023-01-13 12:24:08.480 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] calling handler: handle_login_timeout for code: Timed Out! with data:
2023-01-13 12:24:08.481 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] No handler configured for evl command.
2023-01-13 12:24:08.481 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] KeyError: 'HoneywellClient' object has no attribute 'handle_login_timeout'
2023-01-13 12:24:08.481 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Invoking callback: callback_login_timeout
2023-01-13 12:24:08.481 ERROR (MainThread) [custom_components.envisalink_new] Could not establish a connection with the Envisalink- retrying
2023-01-13 12:24:08.483 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] ----------------------------------------
2023-01-13 12:24:08.483 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Waiting for data from EVL
2023-01-13 12:24:08.484 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] The server closed the connection.
2023-01-13 12:24:08.487 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Cleaning up from disconnection with server.
2023-01-13 12:24:08.487 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Reconnection attempt in 30s
2023-01-13 12:24:15.636 INFO (MainThread) [homeassistant.components.websocket_api.http.connection] [139882319874464] Connection closed by client
2023-01-13 12:24:38.489 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Starting read loop.
2023-01-13 12:24:38.490 INFO (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Started to connect to Envisalink... at 172.20.100.211:4025
2023-01-13 12:24:38.494 INFO (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Connection Successful!
2023-01-13 12:24:38.494 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Waiting for data from EVL
2023-01-13 12:24:38.494 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] ----------------------------------------
2023-01-13 12:24:38.494 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] RX < Login:
2023-01-13 12:24:38.495 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.honeywell_client] Data received:Login:
2023-01-13 12:24:38.495 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] calling handler: handle_login for code: Login: with data:
2023-01-13 12:24:38.495 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Invoking callback: callback_login
2023-01-13 12:24:38.495 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.alarm_panel] Callback has not been set by client.
2023-01-13 12:24:38.495 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] ----------------------------------------
2023-01-13 12:24:38.495 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Waiting for data from EVL
2023-01-13 12:24:48.484 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] ----------------------------------------
2023-01-13 12:24:48.484 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] RX < Timed Out!
2023-01-13 12:24:48.484 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.honeywell_client] Data received:Timed Out!
2023-01-13 12:24:48.485 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] calling handler: handle_login_timeout for code: Timed Out! with data:
2023-01-13 12:24:48.485 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] No handler configured for evl command.
2023-01-13 12:24:48.485 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] KeyError: 'HoneywellClient' object has no attribute 'handle_login_timeout'
2023-01-13 12:24:48.485 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Invoking callback: callback_login_timeout
2023-01-13 12:24:48.485 ERROR (MainThread) [custom_components.envisalink_new] Could not establish a connection with the Envisalink- retrying
2023-01-13 12:24:48.491 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] ----------------------------------------
2023-01-13 12:24:48.491 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Waiting for data from EVL
2023-01-13 12:24:48.492 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] The server closed the connection.
2023-01-13 12:24:48.493 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Cleaning up from disconnection with server.
2023-01-13 12:24:48.496 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Reconnection attempt in 30s

[ufodone]

Thanks! That extra logging you added is helpful and I think I know what's going on now. Once again bitten by my inability to test the Honeywell devices. 😞

I think it was v0.2.1 which introduced the issue. I'll get a fix out later today.

[ufodone]

I've published a new v0.3.0 release that I hope fixes these latest issues.

Debugging the issue led me to discover a number of other problems which I've tried to address as best as I could without actually having a Honeywell system to test again. I'd appreciate any testing you can provide!

[greggitter]

Hi @ufodone ... updated via hacs (0.3) and checked the log. There are a couple errors I'm seeing. I'll have a block of time today to help with this...so hopefully our schedules mesh. :) Using the keypad to arm, seems still non-functional.

2023-01-14 11:22:57.063 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] RX < %00,01,1C08,08,00,****DISARMED**** Ready to Arm $
2023-01-14 11:22:57.064 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.honeywell_client] Code:%00 Data:01
2023-01-14 11:22:57.064 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] calling handler: handle_keypad_update for code: %00 with data: 01
2023-01-14 11:22:57.064 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Caught unexpected exception: IndexError('list index out of range')
2023-01-14 11:22:57.077 DEBUG (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Cleaning up from disconnection with server.
2023-01-14 11:22:57.078 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Reconnection attempt in 30s

[ufodone]

I've pushed a v0.3.1 which has a fix for the above error.

Thanks for the quick turnaround. I'm around for a bit this morning and then will be out for a while and back later in the day.

[greggitter]

It's working! Tested both instant and night stay and both work. Checking the logs, I don't see any errors, is there anything you want to see before I disable debug? Anything else you want tested specific to this change?

[ufodone]

Great! The ticket that was opened regarding the Night/Instant mode also said:

When arming system in Night Stay (code + 33), Home Assistant reports that it is just armed Home

If you also see this behaviour could you get me some debug info for that? You'd need to arm in Night mode and then I'd be interested in output from the EVL for the %00, %02, and %03 updated. Look for entires like this:

2023-01-14 08:53:24,746 DEBUG <pyenvisalink.honeywell_client honeywell_client parseHandler> Code:%00 Data:'01,1C08,08,00,****DISARMED**** Ready to Arm '

This example is a %00 command.

I don't see in the EVL documentation how it would be able to distinguish Night mode so I'm wondering if it is out of date and the EVL is sending some new codes which hopefully that debug output will show.

[ufodone]

Also, if it's not too much to ask, I'd love to get zone timer debug as I found what I believe is a bug in there which may be causing the problems many people have had with this feature in the past.

This is the %FF command that you'll get once every 30 second (based on your zonedump_interval config). What I'd like to capture is described in here. I've tested this with my DSC/EVL4 system and would like to get data for Honeywell systems for both EVL3 and EVL4 units.

[greggitter]

Here's a chunk of the log...let me know when you get this so I can remove it. If it doesn't have what you need, let me know that too.

I verified on the honeywell panel it too says night stay.

[ufodone]

I don't have access to that link but requested it so hopefully you go the notification.

[greggitter]

Done.

[greggitter]

Just tested again (been a while since a restart) and non-functional. Logs show this, but debugging is now off.

2023-01-14 12:44:36.071 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command '02' failed due to timeout waiting for response from EVL
2023-01-14 12:45:11.078 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command '02' failed due to timeout waiting for response from EVL
2023-01-14 12:45:32.073 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command '00' failed due to timeout waiting for response from EVL
2023-01-14 12:45:46.083 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command '02' failed due to timeout waiting for response from EVL
2023-01-14 12:46:21.086 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command '02' failed due to timeout waiting for response from EVL
2023-01-14 12:46:37.080 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command '00' failed due to timeout waiting for response from EVL
2023-01-14 12:46:56.091 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command '02' failed due to timeout waiting for response from EVL
2023-01-14 12:47:22.524 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command '03' failed due to timeout waiting for response from EVL
2023-01-14 12:47:27.528 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command '03' failed due to timeout waiting for response from EVL
2023-01-14 12:47:31.096 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command '02' failed due to timeout waiting for response from EVL
2023-01-14 12:47:32.533 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command '03' failed due to timeout waiting for response from EVL
2023-01-14 12:47:37.540 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command '03' failed due to timeout waiting for response from EVL
2023-01-14 12:47:42.086 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command '00' failed due to timeout waiting for response from EVL
2023-01-14 12:47:42.545 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command '03' failed due to timeout waiting for response from EVL
2023-01-14 12:47:47.550 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command '03' failed due to timeout waiting for response from EVL
2023-01-14 12:48:02.925 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Caught unexpected exception: ConnectionResetError(104, 'Connection reset by peer')
2023-01-14 12:48:02.930 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/config/custom_components/envisalink_new/pyenvisalink/envisalink_base_client.py", line 134, in read_loop
await self.disconnect()
File "/config/custom_components/envisalink_new/pyenvisalink/envisalink_base_client.py", line 172, in disconnect
await self._writer.wait_closed()
File "/usr/local/lib/python3.10/asyncio/streams.py", line 344, in wait_closed
await self._protocol._get_close_waiter(self)
File "/usr/local/lib/python3.10/asyncio/selector_events.py", line 854, in _read_ready__data_received
data = self._sock.recv(self.max_size)
ConnectionResetError: [Errno 104] Connection reset by peer
2023-01-14 12:48:06.104 ERROR (MainThread) [custom_components.envisalink_new.pyenvisalink.envisalink_base_client] Command '02' failed due to timeout waiting for response from EVL

[ufodone]

I've got the log file now so feel free to remove it.

For the log snippet you just posted, is there anything earlier in the logs related to the envisalink?