This section is mandatory. It contains an array of HomeKit accessories that are available on your device.

Each accessory has a number of keys defined to describe it and how it should behave. The list of keys that can be used in any accessory are contained below. Also check each specific accessory for details of other keys available for that specific accessory type.

Each element of the array is made of an accessory type definition, a set of actions to perform when digital inputs change state and the digital inputs that cause the actions to occur. Multiple accessories can be defined for the same physical device. A configuration file should have the following layout e.g.

{
  "c": { ... },        <-- Configuration definition
  "a": [
    {                  <-- First accessory
      "t": 2,          <-- Accessory Type definition
      "0": { ... },    <-- Action definition
      "1": { ... },    <-- Action definition
      "b": [{ ... }]   <-- Digital I/O input definitions
      "l": [{ ... }]   <-- ICMP Ping input definitions
      "s": 5           <-- Initial State definition
      "k": 0           <-- Kill Switch definition
      "f0": [{ ... }]  <-- State Inputs definitions
      "g0": [{ ... }]  <-- Status Inputs definitions
      "q0": [{ ... }]  <-- ICMP Ping status definitions
      "p0": [{ ... }]  <-- ICMP Ping state definitions
      "y0": [{ ... }]  <-- Wildcard action definitions
    },
    { ... },           <-- Second accessory
    { ... }            <-- Third accessory
  ]
}

The above outline example shows the layout for the configuration settings. The first accessory has been expanded to show the different objects that can be defined for an accessory. The documentation below details the generic information. Refer to each specific device type to understand the actions, digital inputs and notifications available for it.

Every accessory needs to have the type "t" option set. This defines the type of device that the hardware supports e.g. switch, sensor, thermostat etc.

Refer to the list of accessory types to determine the value to use for the "t" option.

Digital inputs array e.g. buttons, are defined by the "b" key within an accessory object.

This is an array of objects defining the GPIOs the inputs use, configuration of the GPIO e.g. whether or not it needs a pull up resistor, and the state of the input e.g. normal or inverted signal.

A digital input is a GPIO pin (or pins) that causes accessory action "0" then accessory action "1" to be triggered each time the defined state in key "b" is met e.g. the first time the input state occurs accessory action "0" will be triggered. The second time the input state occurs accessory action "1" will triggered. The third time the input state occurs accessory action "0" will be triggered etc.

Digital input key "b" is an array object. Multiple GPIO inputs can be defined to cause accessory actions "0" & "1" to be triggered.

{
  "c": {},
  "a": [{
    "t": 1,
    "0": { "r": [{ "g": 12, "v": 0 }] },
    "1": { "r": [{ "g": 12, "v": 1 }] },
    "b": [{ "g": 0, "p": 1, "i": 0,  "t": 1 }]
  }]
}

In the above example a button is attached to GPIO 0 ("g": 0), the internal GPIO pull-up resistor is enabled ("p": 1), the GPIO logic is not inverted ("i": 0) and the button is activated by a single press ("t": 1).

NOTE: The example above has entries for the default values. It is recommended these are omitted in an actual configuration as it will result in a smaller in size and use less memory.

These options are explained in more detail below.

This option is mandatory for each digital input definition and must contain the GPIO number the input is connected to.

Depending on the hardware attached to a GPIO there may be a need for enabling an internal pull-up resistor. The "p" option can be used to enable / disable the pull-up.

With some peripherals and hardware the actual GPIO signal may need to be inverted to ensure the correct action is performed when the GPIO changes state. This is normal for digital inputs that are active low. The "i" option can be used to invert / leave the input signal.

This option defines the type of press required on an input to initiate an action.

You can have the same digital input / GPIO with different press types attached to different accessories or functions.

{
  "c": { "l": 13 },
  "a": [{
    "t": 1,
    "0": { "r": [{ "g": 12, "v": 0 }] },
    "1": { "r": [{ "g": 12, "v": 1 }] },
    "b": [ { "g": 14, "p": 1, "t": 1 }, { "g": 14, "t": 0 }]
  }]
}

