An automation rule can have mulitiple conditions. By default the action will only fire if all conditions pass. An optional key `condition_type: 'or'` can be set on the automation rule to fire action if any condition matches. In the example below, the automation would trigger if the time is before 05:00 _OR_ after 20:00.

# At least one of the following required

# Optional

value_template: '{% raw %}{{ state.attributes.battery }}{% endraw %}'

You can verify that your automation rules are being initialized correctly by watching both the realtime logs and also the logbook. The realtime logs will show the rules being initialized (once for each trigger):

The conversation component can process sentences into commands for Home Assistant. It is currently limited to parsing commands in the format `turn <Friendly Name> <on/off>`.

name: Notify when someome arrives home

The logger component lets one define the level of logging activities in Home Assistant.

By default log all messages and ignore log event lowest than critical for custom omponents.

A user can create scenes that capture the states you want certain entities to be. For example a scene can contain that light A should be turned on and light B should be bright red.

Scenes can be activated using the service `scene.turn_on`.

The `weblinks` component allows you to display links in the Home Assistant frontend.

To use this component in your installation, add the following to your `configuration.yaml` file:

* The **Timer** will send every 1 second a `time_changed` event on the event bus.

Home Assistant can be extended by **components**. Each component is responsible for a specific domain within Home Assistant. Components can listen for- or trigger events, offer services and maintain states. Components are written in Python and can do all the goodness that Python has to offer. Out of the box, Home Assistant offers a bunch of [built-in components]({{site_root}}/components/).

We can differentiate between two different types ofcomponents within Home Assistant.

These components will track devices within a specific domain and exist of a core part and platform specific logic. These components make their information available via the State Machine and the Event Bus. The component will also register services in the Service Registry to expose control of the devices.

Component's platform logic uses 3rd party Python libraries to communicate with the devices. This is done so that we can leverage great device libraries that are out there in the Python community.

A slave instance can be started with the following code and has the same support for components as a master-instance.

Because each slave maintains its own ServiceRegistry it is possible to have multiple slaves respond to one service call.

home-assistant.io is using [Octopress](http://octopress.org/). To get more details, please checkout the [documentation](http://octopress.org/docs/). That means that creating a new page is simple. The pages are written in [markdown](http://daringfireball.net/projects/markdown/), you don't need to care about HTML or alike.

To take advantage of the build-in features of Octopress to display code snipplets, just use the default markdown syntax. Please use `$` and `#` if it's a command and to differ from output.

If you want to display line numbers, add the following snipplets somewhere on your page.

Not everything (product, component, etc.) has a logo, to show something for internal parts of Home Assistant we are using the [Material Design Icons](https://materialdesignicons.com/).