ufodone / pyenvisalink Goto Github PK

In HASS, with a Honeywell Vista 21ip panel, the last_disarmed_by_user and last_armed_by_user attributes are empty.
They seem to get populated with DSC Panels, but not with Honeywell. Is it something you can fix maybe?

I'm using your component in Home Assistant with a DSC security system and generally it is working well. However, last night I had an issue where closing a door showed up as closed in HA, but then immediately showed up as open and then within maybe 30 seconds went back to closed. This, of course, is problematic as opening the door turns on the light and the open causes it to turn on again after I turned it off.

I believe that there may be a race condition whereby you query for a zone dump, are waiting for a response, get the status change and then when the zone dump comes in, it overwrites the status change. I've changed my zone dump interval to 86400 to reduce this possibility and my testing has not encountered this issue again.

While I'm not sure the logic to handle this (maybe if there is a status update, cancel the zone update and wait for the next zone update), how about adding an option for 0 for the zone dump interval? Looking through the code, I think that passing a 0 to asyncio.sleep for the delay will cause no delay.

Thanks!

These things don't support NTP... well, at least not the Envisalink 3. Not sure if others do. It would be nice to have accurate time.

There is a rare edge case where it is possible that both handle_connect_failure() and connection_lost() can be called during a stalled connection attempt to the EVL. This will result in reconnect() being scheduled twice. Because the EVL can only support a single connection at a time, this results in the first reconnect establishing a connection and getting status updates, etc. from the EVL and the second reconnect attempt constantly looping trying to reconnect, failing to do so due to the single connection limit, and then reconnecting again.

Associated Home Assistant issue is here: home-assistant/core#68317

According to the Home Assistant log, this deprecation warning originated from "/pyenvisalink/envisalink_base_client.py". I did see that there were some very recent updates, but I did not find if this issue was reported before.

2022-01-16 09:13:31 WARNING (MainThread) [homeassistant.helpers.frame] Detected code that called async_timeout.timeout with loop keyword argument. The loop keyword argument is deprecated and calls will fail after Home Assistant 2022.2. Please report this issue.