In this example we have created a toggle switch by declaring two digital input types with the same GPIO "g": 14 one of press type 1 and one of press type 0. When you press the button down type "t": 0 is triggered and on button up type "t": 1 is triggered (the default type)

ICMP Ping inputs were introduced in firmware version 1.4.0

ICMP ping inputs can be action or state oriented, depending on whether you are trying to update the state of your accessory or perform an action, based on the ping response.

The "l" and "p[n]" objects are action objects and follow the same rules as Digital Inputs and State Inputs. With an "l" key replacing the digital input key "b" and "p[n]" objects replacing "f[n]" objects.

The "q[n]" key is a status key and is used to update the accessory status based on the result of the ping, but not perform the action.

Specific states are defined using the "p[n]" & "q[n]" options (where [n] is an action number e.g. "p0", "q0"). Each device has its own set of actions and these are mapped to the state inputs. Check the device page for details of the specific states.

Ping inputs are triggered only on a response change. If you have set up to listen for a specific state "p0": [{ "h":"iMac-de-Jose","r":0 }] then this state is triggered on the first occurrence of the target host not responding to the ping. If the host remains unresponsive then no further triggers occur until the host becomes responsive and then unresponsive again.

The ping interval is fixed at 5 seconds and 3 failed responses need to occur consecutively before a response type of 0 occurs.

This option is mandatory and must contain the IP address or host name of the device to be targeted with a ping.

NOTE: When using a DNS name ensure that the DNS server allocated in the DHCP server response to the device can resolve the name. There is no mDNS support.

This option defines the expected response in order to trigger the defined action.

In this example we want a power switch to turn on whenever a laptop appears on the local network in order to ensure it gets charged while we are using it.

The switch can be configured to ping the laptop DNS name and when a successful response occurs the power is turned on. Similarly, when the laptop is powered down the ping no longer gets a response and the switch can turn off the power.

{
  "c":{ "l":13 },
  "a":[{
    "t": 1,
    "0": { "r": [{ "g": 12 }] },
    "1": { "r": [{ "g": 12, "v": 1 }] },
    "p0": [{ "h":"iMac-de-Jose","r":0 }],
    "p1": [{ "h":"iMac-de-Jose" }]
  }]
}

In this example we have a Sonoff S20 that uses ping to turn on/off the lounge light when ever the TV is turned on and responds to a ping request.

{
  "c":{ "l":13, "b":[{ "g":0,"t":5 }] },
  "a":[{
    "t": 2,
    "0": { "r": [{ "g":12 }] },
    "1": { "r": [{ "g":12, "v":1 } ]},
    "b": [{ "g": 0 }],
    "p0": [{ "h":"my-tv" }],
    "p1": [{ "h":"my-tv", "r":0 }]
  }]
}

In this example we use ping actions to reflect the current on/off state of the TV e.g. If the TV responds to a ping the HomeKit accessory shows as on in the HomeKit application.

{
  "c":{ "l":13, "b":[{ "g":0,"t":5 }] },
  "a":[{
    "t": 2,
    "q0": [{ "h":"my-tv" }],
    "q1": [{ "h":"my-tv", "r":0 }]
  }]
}

The Inching Time is an accessory option that defines a time period for an accessory to return to the previous state e.g. If the inching time is set to 10 seconds a switch would turn off 10 seconds after turning on.

Inching time is started when action "1" of the accessory is triggered. After the inching time has elapsed action "0" will be triggered. NOTE: the lock mechanism is the opposite of this.

Inching time is a float, so fractions of seconds can be specified e.g. "i":3.5

A typical example of using inching time would be to reset a lock after it has been unlocked.

NOTE: Inching Time is not supported by all accessories, so check before using it.

Initial state is defined by the "s" key contained within the accessory object.

The initial state that an accessory enters on boot can be set using the "s" option.

Check each accessory for details on whether Initial State is supported.

