# -*- coding: utf-8 -*-
from setuptools import setup

packages = \
['elkm1_lib']

package_data = \
{'': ['*']}

install_requires = \
['pyserial-asyncio>=0.5']

setup_kwargs = {
    'name': 'elkm1-lib',
    'version': '1.3.2',
    'description': 'Library for interacting with ElkM1 alarm/automation panel.',
    'long_description': '# Python ElkM1 library\n\n[![PyPI version](https://badge.fury.io/py/elkm1-lib.svg)](https://badge.fury.io/py/elkm1-lib)\n[![CI](https://github.com/gwww/elkm1/actions/workflows/code-quality.yml/badge.svg)](https://github.com/gwww/elkm1/actions/workflows/code-quality.yml)\n[![Downloads](https://pepy.tech/badge/elkm1-lib)](https://pepy.tech/project/elkm1-lib)\n[![License](https://img.shields.io/github/license/mashape/apistatus.svg)](https://pypi.org/project/elkm1_lib/)\n\nLibrary for interacting with ElkM1 alarm/automation panel.\n\nhttps://github.com/gwww/elkm1\n\n## Requirements\n\n- Python 3.6 (or higher)\n\n## Description\n\nThis package is created as a library to interact with an ElkM1 alarm/automation\npattern. The motivation to write this was to use with the Home Assistant\nautomation platform. The library can be used for writing other ElkM1 integration\napplications. The IO with the panel is asynchronous over TCP or over the\nserial port.\n\n## Installation\n\n```bash\n    $ pip install elkm1_lib\n```\n\n## Overview\n\nBasic connection to the Elk panel:\n\n```python\n    from elkm1_lib import Elk\n    import logging\n\n    # Print to STDOUT\n    LOG = logging.getLogger(__name__)\n    logging.basicConfig(level=logging.DEBUG, format=\'%(message)s\')\n\n    # Connect to elk\n    elk = Elk({\'url\': \'elk://192.168.1.100\'})\n    elk.connect()\n    elk.run()\n```\n\nThe above will connect to the Elk panel at IP address 192.168.1.100. the `elk://`\nprefix specifies that the connect is plaintext. Alternatively, `elks://` will\nconnect over TLS. In this case a userid and password must be specified\nand the call to `Elk` changes to:\n\n```python\n    elk = Elk(\n        {\'url\': \'elks://192.168.1.100\', \'userid\': \'test\', \'password\': \'pass\'}\n    )\n```\n\nThe following ElkM1 connection protocols are supported:\n- serial:// - Serial port;\n- elk:// - Elk M1XEP Ethernet, non-secure\n- elks:// - Elk M1XEP Ethernet, secure, TLS 1.0\n- elksv1_0:// - Elk M1XEP Ethernet, secure, TLS 1.0, supported on M1XEP version < 2.0.46\n- elksv1_2:// - Elk M1XEP Ethernet, secure, TLS 1.2, supported on M1XEP version = 2.0.46\n- elksv1_3:// - Elk M1XEP Ethernet, secure, TLS 1.2, not yet supported on M1XEP, reserved for future\n\nA username and password are required for any of the secure modes.\n\nTo see working example code take a look at the script `bin/simple`.\n\nThe `Elk` object supports the concept of `Elements`. An `Element`\nis the base class representation of `Zones`, `Lights`, etc. So, for\nexample there is a list of zones: `elk.zones` and each zone can be\naccessed by `elk.zones[index]`. Each element has a `__str__`\nrepresentation so that it is easy to print its contents.\n\nAll `Elements` are referenced starting at 0. Even though the Elk panel\nrefers to, for example, zones 1-208, the library references them\nas zones 0-207. All translation from base 0 to 1 and vice-versa is\nhandled internally in the `elkm1_lib.message` module.\n\nAfter creating the `Elk` object and connecting to the panel the\nlibrary code will synchronize all the elements to the data from the Elk panel.\n\nMany Elk messages are handled by the library, caching their contents. When a\nmessage causes a change to an attribute of an `Element`, registered\ncallbacks are called so that user use of the library can be notified\nof changing elements. The following user code shows registering a callback:\n\n```python\n    def call_me(element, changeset):\n       print(changeset)\n\n    for zone_number in range(Max.ZONES.value):\n      elk.zones[zone_number].add_callback(call_me)\n```\n\nThe library encodes, decodes, and processes messages to/from the\nElk panel. All the encoding and decoding is done in `elkm1_lib.message` module.\n\nMessages received are handled with callbacks. The library\ninternally registers callbacks so that decoded messages\ncan be used to update an `Element`. The user of the\nlibrary may also register callbacks. Any particular message\nmay have multiple callbacks.\n\nWhen the message is received it is decoded\nand some validation is done. The message handler is called\nwith the fields of from the decoded message. Each type of\nmessage has parameters that match the message type. All handler parameters\nare named parameters.\n\nHere is an example of a message handler being registered and how it is called:\n\n```python\n    def zone_status_change_handler(zone_number, zone_status):\n      print(zone_number, zone_status)\n\n    elk.add_handler(\'ZC\', zone_status_change_handler)\n```\n\nThe above code registers a callback for \'ZC\' (Elk zone status change)\nmessages. When a ZC message is received the handler functions are called\nwith the zone_number and zone_status.\n\nThere are a number of pseudo-handlers that act like the handlers. These are\ncalled when events happen. The pseudo-handlers are:\n\n- `connect`: When a successful connection to the ElkM1 is completed.\n- `disconnect`: When a connection to a panel is disconnected.\n- `login`: When a login is made to the panel (using `elks://` connection mode.\n  A single boolean parameter is passed `succeeded`.\n- `sync_complete`: When the panel has completed synchonizing all its elements.\n- `timeout`: When a send of a message to the ElkM1 times out (fails to send).\n- `unknown`: When a message from the ElkM1 is received and the library does\n  not have a method to decode the message. The message is passed to this handler\n  and can be decoded outside of the library.\n\n## Utilities\n\nThe `bin` directory of the library has one utility program and\na couple of example uses of the library.\n\n### `mkdoc`\n\nThe utility `mkdoc` creates a Markdown table of the list of Elk\nmessages with a check mark for those messages have encoders/decoders\nand an X for those messages are not planned to be implemented.\nThere are no parameters to `mkdoc`. It outputs to stdout.\nThe data for the report comes from the ElkM1 library code mostly.\nA couple of things are hard coded in the mkdoc script, notably\nthe "no plans to implement" list.\n\n### `simple`\n\nThe `simple` Python script is a trivial use of the ElkM1 library.\nIt connects to the panel, syncs to internal memory, and continues\nlistening for any messages from the panel. The URL of the ElkM1 to\nconnect to is retrieved from an environment variable named `ELKM1_URL`.\n\n### `elk`\n\nThe `elk` Python script is a bit of a command interpretor. It can run in\ntwo modes. Non-interactive mode is the default. Just run the `elk` command.\nThe non-interactive mode is similar to `simple` except there are a\ncouple of message handlers (`timeout` and `unknown` handlers).\n\nThe `elk` can also be run in interactive mode by invoking it by\n`elk -i`. In this mode is uses curses (full screen use of the terminal)\nthat has a command line and an output window. `TAB` switches between\nthe command line and output windows. In the output window the arrow keys\nand scrollwheel scroll the contents of the window.\n\nIn the command line when running `elk -i` there are a\nnumber of commands. Start with `help`. Then `help <command>` for\ndetails on each command. In general there are commands to dump the internal\nstate of elements and to invoke any of the encoders to send a message\nto the Elk panel.\n\nFor example, `light <4, 8, 12-14` would invoke the `__str__` method\nfor the light element to print the cached info for lights 0-3, 8, and 12-14.\n\nAnother example would be `pf 3` which issues the pf (Turn light off)\ncommand for light number 3 (light 4 on the panel -- remember 0\nversus 1 base).\n\nAll of the commands that send messages to the panel are automatically\ndiscovered and are all the XX_encode functions in the ``elkm1_lib.message``\nmodule. The docstring and the XX_encode\'s parameters are shown as part\nof the help.\n\n## Development\n\nThis project uses [poetry](https://poetry.eustace.io/) for development dependencies. Installation instructions are on their website.\n\nTo get started developing:\n\n```\ngit clone https://github.com/gwww/elkm1.git\ncd elkm1\npoetry install\npoetry shell # Or activate the created virtual environment\nmake test # to ensure everything installed properly\n```\n\nThere is a `Makefile` in the root directory as well. The `make` command\nfollowed by one of the targets in the `Makefile` can be used. If you don\'t\nhave or wish to use `make` the `Makefile` serves as examples of common\ncommands that can be run.\n\n## Reporting a Bug\n\nNo problem ;) — report the bugs! But, logs are most often required. If you\nare using Home Assistant, which is about the only use I\'m aware of for\nthis library, then add the following to your `configuration.yaml`:\n```\nlogger:\n  default: info\n  logs:\n    custom_components.elkm1: debug\n    elkm1_lib: debug\n```\n\nDo everything in your power to trim to logs down to their smallest. One way is\nto reproduce your problem quickly so that few other logs are not generated in\nbetween. Another recommendation is to use the simplest configuration that you\ncan think of to reproduce the problem.\n\nCan you reproduce the problem in other ways? If this is a problem that is\nbeing experienced while using Home Assistant try using the `Services` in `Developer Tools`.\n\nSometime logs may have sensitive information in them. You may want to\nscan your logs for that info and "X" it out. In addition, you can send logs\ndirectly to me. Support email is in the `pyproject.toml` file. You may also\nsend a link to somewhere you\'ve stored/shared the file (DropBox for example).\n',
    'author': 'Glenn Waters',
    'author_email': 'gwwaters+elkm1@gmail.com',
    'maintainer': None,
    'maintainer_email': None,
    'url': 'https://github.com/gwww/elkm1',
    'packages': packages,
    'package_data': package_data,
    'install_requires': install_requires,
    'python_requires': '>=3.9,<4.0',
}


setup(**setup_kwargs)
