The Asterisk component
After looking at how other platforms were set up in Home Assistant(HA), I ended up with the conclusion that I want to configure my component like this in configuration.yaml:
I now created a file: custom_components/asterisk.py :
One of the most important lines is line 9 where I define the logger that i relied heavily on in my debugging process! It can be used to log different log levels. It is for example used in line 34. Under my development process I logged to .error to make it easy to spot in HA logs.
In line 18 to 25 I define how the config parameters (from configuration.yaml) should be. This information tells HA how to validate the config fields. If these fields are not correctly provided, HA will fail loading this component.
In line 28 is the setup function. This is called when HA loads the component.
In line 29-33 I extract the actual values from the configuration.yaml file.
in line 36 I create the pyst2 AMI object that I will be referencing later when sending commands and getting events from Asterisk. If I succeed connecting to AMI (in line 38-39), I will store this object in the global hass.data object (line 40). It seems a descent way to pass objects an variables between HA components.
Now I have the basic setup of the Asterisk component. Now I can move on the the fun part of creating a sensor that will get actual extension status from Asterisk.
The Extension Sensor component
In the configuration.yaml I want to create my sensors like this:
I decided to call my platform “astext” for “Asterisk Extension”. In this case I will be watching two extensions.
Now I created the sensor component in custom_components/sensor/astext.py :
In line 12 I tell HA that this sensor should not be loaded unless my previously shown asterisk component is loaded correctly..
Line 14-16 tells HA to expect the parameter “extension” in the platform setup of the astext sensor.
Line 19-22 is called when each astext sensor is set up. In my case twice (extension 1000 and extension 1001)
Line 22 registres the AsteriskExtension class (defined in line 24). It passes the hass object and the extension number that was fetched from the sensor platform setup. The “true” parameter tells HA to update the state of sensor on startup.
Line 24-51 is the class the handles the astext sensor. An instance of this class is instanciated for each sensor defined (in my case 2).
Line 27 gets the AMI object that was setup in part1 of this blog. This object is used for communication with AMI.
Line 30 registers the eventhandler for incoming AMI events from Asterisk. We are only listening to events of type ‘ExtensionStatus’. The registration is pointing to the class method defined in line 33.
Line 34-35 gets the extension number and the extension state from AMI. Because we receive events for ALL extensions in Asterosl, we make sure it is for the extension that this instance handles. This is Checked in line 36.
Line 38 keeps the state of the Asterisk extension in a local class variable called “_state”
Line 39 tells HA that the state of this class instance has changed. After HA gets this message, it will go fetch the state. It will get it by calling method in line 45-47
Line 41-43 tells HA how to name the instances of the astext sensor. In my case they will be called “sensor.asterisk_extension_1000” and “sensor.asterisk_extension_1001”
Line 49-51 is called regularly by HA (around every half minute). It tells this class to fetch the status from Asterisk.
What do we have now?
After restarting HA and checking the logs you should see this in the developer tools/states:
In the last part I will glue it all together in an automation, that makes things happen.