This option was implemented in firmware version 1.10.0

The Execution of Actions on Boot is defined by the "xa" key within the accessory object.

By default actions are enabled on boot, but some circumstances require no actions to be performed during the boot of an accessory. When this is the case the actions can be disabled by setting the "xa" key to 0.

See the TV Service device for an example on why disabling actions is necessary.

Kill Switch is defined by the "k" key contained within the accessory object.

Creates simple HomeKit switch to enable or disable the attached accessory or a part of its functions e.g. "k": 1 will create an additional switch within the HomeApp for this accessory. All actions of this accessory will then work when the Kill Switch is enabled.

{
  "c":{ "l":13 },
  "a":[{
    "t": 2,
    "0": { "r": [{ "g": 12 }] },
    "1": { "r": [{ "g": 12, "v": 1 }] },
    "b": [{ "g": 0, "t": 1 }],
    "k": 1
  }]
}

In this example a secure kill switch has been added to the first accessory. When viewed in the HomeApp an extra switch will show up that can be used to disable operation of the accessory defined in this device.

NOTE: Adding a kill switch will change the number of accessories associated with the device and you will need to reset the HomeKit ID

Wildcard actions are defined by the "y[n]" key within an accessory object.

Wildcard actions were introduced in firmware version 1.7.0

Wildcard actions are used to trigger state changes when a minimum value criteria has been met e.g. when a window cover is opened 68%, when the brightness of a lightbulb is set to 20%, when the fan speed reaches 40% or step 3 etc.

Wildcard actions are defined by "y[n]". Where "y[n]" is normally "y0", but in the case of a device that has a humidity sensor accessory (e.g. "t":24 & "t":25) then "y1" refers to the humidity sensor.

The Target Value "v" is a mandatory key for the wildcard action. It defines the minimum target value required in order to trigger the defined action.

If multiple minimum target values are defined then the action associated with the highest minimum value that satisfies the condition will be performed e.g. in the example below two minimum values are defined; 35ºC & 20ºC. At 36ºC, only the action defined by the 35ºC object will be performed.

The Repeat "r" is used to cause the associated action to be performed each time the target value is assessed e.g. In a temperature sensor, if "r":1 then the action will be performed each time the temperature is read and the target value is met.

The default ("r":0) triggers the action only the first time the target value is met.

The Action "0" is an array and contains the list of actions to perform when the target value is met. Any, or multiple accessory actions can be contained within the array.

In this temperature sensor example wildcard actions have been defined to perform actions when the temperature sensor reaches a temperature of 35ºC or 20ºC. Switching GPIO 12 on or off.

Each time the temperature sensor returns a reading above 35ºC the action will be repeated.

NOTE: In the case where the temperature sensor jumps from 18ºC to 35ºC between readings then only the 35ºC action will be performed.

{
  "c": { "l": 13 },
  "a": [{
    "t": 22,
    "g": 14,
    "n": 4,
    "j": 30,
    "y0": [{
      "v": 35,
      "r": 1,
      "0": { "r": [{ "g": 12, "v": 1 }] }
    }, {
      "v": 20,
      "0": { "r": [{ "g": 12, "v": 0 }] }
    }]
  }]
}