Stack (most recent call last):
File "/usr/local/lib/python3.9/runpy.py", line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/local/lib/python3.9/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/usr/src/homeassistant/homeassistant/__main__.py", line 331, in <module>
sys.exit(main())
File "/usr/src/homeassistant/homeassistant/__main__.py", line 318, in main
exit_code = runner.run(runtime_conf)
File "/usr/src/homeassistant/homeassistant/runner.py", line 121, in run
return loop.run_until_complete(setup_and_run_hass(runtime_config))
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 629, in run_until_complete
self.run_forever()
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 596, in run_forever
self._run_once()
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 1890, in _run_once
handle._run()
File "/usr/local/lib/python3.9/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.9/site-packages/pyenvisalink/envisalink_base_client.py", line 61, in connect
async with async_timeout.timeout(self._alarmPanel.connection_timeout, loop=self._eventLoop):
File "/usr/src/homeassistant/homeassistant/async_timeout_backcompat.py", line 19, in timeout
report(
File "/usr/src/homeassistant/homeassistant/helpers/frame.py", line 74, in report
_LOGGER.warning(msg, stack_info=True)
Stack (most recent call last):
File "/usr/local/lib/python3.9/runpy.py", line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/local/lib/python3.9/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/usr/src/homeassistant/homeassistant/__main__.py", line 331, in <module>
sys.exit(main())
File "/usr/src/homeassistant/homeassistant/__main__.py", line 318, in main
exit_code = runner.run(runtime_conf)
File "/usr/src/homeassistant/homeassistant/runner.py", line 121, in run
return loop.run_until_complete(setup_and_run_hass(runtime_config))
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 629, in run_until_complete
self.run_forever()
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 596, in run_forever
self._run_once()
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 1890, in _run_once
handle._run()
File "/usr/local/lib/python3.9/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.9/site-packages/pyenvisalink/envisalink_base_client.py", line 61, in connect
async with async_timeout.timeout(self._alarmPanel.connection_timeout, loop=self._eventLoop):
File "/usr/src/homeassistant/homeassistant/async_timeout_backcompat.py", line 19, in timeout
report(
File "/usr/src/homeassistant/homeassistant/helpers/frame.py", line 74, in report
_LOGGER.warning(msg, stack_info=True)

My envisalink board is working great except for one remaining issue:
It triggers an error log entry every 10 seconds in home assistant log (home-assistant.log)

2023-05-12 13:16:15.481 ERROR (MainThread) [pyenvisalink.honeywell_client] Unrecognized data recieved from the envisalink. Ignoring.
2023-05-12 13:16:25.404 ERROR (MainThread) [pyenvisalink.honeywell_client] Unrecognized data recieved from the envisalink. Ignoring.

Honeywell Vista 15P chip" WA15P-5.3, copyright Honeywell, 2006, rev 5.3
EyeZon EVL4 HW version 190, Firmware Version: 01.00.30A

Is there any way to get more details about the root cause? Pyenvisdalink has access to the actual unrecognized data. It is easy to determine where in the pyenvisalink the error message is generated.

Is there a switch for a more detailed log message? Or, if there is no fix on VISTA or envisalink board level, can the log output be suppressed for this particular error?

Overall the pyenvisalink is working great. I see all events in Home Automation and think that this is a great communicator board to modernize an existing, well-working wired alarm system.

Please advise.

Regards,

Marc

Many of us using HA are seeing the above behavior with our 20P. The behavior appears to happen when we have more than 4 or 5 sensors open. Below that number, everything behaves as expected; and once exceeded, the log shows these sensors gyrating between open and closed incessantly even when the related item is not changing.

I am not sure why this is and if it is even an issue with pyenvisalink. It is worth noting that the Envisalink web GUI does not show this behavior and so it feels like this is something specific to pyenvisalink/HA.

Any help anyone can provide would be appreciated.

I am currently running with HA 2022.9.1, but I have seen this with previous releases as well.

Multiple HA users experienced DSC physical keypad unavailable and its directly related to added zone bypass future, more here:
home-assistant/core#65729
home-assistant/core#65762
home-assistant/core#65856

I'm running HomeAssistant with Python 3.10, which seems to have dropped the loop keyword argument to asyncio.sleep.

2022-05-16 23:49:36 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/var/lib/hass/venv/lib/python3.10/site-packages/pyenvisalink/dsc_client.py", line 50, in keep_alive
    await asyncio.sleep(self._alarmPanel.keepalive_interval, loop=self._eventLoop)
TypeError: sleep() got an unexpected keyword argument 'loop'
2022-05-16 23:49:36 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/var/lib/hass/venv/lib/python3.10/site-packages/pyenvisalink/dsc_client.py", line 57, in periodic_zone_timer_dump
    await asyncio.sleep(self._alarmPanel.zone_timer_interval, loop=self._eventLoop)
TypeError: sleep() got an unexpected keyword argument 'loop'

[I'm not sure whether this issue should be against this library, the Home Assistant integration, or both]

Currently if there is a zone fault, such as RF heartbeats that haven't been received for long enough, that information doesn't appear to be available to home assistant.

Observations on current behavior, during an RF timeout:

• The keypad entity does have the attribute trouble: true but doesn't indicate what the problem is. There is no attribute for trouble with a zone.
• The panel changes the zone state to open when the zone fault occurs. That is reflected in the entity for the zone, and last_tripped_time is updated.
• There don't appear to be any attributes for the zone entity that would indicate trouble with the zone, tamper, or zone low battery in the case of a wireless sensor.
• verbose trouble status code 849 is set to 0x10. That bit is Zone fault according to the Envisalink docs.

I'm not sure what the best way to expose this to Home Assistant, some ideas include:

1. Additional zone entity attributes expose fault, tamper, low battery.

   (I'm assuming since there aren't currently attributes for tamper or battery that they aren't currently implemented at a zone level. There is a keypad attribute for bat_trouble. but I think that might be tied to the panel's backup battery rather than RF sensors. I haven't tested that so I could be wrong.

2. Additional keypad boolean attributes that cover the bits from verbose trouble status (849):

• 0x10 - Sensor/Zone Fault

• 0x20 - Sensor/Zone Tamper

• 0x40 - Sensor/Zone Low Battery

  On a related note, there don't appear to be keypad (partition) or panel level attributes for these other verbose trouble status bits:

• 0x01 - Service is Required

• 0x04 - Telephone Line Fault

• 0x08 - Failure to Communicate

• 0x80 - Loss of Time

One of the simplest things to do might be to expose the verbose_trouble_status byte as an attribute of either the keypad or panel. However there might be a catch that I don't think the Envisalink ever sends 849 00 to turn off all of the trouble bits. I think the verbose trouble status may only be valid when it is also sending 510/511 keypad LED state/keypad LED flash state.

I'll have to dig through my logs. I'm logging everything because I'm using Juggie's AlarmServer to be a proxy for the Envisalink. It gets around the single connection problem.

Edit: when trouble cleared, it didn't send a verbose trouble update, but did send 510 and 841 - to clear the trouble in addition to the 606 to clear the zone fault.

When is zone bypass switches coming back to HA?

Is there a workaround to enable them on the latest version?