The envisalink component does not currently support:
SERVICE_ALARM_ARM_NIGHT
or
STATE_ALARM_ARMED_NIGHT
There appears to be manual ways to get around this with keypresses, but none of them pass through to homebridge.
I’d love to see this support added.
Hi mike- took a quick look at this, since I put the envisalink component together originally. I don’t believe this is possible, since the envisalink api only has arm stay/arm away, with arm stay being what’s typically used at night. My Honeywell panel also only has those 2 modes. Is there a dsc panel you have that has distinct arm night vs arm stay?
Hey! Thanks for responding. I finally got some time to look at this tonight.
My panel is an Ademo Vista 21IP. From a disarmed state if I enter code+7 it will arm the system instant, which from my touch panel (Ademco Tuxedo Touch) is the exact same thing as “arm night”.
It looks like in your code you’d need to add:
def arm_night_partition(self, code, partitionNumber):
self.keypresses_to_partition(partitionNumber, code + '7')
Then reading through the API docs in EnvisaLinkTPI-ADEMCO-1-03.pdf (http://forum.eyez-on.com/FORUM/download/file.php?id=224&sid=15d6c34c16d1ca959182e6fc31ed9aba)
It does appear to report that mode properly:
3.3 under “LED/ICON Bitfield”
“07” is what I’m looking for:
LED/ICON Bitfield
The is a two byte, HEX, representation of the bitfield. When a bit is set to
1, the means the keypad would display the associated ICON or LED.
Bit Pos: Description
15: ARMED STAY
14: LOW BATTERY
13: FIRE
12: READY
11: Not Used
10: Not Used
09: CHECK ICON – SYSTEM TROUBLE
08: ALARM (FIRE ZONE)
07: ARMED (ZERO ENTRY DELAY)
and in section 3.4 “Partition Status Codes”
it does seem to understand “NIGHT” which to me is “06”
00 – Partition is not Used/Doesn’t Exist
01 – Ready
02 – Ready to Arm (Zones are Bypasses)
03 – Not Ready
04 – Armed in Stay Mode
05 – Armed in Away Mode
06 – Armed Instant (Zero Entry Delay - Stay)
07 – Exit Delay (not implemented on all platforms)
08 – Partition is in Alarm
09 – Alarm Has Occurred (Alarm in Memory)
10 – Armed Maximum (Zero Entry Delay - Away)
If you want me to test anything for you / play with anything let me know.
I’m running an Envisalink 4 with a Vista 20P system. If I double-tap “Arm Home” in HA it will invoke Night Stay mode.
I can’t find anything written up about this yet, so hopefully I’m not reporting a feature that was obvious to the whole world except me. 
This is copied from my automation.yaml, it works!
alias: House alarm Weekday ARMED at Midnight
trigger:
platform: time
hours: 00
minutes: 01
seconds: 00
condition:
condition: time
weekday:
alias: House alarm daily DISARMED at 7AM
trigger:
platform: time
hours: 07
minutes: 00
seconds: 00
condition:
condition: time
weekday:
I was wondering about this also. I have a Honeywell panel and it has a night mode. It’s called “instant” and you press *7 to activate it. @Cinntax any chance I can help test? Just got my envisalink up and running yesterday on Honeywell vista p20.
Okay- after looking at this closer i do agree this is pretty trivial. I have gone ahead and implemented this: https://github.com/Cinntax/home-assistant/tree/dev
Can you please test?
By the way, looks like in general the alarm control panel UI is only supporting arm home/away at the moment- but if you go into the dev-services screen, you’ll be able to call the alarm_control_panel.arm_night service to invoke this, and setup an automation- until the UI is updated.
Wow awesome!! Thanks
I just upgraded to hassos so need to figure out how to join the dev branch and test this out (and how to revert to stable afterwards so wife doesn’t kill me)… or will it be included in the next 0.76 release getting pushed this Sunday? Either way I’m on vacation this week traveling so would need to be remotely or wait till next.
I was able to test the component and the service appears. However when I call it we get the following:
Error executing service <ServiceCall alarm_control_panel.alarm_arm_night (c:8308b372b0964bf88905b0603500b51f): entity_id=[‘alarm_control_panel.home_alarm’], code=>
Traceback (most recent call last):
File “/usr/local/lib/python3.6/site-packages/homeassistant/core.py”, line 1115, in _event_to_service_call
await service_handler.func(service_call)
File “/config/custom_components/alarm_control_panel/init.py”, line 140, in async_alarm_service_handler
yield from getattr(alarm, method)(code)
File “/usr/local/lib/python3.6/asyncio/coroutines.py”, line 212, in coro
res = func(*args, **kw)
File “/config/custom_components/alarm_control_panel/envisalink.py”, line 157, in async_alarm_arm_night
self.hass.data[DATA_EVL].arm_night_partition(
AttributeError: ‘EnvisalinkAlarmPanel’ object has no attribute ‘arm_night_partition’
Hey @Cinntax - good news. I was able to load as a custom component, and seems HA pulls the latest pyenvisalink library where you’ve implemented the arm night call. Very cool. Did not realize it would do that.
In short, it works great! THANK YOU!! There is a custom lovelace UI card I am using that even exposes it as a mode.
A few more things to get your thoughts on:
I noticed the component state would not always be accurate, eg., it would never report “Armed night”. I found the logic in HA and submitted a pull request to adjust how I think it’s supposed to work. I am not great with git or python, so maybe further changes are required, but hopefully it helps.
There is another type of arming that seems trivial to implement, as you’ve got most of the code in there already. It’s called Arm MAX, which is when you arm away (eg., proximity + motion) and there is no entry delay (anything that trips immediately sets the alarm). Sometimes this is called Vacation mode. I think there are some small changes required to the alarm_control_panel platform, but should be trivial. I have it working locally and can submit a PR to see if you agree. Will probably need some changes
In doing so, I noticed the entry_delay / exit_delay logic seem to be a bit off … when arming the alarm there should be a period where exit_delay is active (eg., beeping signal you to exit). It works correctly for Arm Away, but not other types of arming. It should happen for all alarm states (at least on my honeywell panel). I believe the issue may be with pyenvisalink but not certain.
I have not tested any entry_delay logic as it requires you to physically trip the alarm once it is armed. This should only happen in arm away and arm home states since arm night and arm max specifically made to not have this delay.
What is your take on this one?
Oh great to hear you got it working- when i saw the error message, i was thinking that was likely the issue, but it got me thinking if maybe i neglected to update the requirements_all.txt file or something.
I see in your PR you also put the night_mode service in and added additional logic for the statuses- looks good (other than fixing the style issues).
The only issue with arm_max is that there doesn’t appear to be a service defined for it yet in the alarm_control_panel parent component- meaning we’d need to add it there first prior to defining it in the envisalink component, so it’s a bit more involved given it technically impacts all alarm control panel.
But anyway- that method is already present in pyenvisalink, so there shouldn’t be anything there.
I updated the PR with a commit to add in the arm_max service call to alarm_control_panel. It was pretty simple just copying from the arm_night code. Would appreciate others testing it out.
I am completely new to git so it was unintentional to submit your arm_night code in the PR. I actually thought i was submitting a PR to your branch (since i forked from there) … rather than the overall homeassistant dev. Sorry about that. The code worked perfectly so guess that was the next step anyway!! Hopefully it gets accepted now that I’ve fixed the style issues on my side…
Any thoughts on the exit_delay status issue mentioned above?
Hi, nice work!
I set the Italian language in Hass.io , the harm_home and harm_away are displayed with . the right translation , only harm_night remain untranslated(shows HARM NIGHT )
can you please help me? do i have to set the labels ?
I have opposite question for Envisalink module: in HomeKit isn’t possible to hide Night Mode?
I had to switch back to homebridge for Vista 20P because even though HomeKit will call “alarm_arm_night” (which Envisalink must support since Homebridge does it fine), in HA it just ignores that call as unimplemented (timed out) and looking at the envisalink.py code it doesn’t look like it handles it.
I’m following along in this discussion and see that the PR got closed out due to inactivity. I attempted to use alarm_arm_night and it shows as not implemented. Was there a plan to get this into stable hass.io?
Yeah as i recall there was someone else working on that a while back, didn’t see where they landed until recently. The pyenvisalink library is all setup to pass the command- so the plumbing is in place, just need to install the sink, so to speak. I’m in the middle of the commit process for some bug fixes, but once I get that tested I can get this in.
Good day, I wanted to try and keep this thread alive. I see several Hass.io updates took place since the last time I looked at this thread. Any more movement getting this into the official release?
I just updated from 87.1 to 88.0. My Arm Night-using the directions in this thread-worked prior to 88.0 Here are the errors I am seeing:
Error while executing automation automation.arm_night_stay_instant. Unknown error for call_service at pos 1:
9:06 AM components/alarm_control_panel/init.py (ERROR)
Error handling message: {‘type’: ‘call_service’, ‘domain’: ‘alarm_control_panel’, ‘service’: ‘alarm_arm_night’, ‘service_data’: {}, ‘id’: 18}
9:06 AM components/alarm_control_panel/init.py (ERROR)
Not passing an entity ID to a service to target all entities is deprecated. Update your call to alarm_control_panel.alarm_arm_night to be instead: entity_id: all
9:06 AM helpers/entity_component.py (WARNING) - message first occured at 9:06 AM and shows up 2 times
Not passing an entity ID to a service to target all entities is deprecated. Update your call to alarm_control_panel.alarm_disarm to be instead: entity_id: all
7:06 AM helpers/entity_component.py (WARNING)
Anyone else seeing this or have suggestions to fix?
Thanks!
More details:
Fri Feb 22 2019 09:06:24 GMT-0500 (Eastern Standard Time)
Error while executing automation automation.arm_night_stay_instant. Unknown error for call_service at pos 1:
Traceback (most recent call last):
File “/usr/local/lib/python3.7/site-packages/homeassistant/components/automation/init.py”, line 375, in action
await script_obj.async_run(variables, context)
File “/usr/local/lib/python3.7/site-packages/homeassistant/helpers/script.py”, line 131, in async_run
await self._handle_action(action, variables, context)
File “/usr/local/lib/python3.7/site-packages/homeassistant/helpers/script.py”, line 210, in _handle_action
action, variables, context)
File “/usr/local/lib/python3.7/site-packages/homeassistant/helpers/script.py”, line 299, in _async_call_service
context=context
File “/usr/local/lib/python3.7/site-packages/homeassistant/helpers/service.py”, line 85, in async_call_from_config
domain, service_name, service_data, blocking=blocking, context=context)
File “/usr/local/lib/python3.7/site-packages/homeassistant/core.py”, line 1133, in async_call
self._execute_service(handler, service_call))
File “/usr/local/lib/python3.7/site-packages/homeassistant/core.py”, line 1155, in _execute_service
await handler.func(service_call)
File “/config/custom_components/alarm_control_panel/init.py”, line 140, in async_alarm_service_handler
yield from getattr(alarm, method)(code)
File “/usr/local/lib/python3.7/concurrent/futures/thread.py”, line 57, in run
result = self.fn(*self.args, **self.kwargs)
File “/usr/local/lib/python3.7/site-packages/homeassistant/components/alarm_control_panel/init.py”, line 130, in alarm_arm_night
raise NotImplementedError()
NotImplementedError