State Inputs manage the state of an accessory. They monitor GPIO inputs and set the state of the accessory when conditions are met e.g. In a lock mechanism two separate GPIO inputs could be linked to buttons. One button will unlock the mechanism and one will lock it. Using state inputs linked to each of the buttons the mechanism can be locked or unlocked from each button (see below for an example.

State inputs are defined by an "f[n]" key contained within the accessory object. Where [n] is the unique identifier for the state input.

Each accessory can have its own set of state inputs and in most cases these are mapped to some of the Accessory Actions the accessory can perform. They can also be mapped to internal states the accessory monitors e.g. "f3" in a thermostat is used to change the target temperature.

Check the device page for details of the specific states.

{
  "c": { "l": 13 },
  "a": [{
    "t": 4,
    "0": { "r": [{ "g": 12, "v": 0 }] },
    "1": { "r": [{ "g": 12, "v": 1 }] },
    "f0": [{ "g": 14, "t": 1 }],
    "f1": [{ "g": 0, "t": 1 }]
  }]
}

In this example of a lock mechanism input action "f0" is defined as a single press on the button connected to GPIO 14. When the button is pressed accessory action "0" will be triggered and the mechanism is unlocked. When the button connected to GPIO 0 is pressed the mechanism will lock.

{
  "c": { "l": 13 },
  "a": [{
    "t": 40,
    "d":18,
    "0": { "r": [{ "g": 12, "v": 1, "i": 0.5}]},
    "1": { "a": 0},
    "2": { "r": [{ "g": 12, "i": 1.5},{ "g": 12, "v": 1, "i": 0.5},{ "g": 12, "v": 1, "i": 2 }]},
    "3": { "a": 2 },
    "f3": [{ "g": 14, "t": 1 }],
    "f4": [{ "g": 14, "t": 0 }]
  }]
}

In this example of a garage door state input "f3" is defined for a garage door as being when the button/sensor connected to GPIO 14 is released (goes high) and "f4" is defined as being when the button/sensor is pressed (goes low) press. Either a door is closing and receives opening order accessory action is triggered ("3") or a garage door is closed accessory action is triggered "4"'.

See Digital Inputs for details on how to define this option.

Status Inputs were introduced in firmware version 1.8.0

Status Inputs are very similar to State Inputs, but differ in that they only set the internal state of an accessory. They do not trigger any actions. e.g. Staying with the lock mechanism example. A Status Input can be used to set the state of the accessory when a key is used in the mechanism and it is manually locked or unlocked. See below for an example of how this might be done.

Status Inputs are defined by an "g[n]" key contained within the accessory object. Where [n] is the unique identifier for the Status Input.

Each accessory can have its own set of Status Inputs and in most cases these are mapped to some of the Accessory Actions the accessory can perform, but can also be mapped to internal states the accessory monitors.

Additionally an accessory can have button(s) or digital input(s) associated with a Status Input. When a specific state occurs then the Accessory Action status is set.

Check the device page for details of the specific states.

{
  "c": { "l": 13 },
  "a": [{
    "t": 4,
    "0": { "r": [{ "g": 12, "v": 0 }] },
    "1": { "r": [{ "g": 12, "v": 1 }] },
    "g0": [{ "g": 14, "t": 1 }],
    "g1": [{ "g": 14, "t": 0 }]
  }]
}

In a modification to the State Inputs lock mechanism example. This accessory has no buttons associated with it, but does have an input to indicate the mechanism is locked or unlocked by a physical key turning the mechanism. When GPIO 14 goes high the mechanism is unlocked and the accessory status is set to unlocked: "g0". WHen GPIO 14 goes low the mechanism is locked and the accessory status is set to locked: "g1".

Action keys define what the accessory should do when state changes occur due to changes in inputs, or when specific triggers occur. Actions can take the form of changes to GPIO lines, system actions (reboot), HTTP requests, ICMP Ping requests and IR transmissions etc. Multiple actions can be defined for each accessory. Actions are specified by using one or more of the action types listed below.

Depending on the accessory type a range of different actions may be possible. See each device type for the list of actions. Refer to the Actions section in each device page.

Available Action Types are:

NOTE: Within an action the copy action type "a" is mutually exclusive to all other actions and can only be used on its own. All other action types can be combined.

{
  "c": { "l": 13 },
  "a": [{
    "t": 1,
    "0": { "r": [{ "g": 12, "v": 0 }] },
    "1": { "r": [{ "g": 12, "v": 1 }] },
    "b": [{ "g": 0, "t": 1 }]
  }]
}

In this example we have defined an accessory of type Switch with two actions; action "0" sets GPIO 12 to a value of 0 and action "1" sets GPIO 12 to a value of 1. These actions are performed when the button "b" attached to GPIO 0 is pressed with a single press.

For the example the device type "t": 1, the value "v": 0 and the button press type "t": 1 are included for clarity, but as they are the default values they can be omitted from the config to save device memory.

{
  "c": { "l": 13 },
  "a": [
    {
      "t": 1,
      "0": { "r": [{ "g": 12, "v": 0 }] },
      "1": { "r": [{ "g": 12, "v": 1 }], "m": [{ "g": 3, "v": 1 }, { "k": 3, "v": 2 }] },
      "b": [{ "g": 0, "t": 1 }]
    },
    { "t": 1 },
    { "t": 2, "k": 1 }
  ]
}

In this example we have added a couple of extra accessories and accessory notifications to the second action "1" of the first accessory that sends a notification with value 1 to the third accessory in the list and also disables its secure kill switch.

NOTE: For simplicity of the example the details of the 2nd & 3rd accessories have not been shown

{
  "c": {},
  "a": [{
    "t": 21,
    "0": { "r": [{ "g": 12, "v": 0 }] },
    "1": { "r": [{ "g": 12, "v": 1 }] },
    "2": { "a": 0 },
    "b": [{ "g": 0 }]
  }]
}

In this example the third action "2" is the same as the second action "0". Using the "a" shortcut to copy an action reduces the size of the JSON configuration string.

{
  "c": {},
  "a": [{
    "t": 21,
    "0": { "r": [{ "g": 12, "v": 0 }] },
    "1": { "r": [{ "g": 12, "v": 1 }], "s": [{ "a": 1}] },
    "b": [{ "g": 0 }]
  }]
}

In this example the second action "1" sets GPIO 12 high and performs a system action "s" to enter the device setup mode ("a": 1).

Every accessory type has a defined set of accessory actions "[n]". An accessory action is represented by an integer e.g. "0", "1" etc.

An accessory action is specific to the accessory e.g. turn the switch or outlet on ("1") or off ("0"), turn on a lightbulb ("1"), turn on the heating ("3") in a thermostat device.

Almost all accessories have a minimum of two accessory actions; "0" & "1". Exceptions are accessory types such as a temperature sensor or a humidity sensor.

Accessory actions have other actions embedded within them to effect the action state they represent e.g. a switch On accessory action "1" may set a GPIO to cause the on condition to occur e.g. "1": { "r": [{ "g": 12, "v": 0 }] }

See above examples of accessory actions.

The copy action is defined by the "a" key array within an accessory object.

The copy action is mutually exclusive with all other action types i.e. if a copy action is present within an accessory definition then no other action types can be present.

If you have two or more accessory actions that do the same thing then a copy action can be used as a shortcut to reduce memory for the JSON configuration data. The value defined in the key is a reference to another action to copy e.g. "3": { "a": 0} is a shortcut for action "3" to copy action "0".

See Action Example 3 for an example.

The digital output array is defined by the "r" key within an accessory object.

The digital output array contains a list of GPIO level changes to perform when an action is invoked e.g. Set GPIO 12 low {"g": 12, "v": 0} or set GPIO 12 high for 2 seconds {"g": 12, "v": 1, "i": 2}

Sometimes multiple actions need to be performed when an action is invoked. In this case the digital output array will have multiple entries in its list e.g. {"g": 12, "i": 1.5}, "g": 12, "v": 1, "i": 2}

