Envisalink Night mode for Vista is not correct

[ryanpie86]

The problem

When arming system in Night Stay (code + 33), Home Assistant reports that it is just armed Home. Additionally, the call from HA to arm Night Stay is using Instant (code + 7). These are two entirely different modes.

I suspect this is because the integration may have been developed to cater to the lesser ADT or 3rd party branded Vista panels which are missing features.

When using the EyezOn app to arm Night Stay, it uses Code + 33 as intended, just not HA itself.

What version of Home Assistant Core has the issue?

2022.11.5

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

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

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @ufodone, mind taking a look at this issue as it has been labeled with an integration (envisalink) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `envisalink` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Change the title of the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign envisalink` Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

envisalink documentation envisalink source _{^{(message by IssueLinks)}}

[ufodone]

You're likely right that this was initially developed for lesser systems. I had a look at the Envisalink TPI documentation (the latest I've been able to find is from 2017!) and it has some references to Ademco panels and them not being very sophisticated.

I don't have a Honeywell system nor do I know what would happen if 'code' + 33 was sent to an older system. So unfortunately I don't think I could just change from 'code' + 7 to 'code' + 33 as it may break other users. It could certainly be a configuration option but unfortunately this integration hasn't been upgraded to the current HA config system and the maintainers are not accepting any changes to configuration using the old system so it's not possible to add this as a configuration without first upgrading to the new system. That's been on my list for long time but I just haven't found the time yet.

[ryanpie86]

Code + 33 sent to an ADT or Brinks panel would arm it in Stay mode, it would just ignore the extra 3. The correct fix here is to just name the modes what they truly are for Honeywell. Code+7 is "Instant" mode on all Vista panels.

I would change the existing option for "Night" to "Instant" and then add the +33 for Night mode, which the documentation can simply reflect. Night mode may or may not be available depending on the panel at hand, which is the truth.

I'm no expert developer, but I would love to help with this in some way. I am a commercial alarm technician also, so if there is some specific data you need about Vistas, I can get it for you.

On Sun, Dec 11, 2022, 8:03 PM ufodone @.***> wrote:

You're likely right that this was initially developed for lesser systems. I had a look at the Envisalink TPI documentation (the latest I've been able to find is from 2017!) and it has some references to Ademco panels and them not being very sophisticated.

I don't have a Honeywell system nor do I know what would happen if 'code'

• 33 was sent to an older system. So unfortunately I don't think I could just change from 'code' + 7 to 'code' + 33 as it may break other users. It could certainly be a configuration option but unfortunately this integration hasn't been upgraded to the current HA config system and the maintainers are not accepting any changes to configuration using the old system so it's not possible to add this as a configuration without first upgrading to the new system. That's been on my list for long time but I just haven't found the time yet.

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/83092#issuecomment-1345726253, or unsubscribe https://github.com/notifications/unsubscribe-auth/AS5MECRXI3H4CXN2GZJURYDWMZ2VRANCNFSM6AAAAAASRPTTXE . You are receiving this because you authored the thread.Message ID: @.***>

[greggitter]

It would be great if this were fixed as I can't use it fully in its current form, we always use night-stay (33). I'm wondering if it's possible to allow the user to set up a custom code, then those with Honeywell could add the night-stay code suffix and name it as we want (in the config file). I'm very new to HA so maybe that's not easy nor practical. I'm grateful this add-on is available at all since it can still be queried...so thanks for that (was a great surprise when I was checking what was available)! Seems like a solid community and glad to become a part of it. Cheers.

[ryanpie86]

If any custom config needs to be done, honestly, that should be left to the users of the lesser featured panels. The default modes of the full featured Vista panels should just be what are automatically configured, as the EVL4 itself does. If a user is missing features because of using a branded (ADT, Brinks, etc) Vista panel, it should be on them to change their configuration to match it.

But alas, HA is moving away from YAML configured integrations altogether, so I believe that is why this can't be updated for now. As someone with beginner to moderate-beginner Python skills, how can I assist in updating this code with you? If you could explain where to begin to understand how this integration works, I can try and help out.

On Mon, Dec 12, 2022 at 11:01 AM greggitter @.***> wrote:

It would be great if this were fixed as I can't use it fully in its current form, we always use night-stay (33). I'm wondering if it's possible to allow the user to set up a custom code, then those with Honeywell could add the night-stay code suffix and name it as we want (in the config file). I'm very new to HA so maybe that's not easy nor practical. I'm grateful this add-on is available at all since it can still be queried...so thanks for that (was a great surprise when I was checking what was available)! Seems like a solid community and glad to become a part of it. Cheers.

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/83092#issuecomment-1346789461, or unsubscribe https://github.com/notifications/unsubscribe-auth/AS5MECRFW6GBWAMFAVZ2NRDWM5D45ANCNFSM6AAAAAASRPTTXE . You are receiving this because you authored the thread.Message ID: @.***>

[ufodone]

Right, it's not that the defaults couldn't be changed but rather that I think there would be a need to allow the current setup to continue to work as-is and I think the only way to do that would be via configuration - which I can't change until the integration is upgraded to the latest config system. I do want to get that done but just haven't found the time.

My other challenge is that I don't have a Honeywell/Vista system so I have nothing I can test against. If you're willing to test and provide debug info for me I could have a go at the changes. We could probably do that via HACS.

Getting the changes into an official HA release would still require the configuration upgrade though.

[cmonteiro128]

Would the alarm_keypress service work as a workaround?

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.