There is actually a built in “pending” control panel mode in the alarm control panel code, it just does not work with the envisalink integration, same with “arming” when there is an exit delay. I have that fixed in my testing code. But of course this uses the state of exit_delay for arming so that needs to work.
I have an idea why it MIGHT not work, are you using step arming?
I will probably get this fixed upstream since it is fixed in my dev branch
I will also keep looking into the night-stay situation, since that should be fixed in pyenvisalink for proper detection
I’m not. Arming using either the built-in alarm function or keypresses (code + mode), either through the Envisilink integration or the physical keypad.
I see, its because you are doing armed stay, not armed away, I also do not hear exit beeps with stay, only away, and the exit_delay being true only happens during the modes that have beeps (away and max).
I have confirmed through experimentation that the EVL does not report the partition status code as 07 (delay in progress) without the beeps, my guess is internally it detects a beep value of 5 (slow continuous beeps) in order to report that code.
I think pyenvisalink can be EASILY modified to look for “May Exit Now” in the alpha code and report exit_delay as true, that should make it better for everyone and simplify the HA end for detecting that state.
I also captured some data on that unknown beep, the valid values are 0 to 5, and in night-stay it is reporting it is 10, along with instant for the arming mode (ARMED_MAX in current code).
I will brainstorm on how to properly parse that combination to get a working night arm status code of some kind, since the alpha and beep fields are part of a keypad update, and the partition status is a partition update, and looping the logic in the partition update requires the keypad update to occur first… and I am not sure if that happens or not.
aaand it turns out keypad updates are always after the partition update, so it has to be in the keypad code, which makes it a little messier, but I did get both the night stay reporting and the exit delay when there is no beeping to work, though a change to the integration is required to get it to report night stay correctly (among other things)
I also integrated an exit delay countdown timer into the state so it can be parsed as an attribute, with the other catch for the exit delay it only added 3 lines of code
How do you integrate alarm_keypress. I don’t get sensor anywhere in my HA. I have Honeywell with envisalink configured in HA. I need to send ‘D’ on the keypad that I have linked with garage door open and close relay.
The garage door activation script checks to see if the alarm is armed first, so it wont set off the alarm. It is also single operation, so if it runs while already running it wont mess with the door, and it includes appropriate delays, so when the script ends, the garage door will for sure be opened or closed, unless there was some kind of error
I can start a new thread, but I thought I’d try here first.
I have an EnvisaLink 4 board on my DSC panel. It works fine with HA as long as the Envisalerts Server (198.61.170.85) status (using the GUI from the board’s IP) says the Internet-based server is “Online”.
At random times, this server goes offline and HA’s log shows the connection not established. I can reboot the board with a “http://192.168.x.y/3?A=2” link.
If I can’t get the vendor to tell me why this happens, can’t I make an automation that sends a HTTP request to reboot the board, along with the user/password? Or, even more slick would be an automation to detect the “OFFLINE” state of the internet connection, and reset the board then.
Have any of you noticed the same “off the air” issue with your board?
Can’t we just make the integration work locally, without contacting the server?
Interestingly, while communication with the DSC panel won’t allow HA to control the arming state, I can see the sensors that show movement, or door opening, even when the internet server is offline!
I have not seen any kind of comm error between HA and my EVL, I updated a few weeks to 1.4.182, and before and after the update I had no issues.
I have also not looked into if Envisalerts goes offline at any point, I am not using the service and without a comm error have had no reason to look into it. I have had internet connection issues on occasion a, so that does not seem to be the root cause… though it might be specific to the DSC firmware.
I fixed this by setting my EV4 to static addressing.
I don’t see anything about the DHCP server, but when a DHCP request comes in, the connection to the internet-based server is dropped. It seems to recover eventually, but Home Assistant can’t control the state of the alarm panel (DSC).
It’s possible that the internet service doesn’t expect a “few second max” delay in establishing the new connection. In fact, in an existing TCP session, there should be a number of retransmissions, with binary-backoff, before giving up on the flow.
Anyway, it’s nice to see my alarm and set and reset it as needed!
I had a similar issue. My problem related to a weak network connection and so DHCP would fail and the Envisalink would drop offline causing HA to lose access. The problem was that my WiFi to Ethernet repeater was not functioning properly. After replacing it, everything worked smoothly.
On a side note, I sometimes wonder about my EV4 reporting to their cloud and so blocked the connection via my firewall. The EV4 reported that it could not connect to the server, but worked fine in all other respects.
I’m getting this error in the logs but otherwise my sensor is working but this annoying message in the notifications is popping out. I think it started after day light savings on the weekend but I checked the time its correct in envisalink and homeassistant. Any idea what to do ?
def handle_connect_failure(self):
"""Handler for if we fail to connect to the envisalink."""
self._loggedin = False
if not self._shutdown:
_LOGGER.error('Unable to connect to envisalink. Reconnecting...')
self._alarmPanel._loginTimeoutCallback(False)
ensure_future(self.reconnect(30), loop=self._eventLoop)
This routine is called when the library cannot connect to the EVL.
This can occur on initial connector or after a connection loss (which calls for reconnect).
So it tries to reconnect every 30s, is that how often it occurs?
Is there a ‘The server closed the connection. Reconnecting…’ message when this started?
Yes the message says
‘ERROR (MainThread) [pyenvisalink.envisalink_base_client] The server closed the connection. Reconnecting…’
Its been happening every 4-5 minutes
I have checked Envisalink page (http://192.168.x.x)/3) EnvisaLink TPI status is online for homeassistant client.