Each defined action has an array of digital outputs "r" e.g. relays, LEDs etc. These outputs have a number of different configuration options defined below.

This option is mandatory for each action defined. The "g" specifies a GPIO to use as the digital output for the action performed e.g. "g": 12 specifies GPIO 12 to be used as the digital output.

This option specifies the level to drive the GPIO output pin. Driving the pin low normally results in an "off" state and a high normally results in an "on" state.

This option can be used to trigger an automatic return of the output to its previous state after a preset period of time has elapsed. The inching "i" value is a floating point number specifying the number of seconds e.g. { "i": 1.34 } will result in a period of 1.34 seconds elapsing before the output pin is returned to its previous state. The time can be specified in hundredths of seconds. NOTE: Positive values only are allowed

Accessory notifications are defined by the "m" key array contained within an accessory object.

Accessory notifications are notifications to send to another accessory or kill switch when an action is invoked and are defined by the "m" option e.g. Send a notification to the 2nd accessory defined in the accessory array {"m": [{"g": 2, "v": 1}]} or enable the 2nd accessory secure kill switch {"m": [{"k": 2, "v": 3}]}

Accessory notifications "m" contain a list of notifications to send e.g. {"m": [{"g": 2, "v": 1}, {"k": 1, "v": 0}]}. If more than one notification is contained in the list then the notifications will be sent in the order they appear in the list.

