# `Grizzly.InclusionHandler`
[🔗](https://github.com/smartrent/grizzly/blob/v9.1.4/lib/grizzly/inclusion_handler.ex#L1)

Behaviour for handling incoming commands during the inclusion process

During the inclusion process different Z-Wave commands can be exchanged
asynchronously. One way to handle this is by wrapping `Grizzly.Inclusions`
in a `GenServer`, but that is a lot of work for something Grizzly can provide
out of the box.

When you initialize an inclusion process you can pass the `:handler` option
to the command-handling function which can either be the a `pid` (defaults to caller pid) or a
module that implements this behaviour.

These reports this callback function will want to handle are:

- `Grizzly.ZWave.Commands.NodeAddStatus`
- `Grizzly.ZWave.Commands.NodeRemoveStatus`
- `Grizzly.ZWave.Commands.NodeAddDSKReport`
- `Grizzly.ZWave.Commands.NodeAddKeysReport`

If you are not handling S2 devices the last two can be ignored until you are
ready to provide support them.

 The timeout-handling function will want to handle timeouts, particularly on state :dsk_requested,
 if you are handling S2-authenticated devices.

# `handle_report`

```elixir
@callback handle_report(
  Grizzly.Report.t(),
  keyword()
) :: :ok
```

# `handle_timeout`

```elixir
@callback handle_timeout(
  atom(),
  keyword()
) :: :ok
```

---

*Consult [api-reference.md](api-reference.md) for complete listing*