See Actions Example 2 for an example.

The target accessory number is the index into the list of accessories in the "a" object. The target accessory index number begins with 1 i.e. the first accessory in the top level accessories key "a".

If n accessories are defined in the "a" object, then a value of 1 for "g" or "k" specifies the first accessory and a value of n specifies the last accessory.

The target accessory value is the value to send as part of the notification.

In the case of an accessory notification the value of the "v" option is determined by the accessory type and is defined in the details of each accessory, in the "HomeKit Notifications" section. Check this section in each accessory to determine the valid values that can be used for accessories.

In the case of a kill switch notification the value of the "v" option is determined by the Kill Switch Notification table.

Kill Switch Notifications were introduced in firmware version 1.0.0

The target accessory value for the kill switch notification defines which kill switch to address and whether to enable or disable it.

System actions are defined by the "s" key array within an accessory object.

System actions were introduced in firmware version 0.8.7

See Actions Example 4 for an example.

The system actions array is used to define system actions to perform when an accessory action is invoked.

Send HTTP/TCP Request Actions were first introduced in firmware version 1.3.0

Send HTTP/TCP request actions are defined by the "h" key array within an accessory object.

Send HTTP/TCP request actions can be used to initiate an HTTP/TCP request to a specified target host and URL when an action occurs. They might be used to communicate to non-HomeKit devices from a HAA device e.g. turn on a WiFI lightbulb when a HAA device button is pressed, enter a record into a time series database etc.

The Host "h" is any valid IP address or a fully qualified domain name e.g. "192.168.22.45" or "lounge-light.lan".

NOTE: If you are using a fully qualified domain name then make sure you have a DNS server on your network capable of resolving the name.

The Port "p" is any valid TCP port number.

The Method "m" is the communication method to use and can be one of:

When using the HTTP methods; 0, 1 or 2. The HTTP request is made up using the specified options to create a request and then sending it via the specified Method to the specified URL e.g. http://<host>:<port>/<url>

When using TCP RAW the Content is sent as-is, without any HTTP header. This method is useful when communicating to websockets or any other protocol outside of HTTP. WHen using TCP RAW method 4 the Content must be in HEX format e.g. { "c":"01b364007aff04"}. When using either of the TCP methods the URL is ignored.

The URL "u" is any valid URL e.g. {"u": "cm?cmnd=Power%20OFF"}

The content "c" is a string and can be any valid content.

NOTE: Any content returned by an HTTP/TCP Send Request is ignored by the device.

You want to send a power command to a device at IP address 192.168.2.15 using the GET method: http://192.168.2.15/cm?cmnd=Power%20ON

{
  "c": { "l": 13 },
  "a": [{
    "t": 1,
    "0": { "h": [{ "h": "192.168.2.15", "u": "cm?cmnd=Power%20OFF"}]},
    "1": { "h": [{ "h": "192.168.2.15", "u": "cm?cmnd=Power%20ON"}]},
    "b": [{ "g": 0, "t": 1 }]
  }]
}

In this example we are using the default method of GET "m":0 and the default port of 80 "p":80. No content is required "c" as we are using a GET.

In this example you want to send a time series event to an influxDB database to record when an action occurs and what that action was e.g.

curl -X POST 'http://influxdb.lan:8086/write?db=haadb' --data-binary 'switch,device=laptop value=0'

{
  "c": { "l": 13 },
  "a": [{
    "t": 1,
    "0": {
      "r": [{ "g": 12, "v": 0 }],
      "h": [{ "h": "influxdb.lan", "p": 8086, "m": 2, "u": "write?db=haadb", "c": "switch,device=laptop value=0" }]
    },
    "1": {
      "r": [{ "g": 12, "v": 1 }],
      "h": [{ "h": "influxdb.lan", "p": 8086, "m": 2, "u": "write?db=haadb", "c": "switch,device=laptop value=1" }]
    },
    "b": [{ "g": 0, "t": 1 }]
  }]
}

Send IR Code Actions were introduced in firmware version 1.5.0

Send IR Code actions are defined by the "i" key array within an accessory object.

The Frequency "x" used in an action to override the global setting defined in the General Configuration for this action only.

The Protocol "p" defines the IR protocol to use. When used in an accessory it overrides the General Configuration setting for actions within the accessory. When used in an action it overrides the setting defined in the General Configuration setting for the action only.

The Repeats "r" defines the number of times the IR command will be transmitted. IR command codes are often sent multiple times in a row to ensure the receiving device is able to capture the code e.g. to turn on some Panasonic TVs, the same code must be sent 5 times.

The Inter-Repeat-Delay "d" defines the delay between repeats in milliseconds when Repeats are greater than 1. Valid values are from 0 to 65535. If none is declared, default value will be 100 milliseconds.

The Command "c" defines the actual command code to be transmitted. At least one definition of the Protocol ("p") must exist, either in the General Configuration section, in the accessory ("a") object or in the action ("p") object.

The Raw Code "w" defines the IR code to be transmitted. The Raw Code does not use any protocol (it is raw data) and does not require a "p" key in either the General Configuration section, accessory object or within the action object. NOTE: If "w" and "c" options are defined for the same action then the "c" option will take precedence and the "w" definition will be ignored.

Refer to the Using Infra-red in HAA for details on defining the protocol and protocol codes.

Example of a HomeKit Switch that can turn on and off a Panasonic TV using an IR TX LED connected to GPIO 2

{
  "c": { "t": 2, "p": "HtDCAQ0?AQCAAK" },
  "a": [{
    "0": { "i": [{ "c": "aAkAiAhAaDbAaDaA" }]},
    "1": { "i": [{ "r": 5, "c": "aAkAiAhAaDbAaDaA" }]},
    "t": 1
  }]
}

UART Actions were introduced in firmware version 2.1.1

UART Actions are defined by the "u" key array within an accessory object.

The UART Number defines the UART port to use. See UART Configuration for details of port and settings.

The Command string in HEX format, without spaces, defining the command to send to the attached accessory e.g. "41424344"

The Inter-command Delay is the time in milliseconds to delay before transmitting subsequent commands to the same UART when multiple commands are contained in the same "u" array.

{
  "c":{"l":13,"b":[{"g":0,"t":5}],"r":[{"n":0, "s":9600, "p":0, "b":0}]},
  "a": [{
    "t": 1,
    "0": { "u":[{"n":0, "v": "48656c6c6f20576f726c64" }]},
    "1": { "u":[
      {"n":0, "d":100, "v": "537769746368204f6666" },
      {"n":0, "v": "4e6f77" }
    ]}
  }]
}

This is a general example of using a UART attached accessory. The external accessory is connected to the switch on UART0 ("n":0) and used 9600 baud, no parity bits and 0 stop bits ("s":9600,"p":0,"b":0). To turn off the device the string "48656c6c6f20576f726c64" must be sent to it. To turn on the device the string "537769746368204f6666", followed by "4e6f77" 100ms later.

Now you know all about Accessory Configuration it is time to discover Accessory Types