# Chirp — Home Automation Platform

Chirp is an AI-first home automation platform — connect any maker's sensors and let a built-in AI helper run the setup.

Chirp is an **AI-first** home automation platform that connects sensors from different manufacturers into one system — with shared dashboards, unified automations, and a single alerting workflow across every device in your home. No vendor lock-in, no juggling multiple apps. And instead of hunting through settings to get any of it working, you can just *ask*: a built-in AI helper sets up sensors, builds automations, and creates alerts for you, in plain language.

Whether you're monitoring temperature in a baby's room, watching for water leaks in the basement, tracking soil moisture in the garden, or making sure the garage door closed after you left — Chirp brings it all together. Sensors from different brands, using different protocols, reporting data in different formats, all working as one.

And Chirp doesn't stop at your front door. Connect a GPS or OBD-II tracker to your car or motorcycle and get engine diagnostics, error codes, real-time location, and theft recovery — all in the same platform, the same dashboards, the same alerts. Pick up a compatible tracker (for example, from [Kilo Electronics — Teltonika trackers](https://kiloelectronics.com/en/product-brand/teltonika/)), plug it in, and your vehicle shows up alongside your home sensors within minutes.

## Why Chirp

### Just ask — your home has an expert built in

The best part of Chirp is that you don't have to be technical to use it. A built-in AI helper knows your whole home — every sensor and its history — so you can ask it anything in plain English: *"What was the bedroom temperature overnight?"* or *"Were there any motion events in the hallway after 11 PM?"* It checks your real data and answers, then draws you a chart if you'd like one.

And it doesn't stop at answers. Ask it to *do* something — "add my new leak sensor", "alert me if the basement gets damp", "let me know if a door opens after midnight" — and it sets it up for you, writing the automation, testing it, and switching it on. It can also work the house itself: *"turn on the lamp"* now turns on the lamp. Before anything important or permanent, it asks you to confirm, so you're always in charge. It's like having a smart-home installer on call, who happens to live inside the app. See [Your Home AI Helper](/ai-assistant).

You don't even need the hardware to start. Chirp can make up **pretend sensors** that invent their own readings, so you can build your dashboards and test your alerts while your real ones are still in the post — then point the same sensor at the real thing when it arrives and keep everything you set up. See [Pretend Sensors](/devices/pretend-sensors).

This is what people mean by **AIoT** — artificial intelligence built right into your connected home, not a chatbot stuck on the side. The helper keeps getting better the more it's used, and the engine behind it is something we built ourselves and were proud enough of to share openly as [Synthetic Brew](https://github.com/syntheticinc/syntheticbrew).

### Connect any manufacturer, one platform

Chirp doesn't lock you into a single brand. You can connect LoRaWAN sensors, vehicle trackers, and MQTT-capable devices from any manufacturer — including thousands of Zigbee devices through the MQTT connector. The vehicle tracker library alone covers over 2,000 preconfigured models — OBD-II dongles that read engine codes, fuel level, and battery voltage, as well as standalone GPS trackers for location and route history.

Different manufacturers report data in completely different formats — one says `temp`, another says `temperature_celsius`, a third just sends a number with no label. Chirp normalizes all of it. Every sensor in your home speaks the same language, so your dashboards, automation rules, and alerts work the same way regardless of which brand made the hardware.

If a better sensor comes along next year, just add it. Your existing rules, dashboards, and alert configurations keep working.

### Every sensor, fully modeled

When you connect a sensor, it doesn't just show you a number. Every device becomes a living digital model — its current state, full history, and patterns over time. Even when a sensor temporarily loses connection, its data and configuration are preserved. You always know what's happening at home.

### Automate with confidence

Set rules that make your home — and your vehicles — respond to what's happening. If the basement humidity goes above 70% for more than an hour, get a notification. If the front door opens after midnight, send a text to everyone in the household. If the garden soil gets too dry, know about it before your plants do. If your car's engine throws a warning code, get an alert on your phone immediately. If your motorcycle moves outside a geofence at 3 AM, trigger a critical alarm.

Rules are built visually — you pick a sensor, set a condition, choose what should happen. Behind the scenes, Chirp uses [CEL (Common Expression Language)](https://cel.dev) for conditions, giving you precise control when you want it. You can combine readings from multiple sensors — regardless of manufacturer — in a single rule, schedule rules to run only on certain days, and set conditions that need to persist for a minimum time before triggering.

That last point matters more than you'd think: a temperature sensor might briefly spike to 35 degrees if sunlight hits it for a moment, then settle back to 22. With Chirp's "remain true for" conditions, you can say *"only alert me if the temperature stays above 30 for at least 15 minutes."* Transient spikes are ignored. You only hear about real problems.

And here's something you won't find in most smart home systems: every change you make to a rule is versioned. If you adjust an automation and it starts behaving unexpectedly, you can see exactly what changed, compare with the previous version, and undo it with one click. Nothing is lost.

### Know when it matters

Chirp delivers alerts through the channels that work for you — email, text messages, or push notifications through the **Chirp Alerts** mobile app ([iPhone](https://apps.apple.com/us/app/chirp-alerts/id6756504956) / [Android](https://play.google.com/store/apps/details?id=io.chirpwireless.alarm)).

The mobile app takes alerting further: critical alerts trigger a full-screen alarm with looping sound and vibration, designed to get your attention even when your phone is locked or in silent mode. The alarm keeps going until you silence or acknowledge it. Informational alerts, on the other hand, arrive quietly — you see them when you check your notifications. For full details, see the [Chirp Alerts App](/alarm/chirp-alerts-app) section.

Set up quiet hours so non-critical notifications don't disturb you at night. Configure escalation chains so that if one person doesn't respond, the alert goes to the next. And if a notification fails to deliver for any reason, the system automatically retries.

### See your home at a glance

Build dashboards for any room, any purpose — or any vehicle. A "Kitchen" dashboard showing temperature and air quality. A "Security" dashboard with every door and window sensor. A "Garden" view tracking soil moisture and rainfall. A "My Car" dashboard with live location, engine status, and trip history. Sensors and trackers from different manufacturers show up side by side — because Chirp normalizes their data into a shared model.

Each dashboard is made of widgets you customize. Pick the display type — charts for trends, numbers for current readings, on/off indicators for states. Then fine-tune: set value boundaries so you can see at a glance when a reading is in or out of range, choose your preferred units, and toggle graph visibility. Each widget adapts to the way you want to see your data.

Your data appears on screen the moment your sensor reports it — no polling, no refresh button, no "data updated 5 minutes ago." The platform streams data through specialized channels built for real-time delivery. And when you pull up a chart of last month's humidity readings, it loads quickly even with thousands of data points.

### See your home in 3D

Build a 3D model of your home and watch your sensors come to life inside it. The Digital Building Twin lets you draw your rooms — walls, doors, windows, every floor — or import a floor plan, then furnish it from a library of more than 60 ready-made 3D objects: sofas, beds, the fridge, a parking spot in the driveway. Connect each one to a sensor and choose what its colors mean.

Then the model lights up. The nursery glows warm when the temperature climbs. The garage shows at a glance whether the door was left open. The basement turns blue the moment the leak sensor gets wet. The driveway shows whether the car is home. Your house stops being a list of readings and becomes a picture you can read in a second — and what it shows is up to you, room by room, however your home is laid out.

You can even place your home on the real-world map, anchored to its actual location. See [Digital Building Twin](/dashboards/adding-widgets/digital-building-twin) for the full guide.

### Share with the people who live there

Invite family members, roommates, or property managers to your organization. Give everyone full access, or limit some members to view-only — kids can check the temperature but can't modify rules. If you're a landlord, give tenants view access to shared utility sensors without exposing your own devices or settings.

Every organization has an activity log, so you can see who changed what and when. From the user menu, go to **Users** to manage members and **Organization settings** to configure your setup.

### Connect your own tools

Prefer to wire Chirp into your own scripts or another home-automation platform? A scoped API key lets trusted tools read your sensors and history — pull readings into a spreadsheet, bridge data into another system, or build a small automation of your own. REST over plain HTTPS is all most setups need. See the [API](/api) section to get started, and [API Keys](/settings/api-keys) to create a key.

### No gateway lock-in

Chirp includes a built-in LoRaWAN Network Server, which means your gateway connects directly to the platform — no separate network server to manage, no middleware in between. You can use a variety of compatible gateways, and adding one takes just a few minutes.

## Available in your language

The interface is available in English, German, French, Spanish, and Portuguese. Switch between light and dark modes with one click, and your preferences are remembered automatically.

## Plans

Chirp offers several plan tiers to fit every home — from a free tier to get started, up to plans with more devices, unlimited automation rules, and advanced features. You can view and manage your plan from the **Subscription** section in the user menu.

## Access the Platform

Open Chirp at [app.chirpwireless.io](https://app.chirpwireless.io).

## Let's get started

Ready to connect your first sensor? Head to [First Steps](/first-steps) — we'll walk you through the interface and the standard LoRaWAN path to your first alert, while pointing out where other connection types follow a different setup order.


# First Steps

Get started with Chirp — what you need and the LoRaWAN setup flow that takes you from unboxing to live sensor data.

Welcome to Chirp. This section helps you get comfortable with the platform and walks you through connecting your first sensor. The hands-on guide here uses the LoRaWAN path from unboxing to live data, while the rest of the docs explain where other connection types start differently. Every feature has its own dedicated section later in the documentation — here we're just covering the essentials to get you up and running.

## What's ahead

| Page                                                                | What you'll learn                                                                                                                               |
| ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| [Finding Your Way Around](/first-steps/finding-your-way-around)     | A tour of the interface — where everything is, what each section does, and how to customize your view                                           |
| [Connect Your First Sensor](/first-steps/connect-your-first-sensor) | A hands-on LoRaWAN guide: set up your gateway, create an LNS connection, register a sensor, build a room dashboard, and create your first alarm |

## What you'll need

* A Chirp account
* A web browser on your computer, tablet, or phone
* For the hands-on guide: a LoRaWAN gateway and a sensor (like a temperature/humidity sensor) with its Device EUI and AppKey — these usually come printed on the device or its packaging

No hardware yet? The first two pages are still worth reading — they'll help you understand what Chirp can do and how it works before your sensors arrive.

## The LoRaWAN setup flow

Here's what that path looks like:

```
Sign up → Plug in your gateway → Create a connector → Register your sensor → Build a dashboard → Set up an alarm
```

Not every Chirp setup starts with a gateway. This flow is specifically for LoRaWAN sensors. Other connection types begin with the connection itself instead.

Most people have their first LoRaWAN sensor reporting data within 15 minutes. The [Connect Your First Sensor](/first-steps/connect-your-first-sensor) guide walks you through every step.

## After your first sensor

Want to connect scripts or trusted tools to Chirp? Create an API key and use the [API](/api) — REST over plain HTTPS is all most home setups need.


# Finding Your Way Around

Tour the Chirp interface — left menu, profile options, notification bell, home screen — find where everything lives.

Here's a quick tour of the Chirp interface so you know where everything lives.

## The menu on the left

The left side of the screen has your main menu. Everything you need is organized here, top to bottom.

You can tuck the menu away when you do not need it — hover over the Chirp logo at the top and click the double-chevron that appears. The menu collapses to just icons, giving your dashboards and data the full screen. Click the chevron again to bring the labels back. This is especially handy if you use a tablet or touchscreen to display your dashboards.

### Your main sections

* **Overview** — Your home screen. Summary cards showing your sensor and gateway counts, and recent alarms. Think of it as the front page of your smart home.
* **Dashboards** — Custom views you build for any room or purpose. Create a "Kitchen" dashboard, a "Garden" view, or a "Security" overview. Organize them in folders and fill them with the sensor data that matters to you.
* **Connectors** — Define which protocols Chirp listens on. Connector types: **LNS** (for LoRaWAN sensors), **Tracker** (for vehicle trackers — OBD2, CAN bus, standalone GPS), **MQTT** (for Zigbee sensors via Zigbee2MQTT, DIY hardware, and other MQTT-capable devices), and **Emulator** (pretend sensors, for setting things up before your hardware arrives). Click an LNS connection to see **LoRaWAN Gateways** and **Connected Devices** tabs. A Tracker connection shows the sensor list directly. Sensors are registered separately through the sensor dialog.
* **Devices** — See all your registered sensors in one place. Browse and search. Click any sensor to view or edit its details.
* **Gateways** — Your LoRaWAN gateways (must support Basics Station protocol for secure connectivity). See which ones are online, check their signal stats, add a new gateway, or update firmware.
* **Alarm** — Your alert headquarters, with three tabs:
  * **Inbox** — See every alarm that's been triggered. Each one shows what happened, how serious it is (from Critical down to Info, with High, Medium, and Low in between), which sensor triggered it, and whether it's been resolved. Filter by severity or status, and search through past incidents.
  * **Alarm definitions** — The alarm rules you've set up. Create rules that define when to alert you, who gets notified, and how urgently. Rules support escalation — if nobody responds within a set time, the alert can automatically reach the next person or channel.
  * **Settings** — Configure how different severity levels behave and manage delivery preferences.
* **Rules engine** — Your automation builder. Create rules visually: "if this sensor reads this, then do that." Rules can be as simple or as detailed as you need.
* **Reports** — Activity and audit information for your household.
  * **Audit Trail** — A log of membership activity in your household. See when users were invited, when they joined, when permissions changed, and when someone was removed.

### Settings

Click **Settings** to see more options:

* **Profile settings** — Change your name, email, profile photo, or password. You can also delete your account from here.
* **Locations** — Set up your rooms and zones. Once defined, you can filter devices by location and organize dashboards by room.
* **Device sharing** — See which devices you've shared with family members and manage who has access to what.
* **API Keys** — For power users and tinkerers. Create secure keys to connect Chirp with your own scripts, home automation setups, or other services. Each key has specific permissions and can be set to expire automatically.
* **New device request** — Can't find your sensor's model when adding it? Choose **New device request** to ask the team to add support. Tell them the **Brand**, **Model**, and **Band**, and add a **Documentation link** or **Codec link or code** if you have one, then tap **Send request** — you'll see a confirmation once it's on its way.
* **Changelog** — See what's new in the latest platform updates.

### At the bottom

* **Get Help** — Opens a form where you can describe your issue, enter your email, and send a message directly to the support team.
* **Docs** — Opens this documentation.

### Making more space

You can collapse the menu to just icons by using the collapse arrow. This gives more room for dashboards and device views. Hover over the collapsed menu to temporarily see the labels.

## Your profile menu

Click your **name or photo** in the bottom-left corner to open a dropdown. This is where you'll find several important things that aren't in the main menu:

* **Language** — Switch between English, German, French, Spanish, and Portuguese. The change is instant and Chirp remembers your choice.
* **Dark / Light mode** — Toggle between themes. Dark mode is great for checking sensors before bed or in dimly lit rooms.
* **Subscription** — See which plan you're on, how many devices and rules you're using, and upgrade if you need more.
* **Users** — Manage members of your organization — invite people, set permissions, and control who can see or change what. This is how you share your smart home with family members, roommates, or a landlord.
* **Organization settings** — Change your organization's name or transfer ownership. Only visible to the organization owner.
* **Log out** — End your session.

### Switching organizations

Under **My organizations** in the menu, you'll see all organizations you belong to — for example, your own home and a vacation property you manage. Pick a different one and the entire interface switches — different devices, different rules, different members. Each organization is completely separate.

## The notification bell

On desktop, a small **bell icon** appears near your profile. It shows a number badge when you have unread alarms. Click it to see recent alarms in a sidebar without leaving whatever page you're on.

## Your home screen (Overview)

When you open Chirp, you land on the **Overview** page — titled **"My board"** in the interface.

### At the top: counts and status

Two cards show how your home is doing:

* **Devices** — How many sensors you have. Warnings appear if any aren't communicating.
* **Gateways** — How many are online. If one drops off, you'll see it immediately.

### Below: recent alarms

* **Recent alarms** — Latest triggered alarms. What happened, which device, when. Mark all as read, or click one for the full story.

Everything updates automatically — new readings and alarms appear without refreshing.

## Managing your devices

Sensors are added and managed through **Connectors** or **Devices**. Adding a new sensor opens a dialog where you enter a name and save. The dialog then transitions to edit mode with four tabs:

* **Device info** — Name your sensor and add photos.
* **Connection** — Choose the connector type, select a known device profile (brand, model, frequency band) or enter credentials manually (Device EUI, AppKey).
* **Metrics** — Choose which sensor parameters the device reports, using templates.
* **Logs** — See the device's activity history.

This same dialog is used for adding new devices and editing existing ones.

## Inside a gateway page

Click a gateway to see:

* **Overview** — Whether it's online, how long it's been running, signal quality, traffic, and which devices connect through it.
* **Settings** — Change the name, update the location, manage antenna configuration.


# Connect Your First Sensor

Hands-on guide to pair a gateway, register a LoRaWAN sensor, build a room dashboard, and set your first home alarm.

Let's get something working. This guide walks you through the simplest LoRaWAN path to live data on your screen and an alarm watching over it. Not every Chirp setup starts with a gateway, but this one does because it covers the LNS / LoRaWAN route. Every feature has its own section later — here we're just getting you up and running.

**You'll need:**

* A Chirp account
* A LoRaWAN gateway (the small box that receives signals from your sensors)
* A LoRaWAN sensor (like a door sensor or temperature sensor) — along with its Device EUI and AppKey, usually printed on the device or its packaging

**By the end, you'll have:**

* A gateway receiving signals in your home
* A connector linking the gateway to Chirp
* A sensor sending live readings
* A room dashboard showing your data
* An alarm that notifies you when something needs attention

***

## Step 1: Set up your gateway

The gateway is the bridge between your wireless sensors and Chirp. It plugs into your home network and listens for sensor signals within range.

Your gateway needs to support the **Basics Station** protocol — this is how it connects securely to Chirp using encrypted TLS certificates (which is why you'll download a certificate bundle during setup). Most modern LoRaWAN gateways support this; check the specifications when choosing one.

1. Plug in your gateway and make sure it has power plus an internet connection or backhaul (for example Ethernet, Wi-Fi, or LTE, depending on the model).
2. In Chirp, click **Gateways** in the left menu.
3. Click **Add gateway** in the top-right corner.
4. Give it a **name** — like "Living Room Gateway" or "Home Hub."
5. Choose the right **region** for your gateway hardware and location:
   * Usually this matches the band your gateway was sold or configured for
   * **EU868** for most deployments in Europe
   * **US915-0 / US915-1** in the United States, depending on the network setup
   * **EU433** only if your gateway is specifically built or configured for 433 MHz
   * Other regions are in the dropdown
6. Type in the **Gateway EUI** — a 16-character code printed on a sticker on the gateway, usually on the bottom or back.
7. Click **Next**.

### Connect your gateway to Chirp

The next screen shows two important things:

8. An **LNS address** — this is the server URL your gateway needs. Click the **copy icon** to copy it.
9. A **Download certs.zip** button — click it to download the security certificates.
10. Click **Continue**.

Now open your gateway's settings page in your browser (find its IP address on your router's connected devices list) and enter:

* The **LNS address** you just copied
* The **certificates** from the zip file

The exact steps depend on your gateway model — check the guide that came with it. Once connected, the gateway shows as **online** in your Gateways list. This may take a couple of minutes.

> **Where to put it:** A central, elevated location works best. For an apartment, one gateway usually covers everything. For a house, the main floor is a good choice.

***

## Step 2: Create a connection

Before adding sensors, you need a connection. A connection tells Chirp which protocol to listen on — in this case, LoRaWAN.

1. Click **Connectors** in the left menu.
2. Click **Add connector** (or the **Add connector** button if you haven't set one up yet).
3. Select **LNS** from the **Connector type** dropdown.
4. Click **Add**.

Done — the connection is created. No extra setup needed. Chirp handles the LoRaWAN network integration automatically.

***

## Step 3: Add your sensor

With the gateway online and the connection in place, you can register your first sensor — giving it a profile in Chirp that tracks its state, readings, and history.

1. In the **Connectors** page, click on your **LNS** connection to open it.
2. Click the **Connected Devices** tab.
3. Click **Add device**.

### Create the sensor profile

The dialog opens showing only the basic info:

4. Type a **name** — like "Front Door Sensor" or "Bedroom Temp."
5. Optionally add a **photo** of the sensor.
6. Click **Save**.

The sensor profile is created and the dialog transitions to edit mode with all tabs visible.

### Configure the connection

7. Click the **Connection** tab.
8. Select your **connector** from the dropdown.
9. Under **"Use device profile templates"**, check the box if your brand is in the list:
   * Pick the **Brand** (e.g., Dragino, Milesight, Browan).
   * Pick the **Model** — the list narrows by brand.
   * **Profile** (band and device class) fills in automatically.
10. If your sensor isn't listed, leave the checkbox unchecked and enter:
    * **Device EUI** — 16 characters, printed on the sensor or its box.
    * **AppKey** — 32 characters, also included with the sensor.
11. Click **Save**.

The sensor appears in the Connected Devices list. It needs a moment to join the network through your gateway — most sensors send their first reading within a minute or two.

> **Don't see your brand?** No problem — leave the template checkbox unchecked and enter the Device EUI and AppKey manually. Chirp works with any LoRaWAN sensor. You can configure data templates later to define how raw data maps to meaningful readings. See the [Data Templates](/devices/data-templates) section for details.

***

## Step 4: See your live data

Once your sensor has reported in, you can view its data in two ways:

* Click a **sensor row** in the Connected Devices list — the sensor's detail page opens. Click the **Metrics** tab to see readings.
* Or check **Devices** in the sidebar to see all your sensors and their status.

The best way to keep an eye on your data is through a dashboard — which we'll set up next.

***

## Step 5: Create a room dashboard

Dashboards let you see data from one or many sensors at a glance.

1. Click **Dashboards** in the left menu.
2. Click **Add dashboard**.
3. In the modal:
   * Pick an **icon** for the dashboard.
   * Enter a **name** — like "Front Door" or "Home Overview."
   * Optionally choose a **folder** or add a **description**.
4. Click **Save**.

### Add your sensor's data

5. On the new dashboard, click **Add widget**.
6. **Choose your device** from the list.
7. **Choose a metric** — like door status or battery level. You'll see a live preview of how the widget will look.
8. Click **Choose** to add it.

Repeat to add more widgets. **Drag** them to rearrange and **resize** by pulling their edges.

> **Idea:** Create a dashboard for each room, or one "Home Overview" with the most important reading from each sensor.

***

## Step 6: Get alerted when something happens

Let's set up an alarm so Chirp tells you when the door opens.

1. Click **Alarm** in the left menu.
2. Click **Add alarm rule** in the top-right corner.
3. In the modal, fill in:
   * **Name** — like "Front Door Opened."
   * **Title** — the subject of the alert (e.g., "Door Alert").
   * **Body** — the message (e.g., "The front door has been opened.").
   * **Severity** — pick **Critical** if this needs immediate attention, **High** or **Medium** for important but non-urgent events, or **Low** / **Info** for things you just want to know about.

### Who gets notified

4. The first **escalation step** is pre-configured with your account and email.
   * Choose additional **channels** if available (SMS, push notifications).
   * To escalate further: click **Add step** — for example, notify your partner if you don't respond within 10 minutes.
   * Set the **delay** between steps.
5. Click **Save**.

The alarm rule is now watching. When triggered, an alarm appears in **Alarm → Inbox** and you receive a notification through your configured channels.

***

## You're up and running

That's it — you have a working LoRaWAN smart home setup:

* A **gateway** receiving signals from your sensors
* A **connector** linking the network to Chirp
* A **sensor** sending live data
* A **dashboard** where you see it all at a glance
* An **alarm rule** keeping watch while you don't

From here, you might want to:

* **Add more sensors** — Repeat Step 3 for each new device through your connector
* **Build automations** — Check out the Automation section for rules like "alert me if the door opens after midnight"
* **Invite your family** — Go to **Users** in the user menu to invite family members and control what they can see and change
* **Explore the AI helper** — Ask it *"When was the front door last opened?"* and get a real answer from your data


# Overview

Read your home at a glance — device and gateway status cards, notifications, and self-refreshing live readings.

The home overview is the first thing you see when you open Chirp. Think of it as your home's front page — a single screen that tells you whether everything is running smoothly, which devices need attention, and what's happened recently.

The overview is available on plans that include the Overview feature. If your plan includes it, it loads automatically when you log in.

## Where to find it

Tap **Overview** in the sidebar.

## What you'll see

The overview is divided into a few easy-to-scan sections, each showing a different slice of your home's status.

### "My board" and Live Data

The heading **My board** sits at the top of the page, next to a **Live Data** button.

The Live Data button is a small clickable icon. When you hover over it, a tooltip reads **"New data is automatically displayed"** — meaning Chirp keeps the overview fresh as new sensor readings arrive. If you've just made a change (like adding a new sensor) and want to see it reflected immediately, click the button to trigger a manual refresh.

### Summary cards

Below the header, a row of summary cards gives you an at-a-glance view of your smart home. The row scrolls sideways if there are more cards than your screen can fit.

Cards you'll see include:

* **Devices** — Shows how many devices are registered in your home. A small warning indicator appears on the card when Chirp can't confirm a device is reporting — either it has never sent anything, or it has gone quiet for longer than its **Data sending interval** — the field where you tell Chirp how often the device is configured to send (see [Adding Sensors](/devices/adding-sensors)). Tapping the card takes you to the full device list. A small add button in the corner lets you start registering a new device right from here.
* **Gateways** — Shows how many gateways you have connected. Warning indicators appear if a gateway has gone offline or become inactive. Tapping takes you to the gateways page, and the add button starts the gateway setup flow.

These cards work as both a status check and a shortcut. If you see a warning number, you know something needs your attention before you even open the details.

### Notifications

Below the cards, a **Notifications** panel shows recent alerts and events — what happened, which device triggered it, and when. If a door opened while you were out or a temperature crossed a threshold overnight, you see it here without opening the full alarm inbox.

### Add a sensor

At the bottom of the page, a dedicated **Add Device** section makes it easy to register new sensors or gateways. This is especially helpful when you're first setting up your home and the overview is still empty — it's the natural "what to do next" prompt.

## When your home is brand new

If you've just created your Chirp account and haven't connected anything yet:

* The **Devices** and **Gateways** cards show **0** with no warnings.
* The **Notifications** section has nothing to display.
* The **Add Device** section at the bottom invites you to get started.

As soon as you connect your first sensor and gateway, the cards light up. Readings flow in and notifications start tracking what matters.

## Making the most of your overview

* **Use notifications as a morning briefing.** Scroll through recent notifications to see what happened overnight without opening each sensor individually.
* **Tap the Live Data button after adding a sensor.** When you've just registered a new sensor, tapping Live Data confirms that Chirp is receiving its readings right away.

## What's next

* [Finding Your Way Around](/first-steps/finding-your-way-around) — A tour of the full Chirp interface.
* [Adding Sensors](/devices/adding-sensors) — Register your first sensor.
* [Building a Dashboard](/dashboards/building-a-dashboard) — Create a custom view tailored to a room or purpose.


# Dashboards

See your whole smart home at a glance — overview, custom dashboards, widgets, maps, and live sensor data.

Once your sensors are connected and reporting, Chirp gives you several ways to see what's happening across your home — from a quick status check to fully personalized dashboards that show exactly the information you care about.

## What you can see

Chirp's visibility layer is built around a few key surfaces that work together:

1. **Home overview** — If your plan includes the Overview feature, this is the first screen you see when you log in. It shows summary cards for your devices and gateways, and recent notifications. A clickable Live Data button lets you refresh your data on demand.
2. **Custom dashboards** — Views you build yourself, organized the way you think about your home. A "Kitchen" dashboard might show temperature and humidity. A "Security" dashboard might focus on door and window sensors. You decide what goes where. Dashboards are available on plans that include the Dashboard feature.
3. **Widgets** — Each piece of information on a dashboard is a widget. Widgets are not fixed cards — they are configurable display components that you tailor to your needs. A temperature widget for your living room might show a comfortable green range of 18–24°C, while the same sensor type in a fridge widget turns red above 5°C. You control the ranges, colors, and labels.
4. **Maps and device placement** — See where your sensors are placed on an interactive map, so you always know which device is where.
5. **Tracking** — If you have a GPS tracker (for a vehicle, pet, or bike), see where it's been with location history and route details. Location history works for any device that reports GPS coordinates; a cellular vehicle tracker connects through the [Tracker Connector](/connectors/tracker-connector), while a LoRaWAN GPS tag connects through the [LNS Connector](/connectors/lns-connector).
6. **Live data** — Understand what the Live Data indicator means, and what to check if data isn't appearing as expected.

## Ideas for dashboards around the home

Dashboards are not just for sitting at your computer. Put them where they are most useful:

* **A tablet by the front door** — Glance at your home's status on the way in or out. Are all doors and windows closed? What is the temperature? Any alerts waiting? Mount an inexpensive tablet, open Chirp, and collapse the menu for a clean full-screen view.
* **A kitchen display** — A spare tablet showing a "Kitchen & Garden" dashboard with live temperature, humidity, and soil moisture readings.
* **A bedside screen** — Bedroom temperature, overnight door/window sensor activity, and security status — visible without reaching for your phone.
* **A shared family display** — A living room screen showing the home overview so everyone in the household can see what is going on at a glance.

For any mounted or dedicated screen, collapse the sidebar to give the dashboard the full display — hover over the logo and click the double-chevron. The menu shrinks to tiny icons, keeping the focus on your data.

## What's ahead

* [Home Overview](/overview) — Your default landing page: sensor status and notifications.
* [Building a Dashboard](/dashboards/building-a-dashboard) — Create a personalized dashboard with a name, icon, and folder.
* [Adding Widgets](/dashboards/adding-widgets) — Pick widget types, connect them to your sensors, and customize how readings are displayed.
* [Organizing Your Views](/dashboards/organizing-your-views) — Group dashboards into folders and arrange them to match how you use your home.
* [Maps and Device Placement](/dashboards/maps-and-device-placement) — See where your sensors are on a map.
* [Tracking What Matters](/dashboards/tracking-what-matters) — View location history for GPS tracker devices.
* [Live Home Data](/dashboards/live-home-data) — How live updates work and what to do if data isn't showing up.


# Building a Dashboard

Create, rename, and delete a personalized Chirp dashboard with its own name, icon, and folder.

The home overview shows your whole smart home at a glance, but sometimes you want a view focused on just one part — the kitchen temperature and humidity, the security sensors on every door, or the garden moisture probe and weather station. That's what dashboards are for.

A dashboard is a view you design yourself by choosing which sensors and readings to display. Before adding any widgets (the individual data displays), you first create the dashboard itself — give it a name, pick an icon, and choose where it lives in your sidebar.

This page covers creating, editing, and deleting dashboards. For organizing dashboards into folders, see [Organizing Your Views](/dashboards/organizing-your-views).

<figure><img src="/files/B7WyaLYVJzdl5Lz72DGX" alt="A home dashboard of Control widgets — a switch, a dial, a slider, and an input controlling a lamp"><figcaption></figcaption></figure>

## Finding your dashboards

Your dashboards live in the **Dashboards** section of the sidebar. Dashboards are available on plans that include the Dashboard feature. Tap the section to expand and see everything you've created. If this is your first time, the sidebar shows **"No dashboards yet"** — which is perfectly normal.

Next to the Dashboards section, you'll notice two small controls:

* **Add dashboard** (plus icon) — Opens the dialog where you create a new dashboard.
* **Dashboard settings** (gear icon) — Opens the management dialog for folders and reordering, covered in [Organizing Your Views](/dashboards/organizing-your-views).

## Creating your first dashboard

Tap **Add dashboard** in the sidebar. A dialog opens with the title **"Add dashboard"** and the message **"Create your personalized dashboard, add the necessary widgets to meet your goals."**

### What to fill in

* **Icon** — Pick an icon that represents the dashboard's purpose. The default is a house icon. Some ideas: a thermometer for a temperature dashboard, a lock for security, a leaf for your garden.
* **Name** *(required)* — Give your dashboard a clear name. The placeholder suggests **"My dashboard"**, but something descriptive works better — "Living Room", "Garden Sensors", or "Front Door Security". If you leave this blank and try to save, you'll see **"Dashboard name is required"**.
* **Folder** — Choose a folder for the dashboard, or leave it at **"None (top level)"** to place it directly in the sidebar. If you've created folders (through [Organizing Your Views](/dashboards/organizing-your-views)), they appear in the dropdown. This option only shows up when creating a new dashboard — not when editing later.
* **Description** — An optional note about what this dashboard is for. The placeholder reads **"Describe your dashboard, if needed"**. You might write "Tracks temperature and humidity in the kitchen and dining area" so you remember the purpose later.

### Saving

Tap **Save** to create the dashboard. It opens right away, ready for you to [choose and add widgets](/dashboards/adding-widgets). Tap **Cancel** to close without creating anything.

## What you see on a dashboard

Once your dashboard is created and you open it from the sidebar, you'll see:

* The **dashboard name** as a heading on the left.
* A **Live Data** label with a small icon on the right side of the header. This is a status indicator (not a button) that tells you the dashboard receives fresh sensor readings automatically.
* An **actions menu** (three dots) on the far right.

If you haven't added any widgets yet, the center of the dashboard shows the message **"You have no widgets here"** alongside **"Add your first widget to build your dashboard"** and an **Add widget** button. This is your prompt to head to [Choosing Widgets](/dashboards/adding-widgets).

## Changing a dashboard's name or icon

Made a typo, or want a different icon?

1. Open the dashboard.
2. Tap the actions menu (three dots) and select **Edit dashboard**. This puts the dashboard into edit mode.
3. Look for the small **pencil icon** that appears near the top left — it replaces the Live Data indicator when you're in edit mode. Tap it.
4. The edit dialog opens with your current name, icon, and description pre-filled. Make your changes.
5. Tap **Save**.

You can't change the folder from this dialog — moving a dashboard between folders is done through [Organizing Your Views](/dashboards/organizing-your-views).

## Deleting a dashboard

If you no longer need a dashboard:

1. Open it from the sidebar.
2. Tap the actions menu and select **Delete dashboard**.
3. A confirmation appears: **"Are you sure you want to delete {dashboard name} dashboard?"** with the note **"Once deleted, this action cannot be undone."**
4. Tap **Yes, delete** to confirm.

This permanently removes the dashboard and everything on it.

## What's next

* [Choosing Widgets](/dashboards/adding-widgets) — Add sensor data, charts, and floor plans to your new dashboard.
* [Organizing Your Views](/dashboards/organizing-your-views) — Group dashboards into folders like "Upstairs" and "Garden".
* [Home Overview](/overview) — The default view that's always there, even before you create dashboards.


# Adding Widgets

Add and configure dashboard widgets — pick a type, connect it to your sensors, and tailor the ranges and colors.

A dashboard comes alive when you add widgets — the individual display panels that show what your sensors are doing right now. But the same temperature sensor in the bedroom and the same temperature sensor watching a fridge are not the same thing. One widget shows comfort. The other shows whether your groceries are safe. The value is identical in type; the meaning is entirely different.

This is what widgets are designed for. You choose what each one shows, set the ranges and colors that match the context, and give it a name that makes sense for where it lives. Two widgets can read from the same sensor and look completely different because you've configured them for different purposes.

## How to add a widget to a dashboard

Before you can add widgets, you need a dashboard. If you haven't created one yet, see [Building a Dashboard](/dashboards/building-a-dashboard).

**Opening edit mode:**

Open the dashboard, tap the **actions menu** (three dots) in the top right, and select **Edit dashboard**. The dashboard enters edit mode — you'll see a **Cancel** button and a **Save** button appear in the header, replacing the Live Data indicator.

**If the dashboard is empty:**

An empty dashboard shows **"You have no widgets here"** with an **Add widget** button in the center. Tap it to open the widget picker.

**If the dashboard already has widgets:**

In edit mode, a **plus (+) button** appears — use it to add more widgets. You can also tap the **three-dot menu** on any existing widget to edit, move, resize, or delete it.

**Reusing a widget you've already set up:**

Once a widget is configured just the way you like it, you don't have to build the next one from scratch.

* **Duplicate** a widget from its three-dot menu to get a copy on the same dashboard — you'll see **"Widget successfully duplicated"**. This is the quick way to cover several identical sensors: set up the first radiator's temperature widget with the ranges and colors you want, duplicate it once per radiator, and just point each copy at its own sensor. If the copy doesn't appear, you'll see **"Could not duplicate widget"** — try again.
* **Move to dashboard** sends a widget to a different dashboard entirely. Handy when the garden soil probe you added to "Kitchen" really belongs on "Garden". If the move doesn't go through, you'll see **"Could not move widget"**.

**Saving your changes:**

After configuring a widget, tap **Save** in the widget settings to add it to the dashboard. When you're done arranging, tap **Save** in the dashboard header to exit edit mode and keep your layout.

## Choose the right widget

| Widget                                                                    | Use it when                                                                                  | What it shows                                                                             |
| ------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| [Last Data](/dashboards/adding-widgets/last-data-widget)                  | You need to know what something is doing right now                                           | The latest value received from one or more sensors                                        |
| [Chart](/dashboards/adding-widgets/chart-widget)                          | You need to see how a value changed over time                                                | A historical graph plus the live current reading                                          |
| [Image](/dashboards/adding-widgets/image-widget)                          | You want to see sensor data pinned onto an image — a floor plan, a room photo, a diagram     | Your own uploaded image with live numeric readings pinned to their locations              |
| [Map](/dashboards/adding-widgets/map-widget)                              | You want to see where a GPS-reporting device is right now                                    | Current position on a real outdoor interactive map, plus one sensor reading on the marker |
| [iFrame](/dashboards/adding-widgets/iframe-widget)                        | You want a web page you check often — weather, traffic, a calendar — right on your dashboard | A live web page from a supported service, embedded in the tile next to your sensors       |
| [Digital Building Twin](/dashboards/adding-widgets/digital-building-twin) | You want a 3D model of your home with sensors mapped to real rooms and objects               | A 3D editor that turns your home into a live picture, colored by what your sensors say    |

## What comes next

* [Last Data Widget](/dashboards/adding-widgets/last-data-widget) — Latest sensor values, gauges, and per-sensor conditions
* [Chart Widget](/dashboards/adding-widgets/chart-widget) — Time-series graphs with live current reading and threshold bands
* [Image Widget](/dashboards/adding-widgets/image-widget) — Any image with draggable live-data pins
* [Map Widget](/dashboards/adding-widgets/map-widget) — GPS tracker location with route history
* [iFrame Widget](/dashboards/adding-widgets/iframe-widget) — Pin a live web page — weather, traffic, calendar — next to your sensors
* [Digital Building Twin](/dashboards/adding-widgets/digital-building-twin) — A 3D model of your home that lights up with live sensor readings
* [Conditions](/dashboards/adding-widgets/conditions) — Color rules that turn readings into meaning
* [Organizing Your Views](/dashboards/organizing-your-views) — Group dashboards into folders


# Last Data Widget

Show the latest value from one or more sensors as a number, gauge, or ring — is the door open, how warm is the room?

The Last Data widget shows the **last value received from a sensor**. When the device is actively reporting, that is also the current value. When the device goes offline after its last transmission, the widget continues showing that last value — it does not clear the display or flag that the device is silent. You see what the sensor last said, which is current if the device is still transmitting and may be stale if it is not.

Is the bedroom light on or off? Is the front door open or closed? What is the living room temperature? These are Last Data questions. The widget shows the last transmitted value for each — no chart, no history, no trend. If you want to see how a value changed over time, that is the [Chart widget](/dashboards/adding-widgets/chart-widget).

You can display the latest value as-is — a number, text, or an on/off (`true`/`false`) reading — or as a ring gauge (Doughnut), a filled gauge (Pie), a Tube that fills up like a tank, a Gauge that slides a marker along a colored track, or a Radial Gauge that shows the reading on a round dial. One widget can hold multiple sensors — bedroom temperature, humidity, and CO2 level side by side, each styled independently. Conditions turn the raw number into visible meaning: green means everything is fine, red means look at this now.

## Setting up a Last Data widget

### Step 1 — Choose Last Data from the widget picker

Open dashboard edit mode and tap **Last data** in the widget picker. (See [Adding Widgets](/dashboards/adding-widgets) for how to open edit mode.) The settings panel opens with two tabs: **Datasource** and **Appearance**.

### Step 2 — Datasource tab: connect your sensors

The Datasource tab is titled **"Last Data configuration"** with the subtitle **"Configure last data and data sources."**

**Adding a data source:**

1. Tap **Add datasource**. A **Datasource 1** block appears.
2. In the block, tap **Choose device** and select the device whose sensor you want to display.
3. Tap **Add metric**. A metric row appears. Each metric row shows:
   * **Data type** — set to Telemetry
   * **Device metric** — choose which sensor reading to display (any reading — number, text, or on/off)
   * **Icon** — pick an icon to represent this metric on the widget
   * **Conditions button** — labeled **"Conditions: N"** where N is the number of conditions currently set. Tap it to open the Conditions modal and define what color this reading shows at different values. This is also where you set the **default color** for the metric. See [Conditions](/dashboards/adding-widgets/conditions) for details.
   * **Delete** — remove this metric from the widget

There is no color picker directly in the metric row. The reading color is controlled entirely through the Conditions modal.

> **About reading types.** The **Device metric** list shows every reading, whatever its type. The **Value** display shows it as-is — a number, text, or an on/off value (`true`/`false`) — so no conversion is needed. The gauge-style displays (Doughnut, Pie, Tube, Gauge, Radial gauge) need a number to fill a scale: a numeric text reading is read as that number, and anything non-numeric shows as 0. To change a reading's type, open [Data Templates](/devices/data-templates) and set its **Type** on the **Metrics** tab.

**Adding multiple sensors:**

Tap **Add datasource** to add a second device. You can add as many devices as you like. Duplicate devices are not allowed — once a device is added, it won't appear in the picker again.

Each device can expose multiple metrics. After adding a device, tap **Add metric** on its row to include additional sensor readings from the same device. The Add metric button grays out once all of that device's available metrics have been added.

**Default value range for gauges:**

When you add a metric, a default value range of 0–100 is created for it automatically. This range is used by the Doughnut, Pie, Tube, and Gauge display types to set the scale. You can change it in the Appearance tab.

When your sensors are set, tap **Next** to continue to the Appearance tab.

### Step 3 — Appearance tab: choose how it looks

**Widget name** *(required)* — The title shown on the widget. The placeholder reads **"Enter widget name"**.

**Description** — An optional subtitle below the name.

**Widget type** — Choose how readings are displayed. Each display type has its own page with a screenshot and the full detail:

* **Value** — The latest reading shown as-is — a number with its unit, text, or an on/off (`true`/`false`) value. Clean and direct. [→ Value Display](/dashboards/adding-widgets/last-data-widget/number)
* **Doughnut** — A ring gauge that fills proportionally between the Min and Max you set. [→ Doughnut Display](/dashboards/adding-widgets/last-data-widget/doughnut)
* **Pie** — A filled circle gauge — the same idea as Doughnut, with a bolder look. [→ Pie Display](/dashboards/adding-widgets/last-data-widget/pie)
* **Tube** — A tall cylinder that fills from the bottom like a tank. [→ Tube Display](/dashboards/adding-widgets/last-data-widget/tube)
* **Gauge** — A horizontal track with a sliding marker and your color conditions shown as bands. [→ Gauge Display](/dashboards/adding-widgets/last-data-widget/gauge)
* **Radial gauge** — A round dial with a needle, a sweep angle you choose, and your conditions as colored arcs. [→ Radial Gauge Display](/dashboards/adding-widgets/last-data-widget/radial-gauge)

**Value range** *(Doughnut, Pie, Tube, Gauge, and Radial gauge)* — Appears per sensor once you choose one of these display types. Set the **Min** and **Max** values that define the scale the widget fills or marks against. The tooltip reads: **"Set min and max to define the chart scale. Max is the value where the indicator is fully filled (for a pie, the whole circle)."**

Validation: Min must be strictly less than Max. If they are equal or reversed, the widget won't save.

**Tick marks** *(Tube, Gauge, and Radial gauge)* — Choose how many tick marks divide the scale. On a Gauge they run along the track, on a Tube they run down the side and pick up the color of whatever condition band they land in, and on a Radial gauge they ring the dial.

**Sweep angle** and **Radial Gauge name** *(Radial gauge only)* — Set how far around the dial sweeps (0 to 360 degrees; 300 by default) and the label shown with it. See [Radial Gauge Display](/dashboards/adding-widgets/last-data-widget/radial-gauge).

**Tube and Gauge don't have a built-in "good" end.** The fill or marker just shows where the reading sits — your conditions decide what's fine and what isn't. Put the red band at the low end to be warned when something is running out, or at the high end when something is rising too far. The [Tube](/dashboards/adding-widgets/last-data-widget/tube) and [Gauge](/dashboards/adding-widgets/last-data-widget/gauge) pages walk through both.

**Display data legend** — A toggle that adds a legend listing your sensor metrics below the reading. Works for every display type.

### Step 4 — Save

Tap **Save** to add the widget to the dashboard.

## What to expect

Once placed, the widget immediately shows the last known value from each sensor. As sensors report new data, the display updates live.

The value shown is the last one received. If a device has been offline or silent, the widget continues showing the last reading it got — it does not clear the display. Check the sensor's last-reported time on the device page before acting on a reading if the device might be offline.

If a sensor hasn't reported yet, the widget shows **"Waiting for live data"** in the reading area. If no metrics have been configured, it shows **"Add a metric to start visualizing data"** or **"Choose data source and add metric"**.

## Common patterns

Almost every Last Data tile is one of a few simple ideas. Each display type has its own page with the full step-by-step and home examples — here is where to start.

* **Is it on or off?** — a door, a light, a leak sensor. A plain [Value display](/dashboards/adding-widgets/last-data-widget/number) with one color per state is all you need.
* **What is the reading right now?** — a room temperature, an air-quality figure. A [Value display](/dashboards/adding-widgets/last-data-widget/number) shows the value; a [Gauge display](/dashboards/adding-widgets/last-data-widget/gauge) also shows whether it is in a comfortable range.
* **How full is it?** — a water tank, a battery, a rain barrel. Show it as a [Doughnut](/dashboards/adding-widgets/last-data-widget/doughnut) or [Pie](/dashboards/adding-widgets/last-data-widget/pie) ring, or as a filling [Tube](/dashboards/adding-widgets/last-data-widget/tube) that looks like the tank itself.
* **Is something heading for trouble?** — a level creeping too high or a supply running too low. A [Gauge display](/dashboards/adding-widgets/last-data-widget/gauge) turns your colors into bands so you can spot the moment it crosses the line.

## See also

* [Conditions](/dashboards/adding-widgets/conditions) — Define color rules for each metric: what green, yellow, and red mean for that specific sensor in that specific place
* [Adding Widgets](/dashboards/adding-widgets) — How to open edit mode and use the widget picker


# Value Display

Show a sensor's latest reading as a number, text, or on/off with the Value display in the Chirp Last Data widget.

<figure><img src="/files/427TbxB0JmSqBxBLoocX" alt="Last Data widget using the Value display"><figcaption></figcaption></figure>

The Value display shows a reading's latest value just as it comes in — no dial, no bar, just the value. It works for **any** kind of reading: a number with its unit, a bit of **text** shown as-is, or an on/off (**Boolean**) value shown as `true` or `false`. As the screenshot shows, several readings can share one tile, sitting side by side, each in its own color — handy for showing a room's temperature and humidity together.

Pick Value when the reading itself is what you want to see, and there's nothing to "fill up" — the actual temperature, the actual battery percentage, a text status, an open/closed state. It's also the neatest way to fit two or three related readings into one small tile.

Value is the only display type with no value range, because there's no scale to fill against.

## When to choose it

* The exact reading is the point — "the bedroom is 21°C," "the battery is at 64%."
* A compact tile carrying two or three readings for one room or device.
* A simple on/off or open/closed value where the plain number says it all.

Those are just ideas — any reading that's clearest as a plain figure is a good fit for the Value display.

## Configure a Value display

Let's build a real one — a tile that tells you at a glance whether the front door is open. The door's contact sensor reports just two values — `1` when it's open and `0` when it's shut. Because the reading is only ever 0 or 1, there's nothing to fill or scale, so a Value tile is the right pick and each condition only needs to match one of those two numbers. This is just an example: a Value tile suits any reading where the figure itself is what you want — only the sensor and the conditions change.

1. Open your dashboard in edit mode and tap **Last data** in the widget picker. The **Datasource** tab opens with nothing added yet.
2. Tap **Add datasource**. A **Datasource 1** block appears.
3. In the block, tap **Choose device** and pick the front-door contact sensor.
4. Tap **Add metric**. A metric row appears.
5. In the row, leave **Data type** on **Telemetry**, choose the open/closed reading under **Device metric**, and add an **Icon**.

   > **About reading types.** The **Device metric** list shows every reading, whatever its type. The Value display shows it as-is — a number, a bit of text, or an on/off value (`true`/`false`) — so you don't need to convert anything here. (The gauge-style displays — Doughnut, Pie, Gauge, Tube, Radial gauge — do need a number: a numeric text reading is read as that number, and anything non-numeric shows as 0. To change a reading's type, use the **Metrics Templates** button on your connection's Connected Devices list — see [Data Templates](/devices/data-templates).)
6. Tap **Conditions: N** to open the Conditions window. Choose a **Default color** — the color the reading uses whenever none of your bands match the current value — then for each state tap **Add condition** and fill in the row — type a **Condition name**, set **Data type** to **Number** (the condition's own Data type, not the metric's), because the door sensor only ever sends 0 or 1, set **From** and **To** to the same number — the value that condition should match — and pick a **Color**. Then you set the two states — for example:

   * "Open" — **From** 1, **To** 1 — red
   * "Closed" — **From** 0, **To** 0 — green

   Tap **Save** to close the window.
7. Tap **Next** to go to the **Appearance** tab.
8. Type a **Widget name** — "Front door" — and a **Description** if you'd like a subtitle.
9. Under **Widget type**, choose **Value**. There's no **Value range** or **Tick marks** — the Value display has no scale, because an on/off reading has nothing to fill; the value itself is the message.
10. Flip on **Display data legend** if you'd like a label, then tap **Save**.

The tile still shows the number — `1` or `0` — but the condition color turns it red when the door is open and green when it's shut, so you read the state in an instant without thinking about the digit. The same trick works for any on/off sensor — a window contact, a leak detector, a light — just swap the sensor and the two conditions.

## Worked examples

**The exact reading, with a verdict** When you want the actual figure, the Value tile shows it in full. A Value tile has no scale, so the bedroom temperature just needs conditions — the °C thresholds that matter to you. Add three: "Comfortable" — From 18, To 24 — green; "Cool" — From 15, To 18 — yellow; "Chilly" — From -5, To 15 — blue. You see the real number — `21.4 °C` — and its color tells you how it feels, both at once. The number is never hidden; the color is just extra meaning laid on top. To see how the temperature changed through the day, use the [Chart widget](/dashboards/adding-widgets/chart-widget) instead.

**A text or on/off reading** The Value display isn't just for numbers. A sensor that reports text (like `OPEN`, `CLOSED`, or `MOTION`) or a simple on/off value shows it directly — the text as written, or `true`/`false` — with no conversion. You can still add conditions and colors, so an `OPEN` status can glow red while `CLOSED` stays green.

**One tile for a whole room** A Value tile can hold several readings together. Add temperature, humidity, and air quality from one multi-sensor and each keeps its own icon and colors, lined up side by side — your "Bedroom" tile in one neat square.

## See also

* [Last Data Widget](/dashboards/adding-widgets/last-data-widget) — The full widget setup and the other display types
* [Conditions](/dashboards/adding-widgets/conditions) — Setting the From/To color rules
* Other display types: [Doughnut](/dashboards/adding-widgets/last-data-widget/doughnut) · [Pie](/dashboards/adding-widgets/last-data-widget/pie) · [Gauge](/dashboards/adding-widgets/last-data-widget/gauge) · [Tube](/dashboards/adding-widgets/last-data-widget/tube) · [Radial gauge](/dashboards/adding-widgets/last-data-widget/radial-gauge)


# Doughnut Display

Show a reading as a filling ring with the number in the middle — perfect for a tank, battery, or humidity level.

<figure><img src="/files/ODqYrbkLr1v9eBNIOpNp" alt="Last Data widget using the Doughnut display type"><figcaption></figcaption></figure>

The Doughnut display shows a reading as a ring that fills up between a low and a high value you choose, with the number in the middle. One look tells you how full something is — you don't have to read the figure to know it's nearly empty or almost maxed out.

It's a great fit for anything with a sensible range — a water tank, a battery, a humidity level. As the reading climbs, more of the ring fills in.

## When to choose it

* A reading with a clear low and high — water-tank level, battery percentage, room humidity.
* A tile where you just want to sense "getting full" or "getting low" at a glance.
* A value that feels like a proportion of something rather than a bare number.

Anything in your home that has a meaningful "empty" and "full" can become a Doughnut — your own sensors will suggest plenty of uses.

## Configure a Doughnut display

Let's build a real one — a ring that shows the living-room temperature and whether it's comfortable. A temperature sensor reports the room in °C. A temperature isn't like a tank — it has no real "empty" or "full", so there's no obvious 0 and 100. The ring still needs a bottom and a top, so you pick a window wide enough to cover any temperature the room could realistically reach: for a house, about -5 °C to +40 °C. This is just an example: a Doughnut suits any reading you'd like to see as a share of a range, so only the sensor and the numbers change.

1. Open your dashboard in edit mode and tap **Last data** in the widget picker. The **Datasource** tab opens with nothing added yet.
2. Tap **Add datasource**. A **Datasource 1** block appears.
3. In the block, tap **Choose device** and pick the room's temperature sensor.
4. Tap **Add metric**. A metric row appears.
5. In the row, leave **Data type** on **Telemetry**, choose the temperature reading under **Device metric**, and pick an **Icon**.

   > **This display needs a number.** The **Device metric** list shows every reading, but a gauge fills against a scale — pick a numeric one here; a text reading shows as 0. (To show text or an on/off value as-is, use the [Value display](/dashboards/adding-widgets/last-data-widget/number).) To change a reading's type, use the **Metrics Templates** button on your connection's Connected Devices list — see [Data Templates](/devices/data-templates).
6. Tap **Conditions: N** to open the Conditions window. Choose a **Default color** — the color the reading uses whenever none of your bands match the current value — then for each band tap **Add condition** and fill in the row — a **Condition name**, **Data type** set to **Number** (the condition's own Data type, not the metric's), the band's **From** and **To** — a living room realistically sits between -5 °C and 40 °C, so those run from **-5** to **40** — and a **Color**. Then you set the color levels — for example:

   Starting at the coldest:

   * "Too cold" — **From** -5, **To** 15 — blue
   * "Cool" — **From** 15, **To** 18 — yellow
   * "Comfortable" — **From** 18, **To** 24 — green
   * "Warm" — **From** 24, **To** 28 — yellow
   * "Too hot" — **From** 28, **To** 40 — red

   Tap **Save** to close the window.
7. Tap **Next** to open the **Appearance** tab.
8. Type a **Widget name** — "Living room" — and a **Description** if you want one.
9. Under **Widget type**, pick **Doughnut**.
10. In **Value range**, set **Min value** to **-5** and **Max value** to **40** — the window you picked for a house room. The ring fills to show where the temperature sits across that -5–40 °C span, and the matching condition colors it.
11. Turn on **Display data legend** if you'd like, then tap **Save**.

The ring shows the temperature as a spot in the range and goes green only while the room is comfortable. The same steps fit anything with a sensible low and high — just change the sensor, the **Min value**/**Max value**, and the conditions. One honest note: a temperature is often easier to read on a Number tile or a Gauge — the Doughnut is shown here because it makes the next example easy to see.

## Worked examples

**The same sensor, set up completely differently — the fridge** Your fridge uses the very same kind of temperature sensor as the living room above — but a comfortable fridge and a comfortable room are nothing alike. A fridge stays cold, so its safe range is only about 0–5 °C — set the scale a little wider than that band so a fridge that fails and warms up still shows on the ring: **Min value** **-5**, **Max value** **15**. Then build three conditions: "Too cold" — From -5, To 0 — blue; "Safe" — From 0, To 5 — green; "Too warm" — From 5, To 15 — red. Same sensor, same steps — only the numbers move, because you decide what "good" means for each spot in your home. That's the whole idea behind conditions.

**How full is the water tank?** A Doughnut is a natural fit for a tank. A level sensor in a 500-liter tank reports the contents in liters, so 0 is empty and 500 is full — **Min value** 0, **Max value** 500 — with conditions green From 300 To 500, yellow From 100 To 300, red From 0 To 100. The ring empties before your eyes as the tank is used.

## See also

* [Last Data Widget](/dashboards/adding-widgets/last-data-widget) — The full widget setup and the other display types
* [Conditions](/dashboards/adding-widgets/conditions) — Setting the From/To color rules
* Other display types: [Value](/dashboards/adding-widgets/last-data-widget/number) · [Pie](/dashboards/adding-widgets/last-data-widget/pie) · [Gauge](/dashboards/adding-widgets/last-data-widget/gauge) · [Tube](/dashboards/adding-widgets/last-data-widget/tube) · [Radial gauge](/dashboards/adding-widgets/last-data-widget/radial-gauge)


# Pie Display

Show a reading as a bold filled circle that fills as the value rises — a chunkier take on the ring gauge.

<figure><img src="/files/8EgAsQ3RR439bq8GtyYS" alt="Last Data widget using the Pie display type"><figcaption></figcaption></figure>

The Pie display is a solid filled circle rather than a ring — it fills in like a slice of pie and becomes whole when the reading reaches its maximum, with the value shown beside it. It works on exactly the same idea as the Doughnut; it just looks bolder and more solid.

Reach for Pie when you'd like a stronger splash of color on the dashboard instead of a thin ring.

## When to choose it

* The same range-based readings the Doughnut handles — tank level, battery, humidity — when you prefer a chunkier look.
* A tile you want to stand out on a busy dashboard.
* A board you glance at from across the room, where a solid shape reads more easily.

Doughnut and Pie do the same job — choose whichever simply looks better to you on the dashboard.

## Configure a Pie display

Let's build a real one — a bold tile showing how much water is in the garden rain barrel. A level sensor reports the barrel contents in liters, and the barrel holds 200 liters — so the reading is 0 when the barrel is empty and 200 when it's full. That 0–200 is the scale, and each color band is a slice of it. This is just an example: a Pie works for any reading shown as a share of a range, so only the sensor and the numbers change.

1. Open your dashboard in edit mode and tap **Last data** in the widget picker. The **Datasource** tab opens with nothing added yet.
2. Tap **Add datasource**. A **Datasource 1** block appears.
3. In the block, tap **Choose device** and pick the rain barrel's level sensor.
4. Tap **Add metric**. A metric row appears.
5. In the row, leave **Data type** on **Telemetry**, choose the volume reading under **Device metric**, and choose an **Icon**.

   > **This display needs a number.** The **Device metric** list shows every reading, but a gauge fills against a scale — pick a numeric one here; a text reading shows as 0. (To show text or an on/off value as-is, use the [Value display](/dashboards/adding-widgets/last-data-widget/number).) To change a reading's type, use the **Metrics Templates** button on your connection's Connected Devices list — see [Data Templates](/devices/data-templates).
6. Tap **Conditions: N** to open the Conditions window. Choose a **Default color** — the color the reading uses whenever none of your bands match the current value — then for each band tap **Add condition** and fill in the row — a **Condition name**, **Data type** set to **Number** (the condition's own Data type, not the metric's), the band's **From** and **To** — the barrel holds 200 liters, so those run from **0** (empty) to **200** (full) — and a **Color**. Then you set the color levels — for example:

   Starting from empty:

   * "Plenty" — **From** 120, **To** 200 — green
   * "Getting low" — **From** 40, **To** 120 — yellow
   * "Almost empty" — **From** 0, **To** 40 — red

   Tap **Save** to close the window.
7. Tap **Next** to move to the **Appearance** tab.
8. Type a **Widget name** — "Rain barrel" — and a **Description** if you want a subtitle.
9. Under **Widget type**, choose **Pie**.
10. In **Value range**, set **Min value** to **0** (an empty barrel) and **Max value** to **200** (its full 200-liter capacity) — the same range your bands use. The slice fills the whole circle at 200 liters.
11. Switch on **Display data legend** if you'd like, then tap **Save**.

Now a solid disc shows the barrel at a glance — full and green after rain, shrinking through yellow to red as you water the garden. The same steps fit any "how full" reading at home; change the sensor, the **Min value**/**Max value**, and the bands to suit.

## Worked examples

**Do the houseplants need water?** A soil-moisture sensor reports a percentage, so the scale is simply **Min value** 0 (bone dry) and **Max value** 100 (soaked), with conditions green From 40 To 80, yellow From 20 To 40, red From 0 To 20. The filled disc makes a thirsty plant impossible to miss.

**A tile you can read from the sofa** On a dashboard you keep on a wall tablet or a TV, a solid Pie reads more clearly from a distance than a thin ring. Use Pie for the readings you want to catch from across the room, and save the Doughnut for closer-up tiles.

## See also

* [Last Data Widget](/dashboards/adding-widgets/last-data-widget) — The full widget setup and the other display types
* [Conditions](/dashboards/adding-widgets/conditions) — Setting the From/To color rules
* Other display types: [Value](/dashboards/adding-widgets/last-data-widget/number) · [Doughnut](/dashboards/adding-widgets/last-data-widget/doughnut) · [Gauge](/dashboards/adding-widgets/last-data-widget/gauge) · [Tube](/dashboards/adding-widgets/last-data-widget/tube) · [Radial gauge](/dashboards/adding-widgets/last-data-widget/radial-gauge)


# Tube Display

Show a level as a filling cylinder, like a real tank — watch the salt, fuel, or rain barrel run low or rise too high.

<figure><img src="/files/lMUcEQ9f8b05JzfR8USc" alt="Last Data widget using the Tube display type"><figcaption></figcaption></figure>

The Tube display is a tall cylinder that fills up from the bottom as the reading rises — just like looking at the level in a real tank. Tick marks run down the side, and the number shows on the tube itself.

It's the most natural way to show anything that has a level — a rainwater butt, a heating-oil tank, the salt in a water softener. And because the colors are yours to set, it works whether you're watching something fill up or watching it run down.

## Watch it run low, or watch it climb too high

The Tube has no fixed "good" end — you choose which way spells trouble and set the colors to match. That means one widget covers two opposite jobs:

* **Watch something run low.** When the worry is *running out* — the fuel in a tank, the salt in your softener, the water in a rain barrel — the level drops as it's used, so put the warning colors at the **bottom**. The tube is green when there's plenty and turns yellow then red as it empties, so you know to refill in good time.
* **Watch something rise too far.** When the worry is the level *getting too high* — say a sensor in your sump or basement pit, where the pump normally keeps the water down — a pump failure lets the water climb, so put the warning colors at the **top**. The tube stays short and green normally and fills into a red band near the top if something goes wrong, warning you before it floods.

It's exactly the same widget — the only difference is whether you paint the red at the bottom or the top. Both are shown below.

## When to choose it

* A real tank or container — water, fuel, propane, feed.
* A "how much is left" reading, where you want to see the level drop toward the bottom.
* A level that shouldn't climb too high — like a sump or drainage pit — where seeing it rise toward the top is the warning.
* Anything you'd naturally picture as a level rising and falling.

If your instinct is to imagine a reading as a column going up and down, the Tube is the display for it — and the colors then decide which end you're watching.

## Configure a Tube display

Let's build a real one — a tube that watches the salt level in a water softener so you never let it run dry. The softener's salt tank is about 100 cm deep, and a level sensor reports how full it is in centimeters — so the reading is 0 when the tank is empty and 100 when it's filled right up. Those two numbers, 0 and 100, are the scale the whole widget works from, and every color band is just a slice of that 100 cm. This is only an example, though: the very same steps work for a rainwater butt, a heating-oil tank, a feed bin — anything with a level. Only the sensor and the numbers change.

1. Open your dashboard in edit mode and tap **Last data** in the widget picker. The **Datasource** tab opens with nothing added yet.
2. Tap **Add datasource**. A **Datasource 1** block appears.
3. In the block, tap **Choose device** and pick the salt tank's level sensor.
4. Tap **Add metric**. A metric row appears.
5. In the row, leave **Data type** on **Telemetry**, choose the level reading under **Device metric**, and pick an **Icon**.

   > **This display needs a number.** The **Device metric** list shows every reading, but a gauge fills against a scale — pick a numeric one here; a text reading shows as 0. (To show text or an on/off value as-is, use the [Value display](/dashboards/adding-widgets/last-data-widget/number).) To change a reading's type, use the **Metrics Templates** button on your connection's Connected Devices list — see [Data Templates](/devices/data-templates).
6. Tap **Conditions: N** to open the Conditions window. Choose a **Default color** — the color the reading uses whenever none of your bands match the current value — then for each band tap **Add condition** and fill in the row — type a **Condition name**, set **Data type** to **Number** (this is the condition's own Data type, not the metric's), because the salt tank is 100 cm tall, enter **From** 0 cm (the empty bottom) and **To** 100 cm (the full top), and pick a **Color**. Then you set the color levels — for example:

   Starting at the bottom:

   * "Critical" — **From** 0, **To** 10 — burgundy (a deep red, darker than the next band)
   * "Refill now" — **From** 10, **To** 30 — red
   * "Refill soon" — **From** 30, **To** 60 — yellow
   * "Healthy" — **From** 60, **To** 100 — green

   Tap **Save** to close the window.
7. Tap **Next** to open the **Appearance** tab.
8. Type a **Widget name** — something like "Softener salt" — and a **Description** if you want one.
9. Under **Widget type**, choose **Tube**.
10. In **Value range**, set **Min value** to **0** (an empty tank) and **Max value** to **100** (filled to the top) — the very same 0–100 your bands use — and set **Tick marks** to **10** so a line marks every 10 cm.
11. Flip on **Display data legend** if you'd like the reading labeled, then tap **Save**.

Now the tube stands tall and green while there's plenty of salt, slips through yellow and red as it gets used up, and shows a thin burgundy strip when it's almost gone — so you top it up before the softener stops working. Point the same setup at a rainwater butt, a pond top-up reservoir, or an oil tank and it behaves exactly the same; you just change the sensor and the band numbers.

## Worked examples

**Catch a basement flood before it spreads** A sump pump sits in a pit in the basement and keeps the water low so the floor stays dry. Drop a level sensor into the pit and show it on a Tube. The pit is about 100 cm deep, so 0 is a dry floor and 100 is water right at the overflow — set **Min value** 0 and **Max value** 100, then add three conditions: "Normal" — From 0, To 30 — green; "Water rising" — From 30, To 60 — yellow; "Pump may have failed" — From 60, To 100 — red. Day to day the column is short and green; if the pump quits, the water climbs and the tube fills into the red. A quick note on the sensor: a level sensor reads higher as the water rises, but a sensor fixed above the water (measuring the gap down to it) reads lower — so put the red condition on whichever value means "high water" for the one you have. The Tube makes the danger easy to spot on the dashboard; to get a phone alert as well, pair it with an [alarm](/alarm).

**A rain barrel in the garden** The same idea for collected rainwater — a level sensor in a 200-liter barrel — **Min value** 0 for an empty barrel and **Max value** 200 because that is how much it holds. The tube rises with every shower and drops as you water the garden, so you always know how much you've saved up.

## See also

* [Last Data Widget](/dashboards/adding-widgets/last-data-widget) — The full widget setup and the other display types
* [Conditions](/dashboards/adding-widgets/conditions) — Setting the From/To color rules for the fill
* Other display types: [Value](/dashboards/adding-widgets/last-data-widget/number) · [Doughnut](/dashboards/adding-widgets/last-data-widget/doughnut) · [Pie](/dashboards/adding-widgets/last-data-widget/pie) · [Gauge](/dashboards/adding-widgets/last-data-widget/gauge) · [Radial gauge](/dashboards/adding-widgets/last-data-widget/radial-gauge)


# Gauge Display

Put a reading on a horizontal track with a sliding marker and colored bands, so you spot the moment it crosses a limit.

<figure><img src="/files/YplzJBtjwdy0Q7GsfAg4" alt="Last Data widget using the Gauge display type"><figcaption></figcaption></figure>

The Gauge display puts a reading on a horizontal track with a marker that slides along it, and the color rules you set show up as bands across that track. The number sits above. So you see two things at once — the value, and whether it's sitting in a good stretch or a worrying one.

## When to choose it

* A reading where it matters *where* it sits — a comfortable room temperature, a healthy battery level — and the colored bands tell you instantly.
* A "running low" warning — set the low end red so the marker sliding down toward it catches your eye.
* A "too high" warning — set the high end red, so a level creeping up (a basement sump filling, say) shows as the marker climbs.

A Gauge has no built-in good or bad end — the bands you choose decide that. Wherever a reading has a "fine" zone and a "not fine" zone, the Gauge makes the line easy to see.

## Configure a Gauge display

Let's build a real one — a gauge that warns you if a basement sump pump fails before the floor floods. The pump's job is to keep the water in its pit low; the pit is about 100 cm deep, and a level sensor reports the water level in centimeters — so the reading runs from 0 (a dry pit floor) up to 100 (water at the overflow). That 0–100 is the gauge's track, and each color band is one stretch of it. This is just an example — a Gauge works for any reading you measure against limits, so only the sensor and the band numbers change.

1. Open your dashboard in edit mode and tap **Last data** in the widget picker. The **Datasource** tab opens with nothing added yet.
2. Tap **Add datasource**. A **Datasource 1** block appears.
3. In the block, tap **Choose device** and pick the pit's level sensor.
4. Tap **Add metric**. A metric row appears.
5. In the row, leave **Data type** on **Telemetry**, choose the water-level reading under **Device metric**, and add an **Icon**.

   > **This display needs a number.** The **Device metric** list shows every reading, but a gauge fills against a scale — pick a numeric one here; a text reading shows as 0. (To show text or an on/off value as-is, use the [Value display](/dashboards/adding-widgets/last-data-widget/number).) To change a reading's type, use the **Metrics Templates** button on your connection's Connected Devices list — see [Data Templates](/devices/data-templates).
6. Tap **Conditions: N** to open the Conditions window. Choose a **Default color** — the color the reading uses whenever none of your bands match the current value — then for each band tap **Add condition** and fill in the row — a **Condition name**, **Data type** set to **Number** (the condition's own Data type, not the metric's), the band's **From** and **To** — because the pit is 100 cm deep, those run from **0** (the dry floor) to **100** (the overflow) — and a **Color**. Then you set the color levels — for example:

   Starting at the dry floor:

   * "Normal" — **From** 0, **To** 30 — green
   * "Water rising" — **From** 30, **To** 60 — yellow
   * "Pump may have failed" — **From** 60, **To** 100 — red

   On a Gauge these bands appear as colored stretches along the track. Tap **Save**.
7. Tap **Next** to open the **Appearance** tab.
8. Type a **Widget name** — "Basement sump" works well — and a **Description** if you want one.
9. Under **Widget type**, choose **Gauge**.
10. In **Value range**, set **Min value** to **0** (a dry pit) and **Max value** to **100** (water at the overflow) — the two ends of the track, the same 0–100 your bands use — and set **Tick marks** to **10**.
11. Flip on **Display data legend** if you'd like, then tap **Save**.

Now the marker sits low in the green while the pump is doing its job. If the pump ever fails, the water rises and the marker slides along the track and crosses into the red — that crossing is your warning that something is wrong downstairs. One thing to get right: a level sensor reads higher as the water rises, but a sensor fixed above the water reads lower — so put the red band on whichever value means "high water" for your sensor. The Gauge makes the problem visible on your dashboard; to get a notification on your phone, pair it with an [alarm](/alarm). The same banded track suits anything with limits — just change the sensor and the numbers.

## Worked examples

**Don't let something run out** When the worry is at the *low* end, flip the colors around. To watch a water softener's salt on a Gauge, use a sensor that reports it as a percentage — 0 % is an empty tank, 100 % is full — so set **Min value** 0 and **Max value** 100, with three conditions: "Top up now" — From 0, To 15 — red; "Getting low" — From 15, To 40 — yellow; "Plenty" — From 40, To 100 — green. The marker rides high and green when the tank is full and slides down toward the red as the salt is used — your cue to buy another bag.

**Keeping a room comfortable** Some readings should stay *between* two numbers. For a living-room temperature, the track needs to cover every temperature the room could realistically reach — for a house that is roughly -5 °C to 40 °C, so set **Min value** -5 and **Max value** 40. Then add: "Too cold" — From -5, To 18 — blue; "Comfortable" — From 18, To 24 — green; "Too warm" — From 24, To 40 — red. A marker in the green middle means the room is just right; drift toward either end shows before anyone reaches for a jumper or opens a window.

## See also

* [Last Data Widget](/dashboards/adding-widgets/last-data-widget) — The full widget setup and the other display types
* [Conditions](/dashboards/adding-widgets/conditions) — The color rules that become the track bands
* Other display types: [Value](/dashboards/adding-widgets/last-data-widget/number) · [Doughnut](/dashboards/adding-widgets/last-data-widget/doughnut) · [Pie](/dashboards/adding-widgets/last-data-widget/pie) · [Tube](/dashboards/adding-widgets/last-data-widget/tube) · [Radial gauge](/dashboards/adding-widgets/last-data-widget/radial-gauge)


# Radial Gauge Display

Show a Chirp reading on a round dial with the Radial Gauge — a needle, a sweep angle you choose, and colored zones.

<figure><img src="/files/Aw6HkqH8GrrWBNu8h66y" alt="Last Data widget using the Radial Gauge display"><figcaption></figcaption></figure>

The Radial Gauge shows a reading on a **round dial**, with a needle pointing to the value — just like the dials on a car dashboard or an old thermostat. Your color conditions wrap around it as arcs, and you can choose how far the dial sweeps, from a near-full circle to a small arc.

It is one of the [Last Data widget](/dashboards/adding-widgets/last-data-widget) display types, joining Number, Doughnut, Pie, Tube, and the flat [Gauge](/dashboards/adding-widgets/last-data-widget/gauge).

## Radial Gauge or the flat Gauge?

Both show a reading against a scale with colored zones — they just look different:

* The [**Gauge**](/dashboards/adding-widgets/last-data-widget/gauge) is a flat, sideways bar. It's tidy and lines up nicely when you have several in a row.
* The **Radial Gauge** is a round dial. It has more presence and feels like a real instrument, which makes it lovely for one or two headline readings on a dashboard.

Pick whichever you like the look of — they work the same way underneath.

## Nice for

* A standout reading you want front and center — the water tank level, the home battery charge, the greenhouse humidity.
* Anything with a clear "full" point, so the dial sweeps from empty to full in a way that feels natural.
* Any reading where colored zones make the meaning obvious at a glance.

## Setting one up

It starts like any [Last Data widget](/dashboards/adding-widgets/last-data-widget) — add a device, pick a number reading, and set up your [Conditions](/dashboards/adding-widgets/conditions). The dial settings appear on the **Appearance** tab once you choose the type.

1. In dashboard edit mode, tap **Last data** in the widget picker.
2. On the **Datasource** tab, **Add datasource**, choose your device, **Add metric**, set **Data type** to **Telemetry**, and pick the reading.
3. Tap **Conditions: N** to set a default color and your colored zones (each with a range and a color), then save.
4. Tap **Next**, give the widget a **name**, and choose **Radial gauge** under **Widget type**. The dial settings appear:
   * **Min value** and **Max value** — the bottom and top of the dial. Min has to be below Max.
   * **Tick marks** — how many little marks ring the dial.
   * **Sweep angle** — how far around the dial goes, from 0 to 360 degrees. The default of 300 leaves a gap at the bottom like a classic dial; turn it up for a full circle or down for a smaller arc.
   * **Radial Gauge name** — a short label for the dial (filled in for you, but you can change it).
5. Toggle the legend on if you'd like, then tap **Save**.

## Home example

**Rainwater tank.** A level sensor in a rainwater tank gets a Radial Gauge set **Min** 0 and **Max** 100 (percent full), with three zones: "Plenty" 60–100 green, "Getting low" 25–60 yellow, "Top it up" 0–25 red. The needle sits high and green after a downpour and swings toward the red as the garden drinks it down over a dry week — a glance from the kitchen tells you where things stand. Want a nudge on your phone when it hits red? Add an [alert](/alarm) for that reading.

## See also

* [Last Data Widget](/dashboards/adding-widgets/last-data-widget) — the full setup and the other display types
* [Gauge Display](/dashboards/adding-widgets/last-data-widget/gauge) — the flat version
* [Conditions](/dashboards/adding-widgets/conditions) — set what the colors mean
* More displays: [Value](/dashboards/adding-widgets/last-data-widget/number) · [Doughnut](/dashboards/adding-widgets/last-data-widget/doughnut) · [Pie](/dashboards/adding-widgets/last-data-widget/pie) · [Tube](/dashboards/adding-widgets/last-data-widget/tube)


# Control Widget

Add a Control widget to a Chirp dashboard — a switch, button, slider, or input that operates a device from one tap.

Every other widget *shows* you something. The **Control widget** lets you *do* something. It puts an interactive control on your dashboard — a **switch**, **button**, **slider**, or **input** — bound to one of a device's commands, so you can operate the device without leaving the screen you're already looking at. It's the dashboard version of [Controlling Your Devices](/devices/commands): the command does the work, the widget is the switch on the wall.

<figure><img src="/files/B7WyaLYVJzdl5Lz72DGX" alt="A home dashboard of Control widgets — a switch, a dial, a slider, and an input controlling a lamp"><figcaption></figcaption></figure>

## First, set up a command

A Control widget runs an action you've already set up on the device — so the device needs at least one command on its **Commands & States** tab. Devices with no commands won't appear to choose from (you'll see *"No controllable devices in this organization"*). Set the command up first — see [Setting up a command](/devices/commands/creating-commands) — then link the widget to it.

## How to add one

Every Control widget is added the same way; only the look-and-feel options differ by type.

1. Open the dashboard in **edit mode** and tap **Add widget** → **Control**.
2. On the **Datasource** tab (*"Control configuration"*), choose the **Source** (Device) and the **Device**, then pick the **Device metric** — the reading that shows the device's current state. Tap **Next**.
3. On the **Appearance** tab, give it a **Widget name** and choose a **Widget type** (below). Fill in that type's options and tap **Save**.

## Pick a control type

| Type                                                                         | Great for                               | What it sends                          |
| ---------------------------------------------------------------------------- | --------------------------------------- | -------------------------------------- |
| [Switch](/dashboards/adding-widgets/control-widget/switch)                   | A simple on/off you flip back and forth | An on or off command as you toggle     |
| [Button](/dashboards/adding-widgets/control-widget/button)                   | A one-tap action (run, restart, open)   | One command per tap                    |
| [Simple Slider](/dashboards/adding-widgets/control-widget/slider-simple)     | Sliding to a value, like brightness     | A command value as you slide           |
| [Circular Slider](/dashboards/adding-widgets/control-widget/slider-circular) | A round dial, like a knob               | A command value as you turn it         |
| [Vertical Slider](/dashboards/adding-widgets/control-widget/slider-vertical) | An upright slider you raise and lower   | A command value as you slide           |
| [Input](/dashboards/adding-widgets/control-widget/input)                     | Typing an exact number                  | A command value when you tap **Apply** |

The three sliders are the **Slider type** options — **Simple**, **Circular**, and **Vertical** — that you pick after choosing **Slider** as the widget type.

## How it behaves

* **Tap to control.** Using the control sends the command the same way the device's States tab does — same checks, same history.
* **Stays in sync.** It reads the **Device metric** and shows the real state, so it's never just guessing based on your last tap.
* **Greys out when it can't.** If the device is offline or a state isn't fully set up, the control shows as unavailable instead of sending into thin air.

## See also

* [Controlling Your Devices](/devices/commands) — set up the commands a Control widget uses
* [Setting up a command](/devices/commands/creating-commands)
* Control types: [Switch](/dashboards/adding-widgets/control-widget/switch) · [Button](/dashboards/adding-widgets/control-widget/button) · [Simple Slider](/dashboards/adding-widgets/control-widget/slider-simple) · [Circular Slider](/dashboards/adding-widgets/control-widget/slider-circular) · [Vertical Slider](/dashboards/adding-widgets/control-widget/slider-vertical) · [Input](/dashboards/adding-widgets/control-widget/input)


# Switch

Add a Switch Control to a Chirp dashboard to flip a home device on or off — a lamp, plug, or relay — with one tap.

The **Switch** is a simple on/off toggle. It's for things that stay in a state — on or off, open or closed — where you flip between the two and the dashboard shows which one is active right now.

## When to use it

A Switch is perfect for everyday home devices you turn on and off: a **lamp**, a **smart plug**, a **garage relay**, a fan, or any simple two-state device. Connect it to a state reading and the toggle shows whether the device is really on, not just what you last tapped.

## What you need first

* A device with a command set up on its **Commands & States** tab (see [Setting up a command](/devices/commands/creating-commands)).
* A command for each state — one command that takes an on/off value, or two separate commands.
* A **Device metric** that reports the device's current state, so the switch shows on or off correctly.

## How to set it up

1. Open your dashboard in **edit mode** → **Add widget** → **Control**.
2. **Datasource** tab: pick the **Device** and the **Device metric** that shows its state. Tap **Next**.
3. **Appearance** tab: type a **Widget name**, then under **Widget type** choose **Switch**.
4. Set up the two states — the **On** row and the **Off** row. For each:
   * **Label** — what to call it ("On" / "Off").
   * **Command** — the command that state sends.
   * **Expected sensor value** — what the device reports when it's in that state (filled in for you where possible).
   * If the command has inputs, set each **Value**.
5. Choose the **Switch color** for **On**, **Off**, and **Disabled**, toggle **Display labels**, and toggle the name/last-update line.
6. Tap **Save**.

<figure><img src="/files/vvvhDjx08u7mYk41sZca" alt="Switch Control toggling a lamp on and off on a Chirp dashboard"><figcaption></figcaption></figure>

## What happens when you tap it

Flipping the switch sends the command for that state, the same way the device's States tab does. The switch flips straight away, then settles to the real state once the device reports back — so if it didn't actually change, the switch returns to where it was.

## Common mistakes

* **No state reading chosen** — without a Device metric, the switch can send commands but can't show the true state. Pick the reading that says on or off.
* **The "on" value doesn't match** — if the Expected sensor value isn't what the device actually reports, the switch looks stuck. Check it against the current value shown.

## See also

* [Control widget](/dashboards/adding-widgets/control-widget) — overview and the other control types
* [Controlling Your Devices](/devices/commands) — set up the command this switch uses


# Button

Add a Button Control to a Chirp dashboard to run a one-tap device action — restart, run a scene, open — with a press.

The **Button** sends a command once when you tap it. Unlike a switch, it doesn't hold an on/off state — it just does something and that's it.

## When to use it

Use a Button for one-tap actions where there's no lasting state to track: **ring a chime**, **restart a device**, **run a scene**, or fire a **momentary relay** (like a pulse to a gate). If it's "do this now" rather than "stay this way," a Button is the one.

## What you need first

* A device with a command set up on its **Commands & States** tab (see [Setting up a command](/devices/commands/creating-commands)).
* The command you want the button to run.

## How to set it up

1. Open your dashboard in **edit mode** → **Add widget** → **Control**.
2. **Datasource** tab: pick the **Device** and a **Device metric**. Tap **Next**.
3. **Appearance** tab: type a **Widget name**, then under **Widget type** choose **Button**.
4. Set the **Command** the button runs (and any input **Value**s), plus the **Expected sensor value** if the action leaves a state you can check.
5. Choose the **Button color** and a **Button size** — **S**, **M**, or **L** (default M) — and toggle the name/last-update line.
6. Tap **Save**.

<figure><img src="/files/hRVLB1eGRCve1zk0rmKm" alt="Button Control with color and size options on a Chirp dashboard"><figcaption></figcaption></figure>

## What happens when you tap it

The button sends its command once, and the action shows up in the device's **States** history like any other command. There's no on/off position to keep — it's a trigger.

## Common mistakes

* **Using a Button for something you need to see the state of** — if you want to know whether it's on or off, use a [Switch](/dashboards/adding-widgets/control-widget/switch) instead.
* **Waiting for confirmation a quick action can't give** — a one-tap trigger (like "restart") may not leave a reading to verify against, and that's normal.

## See also

* [Control widget](/dashboards/adding-widgets/control-widget) — overview and the other control types
* [Controlling Your Devices](/devices/commands) — set up the command this button runs


# Simple Slider

Add a Simple Slider to a Chirp dashboard — a horizontal slider that sets a value like brightness by sliding.

The **Simple** slider is a horizontal bar you slide to set a **value**. It's the neatest of the three slider looks and tucks easily into a row of tiles.

## When to use it

Great for anything you set by amount where a side-to-side slider feels natural — a lamp's **brightness**, a dimmer **level**, or **volume**. Prefer a tall slider or a dial? See the [Vertical Slider](/dashboards/adding-widgets/control-widget/slider-vertical) or [Circular Slider](/dashboards/adding-widgets/control-widget/slider-circular).

## What you need first

* A device with a command on its **Commands & States** tab whose **input takes a number** (see [Setting up a command](/devices/commands/creating-commands)).
* A **Device metric** that reports the current value, so the slider shows where it's set.

## How to set it up

1. Open your dashboard in **edit mode** → **Add widget** → **Control**.
2. **Datasource** tab: pick the **Device** and the **Device metric** for the live value. Tap **Next**.
3. **Appearance** tab: type a **Widget name**, choose **Widget type → Slider**, then **Slider type → Simple**.
4. Set the **Command** it controls, the **Parameter** it sets, and a starting **Value**.
5. Add **Start and End labels** for the range (say `150` and `500`) and turn **Display** on; pick a **Slider color** and toggle the name/last-update line.
6. Tap **Save**.

<figure><img src="/files/WMurNyUHDpu9FUivhm3f" alt="Chirp Simple slider — a horizontal bar setting a value across a range"><figcaption></figcaption></figure>

## What happens when you use it

Sliding sends the command with the new value, the same way the device's States tab does. The handle follows the **Device metric**, so it shows the value the device is actually reporting.

## Common mistakes

* **Choosing a command that's only on/off** — a slider needs an input it can set to a number; for on/off use a [Switch](/dashboards/adding-widgets/control-widget/switch).
* **The range doesn't match the device** — set Start and End to the real lowest and highest values so the whole bar maps to values the device accepts.

## See also

* [Control widget](/dashboards/adding-widgets/control-widget) — overview and the other control types
* Other slider looks: [Circular Slider](/dashboards/adding-widgets/control-widget/slider-circular) · [Vertical Slider](/dashboards/adding-widgets/control-widget/slider-vertical)
* [Controlling Your Devices](/devices/commands) — set up the command this slider controls


# Circular Slider

Add a Circular Slider to a Chirp dashboard — a round dial that sets a value like color temperature by turning it.

The **Circular** slider sets a **value** on a round dial — drag around it and the value follows. It looks like a knob, which makes it a nice centerpiece on a dashboard.

## When to use it

Lovely for a setting you'd reach for like a dial — a lamp's **color temperature**, **volume**, or any single value you want front and center. For a slim in-row control use the [Simple Slider](/dashboards/adding-widgets/control-widget/slider-simple); for a tall one use the [Vertical Slider](/dashboards/adding-widgets/control-widget/slider-vertical).

## What you need first

* A device with a command on its **Commands & States** tab whose **input takes a number** (see [Setting up a command](/devices/commands/creating-commands)).
* A **Device metric** that reports the current value, so the dial shows where it's set.

## How to set it up

1. Open your dashboard in **edit mode** → **Add widget** → **Control**.
2. **Datasource** tab: pick the **Device** and the **Device metric** for the live value. Tap **Next**.
3. **Appearance** tab: type a **Widget name**, choose **Widget type → Slider**, then **Slider type → Circular**.
4. Set the **Command** it controls, the **Parameter** it sets, and a starting **Value**.
5. Add **Start and End labels** for the range (say `150` and `500`) with **Display** on, pick a **Slider color**, and toggle the name/last-update line.
6. Tap **Save**.

<figure><img src="/files/5twj0Tcp6VAvRsVvwjdi" alt="Chirp Circular slider — a round dial setting a value across a range"><figcaption></figcaption></figure>

## What happens when you use it

Turning the dial sends the command with the new value, the same way the device's States tab does. The dial follows the **Device metric**, so it shows the value the device is actually reporting.

## Common mistakes

* **Mixing it up with the round gauge** — the Circular slider *sets* a value (you can turn it); the Last Data [Radial Gauge](/dashboards/adding-widgets/last-data-widget/radial-gauge) just *shows* one.
* **Choosing an on/off command** — a slider needs a number input; for on/off use a [Switch](/dashboards/adding-widgets/control-widget/switch).

## See also

* [Control widget](/dashboards/adding-widgets/control-widget) — overview and the other control types
* Other slider looks: [Simple Slider](/dashboards/adding-widgets/control-widget/slider-simple) · [Vertical Slider](/dashboards/adding-widgets/control-widget/slider-vertical)
* [Controlling Your Devices](/devices/commands) — set up the command this dial controls


# Vertical Slider

Add a Vertical Slider to a Chirp dashboard — an upright slider that sets a value like a level you raise or lower.

The **Vertical** slider sets a **value** on an upright bar — up for more, down for less. It reads like a level, so it suits things you picture going up and down.

## When to use it

Nice where an upright control fits the idea — a **brightness** level, **blinds** position, or anything you raise and lower. For a side-to-side control use the [Simple Slider](/dashboards/adding-widgets/control-widget/slider-simple); for a dial use the [Circular Slider](/dashboards/adding-widgets/control-widget/slider-circular).

## What you need first

* A device with a command on its **Commands & States** tab whose **input takes a number** (see [Setting up a command](/devices/commands/creating-commands)).
* A **Device metric** that reports the current value, so the slider shows where it's set.

## How to set it up

1. Open your dashboard in **edit mode** → **Add widget** → **Control**.
2. **Datasource** tab: pick the **Device** and the **Device metric** for the live value. Tap **Next**.
3. **Appearance** tab: type a **Widget name**, choose **Widget type → Slider**, then **Slider type → Vertical**.
4. Set the **Command** it controls, the **Parameter** it sets, and a starting **Value**.
5. Add **Start and End labels** for the range (say `0` and `254`) with **Display** on, pick a **Slider color**, and toggle the name/last-update line.
6. Tap **Save**.

<figure><img src="/files/X4QP4wmJRIFybnR63BiY" alt="Chirp Vertical slider — an upright bar setting a value across a range"><figcaption></figcaption></figure>

## What happens when you use it

Sliding up or down sends the command with the new value, the same way the device's States tab does. The handle follows the **Device metric**, so it shows the value the device is actually reporting.

## Common mistakes

* **Choosing an on/off command** — a slider needs a number input; for on/off use a [Switch](/dashboards/adding-widgets/control-widget/switch).
* **The range doesn't match the device** — set Start and End to the real lowest and highest values so the whole bar maps to values the device accepts.

## See also

* [Control widget](/dashboards/adding-widgets/control-widget) — overview and the other control types
* Other slider looks: [Simple Slider](/dashboards/adding-widgets/control-widget/slider-simple) · [Circular Slider](/dashboards/adding-widgets/control-widget/slider-circular)
* [Controlling Your Devices](/devices/commands) — set up the command this slider controls


# Input

Add an Input Control to a Chirp dashboard to send an exact value, like a thermostat target or color temperature.

The **Input** lets you type an **exact value** and tap **Apply** to send it — for when a slider is too rough and you want a precise number.

## When to use it

Use an Input when the exact figure matters: a **thermostat target**, a **color temperature**, or a specific **dimming level**. Where a [Simple Slider](/dashboards/adding-widgets/control-widget/slider-simple) is for sliding to roughly the right spot, the Input is for entering an exact value.

## What you need first

* A device with a command on its **Commands & States** tab whose **input accepts the value** you'll type (see [Setting up a command](/devices/commands/creating-commands)).
* A **Device metric** that reports the current value, shown next to the box so you can see where it is now.

## How to set it up

1. Open your dashboard in **edit mode** → **Add widget** → **Control**.
2. **Datasource** tab: pick the **Device** and the **Device metric** for the current value. Tap **Next**.
3. **Appearance** tab: type a **Widget name**, then under **Widget type** choose **Input**.
4. Set an **Input placeholder** (the faint hint in the box) and an optional **Input label**.
5. Choose the **Command** it sends, the **Parameter** it sets, and a default **Value**.
6. Toggle the name/last-update line, then tap **Save**.

<figure><img src="/files/vQYMCKSXN4apgFGbcNv7" alt="Input Control setting a lamp&#x27;s color temperature with an Apply button on a Chirp dashboard"><figcaption></figcaption></figure>

## What happens when you use it

You'll see the current value and a box. Type a new number and tap **Apply** to send it — nothing goes out until you tap Apply, so a half-typed number never reaches the device. Whether the value is accepted depends on the command's input (for example any limits set on it), so out-of-range numbers are turned away.

## Common mistakes

* **Expecting it to send as you type** — the Input only sends when you tap **Apply**.
* **Typing a value outside the allowed range** — the command's input sets what's valid; anything outside it won't be accepted.

## See also

* [Control widget](/dashboards/adding-widgets/control-widget) — overview and the other control types
* [Controlling Your Devices](/devices/commands) — set up the command this input sends


# Text Widget

Add a Text widget to a Chirp dashboard to label and organize your tiles with headings and short notes.

As you add more tiles, a dashboard can start to feel like a jumble. The **Text widget** is the simple fix: it drops a heading or a note onto the board so you can group things and label them. "Upstairs", "Garden", "Security" — a few text labels turn a crowded screen into tidy, easy-to-scan sections.

It doesn't show any sensor data — it's purely there to organize and explain.

<figure><img src="/files/JJyq7bvN75nTiaHkhlHy" alt="Text widget adding a labeled heading tile to a Chirp dashboard"><figcaption></figcaption></figure>

## Handy for

* **Section headings** — separate "Living Room", "Kids' Rooms", and "Outside" on one dashboard.
* **Little notes** — a reminder next to a group of tiles, like "Check these before bed."
* **Naming areas** — label each room or zone so anyone in the house knows what they're looking at.

## Adding a Text widget

1. In dashboard edit mode, pick **Text** from the widget picker.
2. Fill in:
   * **Widget name** *(required)* — the heading text. Placeholder *"Enter widget name."*
   * **Description** — optional text under the heading. You can write more than one line, so it works for a short note as well as a title.
3. Tap **Save**.

Then resize and move it like any tile — stretch it wide as a banner across the top of a section, or keep it small as a little label beside a group of readings. With a few text labels and your dashboard folders, even a busy home dashboard stays easy to read.

## See also

* [Adding Widgets](/dashboards/adding-widgets) — edit mode and the widget picker
* [Dashboards](/dashboards) — organizing your boards


# Chart Widget

Graph a reading's history over the hour, day, week, or month with color bands and a live current value.

<figure><img src="/files/I3ThWuI1fr095c9Mq8bU" alt="Chart widget — the Appearance settings beside a live preview of the graph"><figcaption></figcaption></figure>

The Chart widget draws a reading's history as a graph — a line or bars stretching back over the last hour, day, week, or month — so you can follow how it has moved, not just where it is right now.

One Chart widget puts four things together: the **current value** as a big number at the top, the **graph** of its history as a line or bars, an optional **average line** for the period, and optional **color bands** that mark which ranges are fine and which are not. You see today's reading and the pattern that led to it on a single tile.

Those color bands also tint the **big number** at the top: when the current reading sits inside a band, that number takes the band's color — the line or bars themselves keep the color you gave the metric. So the tile tells you how things are going before you even look at the graph.

A Chart widget follows one reading. If you want to watch several, add a separate Chart widget for each.

## Configure a Chart widget

Let's build a real one — a chart that tracks the living-room humidity through the week, so you can see whether the room stayed comfortable or kept drifting damp. A humidity sensor reports the room as a percentage. This is just an example: a Chart works for any reading whose history you care about — only the sensor and the numbers change.

1. Open your dashboard in edit mode and tap **Chart** in the widget picker. The settings panel opens on the **Datasource** tab, with nothing added yet.
2. Tap **Add datasource**. A **Datasource 1** block appears.
3. In the block, tap **Choose device** and pick the room's humidity sensor.
4. Tap **Add metric**. A metric row appears.
5. In the row, leave **Data type** on **Telemetry**, choose the humidity reading under **Device metric**, and pick a **Color** — this is the color of the line (or bars) on the graph, and the starting color of the big number at the top.

   > **Don't see your sensor reading?** The **Device metric** list only shows number readings. If one is missing, that metric is set up as text (String) or on/off (Boolean) instead of a number. Open **Data Templates** (the **Metrics Templates** button on your connection's Connected Devices list), find the metric on the **Metrics** tab, and switch its **Type** to Integer or Float — as long as the sensor really does send a number. See [Data Templates](/devices/data-templates).

   A Chart widget follows just **one reading** — once that metric is in place, there is no second row to fill in. For another reading, build another Chart widget.
6. Tap **Next** to open the **Appearance** tab.
7. Type a **Widget name** — "Living room humidity" — and a **Description** if you want a subtitle.
8. Under **Widget type**, choose **line** or **bar**. The **line** type draws a flowing curve, which suits a reading that drifts up and down gently like humidity; **bar** draws one bar per reading, handy when you would rather see each report on its own. Pick **line** here.
9. Choose the **Timeframe** — how much history the graph shows: **Last hour**, **Last day**, **Last week**, or **Last month**. For a week's view, pick **Last week**.
10. Under **Set value range**, fill in **From** and **To** — the bottom and top of the up-and-down axis. Choose a window that comfortably holds the readings you expect: **From** 20, **To** 80. (A fresh widget starts at 0–100; change it to fit your reading.)
11. Under **Thresholds**, tap **Add threshold** for each band of meaning. A threshold's **From** and **To** are the lower and upper edge of a color band on that same 20–80 scale; give it a **Label** and a **Color**. For room humidity, add three:

    * "Too dry" — **From** 20, **To** 40 — amber
    * "Comfortable" — **From** 40, **To** 60 — green
    * "Too damp" — **From** 60, **To** 80 — red

    Each threshold has two switches that do different jobs. **Show fill** colors in the whole band as a soft background; **Show line** draws a line along the band's edges. Turn **Show fill** on for "Comfortable" so the happy zone shows as a green stripe behind the graph; turn **Show line** on for "Too damp" so its lower edge at 60% is a clear red line you can watch the trace climb toward.
12. Turn on **Show average value** to add a dashed line at the week's average humidity, marked "Average" in the legend.
13. **Show vertical axis lines** and **Show horizontal axis lines** add a faint grid behind the graph — switch them on if a grid makes it easier to read.
14. Turn on **Display data legend** to list your band labels and the average next to the graph.
15. Tap **Save** to drop the widget onto your dashboard.

Now the tile shows the room's humidity right now as a big number, with the whole week traced behind it — and the green band makes it plain whether the room sat comfortable or kept sliding into the dry or damp zones. The same steps fit any reading with a history worth following; just change the sensor, the value range, and the bands.

## How the big number changes color

The large reading at the top starts in the color you gave the metric. When the current reading falls inside one of your threshold bands, the number switches to that band's color, and goes back to the metric color once the reading leaves every band.

So a humidity chart shows a calm green number while the room is comfortable and turns red the moment the air gets too damp — with no extra setup. The chart makes the problem easy to spot; to get a notification on your phone, pair it with an [alarm](/alarm).

## Bands here, conditions elsewhere

The Chart widget uses **threshold bands** — color ranges painted across the graph. The Last Data and Image widgets use the conditions system instead — named color rules with their own priority order. See [Conditions](/dashboards/adding-widgets/conditions).

## Home examples

**Is the fridge holding its cold?** Not just "is it 4°C now" — but "did it stay cold all week?" A fridge temperature sensor, **line** chart, **Last week**, value range 0 to 10. A green band 0–5°C and a red band 5–10°C show at a glance whether the fridge held steady or spiked one afternoon when the door was left open.

**Energy use across the week** A smart meter on a **line** chart, **Last week**. Set the value range to cover your home's draw — for example 0–6 kW — then add a green band over your usual range (say 0–3 kW) and a red band above it (say 4.5–6 kW). The right numbers depend on your home, so set **From** and **To** to what your meter actually reads; an unusually high overnight figure or a weekend peak then stands out the moment the line climbs above the green.

**Bedroom temperature overnight** A bedroom temperature sensor, **line** chart, **Last day**, value range 10–30 °C. A green band 17–21 °C marks a comfortable sleeping temperature, with a cooler color below it. A glance in the morning tells you whether the room held that comfortable band through the night or dipped in the small hours.

Any reading with a history worth watching fits the Chart widget — soil moisture, a water tank's level, air quality — so treat these as a place to start.

## See also

* [Last Data Widget](/dashboards/adding-widgets/last-data-widget) — The current reading on its own, when you do not need the history
* [Conditions](/dashboards/adding-widgets/conditions) — Color rules for the Last Data and Image widgets
* [Adding Widgets](/dashboards/adding-widgets) — How to open edit mode and use the widget picker


# Image Widget

Pin live sensor readings onto your own photo or floor plan, each colored by its conditions, with multi-layer views.

<figure><img src="/files/GGBUu0nydtKY5FoIAEf0" alt="The Image Widget being set up — a photo with sensor pins on it, shown next to a live preview"><figcaption></figcaption></figure>

The Image Widget lets you put your sensor readings straight onto a picture. Upload an image — and it really can be **any image**: a floor plan of your home, a photo of a room, a picture of the basement, a snapshot of the garden, a diagram of a piece of equipment — then drop live readings onto it, each one where its sensor actually sits.

Instead of scanning a list of device names and trying to remember which is which, you look at the real space and see what every part of it is doing. Glance at the floor plan and a cold room stands out; glance at a photo of the basement and you see the water softener is running low on salt.

Upload a supported image file — a PNG or JPG — of any place, object, or thing you want to keep an eye on. Each reading you place shows its current value, its unit, and an icon, and changes color as your conditions say, so the whole picture tells you the story at a glance.

## Configure an Image Widget

Let's build a real one — keeping an eye on the basement using a photo of the utility area. A level sensor watches the water-softener salt tank, and a sump-pit water-level sensor watches for rising water. This is just an example: the image can be anything, and the steps don't change.

1. Open your dashboard in edit mode and tap **Image Widget** in the widget picker. The settings panel opens — and unlike the other widgets, the **Appearance** tab comes first, because you upload the picture before you can place anything on it.
2. Type a name for the widget — something like "Basement".
3. The widget already has one layer, **Layer 1**. Give it a **Layer name** ("Utility area") and upload the image — your photo of the basement. PNG and JPG files work.
4. Tap **Next** to move to the **Datasource** tab.
5. Under the layer, tap **Add datasource** — this adds an empty datasource block. In the block, tap **Choose device** and pick the salt-tank level sensor.
6. Tap **Add metric**. Leave **Data type** on **Telemetry**, choose the salt-level reading under **Device metric**, and pick an **Icon**.

   > **Don't see your sensor reading?** The Image Widget only pins number readings. If one is missing, that metric is set up as text (String) or on/off (Boolean) instead of a number. Open **Data Templates** (the **Metrics Templates** button on your connection's Connected Devices list), find the metric on the **Metrics** tab, and switch its **Type** to Integer or Float — as long as the sensor really does send a number. See [Data Templates](/devices/data-templates).
7. Tap **Conditions: N** to open the Conditions window. Choose a **Default color**, then for each band tap **Add condition** and fill in the row — a **Condition name**, **Data type** set to **Number**, the **From** and **To** values, and a **Color**. The pin takes its color entirely from these. For the salt level as a percentage, add four:

   * "Empty" — **From** 0, **To** 10 — burgundy (a deep red)
   * "Add salt now" — **From** 10, **To** 30 — red
   * "Getting low" — **From** 30, **To** 60 — yellow
   * "Full" — **From** 60, **To** 100 — green

   Tap **Save** to close the window. The salt pin now glows green while the tank is full and slides through yellow and red to a thin burgundy strip as it empties — one look at the basement photo tells you when to buy a bag.
8. The pin appears on the image. **Drag it** onto the salt tank in the photo. The zoom controls (+ / −) on the preview help you place it exactly.
9. Add the second sensor the same way — **Add datasource**, choose the sump-pit water-level sensor, then **Add metric**. Open **Conditions: N** and set the bands in centimeters — 0–30 cm "Normal" green, 30–60 cm "Rising" yellow, 60–100 cm "Critical — check pump" red. A sump pit normally holds a little water, so the low band is "Normal" rather than empty. Drag its pin onto the sump pit in the photo.
10. Tap **Save** to drop the widget onto your dashboard.

Now the basement photo carries two live pins — the salt level and the sump-pit water level — each colored by its conditions. The same steps work for any picture; just change the photo, the sensors, and the bands.

## What layers are

<figure><img src="/files/pK0bo24T4y6KzL4K6NCy" alt="An Image Widget with two layers and the switcher that moves between them"><figcaption></figcaption></figure>

A **layer** is one image view inside a single Image Widget — not a see-through overlay on one picture. Every layer has its own image and its own pins. As soon as a widget has more than one layer, a **layer switcher** appears on it, and tapping it moves you between the views — so one widget can hold several pictures and several sets of readings.

Layers earn their place when one picture cannot show everything. A whole house is the easy example — one layer per floor:

* **Layer 1 — "Ground floor".** Upload the ground-floor plan and pin a reading in each room.
* **Layer 2 — "Upstairs".** Upload the upstairs plan and pin its rooms.

On the dashboard you tap the layer switcher to move from the ground floor to upstairs, all in one widget. Add the basement and the attic the same way — as many layers as the home needs, each with its own picture and its own pins.

The plans themselves are nothing fancy: a flat 2D floor plan is just an image you upload. A quick sketch does the job, and so does the plan an estate agent or builder handed you — there is no building to draw or model. That is what separates this widget from the [Digital Building Twin](/dashboards/adding-widgets/digital-building-twin): reach for the **Image Widget** when you already have flat 2D plans and only want live readings pinned onto them; reach for the **Digital Building Twin** when you want to draw and manage a full 3D model of your home.

**Layers or separate widgets?** Use layers when the pictures are different views of the same place. Use separate Image Widgets when the pictures belong in different parts of the dashboard or cover unrelated things.

Working with layers: **Layer 1** is already there — rename it and upload its image. Tap **Add new layer** only when you want another picture in the same widget. **Every layer needs its own image** — add a layer and leave it empty and **Next** won't let you continue. On the **Datasource** tab, add each datasource and metric under the right layer, and drag each pin on that layer's own picture.

## Home examples

**House floor plan — a reading per room** Upload your floor plan and pin a temperature sensor in each room: green 18–24°C "Comfortable", yellow 15–18°C "Cool", red below 15°C "Cold". Add an upstairs layer the same way and switch between floors.

**Garden layout — soil and watering** Upload a photo or sketch of the garden and pin soil-moisture sensors on the beds and pots — green 40–80%, yellow 20–40%, red below 20% — so you can see at a glance which corner needs watering.

**Basement or utility room — a photo, not a plan** Upload a straight photo of the space and pin whatever you watch there: the water-softener salt level, the sump-pit water level, the temperature, the humidity. The image does not have to be a floor plan — any photo where you want readings shown in place works.

Any picture you can take or draw can become an Image Widget, so treat these as a place to start. Wherever a reading makes more sense once you can see where it is, this widget puts it there.

## What the widget shows

On the dashboard, each layer shows its picture with a colored round pin at every spot you placed. Each pin carries the sensor's icon, its live value, and the unit, and updates as new readings come in.

**A pin's color comes entirely from its conditions.** The first matching condition wins; if none matches, the pin uses the Default color from the Conditions window. The Image Widget shows you the situation — to get a notification on your phone when a reading crosses a line, pair it with an [alarm](/alarm).

When a widget has two or more layers, the **layer switcher** moves between them. If a layer has no picture yet, or the widget has no sensors set up, that area shows a short placeholder message.

## See also

* [Conditions](/dashboards/adding-widgets/conditions) — The color rules behind every pin
* [Maps and Device Placement](/dashboards/maps-and-device-placement) — Placing sensors on an outdoor map (a different feature)
* [Adding Widgets](/dashboards/adding-widgets) — How to open edit mode and use the widget picker


# Map Widget

Show a GPS device's live position on an outdoor map with one reading on the marker and route history by date.

The Map widget shows where a GPS-reporting device is on a real outdoor interactive map — the same kind of map you use for navigation. The device's current location appears as a marker, and the marker shows one selected sensor reading at a time: current speed, battery level, engine on/off status, or any other value the device transmits.

Any device that reports GPS coordinates works — a family GPS tracker, a pet collar, a cellular vehicle tracker connected via the [Tracker Connector](/connectors/tracker-connector), or a LoRaWAN GPS tag connected via the [LNS Connector](/connectors/lns-connector). The widget looks for sensor fields named `lat`/`latitude` and `lon`/`longitude`/`lng`. If those fields exist on the device, it appears on the map automatically.

This is different from the [Image Widget](/dashboards/adding-widgets/image-widget), which lets you upload your own static image and pin sensors onto it. The Map widget is for devices that move in the real world.

Tap a button to switch to a date range view and see the route the device took over any period.

For placing stationary sensors on a map so you can see where each one is installed, see [Maps and Device Placement](/dashboards/maps-and-device-placement). For full GPS route history on the device detail page, see [Tracking What Matters](/dashboards/tracking-what-matters).

<figure><img src="/files/Z7j7OJiX6P0KrYJ7XZni" alt="Add Map widget — appearance settings with a live map preview of a tracker"><figcaption></figcaption></figure>

## Setting up a Map widget

### Step 1 — Choose Map from the widget picker

Open dashboard edit mode and tap **Map** in the widget picker. (See [Adding Widgets](/dashboards/adding-widgets) for how to open edit mode.) The settings panel opens with two tabs: **Datasource** and **Appearance**.

### Step 2 — Datasource tab: select a tracker and a metric

The Datasource tab is titled **"Map configuration"** with the subtitle **"Configure last data and data sources."**

1. Tap the device selector to choose a tracker device. The selector does not pre-filter by location capability — you can pick any device.
2. After selecting a device, the widget automatically looks for sensors named `lat` or `latitude` for latitude, and `lon`, `longitude`, or `lng` for longitude. If it finds them, the marker appears on the map. If no matching sensor names are found, no marker is shown.
3. Once a device is selected, non-location sensors from that device become available to add as an **additional metric**. Pick one to display its value on the map marker — speed, battery level, temperature, or any other reading the tracker sends.
4. The Map widget supports **exactly one additional metric**. Once you've added one, the Add metric option disappears.

The marker color reflects any conditions set for the additional metric — the same conditions system used in Last data widgets. If you want the marker to turn red when battery is low or change color based on speed, configure conditions on that metric.

### Step 3 — Appearance tab: name and style the widget

**Widget name** *(required)* — The heading shown above the map. Give it something clear, like "Family Tracker" or "Dog GPS".

**Description** — An optional subtitle under the widget name.

**Theme** — Choose **Light** or **Dark** for the map tile color scheme. This is independent of your dashboard's overall theme — pick whichever is easier to read.

**Display data legend** — Toggle on to show a legend that identifies the metric displayed on the marker.

### Step 4 — Save

Tap **Save** to add the widget to the dashboard.

## What to expect after adding the widget

The map renders with the tracker's last known position. The marker shows the metric value you selected and uses the condition-based color if conditions are configured. As the tracker reports new positions, the map updates automatically.

## Browsing route history

The Map widget has three controls for reviewing past location data:

* **History** — Tap to switch to a date range view.
* **Date range button** — Displays the active period in **DD.MM.YYYY - DD.MM.YYYY** format. Tap to change the range.
* **Clear data range** — Resets the view back to the tracker's current position.

When a date range is active, the widget draws the tracker's recorded positions as a dashed line connecting all the logged locations during that period. Up to 500 GPS points are rendered per date range.

## Troubleshooting

**No marker appears after selecting a device:** The widget looks for sensors named `lat`/`latitude` and `lon`/`longitude`/`lng` exactly. If your tracker uses different names for its location data, the widget can't find them. Open the device detail page and check the sensor names — they need to match one of those patterns.

**Route is empty for a selected date range:** The tracker either wasn't transmitting during that period or didn't have a GPS signal. Try widening the date range, or check the device detail page to confirm the tracker was active.

**Metric value not showing on the marker:** The tracker hasn't transmitted that specific field yet after the widget was configured. Open the device page and check recent readings to confirm the tracker is sending that value.

## Home examples

**Family GPS tracker:** Keep a Map widget on your home dashboard to see where a family member is on the way home. Add speed as the marker metric — the marker shows the current speed and turns yellow if it exceeds a threshold you set. Tap History to see the route taken.

**Pet GPS collar:** A Map widget for a dog's GPS collar. During the day it shows the dog's current position. In the evening, tap History and set the day's date range to see where the dog roamed on the walk. Set the metric to battery level to keep an eye on when the collar needs charging.

**Car or camper:** A family car or camper van with a GPS tracker. Add the Map widget and select speed as the metric — or switch to engine on/off status to see whether the engine is running when the car is parked. After a road trip, use the date range controls to trace the full route.

## See also

* [Tracking What Matters](/dashboards/tracking-what-matters) — Full GPS route history on the device detail page
* [Maps and Device Placement](/dashboards/maps-and-device-placement) — Place stationary sensors on a map
* [Conditions](/dashboards/adding-widgets/conditions) — Color rules for the marker's additional metric
* [Adding Widgets](/dashboards/adding-widgets) — How to open edit mode and use the widget picker


# iFrame Widget

Drop a live web page — a weather map, live traffic, or your calendar — onto a Chirp dashboard with the iFrame Widget.

<figure><img src="/files/sGV7fvQlfa7Ebc9CMBUl" alt="Setting up the iFrame Widget — an embed link in the Data source box, the list of supported services below, and a live preview"><figcaption></figcaption></figure>

Your home dashboard is where you glance to see how things are. Some of what you want there isn't a sensor reading at all: the local weather map, the traffic before the school run, the family calendar, a published camera or video feed. The iFrame Widget lets you pin those web pages right onto your dashboard, so the things you check every morning live in one place instead of a pile of open tabs.

An iFrame Widget shows a live web page inside a tile on your dashboard. The page keeps doing its thing — updating, animating, refreshing — just as it would in its own window, only now it sits next to your temperature, humidity, and door sensors. You give the widget a web address (an **embed link**) from a supported service, name it, and it appears.

Because the tile loads a real page from the web, Chirp only lets you embed sites from a friendly, checked list of services that are safe to show this way. That keeps your dashboard tidy and trustworthy — a tile can only show a page from a service we've okayed, so nothing unexpected ends up on your home screen.

## Add an iFrame Widget

Here's how to add a live local weather map to a dashboard so you can see the forecast next to your sensors. It's the same for anything else you embed — only the link changes.

1. Open your dashboard and tap the **actions menu** (three dots), then **Edit dashboard**. Tap the **plus (+) button** and pick **iFrame** from the widget picker — its tile says *iFrame*, "Connect a weather service or something else."
2. The settings open on the **Data source** tab (headed "iFrame configuration"), with a preview on the right. Look for the **Data source** box.
3. Grab the **embed link** from the service — not the web address at the top of your browser. Most sites tuck it under a **Share** button, then **Embed** or **Get embed code**. Sometimes you get a tidy link; sometimes you get a whole chunk of code like `<iframe width="650" height="450" src="https://…/embed…" frameborder="0"></iframe>`. **Copy only the bit inside `src="…"`** — the address that starts with `https://` — and nothing else. Don't paste the whole `<iframe …>` block; the box only wants the link, and pasting the full tag won't work.
4. Paste that link into the **Data source** box. Just under it, below **The following services are available**, Chirp shows the sites you can embed, sorted into groups — have a look to check yours is there. The link needs to start with **https\://**. The preview on the right fills in as soon as the link works; if it isn't supported or isn't quite right, you'll see the message *"Enter a valid https\:// embed URL"* instead of the page.
5. Tap **Next** to go to the **Appearance** tab.
6. Type a **Widget name** you'll recognize — like "Weather". You can add a **Description** too, but it's optional.
7. Tap **Save** in the settings, then **Save** in the dashboard header. Your weather map is now live on the dashboard, right beside your sensors.

> **Nothing showing in the preview?** Usually the link isn't quite right. Double-check you copied only the `https://` address from inside `src="…"` (not the whole `<iframe …>` chunk), that it starts with `https://`, and that the service is in the supported list under the box. A regular link, an `http://` one, or a site that isn't on the list won't load.

## What you can embed

The services you can use are sorted into groups in the picker, so it's easy to find what you're after. A few from each:

* **Dashboards & BI** — Power BI, Looker Studio, Tableau, Grafana. Handy if you already keep a chart of your energy use or solar output somewhere.
* **Maps & location** — Google Maps, OpenStreetMap, Mapbox. Show your neighborhood, a trip route, or a spot you're keeping an eye on.
* **Weather & air quality** — Windy, Meteoblue, Ventusky, IQAir. See the forecast, the wind, or today's pollen and air quality at a glance.
* **Video & camera feeds** — YouTube, Vimeo, Twitch. Embed a published stream or a favorite live view.
* **Transport & flights** — Waze, Flightradar24, FlightAware. Pin a Waze traffic map for the morning commute, or watch a flight come in so you know when to leave for the airport.
* **Shipping & parcel tracking** — 17TRACK, AfterShip, TrackingMore. Follow that parcel you're waiting on.
* **Finance & markets** — TradingView, Investing.com, Trading Economics. Keep an eye on a price or a market you follow.
* **Status & docs** — Statuspage, Instatus, Google Docs. Check whether a service you rely on is up, or pin a shared note.
* **Calendars & forms** — Google Calendar, Google Forms, Microsoft Forms, Calendly. Put the family calendar front and center.

The list you see in the widget is always up to date. If the service you want isn't there, tap the **please submit a request to add the desired resource** link under the Data source box and ask us to add it — we'll take a look and see if it can join the list.

## iFrame Widget or Map Widget?

It's easy to mix these up, so here's the difference:

* The **iFrame Widget** shows an external *web page* — including a web map like a Waze traffic view or an embedded Google Map. It shows whatever that website shows; it doesn't know anything about your own sensors.
* The [**Map Widget**](/dashboards/adding-widgets/map-widget) puts one of *your own* GPS devices on a map and follows where it is right now. If you want to see where a car tracker or a moving sensor is, that's the Map Widget — not the iFrame Widget.

## Home examples

**Morning weather, right where you look** Add a Windy or Meteoblue map to your main dashboard and it sits next to the indoor temperature and humidity. One glance tells you both what it's like outside and whether you left a window open.

**Traffic before the school run** Embed a Waze map of your usual route and check it with your morning coffee. See the jams before you set off and decide when to leave — right beside the sensors telling you the house is buttoned up for the day.

**The family calendar on the wall tablet** If you keep a dashboard on a hallway tablet, embed your shared Google Calendar. Everyone sees the week's plans beside the home's sensors — school runs, bin day, and whether the garage door got left up.

## What the widget shows

<figure><img src="/files/m6i5pMyEEkPqfNd5KEHR" alt="A home dashboard with a live weather map embedded in an iFrame Widget, next to a 3D home model and a tank-level gauge"><figcaption></figcaption></figure>

On your dashboard, the iFrame Widget shows the web page live inside its tile, right beside your other panels — above, a weather map sits next to a 3D home model and a tank-level gauge. The page updates on its own, just like it would in a browser, so there's no separate refresh setting on the widget. In edit mode you can drag the tile around and resize it, so a busy page like a map gets the space it needs.

The iFrame Widget is just for viewing — it doesn't read your sensors, run automations, or send alerts. Use it to keep the web pages you care about close by, and let your sensor widgets (Last Data, Chart, Image, and the Digital Building Twin) handle your device readings.

## See also

* [Adding Widgets](/dashboards/adding-widgets) — Edit mode and the widget picker
* [Map Widget](/dashboards/adding-widgets/map-widget) — Follow where your own GPS device is (not the same as embedding a web map)
* [Digital Building Twin](/dashboards/adding-widgets/digital-building-twin) — A live 3D model of your home


# Digital Building Twin

Build a 3D model of your home and watch it light up with live sensor colors and readings, right on your dashboard.

The Digital Building Twin lets you build a 3D model of your home and watch your sensors come to life inside it. Draw your rooms, drop in the furniture, place your sensors where they really are — and then the model lights up: the bedroom glows warm, the front door shows open, the basement turns blue when the leak sensor gets wet.

It's the difference between reading "Sensor 4: 1" in a list and glancing at a picture of your house where the garage door is clearly, visibly open. Your home stops being a column of numbers and becomes something you can actually *see*.

And it's all built right into Chirp. There's no extra app to download and no design software to learn. You sketch the layout, furnish it from a library of more than 60 ready-made 3D objects, connect each one to a sensor, and pick the colors that mean "all good" and "look at this." Once it's done, it sits on your dashboard like any other widget.

<figure><img src="/files/ubOX2qzkF3shQWHQKFfY" alt="Digital Building Twin showing your home and yard live — parking spots out front colored red and green by occupancy, bins by the fence in color-coded fill states, and sensor markers across the rooms"><figcaption></figcaption></figure>

## What you can make with it

* **A 3D model of your home** — draw walls, doors, and windows across as many floors as your house has, in a flat 2D view or a 3D view. See [Drawing your home](/dashboards/adding-widgets/digital-building-twin/drawing-your-building).
* **A head start from a plan** — if you have a floor plan as a DXF file, import it instead of drawing. See [Importing a floor plan](/dashboards/adding-widgets/digital-building-twin/importing-a-dxf-plan).
* **A model traced from a map** — draw your home's outline straight onto a satellite map. See [Tracing from the map](/dashboards/adding-widgets/digital-building-twin/tracing-from-the-map).
* **A furnished home** — add sofas, beds, the fridge, a parking spot, and more from the object library. See [Placing objects](/dashboards/adding-widgets/digital-building-twin/placing-objects) and the [Object library](/dashboards/adding-widgets/digital-building-twin/object-catalog).
* **A live picture of your home** — connect sensors to objects and choose colors so the model reacts as things change. See [Connecting sensors and colors](/dashboards/adding-widgets/digital-building-twin/binding-sensors-and-colors).
* **Readings shown right in the room** — pin a sensor's value to a spot in the model. See [Pins and live readings](/dashboards/adding-widgets/digital-building-twin/drop-pins-and-live-values).
* **A home placed on the real map** — anchor your home to its real-world location. See [GPS anchoring](/dashboards/adding-widgets/digital-building-twin/gps-anchoring).

## Adding a Digital Building Twin to a dashboard

The Digital Building Twin is a dashboard widget. In the widget picker it's listed as **Digital building twin**.

1. Open the dashboard you'd like it on and switch the dashboard to **edit mode**. (Not sure how? [Adding Widgets](/dashboards/adding-widgets) explains edit mode and the widget picker.)
2. In the widget picker, click **Digital building twin**.
3. The home editor opens full-screen. This is where you draw, furnish, and connect everything — each page in this section takes one part of that.
4. When you're happy with it, click **Save** in the top-right corner. A **Widget name** box appears — type a name and click **Save** again.
5. The editor closes and your Digital Building Twin appears on the dashboard, showing the model with live sensor colors.

Want to change it later? Open the dashboard in edit mode and open the widget's settings — the full editor opens again with everything just as you left it.

## How it looks on your dashboard

Once saved, the widget sits on your dashboard grid like any other tile — you can resize it, drop it in a folder, and share it with the household. On the dashboard the model is view-only: it shows your home with live colors and readings, and any editing happens back inside the full editor.

Whatever view you leave the editor in is the view the dashboard shows. Save it in the flat 2D view and the dashboard shows a clean floor plan. Save it in 3D, tilted the way you like, and that's the angle the tile opens at.

## Where to start

* New here? Read the [Editor tour](/dashboards/adding-widgets/digital-building-twin/editor-tour) first to learn your way around.
* Want to dive in? Go to [Drawing your home](/dashboards/adding-widgets/digital-building-twin/drawing-your-building).
* Got a floor plan already? See [Importing a floor plan](/dashboards/adding-widgets/digital-building-twin/importing-a-dxf-plan).

## See also

* [Adding Widgets](/dashboards/adding-widgets) — Edit mode and the widget picker
* [Conditions](/dashboards/adding-widgets/conditions) — How color rules work across your widgets


# Editor Tour

A quick walk around the 3D home editor — the toolbar, Scene panel, settings, floor buttons, and saving.

The Digital Building Twin editor is a full-screen workspace where everything happens — drawing rooms, adding furniture, connecting sensors, setting up the view. This page is a quick walk around it so the rest of the section makes sense. Think of it as the welcome tour; the other pages are the detailed how-tos.

When you add a **Digital building twin** widget, the editor opens with a small starter model already there — a building with one floor. You grow it from there.

## The bottom toolbar

The toolbar in the middle of the bottom edge is your main control. It has four modes:

* **Select** — the normal mode. Click things to pick them up, move them, and change their settings. Press **Escape** any time to come back here.
* **Build** — opens the building tools: **Wall**, **Door**, **Window**, **Fence**, and **Trace from map**. This is how you draw the shell of your home. See [Drawing your home](/dashboards/adding-widgets/digital-building-twin/drawing-your-building).
* **Furnish** — opens the object library: five tabs (**Furniture**, **Appliance**, **Kitchen**, **Bathroom**, **Outdoor**) and a strip of 3D models to drop in. See [Placing objects](/dashboards/adding-widgets/digital-building-twin/placing-objects).
* **Sensors** — opens the Sensors panel, where you connect your devices and link their readings to things in the model. See [Connecting sensors and colors](/dashboards/adding-widgets/digital-building-twin/binding-sensors-and-colors).

Click a mode to switch into it; click it again to go back to Select.

## The Scene panel

The **Scene** panel is a list of everything in your model, shown as a tree — your building, each floor, and the walls, items, doors, and windows on it. Click anything in the list to select it in the view. Double-click it (or use the little pencil) to rename it. Renaming is worth doing: "Kitchen wall" or "Front door" is much easier to find later than "Wall 9."

## The settings panel

Click any object and a panel opens with that object's settings:

* **Furniture and objects** — Name, Position, Rotation (with handy **+45°** / **-45°** buttons), Scale, and size.
* **Walls** — Length, Height, Thickness, and a **Material** you can pick: white, brick, concrete, wood, glass, metal, plaster, tile, marble, or your own color.
* **Doors and windows** — Width, Height, where they sit along the wall, which side a door is hinged, which way it swings.

Whatever you've selected also gets a little badge floating above it with quick **Move**, **Duplicate**, and **Delete** buttons.

## Moving around the model

There are two ways to look at your model:

* **3D view** — spin around it freely. Drag with the left mouse button to rotate, the right button to slide the view across, and the scroll wheel to zoom in and out. Hold the **Space** bar to make left-drag slide instead of rotate.
* **2D view** — a straight-down, flat floor-plan view. You can't rotate it — just slide and zoom. It's the easier view for laying rooms out neatly.

Whatever angle and zoom you leave the editor at is what the dashboard tile shows, so set the view the way you want it before saving.

## The floor buttons

A little floating stack of floor buttons sits off to one side. It lists each floor (**L0**, **L1**, and so on), lets you add a floor above or below, and switches which floor you're working on. It also holds the **3D / 2D** switch and, if your home has more than one floor, a **Stack / Solo** switch. See [Floors and levels](/dashboards/adding-widgets/digital-building-twin/floors-and-levels).

## Undo, redo, and removing things

* **Undo** — Ctrl+Z (Cmd+Z on a Mac).
* **Redo** — Ctrl+Shift+Z (Cmd+Shift+Z).
* **Remove something** — select it and press **Delete** or **Backspace**, or use the Delete button on the badge or settings panel. Your building and its floors are protected, so you can't delete those by accident.
* **Back out of a tool** — press **Escape** or right-click to drop whatever tool you're using and return to Select.

## Saving and closing

* **Save** — the button in the top-right corner. It asks for a **Widget name**; type or confirm it and your model is saved onto the dashboard.
* **Cancel** — closes the editor. If you have unsaved changes it checks first with a **Discard unsaved changes?** message — choose **Discard** to leave or **Keep editing** to stay.

## See also

* [Drawing your home](/dashboards/adding-widgets/digital-building-twin/drawing-your-building) — Walls, doors, and windows
* [Floors and levels](/dashboards/adding-widgets/digital-building-twin/floors-and-levels) — Multiple floors and the 2D/3D switch
* [Placing objects](/dashboards/adding-widgets/digital-building-twin/placing-objects) — The object library


# Drawing Your Home

Draw walls, doors, windows, and fences for your 3D home model in a flat 2D or full 3D view.

The walls, doors, and windows you draw are what make the model recognizably *your* place — not a generic box, but your home, with the kitchen where the kitchen is and the back door where the back door is. A few minutes of drawing is all it takes. This page shows you how.

Prefer not to draw it all by hand? You can import a floor plan or trace your home from a map instead — see [Importing a floor plan](/dashboards/adding-widgets/digital-building-twin/importing-a-dxf-plan) and [Tracing from the map](/dashboards/adding-widgets/digital-building-twin/tracing-from-the-map). And you can mix the approaches: trace the outside, then draw the inside walls yourself.

## Drawing in 2D or 3D

The editor shows your model in two ways, and you can draw in either:

* **2D view** looks straight down, like a paper floor plan. It doesn't rotate, so it's the easy view for getting room shapes right.
* **3D view** shows the walls standing up, so you can see how it really looks.

Flip between them with the **3D / 2D** switch on the floor buttons. Most people sketch the layout in 2D and then pop into 3D to admire it.

## Drawing a wall

1. On the bottom toolbar, click **Build**. The building tools appear.
2. Click **Wall**.
3. Click once in the view to drop the **start** of the wall.
4. Move the mouse — a preview wall stretches out, with its length shown in meters as you go.
5. Click again to drop the **end**. The wall appears.
6. The tool stays on, so you can carry straight on to the next wall. Each wall is its own two-click action.

Walls snap to a grid as you draw, which keeps your corners square and your rooms tidy without any careful aiming. If a new wall crosses one that's already there, the older wall splits at the crossing — handy later, because you can color each piece on its own.

Done drawing? Press **Escape**, right-click, or click **Build** again.

## Adding doors and windows

Doors and windows go *into* a wall, so draw your walls first.

1. Click **Build**, then click **Door** or **Window**.
2. Click on a wall where you want the opening.
3. It's cut into the wall.

Switch to **Select** and click a door or window to tidy it up in the settings panel:

* **Doors** — Width, Height, where it sits along the wall, which side it's **hinged**, and which way it **swings** (inward or outward).
* **Windows** — Width, Height, where it sits along the wall, how high off the floor, and the sill depth.

## Drawing a fence

A fence draws just like a wall — click **Build**, click **Fence**, then click a start point and an end point. Fences are great for the parts of your property that aren't house: the garden boundary, the edge of the driveway, a yard.

## Tweaking walls afterwards

Switch to **Select** and click a wall to open its settings:

* **Length** — shown so you can check it.
* **Height** — how tall the wall is.
* **Thickness** — how thick it is.
* **Material** — a row of looks to choose from (white, brick, concrete, wood, glass, metal, plaster, tile, marble) plus a **custom** color. It's purely for appearance — it doesn't change anything about sensors — but a brick exterior and white interior walls make the model feel like home.

To remove a wall, select it and press **Delete**, or use the Delete button in its settings.

## Naming things as you go

As your home takes shape, open the **Scene** panel and give your walls and rooms real names — double-click to rename. "Living room wall" beats "Wall 12," and good names make connecting sensors much quicker later on.

## Tips

* Draw the outside walls first, then the inside ones. The grid snap keeps it all lined up.
* Lay it out in 2D, then switch to 3D to check the heights and the doorways look right.
* Undo (Ctrl+Z) walks back through everything you've drawn, so don't be afraid to experiment.
* It doesn't have to be a perfect architect's drawing — it just has to look enough like your home that you know which room is which at a glance.

## See also

* [Importing a floor plan](/dashboards/adding-widgets/digital-building-twin/importing-a-dxf-plan) — Start from a plan file
* [Tracing from the map](/dashboards/adding-widgets/digital-building-twin/tracing-from-the-map) — Trace your home from a satellite map
* [Floors and levels](/dashboards/adding-widgets/digital-building-twin/floors-and-levels) — Add upstairs, downstairs, the basement
* [Placing objects](/dashboards/adding-widgets/digital-building-twin/placing-objects) — Furnish the rooms


# Importing a Floor Plan

Turn a DXF floor plan into walls for your 3D home — set the source unit and preview before importing.

If you already have a floor plan of your home — from when you bought the place, from a renovation, from an estate-agent listing — you don't have to draw your home from scratch. The editor can read a **DXF** file, the standard format that design and drawing programs export, and turn it straight into walls.

It's the quickest route to an accurate model: the layout comes in already shaped and to scale, and you get to spend your time on the fun part — furnishing rooms and connecting sensors.

## What you need

* A `.dxf` file of your floor plan. Architects, builders, and home-design apps can all export DXF.
* The file is read right in your browser. Nothing is sent anywhere until you save the widget.

## Bringing in a file

1. On the bottom toolbar, click **Build**, then click **Trace from map** — the import window is reached from the same building-tools row.
2. In the import window, click **Choose file** and pick your `.dxf` file.
3. The window reads the file and shows you a **preview** of the walls it found, so you can check it looks right before anything is added.
4. Have a look at the **Options** and the count of what was found (below).
5. Click **Import**. The plan's lines become walls, placed on the floor you're currently working on.

If the file can't be read, the window will tell you. If it reads but doesn't contain any walls, it says that too — some plan files only hold labels and measurements, with no actual walls.

## Options

Two settings control how the plan is read:

* **Source unit** — the unit your plan was drawn in: **Millimeters**, **Centimeters**, **Meters**, **Inches**, **Feet**, or **Unitless**. The editor reads the unit from the file when it can and fills this in for you; change it if the file got it wrong. This is the setting that decides whether your home comes in at the right size — if the imported plan looks far too big or far too small, the source unit is almost always why.
* **Arc segments** — how smoothly curved lines are drawn, since walls are made of straight pieces: **Low**, **Medium**, or **High**. Medium is fine for most homes.

The preview updates every time you change a setting, so you can get the size right just by looking.

## What was found

The window shows a count of what the import did — how many **Walls** it created, how many curved shapes it approximated, and how many **Skipped entities** it left out. **Warnings** explain anything that was dropped. A few skipped items is completely normal: a plan file carries lots of things that aren't walls — text, dimension lines, furniture symbols — and only the walls belong in your model.

## After importing

The imported walls work exactly like walls you draw yourself. Click any of them to set the height, thickness, and material, add doors and windows, and keep building. If something's not right, **Undo** (Ctrl+Z) takes the import back out so you can change the source unit and try again.

A nice workflow: import the shell from the plan file, switch to the flat **2D view** to check the rooms, then draw any inside walls the plan didn't have — and you're ready to furnish.

## Tips

* If your home imports at the wrong size, fix the **Source unit** and import again.
* Importing a multi-floor home? Add the floor first (see [Floors and levels](/dashboards/adding-widgets/digital-building-twin/floors-and-levels)), switch to it, then import that floor's plan.
* The tidier the plan file, the cleaner the import. If a plan is crowded with extra layers, exporting just the walls from the design app gives the best result.

## See also

* [Drawing your home](/dashboards/adding-widgets/digital-building-twin/drawing-your-building) — Draw or adjust walls by hand
* [Tracing from the map](/dashboards/adding-widgets/digital-building-twin/tracing-from-the-map) — Build from a satellite map instead
* [Floors and levels](/dashboards/adding-widgets/digital-building-twin/floors-and-levels) — Import each floor onto its own level


# Tracing from the Map

Click your home's outline on a satellite map to turn it into walls and save its real-world location.

No floor plan? No problem. You can build the shell of your home straight from a satellite map. Open the map, find your house, click around its outline, and the editor turns that shape into walls — and remembers where on Earth your home actually is.

This is the easiest way to start when you can see your home from above but don't have any drawings of it. It works just as well for the parts of your property beyond the house — the garden, the driveway, the garage, a shed. It's also how your home gets its **map location**: the trace saves your home's real coordinates, which is what the features in [GPS anchoring](/dashboards/adding-widgets/digital-building-twin/gps-anchoring) build on.

## Opening the map

1. On the bottom toolbar, click **Build**.
2. In the building-tools row, click **Trace from map**.
3. A full-screen map opens.

Move and zoom the map until your home is nicely in view — drag to move, scroll to zoom, or use the controls in the corner.

## Tracing your home

1. Click **Trace building** to start. The cursor turns into a crosshair and a hint appears: *Click on the map to add building corners*.
2. Click each **corner** of your home, one after another. Each click drops a point, and the points join up into the outline you're drawing.
3. Go all the way around the edge of the house. The toolbar keeps a running count of your points.
4. Put a point in the wrong spot? Click **Undo** to take the last one back. **Reset** clears everything and starts fresh. **Pause** lets you stop adding points for a moment without losing the ones you have.
5. When you've gone all the way around — three points or more — click **Import**.

The outline becomes walls, one for each side, placed on the floor you're currently on. The map closes and you're back in the editor with the shell of your home in place.

## What gets saved

Importing a traced home does two things:

* **Creates the walls** — one for each edge of the outline you drew, on the active floor.
* **Saves your home's location** — because you drew on a real map, the editor remembers your home's real-world coordinates. That location travels with the model, and it's what the map-based features build on later. See [GPS anchoring](/dashboards/adding-widgets/digital-building-twin/gps-anchoring).

## After tracing

The traced walls are just ordinary walls — click any of them to set height, thickness, and material, add doors and windows, draw the inside rooms, and furnish away. Tracing gives you a correctly-shaped, correctly-placed outline; everything inside it you build like normal.

## Tips

* Zoom in close on the map before you start — the bigger your house looks on screen, the more accurately you can click each corner.
* Go around the outline in order, all the way around once. Don't hop from one side of the house to the other.
* For an L-shaped house, click a point at every corner — including the inside corners where the L bends.
* Use **Pause** if you need to move the map partway through, then carry on clicking.

## See also

* [GPS anchoring](/dashboards/adding-widgets/digital-building-twin/gps-anchoring) — What your home's saved location is for
* [Drawing your home](/dashboards/adding-widgets/digital-building-twin/drawing-your-building) — Add the inside rooms after tracing
* [Importing a floor plan](/dashboards/adding-widgets/digital-building-twin/importing-a-dxf-plan) — Build from a plan file instead


# Floors and Levels

Add upstairs, downstairs, and basement levels to your 3D home and switch between stacked and solo floor views.

Most homes have more than one level — an upstairs and a downstairs, maybe a basement, maybe a loft. A Digital Building Twin handles all of them in a single widget. Each floor is its own layer of the same model, with its own rooms, its own furniture, and its own sensors.

This page covers adding floors, moving between them, and the two ways to look at a multi-floor home.

## The floor buttons

A small floating stack of buttons sits to one side of the editor. It's mission control for floors:

* Each floor is a button — **L0**, **L1**, **L2**, and so on. The top floor sits at the top of the stack, the bottom floor at the bottom, just like the real house.
* The floor you're currently working on is highlighted.
* Click any floor button to switch to that floor. Whatever you draw, place, or connect goes onto the floor you're on.

## Adding a floor

* Click the **+** at the **top** of the stack to add a floor **above** the highest one — an attic or loft.
* Click the **+** at the **bottom** of the stack to add a floor **below** the lowest one — a basement or cellar.

When you add a floor, the editor gives it a floor plate shaped like the floor next to it, so a new level starts with a footprint instead of nothing. From there you draw its walls, add its furniture, and connect its sensors on their own.

A tidy way to do a whole house: add all the floors first, then work through them one at a time.

## Removing a floor

Select the floor on the stack, then click the **delete** icon on its button. A model always keeps at least one floor, so the delete button only shows up when there's more than one.

## Two ways to view a multi-floor home

Below the floor buttons are two view switches.

### 3D / 2D

Switches between the **3D view** (spin the model around) and the **2D view** (a flat, top-down plan). It's the same switch covered in the [Editor tour](/dashboards/adding-widgets/digital-building-twin/editor-tour). Lay rooms out in 2D, check them in 3D.

### Stack / Solo

This switch decides how the floors are shown, and only appears once your home has more than one floor:

* **Stack** — every floor is shown in its real place, one on top of another. You see the whole house at once. Best for a final look and for setting up the dashboard view.
* **Solo** — only the floor you're on is shown; the others are hidden. Best while you're working — just the one floor, with nothing from above or below getting in the way.

Most people work in **Solo** so each floor is clear while they build it, then flip to **Stack** to see the whole house before saving.

## What the dashboard shows

The dashboard tile shows your home from the angle and view you leave the editor in. For a multi-floor house, framing it in **Stack** with a gentle 3D tilt gives a nice whole-house view on the dashboard. If one floor matters most — the floor with the nursery, the basement with the leak sensor — you can frame that one instead and save.

## Tips

* Give your floors real names in the **Scene** panel — "Upstairs," "Ground Floor," "Basement" — rather than leaving them as L0, L1, L2.
* Build one floor at a time. Switching to **Solo** keeps the floor you're on free of clutter.
* Sensors stay attached to their objects, so a sensor upstairs and a sensor downstairs both stay in the right place no matter which floor you're viewing.

## See also

* [Editor tour](/dashboards/adding-widgets/digital-building-twin/editor-tour) — The 3D/2D switch and getting around
* [Drawing your home](/dashboards/adding-widgets/digital-building-twin/drawing-your-building) — Build each floor
* [Connecting sensors and colors](/dashboards/adding-widgets/digital-building-twin/binding-sensors-and-colors) — Wire up sensors on every floor


# Placing Objects

Drop furniture and objects into your 3D home, turn them as you place, and adjust position, scale, and rotation.

Walls give you rooms; objects make those rooms feel like *your* home. The sofa in the living room, the bed in the bedroom, the car on the driveway. And objects are more than decoration — they're what most of your sensors connect to. A sensor reads "the door is open," and the garage door you placed swings into red.

The editor comes with a library of more than 60 ready-made 3D objects. This page is about placing them; the full list is in the [Object library](/dashboards/adding-widgets/digital-building-twin/object-catalog).

## Opening the library

1. On the bottom toolbar, click **Furnish**.
2. A row of five tabs appears — **Furniture**, **Appliance**, **Kitchen**, **Bathroom**, **Outdoor** — above a scrollable strip of object pictures.
3. Click a tab to load that category, and scroll the strip to see what's there.

## Placing an object

1. With **Furnish** open, click an object's picture in the strip to pick it up.
2. Move your cursor into the model — an outline of the object follows it around.
3. Click where you want it. The object drops into place.
4. The tool stays ready, so you can keep clicking to place more of the same thing. Pick a different picture to switch objects.
5. Press **Escape** or right-click when you're finished placing.

Objects snap to a fine grid as you go, so a row of chairs or a line of parking spots ends up evenly spaced without any careful lining-up.

### Turning objects as you place them

For objects that sit on the floor, press **R** or **T** while you're placing to spin the outline by 45° before you click. That way the bed faces the right wall and the car points down the driveway from the moment you drop it.

### Things that go on the wall

Some objects belong on a wall, not the floor — a wall-mounted TV, a wall AC unit, a shelf, a wall sink. When you place one of these, it sticks to whatever wall your cursor is over and turns to face into the room. Slide your cursor up or down the wall to set how high it sits.

## Adjusting an object afterwards

Switch to **Select** and click an object to open its settings:

* **Name** — rename it so it's easy to spot in the Scene panel and when you connect sensors.
* **Position** — where it sits, adjustable precisely if you need it just so.
* **Rotation** — set the angle directly, or use the **+45°** / **-45°** buttons.
* **Scale** — make an object a bit bigger or smaller than its standard size.
* **Dimensions** — the object's size, shown for reference.

The selected object also gets a little badge above it with quick **Move**, **Duplicate**, and **Delete** buttons. **Duplicate** is the fast way to fill a room — place one dining chair exactly right, then duplicate it around the table.

## Parking spots

The **Parking Spot** object (in the **Outdoor** tab) has one bonus setting: a **Spot #** field. If you've got assigned parking, give the spot its number and it shows right on the spot in the model. When you duplicate a numbered spot, the number ticks up automatically — handy if you're laying out a whole row. A parking spot is the perfect partner for an occupancy sensor — see [Connecting sensors and colors](/dashboards/adding-widgets/digital-building-twin/binding-sensors-and-colors).

## Tips

* Place the objects that will have sensors first — the doors, the garage, the parking spot, the appliances you watch — then add other furniture if you'd like the model to feel more complete.
* Use **Duplicate** with the grid snap to fill a room quickly.
* Rename objects as you place them. "Garage door" is much easier to connect a sensor to than "Gate 2."
* You don't have to furnish every corner. Place what matters; the point is that you can look at the model and instantly know which room is which.

## See also

* [Object library](/dashboards/adding-widgets/digital-building-twin/object-catalog) — Everything you can place, by category
* [Connecting sensors and colors](/dashboards/adding-widgets/digital-building-twin/binding-sensors-and-colors) — Link objects to live readings
* [Drawing your home](/dashboards/adding-widgets/digital-building-twin/drawing-your-building) — Build the rooms objects go in


# Object Library

Browse the 60-plus 3D objects for your home model — furniture, kitchen, bathroom, appliances, and outdoor items.

The editor comes with a library of more than 60 ready-made 3D objects, sorted into five tabs. This page is the rundown of what's in each one. For how to actually drop objects into your model, see [Placing objects](/dashboards/adding-widgets/digital-building-twin/placing-objects).

Every object is a real, properly-sized 3D model — a bed is bed-sized, a parking spot is the size of a real parking space. That's what makes the finished model feel like your home rather than a rough sketch.

## Furniture

Everyday things for living spaces and bedrooms:

Sofa, Armchair, Dining Chair, Office Chair, Stool, Coffee Table, Dining Table, Office Table, Pool Table, Double Bed, Single Bed, Bunk Bed, Bookshelf, Dresser, Closet, Shelf, Trash Bin, Column, Round Carpet, Large Plant, Small Plant, Office Trash Bin, Office Wastebasket.

This is the tab you'll reach for most when furnishing the living room, the bedrooms, and a home office.

## Kitchen

The basics for your kitchen:

Stove, Fridge, Counter, Microwave.

The **Fridge** is a natural one to connect a temperature sensor to — your model can show at a glance whether the fridge is keeping its cool.

## Bathroom

Fixtures for bathrooms and washrooms:

Toilet, Bathtub, Sink, Faucet, Vessel Sink, Vessel Sink with Faucet.

A bathroom is one good place for a leak sensor — place the sink or bath, then connect a leak sensor nearby so the room turns blue if water appears. The same idea works under the kitchen sink, behind the washing machine, by the water heater — anywhere a leak would matter to you.

## Appliance

Devices and home equipment — often the things you most want to keep an eye on:

Ceiling Lamp, Floor Lamp, Table Lamp, TV, Computer, Washer, AC Unit, Smoke Detector, Water Boiler, Gas Water Heater, Water Pump, Water Pump (Heavy Duty), Water Pump Station, Water Softener Cylinder, Water Softener Tank.

Plenty here to connect sensors to: a **Smoke Detector** for fire safety, an **AC Unit** for comfort, a **Washer** for a laundry-done alert, a **Water Boiler** or **Water Pump** for the utility room. Connect a sensor and the appliance itself shows its status in the model.

## Outdoor

Everything beyond the front door — gardens, driveways, and the edges of your property:

Fir Tree, Bush, Patio Umbrella, Parking Spot, Car, AC Condenser, Rooftop AC Unit, Outdoor AC Unit, Traffic Barrier, Gate, Public Trash Bin, Public Trash Bin (Round), Wheelie Bin, Wheeled Trash Container, Waste Dumpster, Large Waste Dumpster.

**Parking Spot** and **Car** are great for the driveway — connect an occupancy sensor and your model shows whether the car is home. **Gate** works for a driveway gate you'd like to monitor, and the trees and bushes help the garden look like your garden.

## On the wall or on the floor

Most objects stand on the floor. A few are made for walls — wall TVs, wall AC units, shelves, wall sinks — and they stick to a wall automatically when you place them, facing into the room. You don't pick a type; you just place the object and it knows where it belongs. See [Placing objects](/dashboards/adding-widgets/digital-building-twin/placing-objects) for the details.

## Choosing what to place

How much you furnish your home model is entirely up to you — some people place every piece of furniture, others add only what carries a sensor. Either way works; what matters is that the model is *clear* enough that one glance tells you which room you're looking at. A simple way to start:

1. Place the objects that will have sensors first — the doors, the garage, the parking spot, the appliances and rooms you actually monitor.
2. Add a few familiar pieces — the sofa, the beds, the dining table — so each room is easy to recognize.
3. From there, add as much or as little as you enjoy. A sparse model and a fully decorated one both do the job. Let what feels readable to you decide — and treat the library as a kit for building whatever your home actually is, not a checklist.

## See also

* [Placing objects](/dashboards/adding-widgets/digital-building-twin/placing-objects) — How to place, turn, and arrange objects
* [Connecting sensors and colors](/dashboards/adding-widgets/digital-building-twin/binding-sensors-and-colors) — Turn objects into live indicators


# Connecting Sensors and Colors

Link a sensor reading to objects in your 3D home and set color rules so the door, room, or basement reacts live.

This is the step that makes the whole thing worthwhile. Up to now your model is a nice 3D drawing of your home. Connecting sensors brings it to life: a sensor says "open" and the garage door turns red; a sensor reads 26 °C and the nursery shifts from green to amber.

A **connection** links one sensor reading to one or more objects in your model, along with the color rules that decide what color those objects show. This page walks through making that link.

## Opening the Sensors panel

On the bottom toolbar, click **Sensors**. The Sensors panel opens. This is where every connection is set up.

## Step 1 — Add a data source

A data source is one of your devices.

1. Click **Add datasource**. A new card appears.
2. Click **Choose device** and pick the device you want to use.
3. The card now shows the device's name. Add as many data sources as you need — one per device.

## Step 2 — Add a metric

Each device has its own individual readings, called **metrics**.

1. On the data-source card, click **Add metric**.
2. In the **Device metric** dropdown, pick the reading you want — temperature, the door's open/closed state, moisture, and so on.
3. Add more metrics if the device has more readings you want to use.

Each metric is one connection. A sensor that reports both temperature and humidity gives you two metrics, and you can connect each one to different things.

## Step 3 — Connect the metric to objects

1. On the metric, click **Configure**. The metric switches into connect mode and its editor opens up.
2. The editor shows the prompt **Click objects on the scene to bind them**.
3. Click any object in your 3D model — the garage door, a room's wall, a bed, the fridge. Each one you click is linked to this metric and shows up in the editor's **Bound** list.
4. Link as many objects as the reading should control. To unlink one, remove it from the Bound list.
5. When you're done, click **Done**.

One metric can drive several objects at once. Connect a single room-temperature sensor to every wall of that room and the whole room changes color together. The metric's **Bound** count tells you how many objects it's currently linked to.

## Step 4 — Choose the colors

The metric's editor is where you set the colors. Two things decide what an object shows:

* **Default color** — the color used when none of your rules match. Set it with the color picker in the editor.
* **Conditions** — the rules that turn readings into colors. Click **Add condition** to make one. Each condition has:
  * a **color**,
  * a **Name** (a label like "Open," "Too warm," "Leak"),
  * a **Data type** — **Number**, **String**, or **Boolean**,
  * and a test that depends on the type:
    * **Number** — a **From** / **To** range. The rule matches when the reading is inside it.
    * **String** — a single **Value**. The rule matches when the reading is exactly that word.
    * **Boolean** — a **True** / **False** setting. The rule matches a true/false reading.

The rules are checked in order, and **the first one that matches wins**. If none match, the object shows the default color. This is the same color-rule system you already use on your other widgets — see [Conditions](/dashboards/adding-widgets/conditions) for the full details.

## Step 5 — Try it out

The metric's editor has a **Value** slider. If the sensor isn't sending live data yet, drag the slider and watch your objects change color in real time — it's the quickest way to check your rules before the model goes on a dashboard. Once the device is reporting, the editor shows the real **Current value** and the model follows your live readings.

## A few examples

**Is the garage door open?** Connect a door sensor's open/closed metric to the garage door object. Add two rules: when the value means "open," show red; when it means "closed," show green. One look at the model and you know.

**Is the nursery too warm?** Connect a temperature sensor to the nursery's walls. Add Number rules: 18–22 °C green ("Just right"), 22–25 °C amber ("Warm"), and set the default to red for anything hotter. The room's color tells you the comfort level at a glance.

**Is the basement dry?** Connect a leak sensor to the basement floor. A Boolean rule — wet `true` → blue — turns the basement blue the instant water is detected.

**Is anyone in the home office?** Connect a motion or occupancy sensor to the home-office room. Occupied shows one color, empty another — so you can see if the room is in use before you walk in for a call.

These are just a starting point. Any sensor in your Chirp setup can be wired to any object in the model — however you'd describe what a reading means for a spot in your home, you can make the model show it. Let your own home give you the ideas.

## Tips

* Give your objects clear names in the **Scene** panel before you connect — clicking the right door is much easier when it's labelled "Garage door."
* Connect one metric to several objects when they share a reading; use separate metrics when each thing has its own sensor.
* Use the test slider to check every rule before you save.
* Keep your rules simple — two or three colors (good / warning / problem) usually say more than a long list.

## See also

* [Conditions](/dashboards/adding-widgets/conditions) — The full color-rule reference
* [Pins and live readings](/dashboards/adding-widgets/digital-building-twin/drop-pins-and-live-values) — Show the actual number in the model
* [Placing objects](/dashboards/adding-widgets/digital-building-twin/placing-objects) — Add the objects sensors connect to


# Pins and Live Readings

Pin a sensor's exact value into your 3D home, colored by its status, and show or hide every pin at once.

Color tells you *that* something is up — the nursery's gone amber, the basement's gone blue. Sometimes you also want the actual **number**: not just "the nursery is warm" but "the nursery is 26.3 °C." A pin puts that exact reading right into the model, at the spot it belongs to.

A pin is a marker placed at a particular point in your model. It shows the reading's name and current value with its units, and the pin itself takes the same color as the reading — so it's a label and a status light at the same time.

## Pinning a reading

Pins are added from the Sensors panel, on a metric you've already set up (see [Connecting sensors and colors](/dashboards/adding-widgets/digital-building-twin/binding-sensors-and-colors)).

1. On the bottom toolbar, click **Sensors** and find the metric you want to pin.
2. On that metric, click **Pin to scene**.
3. The editor switches into pick mode with the prompt **Click on the scene to pin this metric**.
4. Click the spot in your model where the pin should sit — over the nursery, by the back door, on the driveway.
5. The pin appears there, showing the reading's name and current value.

Once a metric is pinned, you get two more buttons: **Re-pin** to move the marker somewhere else, and **Unpin** to take it off.

## What a pin shows

Each pin is a little teardrop marker with a label hovering above it. The label has the reading's name and its current value with units — `Nursery / Temperature 26.3 °C`. The marker and label are colored by your rules, the same way your objects are: a reading in the "warm" band makes the pin amber, one in the "just right" band makes it green.

So a pin does two things at once — it shows you the exact number, and its color tells you the status without you even having to read it.

## Pins and floors

A pin belongs to the floor it was placed on. In a multi-floor home, a pin you put upstairs shows when you're viewing upstairs and stays out of the way when you're looking at the ground floor — so a tall house doesn't end up with every floor's pins piled on top of each other. See [Floors and levels](/dashboards/adding-widgets/digital-building-twin/floors-and-levels).

## Showing and hiding pins

The Sensors panel has a **Show sensor pins** switch. It appears once you've pinned at least one reading, and turns every pin in the model on or off together.

Turn pins **off** for a clean, color-only look — nice for a dashboard you glance at from across the room. Turn them **on** when you want the exact numbers. However the switch is set when you save the widget is how the dashboard tile shows it.

## When to use a pin

For a lot of things, color alone is enough — the garage door doesn't need a number, "open" or "closed" is the whole story. Reach for a pin when the number itself matters:

* The nursery or bedroom, where the exact temperature is what you care about.
* A water tank, where the fill percentage tells you when to top it up.
* Anywhere "how much" matters as much as "is there a problem."

Pin the few readings you genuinely want as numbers, and let color handle the rest. A model covered in pins is as hard to read as a spreadsheet; a few well-placed ones draw your eye exactly where it should go.

## See also

* [Connecting sensors and colors](/dashboards/adding-widgets/digital-building-twin/binding-sensors-and-colors) — Set up the metric a pin is based on
* [Floors and levels](/dashboards/adding-widgets/digital-building-twin/floors-and-levels) — How pins behave across floors
* [GPS anchoring](/dashboards/adding-widgets/digital-building-twin/gps-anchoring) — Place your home on the real-world map


# GPS Anchoring

Tie your 3D home model to real latitude and longitude, automatically from a map trace or by hand.

Your Digital Building Twin is a model of a real place — and a real place sits somewhere on the map. GPS anchoring records that: it ties your home, and points inside it, to actual latitude and longitude. It gives your model a real-world location to sit at.

This page covers the two ways your home gets anchored, and how to manage anchors from the Sensors panel.

## Two ways to anchor your home

### Anchored automatically when you trace from the map

If you built the shell of your model by [tracing it from the satellite map](/dashboards/adding-widgets/digital-building-twin/tracing-from-the-map), you drew it on real-world coordinates — so it's already anchored. Importing the trace saves your home's location automatically, with no extra step. If you traced your home from the map, you're done.

### Anchored by hand

You can also place anchors yourself, on any model — including one you drew from scratch or imported from a plan file. This is done in the **GPS Anchors** section at the bottom of the Sensors panel.

1. On the bottom toolbar, click **Sensors**, and find the **GPS Anchors** section.
2. Click **Add by click**. The editor switches into pick mode with the prompt **Click on the scene to pick a point**.
3. Click a point in your model — a corner of the house, a spot you know the coordinates of.
4. A small form appears showing the point you picked. Type in its real **Latitude** and **Longitude**.
5. Click **Save**. The anchor joins the list, labelled **A**, **B**, **C**, and so on.

Add as many as you like. A couple of known points — opposite corners of the house, say — are enough to fix your model onto the real map.

## The center point

As you add anchors, the editor works out a **Center** — the average of all your anchor points. It's shown at the top of the anchor list with its latitude and longitude, and it represents where, on a real map, your home sits.

## Managing anchors

The GPS Anchors section lists every anchor with its coordinates, and each one can be removed on its own. There's also a switch to show or hide the anchor markers in the model — handy to keep them visible while you set things up and hidden afterwards for a clean view.

## What anchoring is for

GPS anchoring gives your Digital Building Twin something a plain 3D model doesn't have: a real place in the world. Your home and its anchored points aren't floating in empty space anymore — they have real coordinates.

It puts your home on the map, which is the groundwork for map-aware features down the line. For now, think of it as giving your model its address: it knows where it really is.

## Tips

* Trace your home from the map and anchoring is already done — open the GPS Anchors section and you'll see the anchors the trace created.
* When anchoring by hand, pick points you actually know the coordinates of — a phone's map app can give you the latitude and longitude of a spot if you tap and hold it.
* Spread your anchors out — points at opposite corners of the house fix it more firmly than two points close together.
* Hide the anchor markers once you're set up, so the dashboard view stays focused on your sensors.

## See also

* [Tracing from the map](/dashboards/adding-widgets/digital-building-twin/tracing-from-the-map) — Anchoring happens automatically when you trace
* [Pins and live readings](/dashboards/adding-widgets/digital-building-twin/drop-pins-and-live-values) — Mark live readings inside the model
* [Editor tour](/dashboards/adding-widgets/digital-building-twin/editor-tour) — Finding the Sensors panel


# Conditions

Set per-metric color rules so a reading turns green, yellow, or red — green for comfortable, red for check it now.

Conditions are per-metric color rules that turn a raw sensor reading into visible meaning. Instead of looking at a number and deciding whether it's good or bad, the widget does that for you — a green pin means comfortable, a red pin means check it now, a yellow marker means getting close to the limit. You define what those colors mean for each sensor in each place it's used.

A temperature sensor in the living room should be green at 18–24°C. The same type of sensor watching a fridge should be green at 2–5°C. Different place, different meaning, completely different conditions — even though the data looks the same.

## Which widgets use conditions

Conditions are available for **Last Data** and **Image** widgets. Each metric in these widgets has its own set of conditions, configured independently.

The **Chart** widget uses a different approach — per-metric color picker and threshold bands on the graph. See [Chart Widget](/dashboards/adding-widgets/chart-widget) if you're working with a Chart.

**Note on metric types:** Both the Image and Last Data metric selectors surface numeric sensors only (INTEGER and FLOAT types). Number conditions are the practical path for both widgets. The conditions modal also exposes String and Boolean data type options — these are described below — but they require a widget that can select a sensor of those types, which is not currently the case for Last Data or the Image widget.

## How to open the Conditions modal

1. Open the widget's settings and go to the **Datasource** tab.
2. Find the metric row for the sensor you want to configure.
3. Tap the **Conditions button** — it's labeled **"Conditions: N"** where N is the number of conditions currently set.
4. The Conditions modal opens.

## What the Conditions modal contains

**Title:** "Conditions" / **Subtitle:** "The conditions set first will be considered as a priority"

**Header (applies to the whole metric):**

* **Device metric** — Read-only. Shows which sensor this modal is for.
* **Unit** — A free-text box for the unit shown next to the value on the tile (like `42 cm`). Type **whatever unit you want** — `mm`, `cm`, `m`, inches, `L`, `°C`, anything. It's not limited to a list and it's not a percentage unless you make it one. It starts from the sensor's own unit, and you can change it to suit. The **From / To** numbers in your rules are in this unit (so `From 0 To 30` means 0–30 of whatever you set here).
* **Icon** — Pick or change the icon for this metric.
* **Default color** — The color used when no condition matches. This is the only place to set the metric's base color.

**Conditions list:** Each condition has:

* **Condition name** *(required)* — A label like "Comfortable", "Warning", or "Critical". Must not be empty.
* **Data type** — Number, String, or Boolean (see below)
* **Value fields** — Depend on the data type
* **Color** — The color to show when this condition matches
* **Delete** — Remove this condition

**Add condition** — Tap to add a new condition. New conditions default to: name "Condition N", type Number, From 0, To 100, primary color.

There's no limit on the number of conditions you can add.

**Save** (disabled while any validation error exists) / **Cancel**

## Priority: first match wins

Conditions are evaluated top to bottom. The **first condition in the list that matches the current reading** determines the color. Order matters.

If your sensor reads 7°C and you have:

1. "Normal" — Number, From 2, To 8 — green
2. "Warning" — Number, From 8, To 12 — yellow

The reading 7°C matches condition 1, so green is shown. Condition 2 is not evaluated.

To change priority, reorder the conditions in the list.

## Value fields by data type

### Number

**From** and **To** fields — both are optional. Either can be left empty to create an open-ended range:

* **Empty From** — matches any value below To (no lower limit)
* **Empty To** — matches any value above From (no upper limit)
* **Both filled** — From must be ≤ To

Examples:

* From: 18, To: 24 → matches readings between 18 and 24
* From: 30 (no To) → matches any reading 30 and above
* (no From), To: 5 → matches any reading 5 and below

### Number conditions — on/off and open/closed states

Many sensors report binary state as a number: 1 when something is active or open, 0 when it is off or closed. Number conditions map these values to meaningful labels and colors:

* Condition "On" — Number, From 1, To 1 — yellow (or your chosen color)
* Condition "Off" — Number, From 0, To 0 — grey

Examples using this pattern:

* Light sensor: 1 = "On" (yellow), 0 = "Off" (grey)
* Contact sensor (door): 1 = "Open" (red), 0 = "Closed" (green)
* Leak sensor: 1 = "Leak detected" (red), 0 = "Clear" (green)

The same Number condition type handles all of these. The difference is only in the labels and colors you assign.

### String

A single **Value** text field. Matches the reading exactly, case-sensitive. Available in the conditions modal but requires a widget that surfaces a String-type sensor — Last Data and Image widget selectors do not surface String sensors.

### Boolean

A **True / False** dropdown. Matches the reading exactly. Available in the conditions modal but requires a widget that surfaces a Boolean-type sensor — Last Data and Image widget selectors do not surface Boolean sensors.

## Color fallback hierarchy

1. **Matched condition color** — The color of the first matching condition
2. **Default color** — The color set in the modal header (applies when no condition matches)
3. **Platform default** — Applied when no default color is set in the modal

## Examples

### Keeping something topped up

Say you've got a sensor on something you want to keep full — a rainwater tank, the salt in a water softener, a heating-oil tank — reading how full it is in whatever unit suits you. Set that in the **Unit** box (it takes anything — `cm`, `m`, inches, liters…); here we'll use **centimeters** of depth. Three rules then turn that into a clear "do I need to refill?" status, and since the **first matching rule wins**, list the most urgent one first:

* **Refill** — Number, From 0, To 30 — red
* **Getting Low** — Number, From 30, To 50 — amber
* **Normal Level** — Number, From 50, To 100 — green

<figure><img src="/files/DGuGEIDxEaOEoxsI5cXv" alt="Conditions window with three fill-level rules — Refill 0–30 red, Getting Low 30–50 amber, Normal Level 50–100 green"><figcaption></figcaption></figure>

The tile stays green while it's well stocked, turns amber as it runs down, and goes red as soon as it drops into the refill zone — so you top it up before it runs out. Want a nudge on your phone too? Add an [alert](/alarm) on the same level.

### Number conditions — temperature in two contexts

**Living room sensor:**

* "Comfortable" — From 18, To 24 — green
* "A bit cool" — From 15, To 18 — yellow
* "Cold alert" — (no From), To 15 — red

**Fridge sensor (same sensor type, completely different meaning):**

* "Normal" — From 2, To 5 — green
* "Check fridge" — From 5 (no upper limit) — red

The readings look the same — both are temperatures in °C. The conditions are completely different because "2°C in a fridge" is fine, while "2°C in the living room" is an emergency.

### Number conditions — open-ended bounds for a tank level

A water tank sensor reports its fill level (here in percent, but you choose the unit):

* "Critical" — (no From), To 20 — red
* "Low" — From 20, To 50 — yellow
* "Good" — From 50 (no upper limit) — green

The first condition catches everything below 20%. The last catches everything above 50%. There's no need to specify exact upper/lower limits for every range.

### Number conditions — any numeric reading

The system doesn't care what the number represents. The same pattern works for:

* Battery level (%, 0–100)
* Soil moisture (%, 0–100)
* CO₂ level (ppm)
* Tank volume (liters or gallons)
* Any sensor that reports numbers

The meaning and the thresholds are yours to define.

### String conditions — device status sensor

A sensor that reports text values like "OK", "WARNING", or "FAULT":

* "OK" — String, Value: OK — green
* "Warning" — String, Value: WARNING — yellow
* "Fault" — String, Value: FAULT — red

No math involved. The widget reads the string, matches it exactly, and shows the right color.

### Boolean conditions — binary state sensors

**Motion sensor:**

* "Motion detected" — Boolean, True — orange
* "Clear" — Boolean, False — green

**Leak detector:**

* "Leak detected" — Boolean, True — red
* "Clear" — Boolean, False — green

**Pump running:**

* "Running" — Boolean, True — blue
* "Idle" — Boolean, False — grey

Any binary sensor works the same way: pick a color for each state and a label that makes sense in context.

## See also

* [Last Data Widget](/dashboards/adding-widgets/last-data-widget) — Use conditions to color sensor readings and gauges
* [Image Widget](/dashboards/adding-widgets/image-widget) — Use conditions to color the pins on your image


# Organizing Your Views

Group dashboards into folders and drag-and-drop them so the views you use most sit right at the top.

When you have just one or two dashboards, finding them in the sidebar is easy. But as your smart home grows — a dashboard for each room, one for security, one for the garden — the list gets longer. Folders help you group related dashboards together, and drag-and-drop reordering lets you put the ones you use most right at the top.

## Opening the dashboard settings

Tap the **gear icon** (tooltip: **"Dashboard settings"**) next to the Dashboards section in the sidebar. A dialog opens with the title **"Dashboard settings"** and the description **"Create folders and rearrange dashboards and folders with a drag-and-drop gesture"**.

If you haven't created any dashboards yet, you'll see **"No dashboards yet"** in the center of the dialog.

## Creating a folder

At the top of the dialog, you'll find a text input for creating folders:

1. Type a folder name. The placeholder reads **"My folder"** — but something like "Upstairs", "Garden", or "Security" is more helpful.
2. Tap **Create folder**.

If you try to create a folder without entering a name, you'll see **"Folder name is required"**.

Once created, the folder appears in your sidebar as a collapsible group. Tap it to see the dashboards inside.

### How deep can folders go?

Folders are **one level only**. You can put dashboards inside a folder, but you can't put a folder inside another folder. This keeps things simple:

```
Dashboards
├── Upstairs             (folder)
│   ├── Bedroom
│   └── Nursery
├── Downstairs           (folder)
│   ├── Kitchen
│   └── Living Room
├── Garden               (folder)
│   └── Soil & Weather
└── Security             (top-level dashboard)
```

## Rearranging with drag-and-drop

The dialog shows all your dashboards and folders in a list. You can drag items to:

* **Change the order** — Move a dashboard or folder up or down in the list.
* **Move a dashboard into a folder** — Drag it onto the folder name.
* **Move a dashboard out of a folder** — Drag it back to the top level.

Your sidebar updates immediately to reflect the new arrangement.

## Deleting a folder

Tap the **trash icon** next to a folder name. A confirmation asks:

**"Are you sure you want to delete {folder name} folder?"**

with the warning:

**"All dashboards inside this folder will also be deleted. Once deleted, this action cannot be undone."**

Tap **Yes, delete** to confirm. The folder and every dashboard inside it are permanently removed.

## Deleting a dashboard from settings

You can also delete individual dashboards from this dialog. The confirmation reads:

**"Are you sure you want to delete {dashboard name} dashboard?"**

**"Once deleted, this action cannot be undone."**

Tap **Yes, delete** to confirm.

## Closing the settings

Tap **Ok** to close the dialog. All changes are already saved.

## Ideas for organizing a home

* **By floor** — "Upstairs", "Downstairs", "Basement". Simple and intuitive.
* **By purpose** — "Comfort" (temperature, humidity), "Security" (doors, windows, motion), "Garden" (moisture, weather).
* **By person** — If family members have their own rooms with sensors, a folder per person keeps things personal.

Start simple. You can always reorganize later by dragging dashboards between folders.

## What's next

* [Building a Dashboard](/dashboards/building-a-dashboard) — Create dashboards to fill your folders.
* [Adding Widgets](/dashboards/adding-widgets) — Add sensor data to each dashboard.


# Maps and Device Placement

See where each sensor sits in your home on an interactive map and assign a room to put it on the map.

When you have sensors spread around your home — in the kitchen, the garden, the garage — it helps to see where each one actually is. Chirp shows your sensor locations on an interactive map, so you always know which device is where without checking labels or room assignments.

## Where to find the map

The map appears on each sensor's detail page:

1. Tap **Devices** in the sidebar.
2. Tap a sensor to open its detail page.
3. The **Overview** tab is selected by default. The map appears in a card below the sensor's status information.

If the sensor has a location assigned, you'll see a marker on the map showing its position. A **location bar** above the map shows the sensor's room and sub-location (for example, "Living Room, Window side").

## When no location is set

If you haven't assigned a location to the sensor yet, the map area shows a placeholder:

* The text reads **"Your device location is empty"** and **"data will be available here soon"**.
* An **"Add device location"** button appears below. Tapping it takes you to the sensor's **Settings** tab, where you can pick a room from the rooms you've set up.

The button only appears if you have permission to edit the sensor.

## What the map can do

The map view gives you:

* **Pan and zoom** — Explore the area around your sensor's location.
* **Fullscreen** — Expand the map for a better look on any screen.
* **Responsive sizing** — On your phone, the map adjusts to fit comfortably.
* **Light and dark mode** — The map matches your Chirp theme.

## Setting a sensor's location

To put a sensor on the map:

1. Tap **"Add device location"** on the map placeholder, or go directly to the sensor's **Settings** tab.
2. Choose a room from the rooms you've created (rooms are set up in [Rooms](/devices/rooms)).
3. Save. The map on the Overview tab now shows your sensor's position.

## GPS trackers

If you have a GPS tracker device (for a vehicle, pet, or bike), the same map area can show where the tracker has been — not just where it is now. This location history feature is covered in [Tracking What Matters](/dashboards/tracking-what-matters), since it involves additional controls like date selection and route details that are specific to tracker devices.

## What's next

* [Rooms](/devices/rooms) — Set up the room structure that feeds into device locations.
* [Tracking What Matters](/dashboards/tracking-what-matters) — Location history for GPS tracker devices.
* [Sensor Details](/devices/sensor-details) — View and edit everything about a sensor.


# Tracking What Matters

View location history for a GPS tracker — see the route your car, pet, or bike took on any chosen day.

If you have a GPS tracker device — for your car, a pet collar, a bike, or anything else that moves — Chirp records where it's been and shows you the full history on a map. Instead of just knowing "the tracker is online," you can see the exact route it took, when it was at each point, and how fast it was moving.

GPS tracking is only available for tracker-type devices. It's not a feature for every sensor — your living room temperature sensor stays put and doesn't need tracking. For seeing where stationary sensors are placed, see [Maps and Device Placement](/dashboards/maps-and-device-placement).

Location history works for any device that reports GPS coordinates. A cellular vehicle tracker (OBD2, CAN, or standalone GPS) connects through the [Tracker Connector](/connectors/tracker-connector); a LoRaWAN GPS tag connects through the [LNS Connector](/connectors/lns-connector). Either way, once a device reports its location, its history shows up here.

## Where to find tracking

1. Tap **Devices** in the sidebar.
2. Tap a tracker device to open its detail page.
3. The tracker page opens with the **Overview** tab showing a map of the device's recent movements.

### What tabs you'll see

The tabs on the tracker page depend on your screen size and the type of tracker:

**On your computer (all tracker types):**

* **Overview** — The map with location history.
* **Device log** — A raw log of events from the tracker.
* **Settings** — Tracker configuration.

**On your phone (standard and GPS trackers):**

* **Overview**, **Metrics**, **Device log**, **Settings**

**On your phone (mobile tracker type):**

* **Overview**, **Device log**, **Settings**

The **Metrics** tab shows up on mobile for certain tracker types, giving you access to telemetry readings in a phone-friendly format.

## Picking a date range

At the top of the tracker page, you'll see a **"Date range"** button. Tap it to choose which time period you want to see on the map.

The calendar opens with only the days that have recorded data available for selection — grayed-out dates mean the tracker didn't send any position updates on those days. You can also use quick-select shortcuts for common ranges.

Once selected, the button updates to show either the range name (like "Today" or "This week") or the specific dates in **DD.MM.YYYY - DD.MM.YYYY** format.

## Reading the map

The Overview tab shows every recorded position from the selected date range as a **dot on the map**, connected by lines that trace the route.

### Tapping a point

* **Tap** a point on the map to select it. The map smoothly zooms in on that location.
* The selected point appears at full brightness, while all other points fade to make it stand out.
* A **tooltip** pops up showing:
  * **When:** The date and time in DD.MM.YYYY, HH:mm format.
  * **Signal strength (RSSI):** If available — this tells you how strong the tracker's signal was at that point.
  * **Speed:** If available — how fast the tracker was moving.

### Following the route

The lines between points show the path the tracker took. You can trace the route visually to see:

* Where the tracker went during the day.
* Where it stopped or lingered (points clustered together).
* Whether it followed the expected path.

## What you might use this for

* **Checking on your car** — "Where did the car go today?" Select today's date and see the full route on the map.
* **Pet tracking** — If your dog's collar has a GPS tracker, check where your pet wandered during the afternoon.
* **Bike security** — Left your bike locked up somewhere? Confirm it hasn't moved since you parked it.
* **Reviewing yesterday** — Use the date range to look back at any day and see the full movement history.

## What's next

* [Maps and Device Placement](/dashboards/maps-and-device-placement) — See where your stationary sensors are placed.
* [Live Home Data](/dashboards/live-home-data) — How real-time updates reach your dashboards and maps.


# Live Home Data

How live sensor updates reach your screen, what the Live Data indicators mean, and what to check if data is missing.

One of the best things about a smart home is knowing what's happening right now — not five minutes ago, not after refreshing a page, but right now. Chirp delivers sensor readings to your screen in real time: the moment a sensor reports a temperature, humidity level, or door status, you see the updated value on your overview or dashboard.

This page explains how live data works in Chirp, what the Live Data indicators mean, and what to check if data isn't showing up.

## The Live Data button on the overview

When you open the [home overview](/overview), the header shows **"My board"** alongside a **"Live Data"** label with a small clickable icon. If you hover over it, a tooltip says **"New data is automatically displayed"**.

**You can tap this button.** Tapping it tells Chirp to pull the latest information for the overview — updated sensor counts, gateway status, and notification cards. This is handy when you've just added a new sensor and want to see it appear right away instead of waiting for the next automatic refresh.

## The Live Data indicator on dashboards

When you open any [dashboard](/dashboards/building-a-dashboard), the header shows the dashboard name and a **"Live Data"** label with a small icon on the right.

**This one is not a button** — it's a status indicator. You can't tap it, and it doesn't do anything when you hover. It simply tells you that the dashboard is connected and receiving fresh data automatically. As your sensors report new readings, the widgets on the dashboard update on their own.

When you enter edit mode to modify widgets, the Live Data indicator disappears (replaced by the edit controls). It comes back when you exit edit mode.

## How it works

Behind the scenes, Chirp maintains a live connection between your browser (or phone) and the platform. When a sensor sends a new reading:

1. The reading arrives at Chirp through the sensor's connection.
2. Chirp processes and stores it.
3. At the same time, the new value is pushed directly to your screen.
4. Any widget or card displaying that sensor's data updates immediately — no page refresh needed.

The speed of updates depends on how often your sensor reports. A temperature sensor that sends a reading every 5 minutes will update your dashboard every 5 minutes. A motion sensor that reports events instantly will show up as soon as motion is detected.

## "Waiting for live data"

Sometimes a widget or dashboard shows the message **"Waiting for live data"**. This is normal and happens when:

* **A sensor was just added** — It hasn't sent its first reading yet. Give it a moment (or trigger a reading if the sensor supports manual transmission).
* **The reporting interval hasn't passed** — If a sensor reports every 15 minutes, you might need to wait until the next cycle.
* **The sensor is offline** — Check whether the sensor is powered on and within range of your gateway.

## What to check if data isn't appearing

If your overview or dashboard isn't showing fresh data:

1. **Is the sensor online?** Open the sensor's detail page and check the last-seen time. If it's been a while, the sensor may have lost power or connectivity.
2. **Is the gateway running?** *(LoRaWAN sensors)* Your gateway needs to be powered on and connected to your home internet. Check [Checking Gateway Health](/gateways/lorawan-gateways/checking-lorawan-gateway-health).
3. **Is the sensor within range?** If the sensor is too far from the gateway, readings may not arrive. Try moving the sensor closer or repositioning the gateway.
4. **Try the Live Data button** on the overview page. Tapping it forces a fresh data pull.
5. **Refresh the page.** In rare cases, the live connection between your browser and Chirp may need to reconnect. A simple page refresh usually fixes this.

## The difference between overview and dashboard live data

|                       | Overview                                               | Dashboard                                       |
| --------------------- | ------------------------------------------------------ | ----------------------------------------------- |
| **Live Data control** | Clickable button — tap to refresh                      | Non-clickable indicator — status only           |
| **Tooltip**           | "New data is automatically displayed"                  | No tooltip                                      |
| **What updates**      | Summary cards (sensor count, gateway status, warnings) | Individual widget values                        |
| **Manual refresh**    | Yes (tap the button)                                   | No (automatic only; refresh the page if needed) |

Both surfaces receive real-time data automatically. The difference is that the overview gives you an extra manual refresh option through its clickable button.

## What's next

* [Home Overview](/overview) — The page where the clickable Live Data button lives.
* [Adding Widgets](/dashboards/adding-widgets) — Add widgets that display live sensor readings.
* [Checking Gateway Health](/gateways/lorawan-gateways/checking-lorawan-gateway-health) — Make sure your gateway is delivering data.


# Sharing Your Dashboard

Share a Chirp dashboard with a password-protected link — choose View or Control, then copy, regenerate, or revoke it.

You've built a dashboard that shows exactly what you care about — the hallway temperature, the front door sensor, the lamp in the living room. Now you want it somewhere other than your own laptop. On the tablet by the door. On your partner's phone. In the hands of the house-sitter for the two weeks you're away.

A **share link** does that. It turns one dashboard into a web address you can hand to someone, protected by a password you choose. They don't need a Chirp account, they don't need an invitation, and they never see the rest of your home — just the one dashboard you shared. When you no longer want them to have it, you take it back in two taps.

## Why you'd want one

Without a share link, every person who wants to see your data needs an account in your household. That's the right answer for your family. It's a lot of ceremony for a tablet on the wall, and it's more than you want to hand a house-sitter who's only around for a fortnight.

A share link fits the in-between cases:

* **The wall tablet.** The link opens the dashboard full screen, with no menus around it. Mount a cheap tablet in the hallway, open the link once, and it just sits there showing the house.
* **The house-sitter.** Send a **View** link before you leave. They can see that the boiler is fine and the cat's water bowl sensor is reporting. They can't change a thing.
* **Your partner.** A **Control** link means they can actually flip the switches — turn the porch light on, start the heating — straight from the shared page.
* **Grandparents checking in.** A View link on the holiday home dashboard, so they can see the place hasn't frozen over the winter.

And the moment the house-sitter hands the keys back, you revoke the link. It stops working immediately.

This page is about sharing a dashboard you've already built. If you haven't made one yet, start with [Building a Dashboard](/dashboards/building-a-dashboard) and [Adding Widgets](/dashboards/adding-widgets).

## Opening the sharing dialog

1. Open the dashboard you want to share from the **Dashboards** section of the sidebar.
2. Tap the **actions menu** (three dots) in the top right of the dashboard header.
3. Select **Share dashboard**.

The **Dashboard access** dialog opens. Under the title you'll see the helper text **"Protect the link with a password and choose what visitors can do"** — which is a fair summary of the two decisions ahead of you.

If no link has been created for this dashboard yet, the dialog tells you so: **"No link yet. Set a password and generate one."**

## Decide who can reach the dashboard

The first choice is how open the dashboard is:

* **Only organization users can access** — the default, and the private option. Its description reads **"Organization users can view and edit the dashboard according to the organization's permissions"**. Nothing leaves your household: only people who are already members of your Chirp organization can open it, with whatever access they already have.
* **Anyone with the link, no account needed** — the sharing option. This is what produces a link you can send to someone outside your household. Anyone who has the link *and* the password can open the dashboard in a browser.

Pick **Anyone with the link, no account needed** to carry on with the steps below.

## Decide what visitors can do

Once the link is open to anyone, choose the permission the link carries:

* **View** — described as **"Can view the dashboard, but cannot edit widgets"**. The visitor sees live readings and nothing else. They cannot rearrange the dashboard, change a widget, or touch your devices.
* **Control** — the visitor can operate devices from the dashboard's [Control widgets](/dashboards/adding-widgets/control-widget). If there's a switch on the dashboard for the porch light, they can flip it.

**Be deliberate about Control.** Anyone holding the link and the password can switch your devices on and off — a lamp, a heater, a pump, a gate. There is no second identity check behind the password. Give **Control** to your partner or to a tablet you trust in a room only your family walks through. For everyone else — the house-sitter, a guest, the neighbor watering the plants — choose **View**.

You can always create a fresh link with a different permission later.

## Set a password and generate the link

1. In the **Password** field (placeholder **"Enter a password"**), type the password visitors will need.
2. Passwords have a minimum length. If yours is too short, the field shows **"Password must be at least N characters"** — lengthen it and try again.
3. Tap **Generate link**.

You'll see the toast **"Share link created"**, and the link appears in the dialog, ready to hand over.

The address looks something like `/dashboards/{id}/fullscreen?t=...`. That `fullscreen` part is the nice bit: whoever opens it gets the dashboard filling the whole screen, with no sidebar and no navigation around it — exactly what you want on a tablet mounted to a wall.

### Sending it on

Tap **Copy link**. You'll see **"Link copied to clipboard"**, and you can paste it into a message, an email, or the tablet's browser.

Send the password separately, and don't paste both into the same message. A link with its password sitting next to it in a group chat is a link anyone in that chat can use.

## Changing the password

If you'd rather rotate the password without disturbing the link itself:

1. Open the dashboard's actions menu and select **Share dashboard** again.
2. Type the new one into the **Password** box.
3. Tap **Change password**.

The toast **"Password changed"** confirms it. The link stays exactly the same — anyone who has it will simply need the new password from now on. This is the gentle option when you want to cut off one person but keep the wall tablet working (you'll just need to type the new password into the tablet once).

## Regenerating the link

Sometimes you want a brand-new address, not just a new password — the old link went somewhere you didn't intend, or you've simply lost track of who has it.

1. Open the **Dashboard access** dialog.
2. Tap **Regenerate link**.
3. A confirmation appears: **"Regenerate share link?"** with the warning **"The previous link will stop working immediately."**
4. Confirm.

The toast **"Share link regenerated"** appears and a fresh link takes the old one's place. Everyone you want to keep sharing with — including your wall tablet — needs the new link. Anyone still holding the old one gets a dead page.

## Revoking the link

When the house-sitter leaves, or the reason for sharing has simply passed, take the link back.

1. Open the **Dashboard access** dialog.
2. Tap **Revoke**.
3. The confirmation reads **"Revoke share link?"** followed by **"The link will stop working immediately and cannot be restored."**
4. Tap **Yes, revoke**.

You'll see **"Share link revoked"**. That link is finished — it can't be brought back, and knowing the password won't help anyone. Your dashboard is untouched and still yours; only the doorway you'd opened is closed. If you want to share again later, generate a new link.

## What your visitor sees

It's worth knowing what's on the other end, so you can help someone who calls you saying "it's not working."

When they open the link, they get a **"Password required"** screen with the message **"This dashboard is protected. Enter the password to continue."** They type the password, and the dashboard opens full screen with live readings.

The messages they might run into instead:

| What they see                                                                    | What it means                                         | What to tell them                                                                                                |
| -------------------------------------------------------------------------------- | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **"Wrong password"**                                                             | The password doesn't match.                           | Re-send the password — watch for a trailing space when it's copied and pasted.                                   |
| **"Too many attempts. Please try again later."**                                 | Too many failed password tries in a row.              | Wait a bit, then try once with the correct password.                                                             |
| **"This share link is no longer valid"**                                         | The link was revoked or regenerated.                  | Send them the current link, or generate a new one.                                                               |
| **"This dashboard session has expired. Please reopen the link you were given."** | Their session has simply timed out.                   | Reopen the original link and enter the password again.                                                           |
| **"Access denied"** or **"You do not have permission to access this dashboard"** | The link doesn't grant them access to this dashboard. | Check the dialog is set to **Anyone with the link, no account needed**, and that they're using the current link. |

That expiry message is the one to remember for a wall tablet: a shared session doesn't run forever, so a tablet left alone for a long stretch may eventually ask for the password again.

## Share to TV — the other option

The same actions menu also offers **Share to TV**, and it solves a different problem. Its helper text explains it: **"Open this dashboard on a TV or tablet with a non-expiring key. Create an API key in Settings → API Keys (with device control scope to operate devices), then paste it here."**

The difference is what's behind the link. A share link is protected by a password, hands out **View** or **Control**, and you can revoke it the day someone stops needing it. **Share to TV** is built from an [API key](/settings/api-keys) instead — no password screen, and no expiry — which suits a screen that stays put and never gets handed to anyone. Reach for a share link when you're sharing with a *person*; reach for Share to TV when you're setting up a *screen* that lives in your home permanently.

## Tips

* **Default to View.** Give **Control** only when you actually want that person switching your devices. It's a one-word difference in the dialog and a large difference in your hallway.
* **Share one dashboard, not your home.** A link only ever exposes the dashboard it was made from. If you want a house-sitter to see the boiler and nothing else, build a small dashboard with just those widgets and share that one.
* **Use a password you don't use anywhere else.** It's going into a text message. Treat it as disposable — that's exactly what **Change password** and **Regenerate link** are for.
* **Send the link and the password by different routes.** Link by message, password by phone call, for instance.
* **Revoke on the way back from the airport.** The moment the sharing reason ends, so should the link. It takes two taps and it can't be undone — which is the point.
* **Give the wall tablet its own link.** Then, when you regenerate the link you sent a guest, the tablet in the hallway keeps working.

## What's next

* [Building a Dashboard](/dashboards/building-a-dashboard) — Create the dashboard you're going to share.
* [Adding Widgets](/dashboards/adding-widgets) — Choose what appears on it.
* [Control widget](/dashboards/adding-widgets/control-widget) — The switches and sliders a **Control** link can operate.
* [API Keys](/settings/api-keys) — The keys behind **Share to TV**.


# Connectors

See how connections link your home sensors to Chirp over LoRaWAN, MQTT or a vehicle tracker — or use pretend sensors before any hardware arrives.

A connection tells Chirp which protocol to listen on for a specific sensor type. It does not create sensor profiles — you register sensors separately through the sensor dialog. A connection establishes the protocol binding that makes data flow possible.

Most homes need just one connection: an **LNS connection** for LoRaWAN sensors. If you also want to track a vehicle, you can add a **Tracker connection** for vehicle trackers (OBD2, CAN bus, and standalone GPS vehicle tracking devices).

## Connection types

| Type         | What it's for                                                                                                                                                                                                                                    | Status    |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------- |
| **LNS**      | LoRaWAN sensors — temperature, humidity, door/window, motion, soil moisture, and thousands more                                                                                                                                                  | Available |
| **Tracker**  | Vehicle trackers — OBD2, CAN bus, and standalone GPS vehicle tracking devices (2,000+ preconfigured models)                                                                                                                                      | Available |
| **MQTT**     | Direct MQTT sensor connections — including Zigbee devices via Zigbee2MQTT, DIY sensors, and other MQTT-capable hardware. Two options: **External MQTT** (your own broker, up to 10 per home) and **Cloud MQTT** (Chirp-hosted broker, unlimited) | Available |
| **Emulator** | Pretend sensors that make up their own readings, so you can set up and try your whole home before the real ones arrive — then switch the device over to the real sensor when it does                                                             | Available |

Your home can have **one LNS connection**, **one Tracker connection** and **one Emulator connection**. MQTT connections can be External (up to 10 per home) or Cloud MQTT (unlimited — each gets its own hosted broker credentials).

## Where to find connections

Click **Connectors** in the sidebar to see your connections. If you haven't set any up yet, you'll see an empty page inviting you to create your first one.

Once you have connections, the page shows a table with:

| Column                 | What it shows                                        |
| ---------------------- | ---------------------------------------------------- |
| **Name**               | The connection name (assigned automatically)         |
| **Last data received** | When a sensor last sent data through this connection |
| **Connected devices**  | How many sensors are using this connection           |
| **Creation date**      | When you created the connection                      |

## What's next

Ready to set up your first connection? Head to [Setting Up a Connection](/connectors/setting-up-a-connection) for a step-by-step walkthrough.

Nothing arrived yet? The [Emulator Connector](/connectors/emulator-connector) gives you pretend sensors that invent their own readings, so you can build and test your whole home before the real ones turn up.

Want to learn more about LoRaWAN — the wireless technology behind your sensors? See the [LNS Connector](/connectors/lns-connector) section for an introduction to the protocol, frequency bands by country, and how Chirp's built-in network server works.

Tracking a vehicle? See the [Tracker Connector](/connectors/tracker-connector) for connecting a cellular GPS tracker — OBD2, CAN bus, or standalone GPS.

Want to connect Zigbee sensors, an ESP32 sensor, or any MQTT-capable device? See [MQTT Connector](/connectors/mqtt-connector) for a complete setup guide.


# Setting Up a Connection

Create an LNS connection for LoRaWAN sensors, a Tracker connection for your vehicle, or an Emulator connection to start with no hardware.

Creating a connection takes just a few clicks. Here's how to set up an LNS connection (for LoRaWAN sensors), a Tracker connection (for vehicle trackers), and an Emulator connection (for trying Chirp before your sensors arrive).

## Adding an LNS connection

This is the most common connection for a smart home — it links Chirp's built-in LoRaWAN network to your sensor management.

1. Click **Connectors** in the sidebar.
2. Click **Add connector**.
3. In the dialog, select **LNS** from the **Connector type** dropdown.
4. Click **Add**.

That's it. The connection is created instantly. Chirp's built-in LoRaWAN network handles all the technical setup behind the scenes. To learn more about LoRaWAN, frequency bands, and the built-in network server, see the [LNS Connector](/connectors/lns-connector) reference section.

### Inside the LNS connection

Click the LNS connection row in the table to open it. You'll see two tabs:

* **LoRaWAN Gateways** — Your gateway list. See [Setting Up Your Gateway](/gateways/lorawan-gateways/setting-up-a-lorawan-gateway).
* **Connected Devices** — Your sensor list. See [Adding Sensors](/devices/adding-sensors) and [Sensor Details](/devices/sensor-details).

## Adding a Tracker connection

If you want to track a vehicle, add a Tracker connection alongside your LNS connection. Chirp supports over 2,000 vehicle tracker models including OBD2 and CAN bus devices.

1. Click **Connectors** in the sidebar.
2. Click **Add connector**.
3. Select **Tracker** from the **Connector type** dropdown.
4. Click **Add**.

The Tracker connection is created instantly. Click its row to see the shared sensor list. For registration and management, see [Adding Sensors](/devices/adding-sensors) and [Sensor Details](/devices/sensor-details). For what this connector is (and isn't) for — cellular/GSM vehicle trackers, not LoRaWAN ones — see the [Tracker Connector](/connectors/tracker-connector) page.

## Adding an Emulator connection

No sensors yet? Add an **Emulator** connection and Chirp will make up the readings for you, so you can build your dashboards and alerts before anything arrives in the post.

1. Click **Connectors** in the sidebar.
2. Click **Add connector**.
3. Select **Emulator** from the **Connector type** dropdown.
4. Click **Add**.

There is nothing to fill in — no account to link, no keys to copy. See [Emulator Connector](/connectors/emulator-connector) for what it's for, and [Pretend Sensors](/devices/pretend-sensors) for making one.

## How many of each

Each home can have **one LNS connection**, **one Tracker connection** and **one Emulator connection**. MQTT is the exception: up to 10 External MQTT connections, and as many Cloud MQTT connections as you like.

Once you already have every kind you can add, the **Add connector** button stops offering new ones. If you need to start fresh, remove a connection by clicking the red trash icon on its row in the connection table (a confirmation dialog appears before anything is deleted).

## Next step

With a connection in place, you're ready to start adding sensors. Head to [Adding Sensors](/devices/adding-sensors) to register your first one.


# LNS Connector

The LNS connector links your LoRaWAN sensors to Chirp's built-in network server — nothing to install.

The LNS connector is what lets your LoRaWAN sensors talk to Chirp. It connects to Chirp's built-in LoRaWAN network server — so there's nothing extra to install, configure, or pay for. Once you add the LNS connector, your home is ready to receive data from any compatible LoRaWAN sensor.

## What You'll Find Here

* [What is LoRaWAN?](/connectors/lns-connector/what-is-lorawan) — A quick guide to the wireless technology your sensors use
* [LoRaWAN Frequencies](/connectors/lns-connector/lorawan-frequencies) — Which frequency band applies in your country
* [Built-in Network Server](/connectors/lns-connector/built-in-lns) — How Chirp handles all the network complexity for you

## Setting Up the LNS Connector

For step-by-step instructions on adding the LNS connector to your home, see [Setting Up a Connection](/connectors/setting-up-a-connection).

## Inside the LNS Connector

Once your LNS connector is set up, click it in the connectors list to see two tabs:

* **LoRaWAN Gateways** — Your gateway list. See [Gateways](/gateways) for setup.
* **Connected Devices** — Your sensors. See [Adding Sensors](/devices/adding-sensors) for the full walkthrough.


# What is LoRaWAN?

Learn why LoRaWAN reaches every corner of your home and runs sensors for years on a single battery.

LoRaWAN (Long Range Wide Area Network) is the wireless technology that connects your sensors to Chirp. It's designed specifically for the kind of devices you find in a smart home — small sensors that send readings like temperature, humidity, or door status — and it does so over long distances while using almost no battery power.

Think of LoRaWAN as a wireless network built for sensors, not for streaming video or browsing the web. It sends tiny amounts of data very efficiently, which is exactly what a temperature sensor or a leak detector needs.

## Why LoRaWAN Works Well for Smart Homes

### Reaches Every Corner of Your Property

LoRaWAN uses sub-gigahertz radio frequencies that penetrate walls, floors, and concrete far better than Wi-Fi or Bluetooth. A sensor in the basement behind thick concrete walls, in the attic above insulation, or buried in a utility closet can still reach your gateway reliably. This is what makes LoRaWAN uniquely practical for homes — it reaches the places where Wi-Fi drops out.

A single gateway covers your entire property and often well beyond. In open areas the signal can travel several kilometers, so a shed at the back of the garden, a detached garage, or a greenhouse across the yard are all within easy reach. You don't need electricity or Wi-Fi in those spaces — just place a battery-powered LoRaWAN sensor and it connects on its own. Most home sensors are peel-and-stick — no wiring, no installation tools.

For the best coverage, place your gateway near a window or on the roof if possible. A window-mounted or roof-mounted gateway has a clear line to the surrounding property, giving you the largest radius of reliable reception around your home.

### Years of Battery Life

LoRaWAN sensors are designed to run for years on a single battery. A temperature sensor in your garden or a leak detector under the sink can operate for two to five years without attention. You don't need to wire them into mains power or change batteries every few months. That independence from mains power is what makes LoRaWAN so flexible: you can place a sensor wherever a reading would be useful — the garden, a shed, the basement, an outbuilding, the mailbox, a utility room — without planning around a power outlet or a wiring run.

### Secure Communication

All data between your sensors and Chirp is encrypted end-to-end. Your sensor readings, door status alerts, and environmental data travel securely — nobody can intercept or tamper with the data in transit.

### Works with Many Sensors at Once

A single gateway can handle hundreds of sensors simultaneously. Whether you have five sensors or fifty, one gateway is typically enough for a home setup.

## What Kinds of Sensors Use LoRaWAN?

LoRaWAN is ideal for sensors that send small readings at regular intervals:

* **Temperature and humidity** sensors for rooms, greenhouses, wine cellars
* **Door and window** open/close sensors for security
* **Water leak** detectors for bathrooms, basements, kitchens
* **Soil moisture** sensors for gardens and plant beds
* **Air quality** monitors for living spaces
* **Motion detectors** for entry points or driveways
* **Energy and utility** meters for tracking consumption

## How It Connects to Chirp

Your LoRaWAN sensors communicate with a **gateway** (a small device plugged into your home network). The gateway relays sensor data to Chirp's built-in network server, which processes it and makes it available in your dashboards, automations, and alerts. You don't need to set up or maintain any network infrastructure beyond the gateway itself.

For which frequency band your country uses, see [LoRaWAN Frequencies](/connectors/lns-connector/lorawan-frequencies). For how Chirp handles the network automatically, see [Built-in Network Server](/connectors/lns-connector/built-in-lns).


# LoRaWAN Frequencies

Find the right LoRaWAN frequency band for your country before registering a sensor in Chirp.

> **Reference only.** This page is a general guide. The frequency data may not be 100% accurate or up to date. Always check with your local regulations before deploying devices. Use at your own risk.

LoRaWAN sensors use unlicensed radio frequencies that vary by country. When you set up a sensor in Chirp, you select the correct frequency band for your region. This page helps you find out which band to use.

## The Short Version

**If you bought your sensor locally, you almost certainly have the right frequency already.** LoRaWAN sensors sold in your country are configured for the regional band by default. A sensor purchased from a store in Australia will use AU915, a sensor from Germany will use EU868, and so on. You typically only need to worry about frequency selection if you purchased a sensor from another country or are setting up a device from an international supplier.

## Common Frequency Bands

| Region                   | Band          | Frequency Range |
| ------------------------ | ------------- | --------------- |
| Europe                   | EU868         | 863–870 MHz     |
| Europe (alternate)       | EU433         | 433–434 MHz     |
| United States & Canada   | US915         | 902–928 MHz     |
| Australia                | AU915         | 915–928 MHz     |
| Asia (varies by country) | AS923         | 920–928 MHz     |
| South Korea              | KR920         | 920–923 MHz     |
| India                    | IN865         | 865–867 MHz     |
| Russia                   | RU864 / EU868 | 864–870 MHz     |
| China                    | CN470         | 470–510 MHz     |
| Global (2.4 GHz)         | ISM2400       | 2.4 GHz         |

When registering a sensor in Chirp, you'll see these options in the **Band** dropdown on the Connection tab.

## License-Free and No Extra Cost

LoRaWAN uses license-free radio bands — you don't need any permits or licenses to use your sensors. The frequencies are regulated by your country's communications authority, but they are free for anyone to use as long as the devices comply with local rules (which off-the-shelf sensors already do).

## Frequency Plan Disclaimer

This frequency information is provided for reference. While we aim for accuracy, Chirp does not guarantee the precision of this data. If you are unsure about which band to use in your area, check your sensor's documentation or contact the manufacturer.

## Frequencies by Country

### A

| Country                  | Frequency Plan          |
| ------------------------ | ----------------------- |
| Afghanistan (AF)         |                         |
| Aland Islands (AX)       | EU433 EU863-870         |
| Albania (AL)             | EU433 EU863-870 AS923-3 |
| Algeria (DZ)             | EU433 AS923-3           |
| American Samoa (AS)      | US902-928               |
| Andorra (AD)             | EU433 EU863-870         |
| Angola (AO)              |                         |
| Antigua and Barbuda (AG) |                         |
| Argentina (AR)           | AU915-928               |
| Armenia (AM)             | EU433 EU863-870         |
| Aruba (AW)               |                         |
| Australia (AU)           | AS923-1 AU915-928       |
| Austria (AT)             | EU433 EU863-870         |
| Azerbaijan (AZ)          | EU433                   |

### B

| Country                                | Frequency Plan          |
| -------------------------------------- | ----------------------- |
| Bahamas (BS)                           | US902-928               |
| Bahrain (BH)                           | EU433 EU863-870         |
| Bangladesh (BD)                        | EU433 AS923-1           |
| Barbados (BB)                          | AU915-928 AU902-928     |
| Belarus (BY)                           | EU433 EU863-870         |
| Belgium (BE)                           | EU433 EU863-870         |
| Belize (BZ)                            | AU915-928 AU902-928     |
| Benin (BJ)                             | US902-928               |
| Bhutan (BT)                            | EU433 EU863-870         |
| Bolivia (BO)                           | AU915-928 AU902-928     |
| Bonaire, Saint Eustatius and Saba (BQ) | EU433 EU863-870         |
| Bosnia and Herzegovina (BA)            | EU433 EU863-870         |
| Botswana (BW)                          | EU433 EU863-870         |
| Bouvet Island (BV)                     | EU433 EU863-870 AS923-3 |
| Brazil (BR)                            | EU433 AU915-928         |
| British Indian Ocean Territory (IO)    |                         |
| Brunei Darussalam (BN)                 | EU433 EU863-870 AS923-1 |
| Bulgaria (BG)                          | EU433 EU863-870         |
| Burundi (BI)                           | EU433 EU863-870         |
| Burkina Faso (BF)                      |                         |

### C

| Country                            | Frequency Plan                    |
| ---------------------------------- | --------------------------------- |
| Cabo Verde (CV)                    | EU433 EU863-870                   |
| Cambodia (KH)                      | AS923-1 EU863-870                 |
| Cameroon (CM)                      | EU433                             |
| Canada (CA)                        | US902-928 US915-928               |
| Central African Republic (CF)      |                                   |
| Chad (TD)                          |                                   |
| Chile (CL)                         | EU433 AU915-928                   |
| China (CN)                         | AS923-1 CN779-787 CN470-510       |
| Christmas Island (CX)              | AS923-1 AU915-928                 |
| Cocos Islands (CC)                 | AS923-1 AU915-928                 |
| Colombia (CO)                      | EU433 AU915-928                   |
| Comoros (KM)                       | EU433 EU863-870 AS923-3           |
| Congo, Democratic Republic of (CD) |                                   |
| Congo (CG)                         |                                   |
| Cook Islands (CK)                  | EU433 IN865-867 AS923-1 AU915-928 |
| Costa Rica (CR)                    | EU433 AS923-1                     |
| Cote d'Ivoire (CI)                 | EU863-870                         |
| Croatia (HR)                       | EU433 EU863-870                   |
| Cuba (CU)                          | EU433 AS923-3                     |
| Curacao (CW)                       | EU433 AS923-1                     |
| Cyprus (CY)                        | EU433 EU863-870                   |
| Czechia (CZ)                       | EU433 EU863-870                   |

### D

| Country       | Frequency Plan          |
| ------------- | ----------------------- |
| Denmark (DK)  | EU433 EU863-870 AS923-3 |
| Djibouti (DJ) |                         |
| Dominica (DM) | AU915-928 US902-928     |

### E

| Country                | Frequency Plan            |
| ---------------------- | ------------------------- |
| Ecuador (EC)           | AU915-928                 |
| Egypt (EG)             | EU433 EU863-870 IN865-867 |
| El Salvador (SV)       | AU915-928                 |
| Equatorial Guinea (GQ) | EU433 EU863-870           |
| Eritrea (ER)           |                           |
| Estonia (EE)           | EU433 EU863-870 AS923-3   |
| Eswatini (SZ)          |                           |
| Ethiopia (ET)          |                           |

### F

| Country                          | Frequency Plan  |
| -------------------------------- | --------------- |
| Falkland Islands (FK)            | EU433 EU863-870 |
| Faroe Islands (FO)               | EU433 EU863-870 |
| Fiji (FJ)                        |                 |
| Finland (FI)                     | EU433 EU863-870 |
| France (FR)                      | EU433 EU863-870 |
| French Guiana (GF)               | EU433 EU863-870 |
| French Polynesia (PF)            | EU433 EU863-870 |
| French Southern Territories (TF) | EU433 EU863-870 |

### G

| Country            | Frequency Plan          |
| ------------------ | ----------------------- |
| Gabon (GA)         |                         |
| Gambia (GM)        | EU433                   |
| Georgia (GE)       | EU433 EU863-870         |
| Germany (DE)       | EU433 EU863-870         |
| Ghana (GH)         | EU433                   |
| Gibraltar (GI)     | EU433 EU863-870         |
| Greece (GR)        | EU433 EU863-870         |
| Greenland (GL)     | EU433 EU863-870 AS923-3 |
| Grenada (GD)       | AU915-928               |
| Guadeloupe (GP)    | EU433 EU863-870         |
| Guam (GU)          | US902-928               |
| Guatemala (GT)     | AU915-928               |
| Guernsey (GG)      | EU433 EU863-870 AS923-3 |
| Guinea (GN)        | EU433                   |
| Guinea-Bissau (GW) |                         |
| Guyana (GY)        |                         |

### H

| Country                                | Frequency Plan          |
| -------------------------------------- | ----------------------- |
| Haiti (HT)                             |                         |
| Heard Island and McDonald Islands (HM) | AU915-928 AS923-1       |
| Holy See (VA)                          | EU433 EU863-870         |
| Honduras (HN)                          | AU915-928               |
| Hong Kong (HK)                         | EU433 IN865-867 AS923-1 |
| Hungary (HU)                           | EU433 EU863-870 AS923-3 |

### I

| Country          | Frequency Plan          |
| ---------------- | ----------------------- |
| Iceland (IS)     | EU433 EU863-870         |
| India (IN)       | IN865-867               |
| Indonesia (ID)   | AS923-2                 |
| Iran (IR)        | EU433 EU863-870 AS923-3 |
| Iraq (IQ)        |                         |
| Ireland (IE)     | EU433 EU863-870 AS923-3 |
| Isle of Man (IM) | EU433 EU863-870 AS923-3 |
| Israel (IL)      | AS923-4                 |
| Italy (IT)       | EU433 EU863-870         |

### J

| Country      | Frequency Plan          |
| ------------ | ----------------------- |
| Jamaica (JM) | AU915-928               |
| Japan (JP)   | AS923-1                 |
| Jersey (JE)  | EU433 EU863-870         |
| Jordan (JO)  | AS923-3 EU433 EU863-870 |

### K

| Country                                     | Frequency Plan          |
| ------------------------------------------- | ----------------------- |
| Kazakhstan (KZ)                             | EU433                   |
| Kenya (KE)                                  | EU433 EU863-870         |
| Kiribati (KI)                               |                         |
| Korea, Democratic People's Republic of (KP) |                         |
| Korea, Republic of (KR)                     | KR920-923               |
| Kuwait (KW)                                 | EU433 EU863-870 AS923-3 |
| Kyrgyzstan (KG)                             |                         |

### L

| Country                               | Frequency Plan          |
| ------------------------------------- | ----------------------- |
| Lao People's Democratic Republic (LA) | EU433 EU863-870 AS923-1 |
| Latvia (LV)                           | EU433 EU863-870         |
| Lebanon (LB)                          | EU433 EU863-870         |
| Lesotho (LS)                          | EU433                   |
| Liberia (LR)                          |                         |
| Libya (LY)                            |                         |
| Liechtenstein (LI)                    | EU433 EU863-870 AS923-3 |
| Lithuania (LT)                        | EU433 EU863-870         |
| Luxembourg (LU)                       | EU433 EU863-870 AS923-3 |

### M

| Country               | Frequency Plan          |
| --------------------- | ----------------------- |
| Macao (MO)            | EU433 AS923-1           |
| Macedonia (MK)        | EU433 EU863-870         |
| Madagascar (MG)       | EU433 EU863-870         |
| Malawi (MW)           |                         |
| Malaysia (MY)         | EU433 AS923-1           |
| Maldives (MV)         |                         |
| Mali (ML)             | EU433                   |
| Malta (MT)            | EU433 EU863-870         |
| Marshall Islands (MH) |                         |
| Martinique (MQ)       | EU433 EU863-870         |
| Mauritania (MR)       | EU433 EU863-870         |
| Mauritius (MU)        | EU433                   |
| Mayotte (YT)          | EU433 EU863-870         |
| Mexico (MX)           | US902-928               |
| Micronesia (FM)       |                         |
| Moldova (MD)          | EU433 EU863-870 AS923-3 |
| Monaco (MC)           | EU433 EU863-870         |
| Mongolia (MN)         |                         |
| Montenegro (ME)       | EU433 EU863-870         |
| Montserrat (MS)       | AU915-928               |
| Morocco (MA)          | EU433                   |
| Mozambique (MZ)       |                         |
| Myanmar (MM)          | EU433 AS923-1           |

### N

| Country                       | Frequency Plan                    |
| ----------------------------- | --------------------------------- |
| Namibia (NA)                  | EU433 EU863-870                   |
| Nauru (NR)                    |                                   |
| Nepal (NP)                    |                                   |
| Netherlands (NL)              | EU433 EU863-870                   |
| New Caledonia (NC)            | EU433 EU863-870                   |
| New Zealand (NZ)              | AU915-928 AS923-1                 |
| Nicaragua (NI)                | EU433 EU863-870                   |
| Niger (NE)                    | IN865-867                         |
| Nigeria (NG)                  | EU433 EU863-870                   |
| Niue (NU)                     | EU433 IN865-867 AS923-1 AU915-928 |
| Norfolk Island (NF)           | AS923-1 AU915-928                 |
| Northern Mariana Islands (MP) | US902-928                         |
| Norway (NO)                   | EU433 EU863-870 AS923-3           |

### O

| Country   | Frequency Plan  |
| --------- | --------------- |
| Oman (OM) | EU433 EU863-870 |

### P

| Country               | Frequency Plan          |
| --------------------- | ----------------------- |
| Pakistan (PK)         | EU433 IN865-867 AS923-1 |
| Palau (PW)            |                         |
| Palestine (PS)        |                         |
| Panama (PA)           | AU915-928               |
| Papua New Guinea (PG) | EU433 AU915-928 AS923-1 |
| Paraguay (PY)         | EU433 AU915-928         |
| Peru (PE)             | AU915-928               |
| Philippines (PH)      | EU433 EU863-870 AS923-3 |
| Pitcairn (PN)         |                         |
| Poland (PL)           | EU433 EU863-870 AS923-3 |
| Portugal (PT)         | EU433 EU863-870         |
| Puerto Rico (PR)      | US902-928               |

### Q

| Country    | Frequency Plan          |
| ---------- | ----------------------- |
| Qatar (QA) | EU433 EU863-870 AS923-3 |

### R

| Country                 | Frequency Plan          |
| ----------------------- | ----------------------- |
| Reunion (RE)            | EU433 EU863-870         |
| Romania (RO)            | EU433 EU863-870         |
| Russian Federation (RU) | EU433 EU864-870 AS923-3 |
| Rwanda (RW)             | EU433 EU863-870         |

### S

| Country                                           | Frequency Plan          |
| ------------------------------------------------- | ----------------------- |
| Saint Barthelemy (BL)                             | EU433 EU863-870         |
| Saint Helena, Ascension and Tristan da Cunha (SH) |                         |
| Saint Kitts and Nevis (KN)                        | AU915-928               |
| Saint Lucia (LC)                                  | AU915-928               |
| Saint Martin (MF)                                 | EU433 EU863-870         |
| Saint Pierre and Miquelon (PM)                    | EU433 EU863-870         |
| Saint Vincent and the Grenadines (VC)             | AU915-928               |
| Samoa (WS)                                        | EU433 EU863-870         |
| San Marino (SM)                                   | EU433 EU863-870         |
| Sao Tome and Principe (ST)                        |                         |
| Saudi Arabia (SA)                                 | EU433 EU863-870 AS923-3 |
| Senegal (SN)                                      | EU863-870               |
| Serbia (RS)                                       | EU433 EU863-870         |
| Seychelles (SC)                                   | EU433                   |
| Sierra Leone (SL)                                 |                         |
| Singapore (SG)                                    | AS923-1 EU433           |
| Sint Maarten (SX)                                 |                         |
| Slovakia (SK)                                     | EU433 EU863-870 AS923-3 |
| Slovenia (SI)                                     | EU433 EU863-870 AS923-3 |
| Solomon Islands (SB)                              | AS923-1                 |
| Somalia (SO)                                      | EU433 EU863-870 AS923-3 |
| South Africa (ZA)                                 | EU433 EU863-870         |
| South Georgia and the South Sandwich Islands (GS) | EU433 EU863-870 AS923-3 |
| South Sudan (SS)                                  |                         |
| Spain (ES)                                        | EU433 EU863-870         |
| Sri Lanka (LK)                                    | EU433 AS923-1           |
| Sudan (SD)                                        |                         |
| Suriname (SR)                                     | AU915-928               |
| Svalbard and Jan Mayen (SJ)                       | EU433 EU863-870 AS923-3 |
| Sweden (SE)                                       | EU433 EU863-870         |
| Switzerland (CH)                                  | EU433 EU863-870         |
| Syrian Arab Republic (SY)                         | EU433 EU863-870 AS923-3 |

### T

| Country                       | Frequency Plan                    |
| ----------------------------- | --------------------------------- |
| Taiwan (TW)                   | AS923-1                           |
| Tajikistan (TJ)               |                                   |
| Tanzania (TZ)                 | EU433 AS923-1                     |
| Thailand (TH)                 | EU433 AS923-1                     |
| Timor-Leste (TL)              |                                   |
| Togo (TG)                     | EU433                             |
| Tokelau (TK)                  | EU433 IN865-867 AS923-1 AU915-928 |
| Tonga (TO)                    | EU433 AU915-928                   |
| Trinidad and Tobago (TT)      | AU915-928                         |
| Tunisia (TN)                  | EU433 EU863-870                   |
| Turkey (TR)                   | EU433 EU863-870                   |
| Turkmenistan (TM)             |                                   |
| Turks and Caicos Islands (TC) | AU915-928                         |
| Tuvalu (TV)                   |                                   |

### U

| Country                                   | Frequency Plan          |
| ----------------------------------------- | ----------------------- |
| Uganda (UG)                               | EU433 IN865-867 AS923-1 |
| Ukraine (UA)                              | EU433 EU863-870         |
| United Arab Emirates (AE)                 | EU433 EU863-870         |
| United Kingdom (GB)                       | EU433 EU863-870 AS923-3 |
| United States Minor Outlying Islands (UM) | US902-928               |
| United States of America (US)             | US902-928               |
| Uruguay (UY)                              | AU915-928               |
| Uzbekistan (UZ)                           | EU433                   |

### V

| Country                 | Frequency Plan          |
| ----------------------- | ----------------------- |
| Vanuatu (VU)            | EU433 IN865-867 AS923-3 |
| Venezuela (VE)          | AS923-1                 |
| Viet Nam (VN)           | EU433 AS923-2           |
| Virgin Islands, UK (VG) | AU915-928               |
| Virgin Islands, US (VI) | US902-928               |

### W

| Country                | Frequency Plan  |
| ---------------------- | --------------- |
| Wallis and Futuna (WF) | EU433 EU863-870 |
| Western Sahara (EH)    |                 |

### Y

| Country    | Frequency Plan |
| ---------- | -------------- |
| Yemen (YE) |                |

### Z

| Country       | Frequency Plan  |
| ------------- | --------------- |
| Zambia (ZM)   | EU433 EU863-870 |
| Zimbabwe (ZW) | EU433           |


# Built-in Network Server

Chirp's built-in LoRaWAN network server handles sensor authentication and delivery for you automatically.

Behind every LoRaWAN setup, there's a network server — the system that receives data from your gateway, authenticates your sensors, and routes readings to the right place. In traditional LoRaWAN deployments, this is a separate piece of software that you'd need to install, configure, and maintain on your own. That's a lot of work just to get a temperature reading into a dashboard.

Chirp takes care of all of this for you. The network server is built right into the platform — there's nothing extra to install, no server to manage, and no technical setup required on your end.

## What It Does

When your sensor sends a reading, here's what happens automatically:

* **Authentication** — Chirp verifies the sensor is legitimate using the encryption keys you entered during setup (the AppKey)
* **Data reception** — Your gateway picks up the sensor's radio signal and forwards it to Chirp's network server
* **Deduplication** — If multiple gateways hear the same sensor transmission (which is normal), Chirp keeps one copy and discards the duplicates
* **Delivery** — The sensor reading arrives in your dashboards, automations, and alerts — ready to use

All of this happens in the background, every time any of your sensors sends data.

## What This Means for You

* **No extra software to install** — the network server is part of Chirp, not a separate system
* **No configuration** — adding the LNS connector activates the network server for your home automatically
* **No maintenance** — the network server is managed as part of Chirp — there's nothing for you to maintain
* **Instant data flow** — once a sensor connects to your gateway, its readings appear in Chirp within moments

You can focus on choosing sensors, placing them around your home, and building the dashboards and automations you care about — without worrying about network infrastructure.

For an overview of LoRaWAN, see [What is LoRaWAN?](/connectors/lns-connector/what-is-lorawan). For setting up your gateway, see [Gateways](/gateways).


# Tracker Connector

Connect a cellular GPS vehicle tracker to Chirp — OBD2, CAN bus, and standalone trackers, 2,000+ preconfigured models.

Chirp goes beyond the walls of your home. The **Tracker connector** lets you bring a **vehicle GPS tracker** into Chirp, so your car, motorcycle, or camper shows up on the same dashboards and alerts as your sensors — live location, route history, speed, and whatever else the tracker reports.

<figure><img src="/files/nj8mneXzaUl9Xrcejm5Z" alt="Add connector dialog with Tracker selected as the connector type"><figcaption></figcaption></figure>

## What it's for

The Tracker connector is for **cellular (GSM) vehicle trackers** — devices that send their location over the mobile network:

* **OBD2** plug-in trackers (into a car's diagnostics port)
* **CAN bus** trackers wired into the vehicle
* **Standalone GPS** vehicle trackers

Chirp ships with preconfigured profiles for **over 2,000 tracker models**, so most popular trackers work out of the box.

These trackers almost always need an external power source or a vehicle connection (OBD2/CAN), which makes them a great fit for **cars, motorcycles, campers, trailers with a battery, boats, ATVs**, and similar — not for tiny battery-only room sensors.

> **Cellular trackers only — not LoRaWAN.** Some GPS trackers and tags use LoRaWAN instead of a mobile network. Those do **not** go through the Tracker connector — a LoRaWAN tracker connects through the [LNS Connector](/connectors/lns-connector), just like your other LoRaWAN sensors. Use the Tracker connector for cellular/GSM vehicle trackers.

## Adding the Tracker connector

1. Click **Connectors** in the sidebar.
2. Click **Add connector**.
3. Choose **Tracker** from the **Connector type** dropdown.
4. Click **Add**.

That's it — the connector is created in one step. Each home can have **one Tracker connector**. (See [Setting Up a Connection](/connectors/setting-up-a-connection) for the connection basics.)

## Connecting your tracker

When you register a tracker through this connector, its **Connection** details include three tracker-specific fields:

* **Unique ID** — your tracker's identifier
* **Device model** — pick your tracker from the model list
* **Url for GPS tracker** — the endpoint Chirp gives you; configure your tracker (in its own app or SMS settings) to send data to this URL

Configure the tracker to send its data to that URL; once it starts reporting, it appears in Chirp. For the full registration walkthrough, see [Adding Sensors](/devices/adding-sensors).

## Seeing where it's been

With a tracker connected, the dashboard side comes alive: put it on a map, watch it live, and replay where it has been. See [Tracking What Matters](/dashboards/tracking-what-matters).


# MQTT Connector

Bring Zigbee sensors, smart plugs, and DIY hardware into your home with the MQTT connector.

The MQTT connector is how you bring Zigbee sensors, DIY microcontroller sensors, and other smart home hardware directly into Chirp — without needing LoRaWAN.

The most popular use is Zigbee. Thousands of Zigbee-compatible devices are supported through [Zigbee2MQTT](https://www.zigbee2mqtt.io/supported-devices/) — temperature sensors, motion detectors, smart plugs, door and window sensors, leak detectors, and many more from brands including Aqara, IKEA, Sonoff, Philips Hue, and Tuya. Compatibility depends on Zigbee2MQTT's device support, your coordinator adapter, and the specific device model — check the [Zigbee2MQTT supported devices list](https://www.zigbee2mqtt.io/supported-devices/) to confirm your device before purchasing.

You can also connect non-Zigbee devices: an ESP32 you built yourself, a Tasmota-flashed smart plug, a soil moisture monitor with MQTT firmware, or any hardware that publishes data over MQTT.

> **What this section covers.** These pages cover MQTT telemetry — bringing data *from* your devices into Chirp — and how to map it to sensor metrics. Once a device is connected, you can also send commands *to* it from Chirp: turn a plug on or off, dim a bulb, change its color temperature, and more. That two-way control is set up on each device under [Device Commands](/devices/commands).

## In this section

* [What MQTT is](/connectors/mqtt-connector/what-is-mqtt) — A short primer on brokers, topics, and JSON payloads.
* [Cloud MQTT](/connectors/mqtt-connector/cloud-mqtt) — Use Chirp's hosted broker. The simpler path for most homes.
* [External MQTT](/connectors/mqtt-connector/external-mqtt) — Use your own broker. Chirp connects out to it.
* [Topics and device routing](/connectors/mqtt-connector/topics-and-device-routing) — How Chirp matches incoming MQTT messages to the right device. Read this before registering devices.
* [Setting up Zigbee2MQTT](/connectors/mqtt-connector/zigbee2mqtt) — The generic Z2M install path that produces the telemetry you'll register here.
* [Troubleshooting](/connectors/mqtt-connector/troubleshooting) — When data isn't appearing, or the Logs tab stays empty.
* Tested hardware: [Sonoff ZBDongle-E coordinator](/gateways/zigbee2mqtt-hubs/sonoff-zbdongle-e-coordinator) and [Paulmann 50064 light bulb](/devices/tested-device-guides/zigbee/paulmann-50064-light-bulb). Other Zigbee2MQTT-supported coordinators and devices follow the same flow — these are tested examples.

***

## How Zigbee-over-MQTT works

Zigbee devices don't connect to Chirp directly. They connect through a coordinator — a small USB or network-attached adapter — and software called Zigbee2MQTT that translates Zigbee signals into MQTT messages. The MQTT connector then picks up those messages and routes the data into Chirp.

```
Zigbee sensor  →  Zigbee coordinator  →  Zigbee2MQTT  →  MQTT  →  Chirp
```

You need:

1. A **Zigbee coordinator adapter** — the hardware bridge between Zigbee radio and your home network.
2. **Zigbee2MQTT software** — runs on a Raspberry Pi, home server, or any always-on machine.
3. A **Chirp MQTT connector** — tells Chirp where to listen and how to read the messages.

### Recommended Zigbee coordinator adapters

Any adapter supported by Zigbee2MQTT will work. The most commonly used:

* **SONOFF Zigbee 3.0 USB Dongle Plus** — ZBDongle-P (CC2652P chip) or ZBDongle-E (EFR32MG21 chip). Plug directly into a USB port.
* **SMLIGHT SLZB-06 / SLZB-06M** — Network-attached. Connects over Ethernet or Wi-Fi.
* **Home Assistant Connect ZBT-1 / SkyConnect** — Works when configured to use Zigbee2MQTT (instead of ZHA).
* **ConBee II / Phoscon** — USB adapter from Dresden Elektronik, used with deCONZ or Zigbee2MQTT.

For the current recommended options, see the [Zigbee2MQTT adapter guide](https://www.zigbee2mqtt.io/guide/adapters/).

***

## Two ways to connect: Cloud MQTT vs External MQTT

When you add an MQTT connector, you choose one of two options:

**Chirp Cloud MQTT** — Chirp provides the MQTT broker. You get a ready-to-use endpoint, username, password, and topic prefix. Paste them into Zigbee2MQTT or your device settings and you're done. Nothing to install or maintain. This is the simpler choice for most home setups — especially if you don't already run a local broker.

**External MQTT** — You use an MQTT broker you already operate. Chirp connects to it using the broker URL and credentials you supply. Use External MQTT if your broker is reachable from the internet — for example, a broker you host on a VPS or in a cloud account. For local home setups where Zigbee2MQTT runs on a Raspberry Pi or home server, Cloud MQTT is usually the simpler choice: configure Zigbee2MQTT to publish outward to the Chirp-hosted endpoint rather than the other way around.

You can create multiple connectors of either type — External MQTT up to 10 per home, Cloud MQTT as many as you need.

***

## Step 1: Add a Chirp Cloud MQTT connector

1. Tap **Connectors** in the sidebar.
2. Tap **Add connector**.
3. Select **Cloud MQTT** from the connector type list.
4. Enter a **Name** for the connector.
5. Tap **Add**.

Chirp provisions a broker endpoint and displays the credentials:

| Credential       | Details                                                                                                                |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------- |
| **Broker URL**   | The hosted MQTT endpoint. Copy it using the copy button.                                                               |
| **Topic prefix** | All messages to this connector must be published under this prefix — it keeps your data organized. Copy it.            |
| **Username**     | Assigned automatically. Copy it.                                                                                       |
| **Password**     | Shown once. **Copy it immediately** and save it somewhere safe. If you lose it, you'll need to rotate the credentials. |

#### Connecting Zigbee2MQTT or your device

Copy the credentials above into your Zigbee2MQTT configuration or device MQTT settings. A few things to know before you connect:

* **The Broker URL is the complete endpoint** — copy it exactly as shown. It uses TLS on port 1884 (not the standard 1883). In Zigbee2MQTT, set `server` to this value and enable TLS.
* **Every topic must start with the Topic prefix.** The full topic you publish to is: `{Topic prefix}/{device topic}`. For Zigbee2MQTT, set `base_topic` in its configuration to `{Topic prefix}/zigbee2mqtt` — for example `iot/abc123/xyz789/zigbee2mqtt`. Zigbee2MQTT then publishes each device under that path automatically.
* **Device routing templates don't include the prefix.** When you configure the Device ID Topic in the Topic tab (Step 2), enter only the device-level portion — for example `zigbee2mqtt/{{deviceId}}`. Chirp strips the prefix automatically before matching.

***

## Step 1 (alternative): Add an External MQTT connector

1. Tap **Connectors** in the sidebar.
2. Tap **Add connector**.
3. Select **External MQTT** from the connector type list.
4. Fill in the form:

   | Field          | What to enter                                                                                                                                                                                                                                                                                         |
   | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
   | **Name**       | A label for this connector (required)                                                                                                                                                                                                                                                                 |
   | **Broker URL** | The full address including scheme and port. The broker must be reachable from the internet — a private home network address will not work. Examples: `mqtts://mqtt.yourdomain.com:8883` (TLS), `mqtt://mqtt.yourdomain.com:1883` (plain). Accepted schemes: `mqtt://`, `mqtts://`, `tcp://`, `ssl://` |
5. Choose an **authentication method**:
   * **Anonymous** — no credentials
   * **Basic** — Username and Password (password has a show/hide toggle)
   * **Certification** — three file upload buttons: **CA Certificate**, **Client Certificate**, **Private Key** (upload files — do not paste text)
   * **JWT Token** — Token field (show/hide + copy); a Certificate upload field also appears in the form as an optional attachment
6. Tap **Save**.

***

## Step 2: Register a sensor

Each sensor that sends data through this connector needs to be registered in Chirp. Registration maps MQTT topics and payload structure to a sensor profile.

1. On the connector detail page, tap **Add device** — or go to **Devices** and start registration from there, selecting this connector.
2. Fill in the sensor name and pick a template if one fits.

> **Sensor name = device topic identifier, byte for byte.** Whatever you enter as the **Device ID** must match the device-level topic segment your hardware publishes — exactly. For Zigbee2MQTT, that's the friendly name. The Device ID input strips whitespace, so a Z2M friendly name like `Living Room Sensor` won't match a Device ID typed with spaces — use a whitespace-free name like `LivingRoomSensor` or `living_room_sensor` in **both** Z2M and Chirp. Capitalisation is preserved and significant.

3. The sensor opens with a **Mapping** tab. Inside Mapping there are two sub-tabs: **Topic** (where Chirp learns how to find the device in the topic stream) and **Mapping** (where you map payload keys to sensor metrics). Tapping **Mapping** opens the **Topic** sub-tab first — tap **Next** or the inner **Mapping** label to reach the per-key rows.

***

### Topic tab — how Chirp finds the device

#### The common case: Zigbee2MQTT with a flat JSON payload

Zigbee2MQTT publishes each device's data to a topic named after the device:

```
zigbee2mqtt/0x00158d0001234567
```

or with a friendly name (no spaces — see the byte-for-byte note above):

```
zigbee2mqtt/LivingRoomSensor
```

For **Device ID Topic**, enter:

```
zigbee2mqtt/{{deviceId}}
```

Leave **Telemetry topics** empty. Zigbee2MQTT sends a flat JSON payload like:

```json
{"temperature": 21.4, "humidity": 58, "battery": 92, "linkquality": 115}
```

Chirp reads all keys from this payload automatically — no Telemetry topics configuration needed. However, the Mapping tab is still required: each key you want as a sensor metric needs a row in the Mapping tab with the Connector Key set to match the payload key name. Without a Mapping row for a key, that data is silently ignored.

This is the default path for most Zigbee sensors, ESP32 projects publishing flat JSON, and Tasmota devices.

#### Topic tab fields explained

**Device ID Topic** — The MQTT topic pattern for this device. Use `{{deviceId}}` to mark the part of the topic that contains the device identifier. Required.

**Where to get the device ID** — Dropdown:

* **Topic** (default) — extracted from the `{{deviceId}}` segment.
* **Payload** — taken from a field inside the JSON message body.

**Device ID Payload Path** — Required when source is **Payload**. A dot-notation path to the ID field. Example: `device.id` for a payload like `{"device": {"id": "sensor-01"}, "temp": 22.1}`.

**Telemetry topics** — Optional. Add rows here when you need per-topic control: for example, when a sensor publishes each measurement to a separate topic, or when the measurement value is in the topic segment rather than the payload body. Each row has:

* **MQTT Topic for telemetry** — topic pattern with `{{deviceId}}` placeholder
* **Connector Key** — names the source key arriving from MQTT. The Connector Key does not create a platform metric on its own — it must be linked to a normalized metric in the Mapping tab.

**Add new topic** — adds a telemetry topic row.

**Apply all** — uses the device ID topic pattern as a prefix to generate telemetry topic templates for rows that already have a Connector Key filled in. Useful when you have multiple per-topic rows that follow a predictable naming pattern.

#### Placeholder reference

| Placeholder    | What it does                                                                                                                                                                                                                                                                                                     |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `{{deviceId}}` | Marks the topic segment that contains the device identifier                                                                                                                                                                                                                                                      |
| `{{value}}`    | Marks a topic segment whose content is the measurement value itself — for example, `sensors/dev01/22.5` where `22.5` is the reading. Do not use `{{value}}` for topic segments that name the metric (like `temperature`) — if the segment is a label rather than a value, use the payload-style approach instead |

***

### Mapping tab — what the data means

The Mapping tab links incoming MQTT keys to normalized Chirp sensor metrics. This is where raw data becomes something Chirp can display in dashboards, trigger in alarms, and query in the AI assistant.

The Connector Key in the Mapping tab must match the key published in the MQTT payload (or the Connector Key defined in the Topic tab). If they don't match, data is ignored — the helper text above the table says: **"If the Connector key is not filled in, the data will be ignored."**

The table has 8 columns:

| Column             | Type      | Details                                                                                      |
| ------------------ | --------- | -------------------------------------------------------------------------------------------- |
| **Normalized key** | Dropdown  | Select from sensor templates; includes a "+ Add new metric" option                           |
| **Unit**           | Read-only | Derived from the selected template                                                           |
| **Type**           | Read-only | Integer, Float, String, or Boolean — derived from template                                   |
| **Data type**      | Dropdown  | Reported State, Telemetry, or Device Metadata                                                |
| **Connector key**  | Dropdown  | Lists keys received from this device's payload. Empty until at least one publish has arrived |
| **Value**          | Read-only | Current live value received from the broker                                                  |
| **Last update**    | Read-only | Timestamp of the most recently received value                                                |
| **Actions**        | Icon      | Trash icon removes the row                                                                   |

**Add key** — adds a new empty mapping row.

#### Reported State vs Telemetry

The **Data type** dropdown distinguishes two kinds of values:

* **Reported State** — controllable device properties. The current state of something the device can also be told to change: a bulb's `state` (ON/OFF), `brightness`, `color_temp`, a smart plug's `power_state`. These are facts about what the device *is*.
* **Telemetry** — read-only measurements. Sensor readings that the device only reports: `temperature`, `humidity`, `linkquality`, `battery`, `pressure`. These are facts the device *observes*.

Pick the type that fits the value, not the metric template. Use Reported State when the field describes the device's controllable state; use Telemetry for everything else.

#### Connector Key dropdown is empty until your device publishes once

The **Connector key** column is a dropdown, not a text input. It lists the payload keys that have actually arrived from your device. Before the first publish, the dropdown shows nothing and the rows can't be filled.

The setup flow is two-pass:

1. Add a row per metric you want, pick the **Normalized key** from the templates dropdown (or use **+ Add new metric**), set the **Data type**, and leave the **Connector key** empty.
2. Tap **Save**. The device record is stored.
3. Make sure your hardware is publishing — for Zigbee2MQTT, the Z2M container is running and the device has reported at least once. (See [Discovering payload keys](/connectors/mqtt-connector/troubleshooting) if you're unsure how to force a publish.)
4. Reopen the device. The **Connector key** dropdown now lists the keys received from your device.
5. Match the right key to each row.
6. Tap **Save** again.

#### What the value column shows vs what the Logs tab shows

The Mapping tab's **Value** column updates from the most recent payload. It's a live snapshot — you'll see values as soon as the topic match works, even before you've finished filling in Connector keys.

The **Logs** tab is different: it's per-sensor history, and it only fills with publishes that arrive *after* you've saved Connector keys. If you fill in Connector keys, save, and then the lamp's wall switch is toggled but no MQTT publish is generated, the Logs tab will stay empty even though the Mapping tab shows the right value. To populate Logs, you need a fresh publish — drag a control in the Z2M web UI, send a `/get` poll, or wait for the device's next scheduled report. See [Troubleshooting](/connectors/mqtt-connector/troubleshooting) for the full list.

#### Mapping is iterative

MQTT mapping is rarely a one-shot operation. The first publish often reveals payload keys you didn't know to map during initial registration. After data starts arriving, return to the device's Mapping tab, look at the **Connector key** dropdown and **Value** column to see what the device is actually publishing, add rows for any useful fields you missed, set the right Data type for each, and save again. Generate another publish afterwards if you want the Logs tab to populate the new mappings.

#### Z2M feature type → Chirp data type

When you're mapping a Zigbee2MQTT device, look up the device on [zigbee2mqtt.io/devices](https://www.zigbee2mqtt.io/supported-devices/). Each feature has a type — translate to Chirp's metric Type as follows:

| Z2M feature type | Chirp Type | Example                                                   |
| ---------------- | ---------- | --------------------------------------------------------- |
| `binary`         | **String** | `state` — values are `"ON"`/`"OFF"` strings, not booleans |
| `numeric`        | **Number** | `brightness`, `color_temp`, `linkquality`                 |
| `enum`           | **String** | `color_mode`, `power_on_behavior`                         |
| `text`           | **String** | Free-form text fields                                     |

Selecting Boolean for a `state`-style binary field will leave the value empty — `"ON"` and `"OFF"` arrive as strings.

#### How to find what keys your device publishes

The Mapping tab doesn't auto-detect keys. Three ways to discover them:

1. **Z2M web UI** — open the Zigbee2MQTT frontend (default `http://localhost:8080`), click your device, look at the state panel. Every property name shown is a Connector Key candidate.
2. **The device's Z2M page** — `https://www.zigbee2mqtt.io/devices/{modelId}.html` lists the device's Exposes. Note that actual payloads can include keys that aren't on the Z2M page (`color_mode` is one example) — trust the live payload over the device page.
3. **Z2M logs** — after the first publish, `docker compose logs zigbee2mqtt | grep "MQTT publish"` shows the full JSON. Every top-level key is valid.
4. Tap **Save** to finish registration.

***

## What to expect after setup

Once a sensor is registered and data is flowing:

* The connector's **Last data received** timestamp updates each time a message arrives.
* The sensor's detail page shows incoming readings — temperature, humidity, battery, or whatever your sensor reports.
* Readings appear on your dashboards and are available for automations and alerts.

For Zigbee2MQTT sensors, data typically appears within a few seconds of the sensor's next report.

***

## More MQTT examples

**ESP32 DIY temperature sensor:** Publishes to `home/sensors/esp-kitchen/data` with a flat JSON payload. Device ID Topic: `home/sensors/{{deviceId}}/data`. Leave telemetry topics empty — the payload is parsed automatically. Mapping tab maps `temperature` and `humidity` keys to the corresponding normalized metrics.

**Tasmota smart plug:** Tasmota publishes to `tele/plug-01/SENSOR`. Device ID Topic: `tele/{{deviceId}}/SENSOR`. The payload is flat JSON with energy readings (Power, Voltage, Current, Today). Leave telemetry topics empty; then add Mapping tab rows for the Tasmota keys you want to track.

**Garden soil sensor — single metric on a dedicated topic:** A custom sensor publishes soil moisture to `garden/{{deviceId}}/moisture` with a plain number payload. Add a telemetry topic row: topic `garden/{{deviceId}}/moisture`, Connector Key `soil_moisture`. Then in the Mapping tab, link `soil_moisture` to the normalized soil moisture metric.

***

## Troubleshooting

A short list — the [full troubleshooting page](/connectors/mqtt-connector/troubleshooting) covers Z2M startup logs, the empty-Logs-tab pattern, and how to force a publish for setup-time verification.

**No data appears after setup:**

* For Cloud MQTT: make sure you copied the password correctly at creation time. If unsure, rotate the credentials and update Zigbee2MQTT with the new password. Confirm the Topic prefix is being used correctly — all published topics must start with it.
* For External MQTT: double-check the broker URL and credentials. A small typo in the address is the most common cause of connection failures. For Zigbee2MQTT setups, confirm that Zigbee2MQTT is running and connected to the broker by checking the Zigbee2MQTT web interface.

**Sensor appears but readings are missing or wrong:**

* Open the sensor detail page and check the **Logs** tab for incoming message content.
* Verify the Device ID Topic matches the exact topic path the sensor is publishing to. Topics are case-sensitive.
* Verify the **Device ID** is byte-for-byte identical to the device-level segment (for Zigbee2MQTT, the friendly name) — no spaces, same case.
* If you added telemetry topic rows: check that the Connector Key spellings match the payload keys exactly.
* In the Mapping tab: confirm that the Connector Key column values match what the sensor is actually publishing.

**Mapping tab Value column populates but Logs tab is empty:** This usually means Connector keys were saved after the most recent publish arrived. The Logs tab only fills with publishes that arrive *after* the keys are saved. Generate a fresh publish — drag a control in the Z2M web UI, or send a `/get` poll for setup-time verification — and the Logs tab will populate.

**"Toggle the device" doesn't produce data — what counts as a publish:** Many Zigbee bulbs (including the Paulmann 50064) do not send an MQTT publish on a physical wall-switch toggle. Actions that *do* generate a publish during setup:

* Drag a control or click the toggle in the Z2M web UI for the device — Z2M sends a `/set` and re-publishes the new state.
* Send a `/get` poll (e.g. via `mosquitto_pub` to `{base_topic}/{friendlyName}/get`) — Z2M reads the device and publishes the current state. This is local Z2M-side verification, not a Chirp control path.
* Wait for the device's next scheduled report (battery sensors typically wake on a schedule).

**Zigbee device doesn't join:** This is a Zigbee2MQTT or coordinator issue, not a Chirp issue. Check the [Zigbee2MQTT documentation](https://www.zigbee2mqtt.io/guide/usage/pairing_devices.html) for device pairing steps. Make sure permit join is enabled in Zigbee2MQTT when pairing new devices. For the Paulmann 50064 specifically, see the [tested device guide](/devices/tested-device-guides/zigbee/paulmann-50064-light-bulb).

**Cloud MQTT password lost:** Go to the MQTT connector settings and rotate the credentials. Update Zigbee2MQTT or your device with the new password and topic prefix.

**Device fails to save on a Cloud MQTT connector:** If saving a device on a Cloud MQTT connector fails, contact support for help completing the setup.

***

## What's next

* [Adding Sensors](/devices/adding-sensors) — Complete your sensor setup and assign it to a room.
* [Adding Widgets](/dashboards/adding-widgets) — Display your new sensor readings on a dashboard.
* [Set Up a Home Alert](/alarm/set-up-a-home-alert) — Get notified when readings go outside normal ranges.


# What MQTT is

A friendly intro to MQTT brokers, topics, and JSON payloads — the messaging behind the smart home.

MQTT is the messaging protocol that ties most of the modern smart home together. If you've ever watched a Zigbee sensor's reading appear on a dashboard, or asked your home automation to turn off the kitchen lights, MQTT was almost certainly carrying the message under the hood. It was designed in the late 1990s for satellite oil pipeline monitoring — devices with tiny radios, intermittent connectivity, and no patience for protocol overhead — and that pedigree is exactly why it works so well for battery-powered home sensors today.

If you already understand publish/subscribe messaging and just want to see how Chirp's MQTT connector fits in, skip ahead to [Cloud MQTT](/connectors/mqtt-connector/cloud-mqtt) or [External MQTT](/connectors/mqtt-connector/external-mqtt). If MQTT is new to you, the rest of this page is the orientation that will make those next pages click.

## The mental model

Three things are involved in any MQTT setup:

* A **broker** — the central post office that everything connects to. Devices don't talk to each other directly; they all talk to the broker, and the broker forwards messages to whoever asked for them.
* **Publishers** — anything that sends messages. A Zigbee2MQTT bridge publishing temperature readings, an ESP32 publishing soil moisture, a smart plug publishing its on/off state.
* **Subscribers** — anything that listens for messages. Chirp's MQTT connector is a subscriber; so is your home automation hub if you have one.

The same device can be both a publisher (it tells the broker about its temperature) and a subscriber (it listens for commands telling it to change a setpoint). The broker is the one constant — every message goes through it.

```
Living room sensor  →  publish  →
                                   Broker  →  forward  →  Chirp
Kitchen sensor      →  publish  →
```

Chirp's MQTT connector subscribes to messages the broker is forwarding. When you register a device, you're telling Chirp which messages from the broker belong to which device record.

## Topics: the address of every message

Every MQTT message has a **topic** — a slash-separated path that identifies what the message is about. The broker uses topics to route messages: subscribers say "I'm interested in topics that look like `home/+/temperature`," and the broker delivers anything matching that pattern.

Topics are not predefined. Whoever publishes a message decides the topic — there's no central registry. Conventions vary by software:

* **Zigbee2MQTT** publishes each device's data to `zigbee2mqtt/{friendlyName}` — for example, `zigbee2mqtt/LivingRoomSensor`. Below this device-level topic, the bridge also publishes status, command-acknowledgements, and per-device subtopics for actions like `/set` and `/get`.
* **Tasmota** smart plugs publish to `tele/{deviceName}/SENSOR` for periodic telemetry, `stat/{deviceName}/RESULT` for state changes, and several other topics.
* **Custom firmware** can use whatever topic scheme you write into it. A common pattern is `home/{location}/{deviceName}/{metric}`.

When you register a device in Chirp, the **Device ID Topic** field is where you tell the connector what the topic *shape* looks like. You write the pattern with `{{deviceId}}` standing in for the part of the topic that names the device — for Zigbee2MQTT, that's `zigbee2mqtt/{{deviceId}}`. Chirp matches incoming topics against the pattern and pulls the device identifier out of the placeholder position.

## Payloads: usually JSON, sometimes not

The body of an MQTT message is the **payload**. MQTT itself doesn't care what's in there — bytes are bytes — but in practice almost every modern device publishes JSON.

A typical Zigbee temperature/humidity sensor publishes something like:

```json
{
  "temperature": 21.4,
  "humidity": 58,
  "battery": 92,
  "linkquality": 115
}
```

That single message contains four sensor metrics, all delivered together as a flat object. Chirp's Mapping tab reads the keys from this JSON and maps them to your sensor's metric templates — `temperature` becomes the temperature reading, `humidity` becomes humidity, and so on.

Some devices publish each measurement to its own topic with just a number as the payload:

```
home/garden/soil-01/moisture     →  payload: 42
home/garden/soil-01/temperature  →  payload: 18.2
```

For that style, you add per-topic rows on the **Telemetry topics** section so Chirp knows which topic carries which metric. The flat-JSON case (one topic, all metrics in the payload) is more common and is the default path.

## QoS, retained messages, and other details that usually don't matter for setup

MQTT has features beyond the basics: three quality-of-service levels (QoS 0/1/2), retained messages that the broker keeps and replays to new subscribers, last-will messages that the broker publishes when a device disconnects unexpectedly. For a home setup with Chirp, you almost never need to think about these. Zigbee2MQTT picks reasonable defaults; Tasmota does too; Chirp's broker accepts what it's given.

The one detail that comes up: when Zigbee2MQTT first connects, it publishes a "bridge online" retained message. Chirp's connector will see that as the first incoming traffic — that's a signal the connection is healthy, even before any device has reported.

## Why MQTT and not something else

MQTT is the lingua franca of the smart home for three reasons:

* **Tiny overhead.** A temperature reading is a few bytes of header plus the JSON. This matters on battery-powered sensors that wake up every few minutes.
* **Loose coupling.** Devices don't need to know about each other. Add a new sensor and the broker just routes its messages — no other device has to be reconfigured.
* **It already works.** Zigbee2MQTT, Tasmota, ESPHome, Theengs, OpenMQTTGateway, and dozens of other projects all speak MQTT. Most off-the-shelf "smart home compatible" hardware can be made to publish MQTT with a small bridge.

When you're ready, continue to [Cloud MQTT](/connectors/mqtt-connector/cloud-mqtt) for the simpler setup, or [External MQTT](/connectors/mqtt-connector/external-mqtt) if you already run your own broker.


# Cloud MQTT

The simplest MQTT path — Chirp hosts the broker, you paste the credentials into Zigbee2MQTT and go.

Cloud MQTT is the simpler of the two MQTT paths into Chirp. You don't run a broker yourself — Chirp provisions a managed MQTT broker for the connector, gives you the endpoint and credentials, and you point your devices (or Zigbee2MQTT) at it. That's the whole architecture.

For most homes this is the right choice. You're not running a server in the basement, you're not exposing a port on your router, and you're not managing TLS certificates. You install Zigbee2MQTT on the machine that owns your USB Zigbee dongle, paste in four credentials, and the data starts flowing.

## When to choose Cloud MQTT

* You don't already have an MQTT broker.
* Your devices live on a home network behind NAT, and you'd rather not poke a hole through your router or rent a VPS.
* You want the simplest possible setup that works.

If you already operate your own broker — Mosquitto on a home server, a HiveMQ Cloud account, an MQTT broker on a Raspberry Pi sitting alongside Home Assistant — see [External MQTT](/connectors/mqtt-connector/external-mqtt). Both paths produce the same end result inside Chirp; the difference is who owns the broker.

## Creating the connector

1. Open **Connectors** in Chirp's sidebar.
2. Tap **Add connector**.
3. Pick **Cloud MQTT** from the connector type list.
4. Give it a **Name** — something memorable like `Home Zigbee Hub` or `Garden Sensors`.
5. Tap **Add**.

Chirp provisions a broker endpoint and shows four values:

| Field            | What it is                                                                                                                                                                                                                                               |
| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Broker URL**   | The complete address of Chirp's broker for this connector. Uses TLS on port 1884 (not the default 1883). Copy it as-is — including the `mqtts://` scheme.                                                                                                |
| **Topic prefix** | Every message published through this connector must start with this path. It's how the broker keeps your data separate from everyone else's. Looks like `iot/{org}/{connection}` — two unique segments identifying your organization and this connector. |
| **Username**     | Generated by Chirp. Copy it exactly — case and characters matter.                                                                                                                                                                                        |
| **Password**     | A long random secret. **Shown once.** Copy it immediately and save it somewhere you can find later. If you close the dialog without saving the password, you'll need to rotate the credentials and reconfigure your devices.                             |

There's no recovering the original password later — Chirp doesn't keep it readable. Rotation is the only path back if you've lost it.

## Connecting Zigbee2MQTT to a Cloud MQTT connector

In Zigbee2MQTT's `configuration.yaml`, the four credentials map to:

```yaml
mqtt:
  base_topic: iot/{your-org-segment}/{your-connection-segment}/zigbee2mqtt
  server: mqtts://mqtt-iot.chirpwireless.io:1884
  user: {username from Chirp}
  password: {password from Chirp}
```

A few things to notice:

* **`base_topic` adds `/zigbee2mqtt` to the Topic prefix.** Z2M automatically appends `/{friendlyName}` for each device, so your living-room sensor ends up publishing to `iot/{org}/{connection}/zigbee2mqtt/LivingRoomSensor`. Chirp strips the prefix internally, leaving the device-level topic as `zigbee2mqtt/LivingRoomSensor` — which is what you'll match in the Device ID Topic field when registering the device.
* **`server` uses `mqtts://` and port 1884.** The `mqtts://` scheme tells Z2M to use TLS automatically. You don't need to provide a CA certificate — the broker uses a publicly-trusted certificate.
* **The username and password are the ones from Chirp**, not anything Z2M generates.

For the full Zigbee2MQTT setup including the Docker Compose template and `configuration.yaml` example, see [Setting up Zigbee2MQTT](/connectors/mqtt-connector/zigbee2mqtt).

## Connecting other MQTT devices

Anything that publishes MQTT can use the same credentials — an ESP32 you wrote firmware for, a Tasmota smart plug, an MQTT-publishing weather station. Configure the device's MQTT settings:

* **Broker / server URL:** the Broker URL value from Chirp, including the `mqtts://` scheme and port 1884.
* **Username / Password:** the credentials Chirp generated.
* **Topic to publish to:** must start with the Topic prefix. So if you'd normally publish to `weather/outside`, with Chirp you publish to `{Topic prefix}/weather/outside`.

When you register the device in Chirp, the Device ID Topic field uses the device-level portion only — Chirp strips the prefix automatically.

## Verifying the connection

After Z2M (or your device) starts up:

1. Open the connector's detail page in Chirp.
2. Look at **Last data received**. Within a few seconds of Z2M connecting, this field updates with a timestamp.

The first message Z2M publishes is its own bridge status (`{base_topic}/bridge/state`) — it's how you know the broker accepted the connection, even before any sensor has reported. If **Last data received** stays empty for more than a minute, see [Troubleshooting](/connectors/mqtt-connector/troubleshooting).

## Rotating credentials

If the password is compromised or you've lost it:

1. Open the connector in Chirp.
2. In edit mode, use the regenerate option for the password.
3. Update the password in your device or Z2M `configuration.yaml`.
4. Restart the device or Z2M.

The username and Topic prefix don't change on rotation — only the password.

## Limits

Cloud MQTT connectors are unlimited per home. If you want separate connectors for different device groups (one for the indoor Zigbee mesh, one for the garden sensors, one for the workshop), create as many as you need — each gets its own credentials and topic prefix.


# External MQTT

Point Chirp at a broker you already run at home — set up Mosquitto, expose it safely, and verify it.

External MQTT is the second way to connect MQTT data into Chirp: instead of using a broker Chirp provides, you point Chirp at one you already run. Chirp connects out to your broker, subscribes to its messages, and brings them into the same device-routing pipeline as everything else.

## How the connection works

The most important thing to understand up front: **Chirp connects out to your broker**, not the other way around. This single fact decides everything that follows.

Practically that means your broker must be reachable from the public internet — Chirp's cloud needs to dial it. A broker running on `192.168.1.50:1883` on your home network is invisible to Chirp. Tunnels and port-forwarding fix that, with the trade-off that running an exposure tool such as ngrok does not by itself confirm Chirp can reach the broker — you must publish a test message after saving and verify the connector's **Last data received** field updates.

If your broker is already on a VPS or a cloud account, you're set — point Chirp at the public hostname and you're done.

## When to choose External MQTT

* You already run Mosquitto, HiveMQ Cloud, or another broker, and you want Chirp to consume from it without rerouting devices.
* Your home automation setup (Home Assistant, Node-RED) is already publishing to a broker, and Chirp is one more subscriber.
* You want Chirp to share data with other consumers — your dashboards, your scripts, your local NAS — through one common bus.

If none of those apply, [Cloud MQTT](/connectors/mqtt-connector/cloud-mqtt) is simpler.

## Setting up Mosquitto on a home server

Mosquitto is the most common open-source broker for home use. The minimal Docker setup looks like this:

`~/mqtt/docker-compose.yml`:

```yaml
services:
  mosquitto:
    image: eclipse-mosquitto:2
    container_name: mosquitto
    restart: unless-stopped
    ports:
      - "1883:1883"
    volumes:
      - ./mosquitto/config:/mosquitto/config
      - ./mosquitto/data:/mosquitto/data
```

`~/mqtt/mosquitto/config/mosquitto.conf`:

```
listener 1883
allow_anonymous true
persistence true
persistence_location /mosquitto/data/
log_dest stdout
```

Bring it up:

```bash
cd ~/mqtt
docker compose up -d mosquitto
docker compose logs mosquitto
```

You should see `Opening ipv4 listen socket on port 1883` and `mosquitto version X.Y.Z running` in the logs. If you do, the broker is up locally — internet exposure comes next.

> **`log_dest stdout` matters.** A common mistake is to log to a host-mounted file (`log_dest file /mosquitto/log/mosquitto.log`). On many systems the bind-mount permissions or security labels prevent Mosquitto from writing there, and the container fails to start. Logging to stdout works in every Docker setup, and `docker compose logs` shows the same content.

> **Port 1883 is sometimes already taken.** On a developer machine, another tool may have already bound port 1883 — for example, a kubectl port-forward or a different broker process. The container will fail with `failed to bind host port 0.0.0.0:1883/tcp: address already in use`. Diagnose with `ss -tlnp | grep 1883` to see what's holding the port. The simplest fix is to remap Mosquitto's host-side port to anything free: `"1885:1883"` keeps the container internal port at 1883 but binds it to host port 1885, and any device or tunnel pointing at the host needs to use 1885.

## Exposing the broker to the internet

You have two practical options.

### Option A — ngrok TCP tunnel (good for testing)

ngrok creates a public TCP endpoint that forwards back to your local Mosquitto. It's the fastest way to get something Chirp can reach.

1. Install ngrok using the current instructions from `https://ngrok.com/download` for your operating system.
2. Sign up at `https://dashboard.ngrok.com/signup` (free tier is fine for this).
3. Get your auth token from `https://dashboard.ngrok.com/get-started/your-authtoken`.
4. Configure ngrok with the token:

   ```bash
   ngrok config add-authtoken YOUR_TOKEN_HERE
   ```
5. Start a TCP tunnel pointing at the host port your broker is bound to:

   ```bash
   ngrok tcp 1883
   ```

   ngrok prints something like `Forwarding tcp://0.tcp.ngrok.io:14217 -> localhost:1883`. The `0.tcp.ngrok.io:14217` part is your broker's public address — you'll use it in Chirp's Broker URL field.

ngrok TCP tunnels require an authenticated account; without the auth token, the tunnel won't start. The free tier is sufficient for testing, but the address changes each time you restart ngrok — for a permanent setup, ngrok offers paid plans with reserved TCP addresses, or use Option B.

### Option B — router port forwarding (permanent)

For a permanent home setup:

1. Pick a stable external port (anything not already in use — 8883 is conventional for MQTT-over-TLS).
2. In your router's settings, add a port forward: external port 8883 → your machine's local IP : Mosquitto's host port (1883 or whatever you remapped to).
3. Configure a dynamic DNS hostname (Duck DNS, No-IP, your router may have a built-in option) so you have a stable address even when your home IP changes.

Use `mqtt://yourhome.duckdns.org:8883` (or `mqtts://...` if you've configured TLS) as Chirp's Broker URL.

This approach doesn't depend on a third party and gives you a fixed address forever.

## Securing Mosquitto before exposing it publicly

`allow_anonymous true` is fine while you're verifying the local setup, but **don't expose an anonymous broker to the internet**. Anyone on the internet who finds it can publish or subscribe. Switch to password authentication before going public.

Edit `mosquitto.conf`:

```
listener 1883
allow_anonymous false
password_file /mosquitto/config/passwd
persistence true
persistence_location /mosquitto/data/
log_dest stdout
```

Create the password file:

```bash
docker exec mosquitto mosquitto_passwd -c /mosquitto/config/passwd myuser
# enter password when prompted
docker compose restart mosquitto
```

Now your broker requires `myuser` + the password you set. Update Zigbee2MQTT (`configuration.yaml` `user:` and `password:` fields) and Chirp's connector with the same credentials.

For TLS — encrypted broker traffic — Mosquitto supports it via certificates. The Mosquitto documentation has the full setup; not strictly required for testing but recommended for any permanent public deployment.

## Creating the External MQTT connector in Chirp

1. **Connectors → Add connector**.
2. Pick **External MQTT**.
3. Fill in:
   * **Name**: any label, e.g. `Home Mosquitto`.
   * **Broker URL**: the public address. For ngrok, `mqtt://0.tcp.ngrok.io:14217`. For router forwarding, `mqtt://yourhome.duckdns.org:8883`. Use `mqtts://` if your broker is configured for TLS.
4. Pick the **authentication method**:
   * **Anonymous** if your broker still allows anonymous (for testing only).
   * **Basic** with the username and password you set.
   * **Certification** for TLS with client certs (uploads three files — CA Certificate, Client Certificate, Private Key).
   * **JWT Token** for token-based auth.
5. Tap **Save**.

Chirp creates an outbound bridge from its managed broker to your broker, subscribes to all topics on your broker, and forwards them into the same internal pipeline as Cloud MQTT data.

## Verifying the connection works end to end

After saving the connector, **publish a test message and confirm Chirp's Last data received updates** — this is the only way to confirm the platform can actually reach your broker. Just having ngrok or a port-forward "running" doesn't prove the path is open.

The simplest test is a one-shot publish from the same machine running Mosquitto:

```bash
docker run --rm eclipse-mosquitto:2 mosquitto_pub \
  -h 0.tcp.ngrok.io -p 14217 \
  -u myuser -P 'your-password' \
  -t test/hello -m '{"hello":"world"}'
```

(Substitute your actual ngrok address or DDNS hostname, and your credentials.)

Within a few seconds, the connector's **Last data received** field in Chirp should update. If it doesn't, the message never reached Chirp — see [Troubleshooting](/connectors/mqtt-connector/troubleshooting) for a checklist (the most common causes are firewall blocking the host port, ngrok session expired, or wrong credentials).

## Configuring Zigbee2MQTT for an External MQTT connector

In Z2M's `configuration.yaml`:

```yaml
mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://mosquitto:1883
  # if you set up password auth:
  user: myuser
  password: your-password
```

Note the differences from Cloud MQTT:

* **`base_topic` is just `zigbee2mqtt`**, with no Chirp prefix in front. Chirp's bridge handles the prefix internally.
* **`server` points at your local broker.** If both Z2M and Mosquitto are running in the same Docker Compose project, use the service name (`mqtt://mosquitto:1883`) — Docker's internal DNS resolves it. If Z2M is running on the host and Mosquitto in Docker, use `mqtt://localhost:{host port}` (1883 by default, or your remapped port).
* **No TLS unless you configured it** — local Mosquitto on Docker speaks plain MQTT by default.

After Z2M restarts and the bulb publishes, you'll see the device-level topic in Chirp as `zigbee2mqtt/{friendlyName}` — same as Cloud MQTT. The Device ID Topic in the device registration form is `zigbee2mqtt/{{deviceId}}` for both paths.

## Limits

External MQTT connectors are limited to 10 per home. If you have several brokers — a Mosquitto on the home server, a HiveMQ for outdoor sensors, a third for a hobby project — each gets its own connector and the 10 covers all of them combined.


# Topics and Device Routing

Read this before registering an MQTT device — how Chirp matches topics to the right sensor in your home.

This is the page to read once before you register your first MQTT device. It explains what the **Device ID Topic** field actually accepts, how Chirp matches incoming messages to the right device, why the **Connector key** dropdown is empty when you first open it, and the small handful of conventions that — once you know them — make every MQTT device registration feel routine.

## The shape of an incoming MQTT topic

When a device publishes through your MQTT connector, the topic Chirp sees has the device-level segment plus, for Cloud MQTT, your connector's prefix:

```
Cloud MQTT:    iot/{org}/{connection}/zigbee2mqtt/LivingRoomSensor
External MQTT: zigbee2mqtt/LivingRoomSensor
```

For Cloud MQTT, the `iot/{org}/{connection}/` part identifies which connector the message belongs to. Chirp strips it before matching, leaving the device-level topic — `zigbee2mqtt/LivingRoomSensor`. For External MQTT, the bridge adds and strips its own prefix internally, but the device-level topic ends up the same shape.

So when you fill in **Device ID Topic** in Chirp, you're describing the device-level shape only. Forget the prefix; Chirp handles it.

## The Device ID Topic field is a pattern, not a value

The label might suggest you should type a fixed identifier, but the field actually accepts a **topic pattern** with placeholders. The standard pattern for Zigbee2MQTT is:

```
zigbee2mqtt/{{deviceId}}
```

`{{deviceId}}` is a placeholder. When a topic arrives, Chirp matches it against the pattern and pulls the segment that aligns with `{{deviceId}}` out as the device's identifier. So an incoming topic of `zigbee2mqtt/LivingRoomSensor` resolves to `LivingRoomSensor` — and Chirp looks for a device record whose Device ID equals that string.

For non-Zigbee2MQTT setups, the pattern follows whatever shape your hardware publishes. A Tasmota smart plug publishing to `tele/PlugKitchen/SENSOR` would use:

```
tele/{{deviceId}}/SENSOR
```

A custom ESP32 publishing to `home/sensors/esp-kitchen/data` would use:

```
home/sensors/{{deviceId}}/data
```

The placeholder marks the segment where the device identifier lives. Everything else in the pattern is matched literally.

## Available placeholders

| Placeholder    | What it does                                                                                                                                                                                                                                                                                                                                |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `{{deviceId}}` | Marks the topic segment that contains the device identifier. Required in any Device ID Topic pattern.                                                                                                                                                                                                                                       |
| `{{value}}`    | Marks a topic segment whose content **is** the measurement reading itself — for example, `sensors/dev01/22.5` where `22.5` is the temperature. Useful for sensors that encode the reading in the topic. Do not use `{{value}}` for segments that name a metric (like `temperature`) — for that case, use the payload-side approach instead. |

## The Device ID field must match the device-level segment exactly

When you create the device record in Chirp, the **Device ID** field has to be byte-for-byte identical to whatever the publishing side puts in the `{{deviceId}}` segment. For Zigbee2MQTT, that means it has to equal the friendly name you chose in Z2M.

The biggest hidden trap here: **Chirp's Device ID input strips whitespace.** If your Z2M friendly name is `Living Room Sensor` (with spaces), and you paste that into Chirp's Device ID field, the platform stores it as `LivingRoomSensor` (or as `Living` — the exact normalization isn't guaranteed) — and the topic match fails. No error appears anywhere; you just see an empty Logs tab and wonder why.

The safe pattern: **pick a whitespace-free name on the Z2M side** and use it byte-for-byte in Chirp. Examples that work:

* `LivingRoomSensor` — CamelCase
* `living_room_sensor` — snake\_case
* `lamp-01` — kebab-case

Capitalisation is preserved, so `LivingRoomSensor` and `livingroomsensor` are different devices. Pick one and be consistent on both ends.

## Telemetry topics: when to use them, when to skip them

The **Telemetry topics** section under the Topic sub-tab is for devices that publish **each metric to its own topic** — like a custom sensor that publishes soil moisture to `garden/{deviceId}/moisture` and temperature to `garden/{deviceId}/temperature`, each with just a number as the payload.

For Zigbee2MQTT and most other modern devices, you can leave Telemetry topics completely empty. Z2M publishes a flat JSON payload on a single topic with all the metrics inside:

```json
{"temperature": 21.4, "humidity": 58, "battery": 92, "linkquality": 115}
```

Chirp parses that JSON automatically — every top-level key becomes a candidate Connector Key in the Mapping tab. No per-topic configuration needed.

Add Telemetry topic rows only when you genuinely have one-metric-per-topic publishing. For everything else, the Mapping tab is enough.

## The Mapping tab has two sub-tabs (and they have the same name)

A small UI quirk worth flagging: the device's **Mapping** tab is itself divided into two sub-tabs, **Topic** and **Mapping**. When you tap the outer **Mapping** tab, you land on the **Topic** sub-tab — that's where the Device ID Topic field lives. To reach the connector-key rows, tap **Next** at the bottom or click the inner **Mapping** label directly.

Users who fill in the Topic sub-tab and then tap Save without visiting the inner Mapping sub-tab end up with a device that has no telemetry mappings. The outer "Mapping" name is the headline; the inner "Mapping" sub-tab is where the actual key matching happens.

## Connector Key dropdown is empty until your device publishes once

When you reach the inner Mapping sub-tab and start adding rows, the **Connector key** column is a dropdown — and the first time you open it on a brand-new device, it's empty.

That's intentional. The dropdown lists keys that have actually arrived from your device's payload. Before the first publish, Chirp doesn't know what keys your device sends, so the list is empty.

The setup flow is therefore two-pass:

**Pass 1 — set up the rows without Connector keys:**

1. Add a row for each metric you want to track.
2. Pick the **Normalized key** from the templates dropdown (this is the platform-side metric — Temperature, Humidity, Battery Level, etc.). If the metric you need doesn't exist yet, use **+ Add new metric** to create one. (One-time aside: the **+ Add new metric** modal handles two things behind the scenes — it ensures the normalized name exists *and* creates the sensor template that makes it appear in this dropdown. Pre-creating names elsewhere isn't necessary.)
3. Set the **Data type** (see below).
4. Leave **Connector key** empty.
5. Tap **Save**. The device record is now stored.

**Pass 2 — match keys to rows after data is flowing:** 6. Confirm your device is publishing — for Z2M, check that the container is running and the device has reported at least once. Easy way: drag the slider in the Z2M web UI for the device, or send a `/get` poll. Either generates a publish. 7. Reopen the device record. The **Connector key** dropdown now lists the actual keys received from your device. 8. Match a key to each mapping row. 9. Tap **Save** again.

After the second save, future incoming readings for those mapped keys will populate the Logs tab and be available for dashboards, alarms, and the AI assistant.

### Mapping is iterative — return after data arrives

Even after a clean two-pass save, MQTT mapping often isn't done. Devices can publish keys you didn't anticipate during the first pass, and you may notice useful fields only once you see the live payload. Treat the Mapping tab as something you come back to:

* After the device has been publishing for a while, reopen the device record in Chirp.
* Look at the **Connector key** dropdown and the **Value** column — they tell you exactly what's arriving.
* Add a row for any extra field you'd like to track.
* Pick the right **Normalized key** and **Data type** for each new row.
* Save.
* Generate one more publish (drag a slider in the Z2M web UI, send a `/get` poll, or wait for the device's next scheduled report) so the Logs tab starts collecting history for the new mappings.

This second-look pattern is normal, not a sign that the original setup was wrong. The most common reason to revisit is discovering that a device exposes a useful field you didn't know about until you saw real data.

## Reported State vs Telemetry vs Device Metadata

The **Data type** column is where you tell Chirp what kind of value is coming in:

* **Reported State** — controllable device properties. Things the device can also be commanded to change: a bulb's `state` (ON/OFF), `brightness`, `color_temp`, a smart plug's `power_state`. These describe what the device *is* right now.
* **Telemetry** — read-only measurements. Things the device only reports, never commanded: `temperature`, `humidity`, `linkquality`, `battery`, `pressure`. These describe what the device *observes*.
* **Device Metadata** — values that describe the device itself rather than its readings. Firmware version, hardware model. Less commonly needed.

Pick the type by what the value *means* operationally — not by the metric template type (Integer/Float/String/Boolean), which is fixed by the template.

## A note on `state`: it's a string, not a boolean

For Zigbee2MQTT devices that have an on/off field, the payload sends `"ON"` or `"OFF"` as **strings**, not booleans. That means:

* The metric template Type for `state` must be **String**, not Boolean.
* If you use `+ Add new metric` to create a "State" metric, pick String as the type.
* If you accidentally pick Boolean, you'll see null values in the Mapping tab — Chirp can't parse `"ON"`/`"OFF"` strings into a boolean field.

The full Z2M-feature-type → Chirp-Type mapping:

| Z2M feature type | Chirp Type                                     |
| ---------------- | ---------------------------------------------- |
| `binary`         | **String** (values are `"ON"`/`"OFF"` strings) |
| `numeric`        | **Number**                                     |
| `enum`           | **String**                                     |
| `text`           | **String**                                     |

## Why the Mapping tab Value column updates but the Logs tab is empty

Final concept worth understanding before you finish your first device. After Pass 2, you save, and:

* The **Value** column in the Mapping tab fills in immediately with whatever the device's most recent payload contained.
* The **Logs** tab is still empty.

This isn't a bug. The Value column is a live snapshot of the latest payload — it's there as soon as the topic match works, regardless of whether you've finished setting up Connector keys. The Logs tab is per-sensor history, and it's populated only by publishes that arrive *after* you save Connector keys.

So if your last publish was before Pass 2, that publish doesn't appear in Logs. The fix is to generate a fresh publish: drag a control in the Z2M web UI, send a `/get` poll, or wait for the device's next scheduled report. From that publish onwards, every reading flows into the Logs tab.

## Where to go next

* [Troubleshooting](/connectors/mqtt-connector/troubleshooting) — When the topic match isn't working, when Logs stay empty after a fresh publish, and how to force a publish on a device that isn't reporting on its own.
* [Setting up Zigbee2MQTT](/connectors/mqtt-connector/zigbee2mqtt) — If you haven't installed Z2M yet, this is the source of the topics you're matching here.


# Setting up Zigbee2MQTT

Install Zigbee2MQTT to bridge your Zigbee bulbs and sensors into Chirp through the MQTT connector.

Zigbee2MQTT (Z2M) is the bridge between your Zigbee devices and your MQTT broker. Devices speak Zigbee — a low-power radio protocol — to a USB or network-attached coordinator. Z2M is the software, running on the same machine as the coordinator, that turns each Zigbee message into an MQTT publish. Once Z2M is running, every Zigbee sensor and bulb in your home becomes an MQTT publisher, and Chirp's MQTT connector picks it up like any other MQTT device.

This page is the generic Zigbee2MQTT setup. We worked through it with a Sonoff ZBDongle-E coordinator and a Paulmann 50064 bulb, but Z2M supports thousands of coordinators and devices — anything in the [supported devices list](https://www.zigbee2mqtt.io/supported-devices/) follows the same flow. If you have the exact hardware we tested, the [Sonoff ZBDongle-E walkthrough](/gateways/zigbee2mqtt-hubs/sonoff-zbdongle-e-coordinator) and the [Paulmann 50064 walkthrough](/devices/tested-device-guides/zigbee/paulmann-50064-light-bulb) drop you into the specifics. Otherwise, follow this generic setup and consult your hardware's manufacturer for pairing details — the rest is identical.

## What runs where

A small mental-model warning, because this confuses a lot of people first time around: **the coordinator is the radio bridge, not the brain.**

* **USB coordinators** (Sonoff ZBDongle-E, ZBDongle-P, SkyConnect, ConBee II, etc.) — radio chip plus firmware, communicating with your machine over USB serial using a binary protocol like EZSP or Z-Stack. They have no IP stack, no Wi-Fi, no Ethernet, no operating system.
* **Network-attached coordinators** (SMLIGHT SLZB-06 and similar) — the same radio role, but with a small embedded Linux that exposes the coordinator over Ethernet or Wi-Fi. They have an IP interface for transport, but they don't run MQTT — Z2M still does that.

In both cases, the coordinator handles the Zigbee radio plus protocol-to-transport bridge; **Zigbee2MQTT is the software** that opens the coordinator's transport (serial port for USB, TCP for network-attached), sends Zigbee commands, receives Zigbee messages, translates them to JSON, and publishes them to MQTT. All the device-management intelligence lives in Z2M.

```
Zigbee device → [Zigbee radio]
                    ↓
                Coordinator (radio + firmware, plugged into your machine)
                    ↓
                /dev/ttyUSB0 (or network port for SLZB-06 etc.)
                    ↓
                Zigbee2MQTT (running on your machine)
                    ↓
                MQTT (TCP/TLS to your broker — Chirp Cloud or your own Mosquitto)
                    ↓
                Chirp
```

Practical implication: stop the Z2M container or unplug the host machine and your Zigbee devices stop reaching MQTT, even though their LEDs may still be on and the radios are still healthy. Z2M is the active link.

## What you need

* A **machine that's always on** with a USB port (or a network-attached coordinator on your LAN). A Raspberry Pi, a small home server, an old laptop, an Intel NUC — anything Linux-based works fine. Z2M can also run on macOS or Windows but Docker on Linux is the most common deployment.
* **A Zigbee coordinator.** Any [supported coordinator](https://www.zigbee2mqtt.io/guide/adapters/) — Sonoff ZBDongle-P or ZBDongle-E, SMLIGHT SLZB-06, ConBee II, SkyConnect, etc.
* **Docker and Docker Compose** installed on the host machine. (Z2M has other deployment options, but Docker is the simplest and what we'll use here.)
* **An MQTT broker** to publish to — either a [Cloud MQTT connector](/connectors/mqtt-connector/cloud-mqtt) from Chirp, or your own broker via [External MQTT](/connectors/mqtt-connector/external-mqtt).

## Step 1 — set up the working directory

On the host machine:

```bash
mkdir -p ~/zigbee2mqtt/data
cd ~/zigbee2mqtt
```

You'll create two files in here: a `docker-compose.yml` and the Z2M `configuration.yaml`.

## Step 2 — confirm the coordinator is detected (USB coordinators)

For USB-attached coordinators, plug the dongle in (use the included extension cable if there is one — the metal of your computer chassis attenuates 2.4 GHz signal, and the cable physically moves the antenna away from interference) and check that Linux sees it:

```bash
ls /dev/tty* | grep -E "USB|ACM"
```

You should see `/dev/ttyUSB0` (for CP210x-based dongles like the Sonoff series) or `/dev/ttyACM0` (for some other adapters). If multiple USB serial devices are plugged in, your coordinator will be the highest-numbered one — note which path is yours, you'll need it in `configuration.yaml`.

```bash
lsusb | grep -i "silicon\|zigbee\|conbee"
```

This shows the chip — useful when you're not sure which dongle variant you have. For Sonoff dongles specifically, both ZBDongle-P and ZBDongle-E show as `Silicon Labs CP210x UART Bridge` on `lsusb`, so you must check the packaging or the label on the dongle body to tell them apart.

For network-attached coordinators (SLZB-06, etc.), there's no `/dev/tty*` device — instead you'll use a `tcp://` URL in `configuration.yaml`.

## Step 3 — `docker-compose.yml`

`~/zigbee2mqtt/docker-compose.yml`:

```yaml
services:
  zigbee2mqtt:
    image: koenkk/zigbee2mqtt:latest
    container_name: zigbee2mqtt
    restart: unless-stopped
    volumes:
      - ./data:/app/data
      - /run/udev:/run/udev:ro
    ports:
      - "8080:8080"
    environment:
      - TZ=Etc/UTC
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0
```

A few details that aren't obvious:

* `./data:/app/data` is where Z2M reads `configuration.yaml` and writes its device database. Persisting this directory means paired devices and settings survive container restarts.
* `/run/udev:/run/udev:ro` — without this, Z2M can fail to auto-detect the adapter on some systems. Read-only because Z2M only needs to query udev, not modify it.
* `devices: /dev/ttyUSB0:/dev/ttyUSB0` passes the USB coordinator into the container. Docker handles the permissions, so you don't need to add your user to the `dialout` group on the host.
* For network-attached coordinators, omit the `devices:` mapping — Z2M will use the `tcp://` URL from `configuration.yaml`.

If your coordinator is at a different path (e.g. `/dev/ttyACM0`), update both sides of the `devices:` mapping.

## Step 4 — `configuration.yaml`

`~/zigbee2mqtt/data/configuration.yaml`:

```yaml
homeassistant: false
permit_join: false

mqtt:
  base_topic: iot/{your-org-segment}/{your-connection-segment}/zigbee2mqtt
  server: mqtts://mqtt-iot.chirpwireless.io:1884
  user: {username from Chirp}
  password: {password from Chirp}

serial:
  port: /dev/ttyUSB0
  adapter: ezsp

advanced:
  log_level: debug
  channel: 11

frontend:
  enabled: true
  port: 8080
```

Three settings deserve attention:

* **`adapter: ezsp` vs `adapter: zstack`** — this tells Z2M what kind of radio chip your coordinator has. **Sonoff ZBDongle-E (EFR32MG21/MG24)** uses `ezsp`. **Sonoff ZBDongle-P (CC2652P)** uses `zstack`. They look almost identical externally and have the same USB ID, but the protocol is different. Picking the wrong one logs `Error: Failed to find adapter` and Z2M exits. For other adapters, see the [Z2M adapter guide](https://www.zigbee2mqtt.io/guide/adapters/).
* **`log_level: debug`** — leave this on while you're setting things up. At `info` level, Z2M doesn't log MQTT publish lines, which makes it impossible to tell whether the broker connection is working. Switch back to `info` once everything is verified.
* **`channel: 11`** — Zigbee shares the 2.4 GHz band with Wi-Fi. Channels 11, 15, 20, and 25 are commonly chosen because they reduce overlap with the most-used Wi-Fi channels (1, 6, 11). They are not perfectly non-overlapping, but they're the safer starting points if your Wi-Fi uses default channels. **You can't change the Zigbee channel later without re-pairing every device**, so pick once and don't change it.

For External MQTT, the `mqtt:` section is simpler — see [External MQTT](/connectors/mqtt-connector/external-mqtt) for the configuration. The rest of `configuration.yaml` is identical.

## Step 5 — start Z2M

```bash
cd ~/zigbee2mqtt
docker compose up -d
docker compose logs -f zigbee2mqtt
```

You're looking for these lines, in roughly this order:

```
z2m: zigbee-herdsman started (reset)
z2m: Coordinator firmware version: ... type EZSP v13
z2m: Currently 0 devices are joined.
z2m: Connecting to MQTT server at mqtts://mqtt-iot.chirpwireless.io:1884
z2m: Connected to MQTT server
z2m:mqtt: MQTT publish: topic '.../bridge/state', payload '{"state":"online"}'
z2m: Started frontend on port 8080
z2m: Zigbee2MQTT started!
```

The first MQTT publish line is your end-to-end signal: Z2M's bridge announced itself online, the broker accepted it, and Chirp will see the message arrive. You can verify on the Chirp side too — open the connector's detail page and check **Last data received**. Within a few seconds of Z2M starting, this field updates with a timestamp.

If you don't see those log lines, the most common causes are:

* `Error: Failed to find adapter` → wrong `adapter:` value or wrong serial port. Re-check `serial.port` and `serial.adapter`.
* `Error: Failed to connect to MQTT broker` → wrong server URL, credentials, or port. Re-copy the four credentials from Chirp; check for trailing whitespace.
* `SSL handshake failed` → TLS issue. Add `ssl: true` under `mqtt:` and restart.
* `Authentication failed` → wrong username or password. Rotate the connector's credentials in Chirp and update `configuration.yaml`.

### What to expect on first start

Z2M does two things the first time it boots that can look like errors but aren't:

* **It rewrites your `configuration.yaml`.** Z2M reformats the YAML and adds a `version: 5` line at the bottom. Your values are preserved exactly — only formatting changes. Long single-line strings may be wrapped using YAML block-scalar notation (`>-`), which is functionally identical to the original.
* **It creates migration log files** in `~/zigbee2mqtt/data/` named `migration-1-to-2.log` through `migration-4-to-5.log`. These are Z2M's internal config-schema migrations between its own versions. Normal — no action needed.

If you see your `configuration.yaml` looking different after first boot, that's why. The migration logs can be safely ignored.

## Step 6 — open the Z2M web UI

Z2M ships with a small web interface. Open `http://localhost:8080` (or the IP of your host machine + port 8080 if you're remote). No login by default.

Key things you'll use it for:

* **Permit join** — the green shield icon at the top opens the Zigbee network for new devices to pair (180 seconds at a time).
* **Devices** — list of paired devices, with their IEEE addresses, friendly names, models, and link quality.
* **Logs** — the same output as `docker compose logs -f` but in the browser.
* **Per-device controls** — clicking a device opens a panel where you can rename it, see its current state, and (for actuators like bulbs and plugs) toggle / dim / change settings. These controls publish MQTT `/set` commands, which is also how you can generate a fresh publish during setup-time verification — drag a slider, the bulb confirms the new state, and Z2M re-publishes the payload that Chirp consumes.

## Step 7 — pair your first device

Pairing is device-specific. Generic pattern:

1. In the Z2M web UI, click **Permit join (All)** — the green shield. The Zigbee network is open for 180 seconds.
2. Put your Zigbee device into pairing mode. **The procedure varies by device** — consult the manufacturer's manual or the device's [Z2M page](https://www.zigbee2mqtt.io/supported-devices/). Common patterns:
   * Bulbs: power-cycle 5 times in a row (on/off/on/off/on/off/on/off/on, \~2 seconds each). Many bulbs flash on the 5th on-cycle to signal pairing mode — when they do, **stop cycling and leave them on**.
   * Battery sensors: hold a small reset button (often inside a battery compartment) for 5–10 seconds.
   * Wall-plugs: hold the physical button for 5+ seconds.
3. Within 10–30 seconds, Z2M's web UI shows the device in the Devices list, identified by its IEEE address (`0x...`).
4. Z2M auto-identifies the model from its built-in device database — for most devices, you'll see the brand and model name in the Devices list immediately.

If pairing fails: the 180-second window may have closed (click Permit join again), or the device may already be paired to a previous network and need a factory reset first. Some bulbs need a full reset before they'll accept a new network — see the manufacturer's instructions, or the [Paulmann 50064 walkthrough](/devices/tested-device-guides/zigbee/paulmann-50064-light-bulb) if that's what you're pairing.

## Step 8 — give the device a friendly name

When a device pairs, its initial friendly name is its IEEE address (something like `0x00158d0001abc123`). Rename it to something readable — that name becomes both the device-level MQTT topic Z2M publishes to AND the Device ID you'll enter in Chirp.

In the Z2M web UI:

1. Click the device in the Devices list.
2. Click the pencil icon next to the name.
3. Type a new name. **Avoid spaces** — they cause silent mismatch with Chirp's Device ID input. Use CamelCase (`LivingRoomSensor`) or snake\_case (`living_room_sensor`). Don't use `/`, `#`, or `+` (those are MQTT-reserved characters).
4. Press Enter.

After renaming, Z2M publishes to `{base_topic}/{newName}` immediately. The IEEE-address topic stops receiving data.

## Step 9 — register the device in Chirp

The device is now publishing JSON payloads on a topic like `iot/{org}/{conn}/zigbee2mqtt/LivingRoomSensor` (Cloud MQTT) or `zigbee2mqtt/LivingRoomSensor` (External MQTT). Now register it in Chirp.

The full registration flow — the Mapping/Topic sub-tabs, byte-for-byte Device ID, the Connector key two-pass save, the Reported State vs Telemetry choice — is on [Topics and device routing](/connectors/mqtt-connector/topics-and-device-routing). That's the next page to read.

## Where to go next

* [Topics and device routing](/connectors/mqtt-connector/topics-and-device-routing) — register the device.
* [Sonoff ZBDongle-E coordinator walkthrough](/gateways/zigbee2mqtt-hubs/sonoff-zbdongle-e-coordinator) — if you have this exact dongle and want the physical-install detail.
* [Paulmann 50064 light bulb walkthrough](/devices/tested-device-guides/zigbee/paulmann-50064-light-bulb) — if you have this exact bulb and want the pairing-procedure detail.
* [Troubleshooting](/connectors/mqtt-connector/troubleshooting) — when something isn't working.


# Troubleshooting

Fix MQTT data that isn't reaching Chirp — empty Logs, topic mismatches, and devices that won't publish.

When MQTT data isn't reaching Chirp, the failure is almost always at one of three places: Z2M-to-broker, broker-to-Chirp, or Chirp's device routing. This page walks through each in order — the same order to use when diagnosing — plus the two patterns that catch out almost every first-time MQTT user (empty Logs tab, no publish from a wall-switch toggle).

**Start by letting Chirp narrow it down for you.** Open the device's **Connection** tab and read its diagnostics — they say whether messages are arriving, whether Chirp understood them, and whether they're being saved, which usually points straight at the right phase below. See [Connection Diagnostics](/devices/connection-diagnostics). For the connector itself, its **Connector diagnostics** area has **Source health**, **Incoming**, and **Activity** tabs — the fastest way to tell a broker problem from a single misbehaving device.

## Phase 1 — Z2M is not connecting to the broker

**Symptoms:** Z2M container is running, but the connector's **Last data received** in Chirp never updates. No `MQTT publish` log lines from Z2M.

Check `docker compose logs zigbee2mqtt` for one of these:

| Log line                                   | Cause                                                                  | Fix                                                                                                                                                                                                                                                    |
| ------------------------------------------ | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `Error: Failed to find adapter`            | Wrong `adapter:` value in `configuration.yaml`, or wrong `serial.port` | For Sonoff ZBDongle-E (EFR32MG24): `adapter: ezsp`. For ZBDongle-P (CC2652P): `adapter: zstack`. Check the dongle packaging or label — the USB ID is the same for both. Verify `serial.port` matches the actual `/dev/ttyUSB*` device (\`ls /dev/tty\* |
| `Error: Failed to connect to MQTT broker`  | Wrong server URL, port, or credentials                                 | Re-copy all four credentials from Chirp's connector page. Check for trailing whitespace — `\n` at the end of a copied password is a common cause. Verify the port is **1884** for Cloud MQTT (not the default 1883).                                   |
| `SSL handshake failed`                     | TLS negotiation issue                                                  | Add `ssl: true` under the `mqtt:` section of `configuration.yaml` and restart Z2M.                                                                                                                                                                     |
| `Authentication failed`                    | Wrong username or password                                             | If the password was lost, rotate the credentials from Chirp's connector settings, then update `configuration.yaml` with the new password.                                                                                                              |
| (no MQTT lines, but connection looks fine) | `log_level: info` is hiding publish events                             | Change to `log_level: debug` in `configuration.yaml` and restart Z2M. The `MQTT publish` lines are only logged at debug.                                                                                                                               |

The first MQTT message Z2M sends is its bridge state announcement (`{base_topic}/bridge/state`, payload `{"state":"online"}`). If you see that line in the logs, Z2M is connected and the broker accepted the connection. From there, problems are downstream.

## Phase 2 — Z2M is publishing but the connector's Last data received doesn't update

**Symptoms:** Z2M log shows `MQTT publish: topic '...' payload '...'` lines, but Chirp's connector page shows **Last data received** is still empty.

This is rare — if the Z2M side is publishing successfully on a topic that starts with the right Topic prefix, the broker accepts it. Things to verify:

* **Topic prefix matches.** Z2M's `base_topic` must start with the exact Topic prefix Chirp gave you. For Cloud MQTT, that's `iot/{org}/{conn}/zigbee2mqtt` — the first three segments must match exactly what Chirp's connector page shows.
* **The connector is the right one.** If you have multiple Cloud MQTT connectors, double-check which one Z2M is configured against. The Topic prefix is unique per connector.
* **External MQTT only — Chirp can reach your broker.** External MQTT is the case where this can genuinely fail for network reasons. Even after publishing locally to your Mosquitto broker, the message reaches Chirp only if Chirp can dial out to your broker's public address. Run a one-shot test publish from `mosquitto_pub` against the public address (your ngrok TCP endpoint or DDNS hostname) — see [External MQTT](/connectors/mqtt-connector/external-mqtt) for the test command. If the local broker accepts it but Chirp's **Last data received** stays empty, the public reachability is the problem (firewall, expired ngrok session, wrong port forward).

## Phase 3 — Last data received updates but the device's Mapping tab is empty

**Symptoms:** The connector shows recent Last data received timestamps, but when you open a registered device, the Mapping tab's Value column is empty and nothing's coming in.

This is a device-routing problem inside Chirp. The connector is receiving messages but they're not matching the device record.

* **Device ID Topic pattern doesn't match the published topic.** Z2M publishes to `zigbee2mqtt/{friendlyName}` (after Chirp strips the prefix). The Device ID Topic field must be `zigbee2mqtt/{{deviceId}}` — exactly. Common mistakes: leading slash, missing the `zigbee2mqtt/` prefix, an extra path segment that the published topic doesn't have.
* **Device ID is byte-for-byte different from the friendly name.** This is the single most common cause. Chirp's Device ID input strips whitespace, so a Z2M friendly name with spaces (`Living Room Sensor`) won't match a Device ID typed with the same spaces — Chirp stored a different string. The fix: rename the device in Z2M to a whitespace-free name (`LivingRoomSensor`), and use the same exact string in Chirp's Device ID field. Capitalisation is preserved and significant — `LivingRoomSensor` and `livingroomsensor` are different.

Verify what Z2M is publishing right now:

```bash
docker compose logs zigbee2mqtt | grep "MQTT publish" | grep -v bridge | tail -5
```

The topic in those lines is what your Device ID Topic and Device ID need to match against.

## Phase 4 — Mapping tab Value column updates but Logs tab is empty

**Symptoms:** Open a registered device, the Mapping tab shows live values and Last update timestamps, but the Logs tab stays empty even after toggling the device. The most common cause of "is this thing broken?"

It's not broken. The two tabs read different things:

* **Mapping tab Value column** = a live snapshot of the most recent payload. Updates on every accepted publish, regardless of whether you've finished setting up Connector keys.
* **Logs tab** = per-sensor history. Populated only by publishes that arrive *after* you've saved Connector keys for that sensor.

If the most recent publish happened before you saved Connector keys, that publish never reaches Logs — only future publishes will. The fix is to **generate a fresh publish**.

For a Zigbee device the cleanest way is to use the Z2M web UI:

1. Open `http://localhost:8080`.
2. Click your device.
3. Drag a control — the brightness slider on a bulb, the on/off toggle on a plug, etc.

Z2M sends a `/set` command, the device confirms the new state, and Z2M publishes the confirmed payload back. That publish flows through Chirp into the Logs tab.

Alternatively, you can poll the device with a `/get` request via `mosquitto_pub` — useful when the device doesn't have a controllable state (a temperature sensor, for example).

## Phase 5 — physical wall-switch toggles don't generate publishes

**Symptoms:** You toggle the wall switch for a Zigbee bulb. The light comes on. The Logs tab still shows nothing.

Many Zigbee CCT bulbs (the Paulmann 50064 confirmed; many other brands behave the same) **don't send an MQTT publish on a physical power-cycle**. The bulb's firmware only reports state changes that came in over Zigbee — not changes caused by the wall switch.

Actions that **do** generate a publish:

| Action                                                                           | Notes                                                                                                                                                                                                         |
| -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Drag a control or click the toggle in the Z2M web UI                             | Z2M sends `/set` over Zigbee, bulb confirms, Z2M publishes the new state. The cleanest setup-time check.                                                                                                      |
| `mosquitto_pub` to `{base_topic}/{friendlyName}/get` with `{"state":""}` payload | Forces Z2M to poll the bulb for current state and publish what it reads back. Useful for non-controllable devices and for forcing a publish on demand. Local Z2M-side verification, not a Chirp control path. |
| Wait for the device's next scheduled report                                      | Battery sensors typically wake on a schedule (every 5 minutes, every hour, etc.). Mains-powered bulbs without state-change reporting won't publish unless commanded.                                          |

## Forcing Z2M to publish: the `/get` command

The `/get` request is the tool of last resort when you need a current-state publish from a device that won't generate one on its own. Send a JSON payload with empty strings as values for the keys you want the bulb to report:

```bash
docker run --rm eclipse-mosquitto:2 mosquitto_pub \
  -h mqtt-iot.chirpwireless.io \
  -p 1884 \
  --cafile /etc/ssl/certs/ca-certificates.crt \
  -u {your-cloud-mqtt-username} \
  -P '{your-cloud-mqtt-password}' \
  -t "iot/{org}/{conn}/zigbee2mqtt/{friendlyName}/get" \
  -m '{"state":"","brightness":"","color_temp":""}'
```

(Use your actual Cloud MQTT credentials and connection prefix. For External MQTT, replace the broker host/port/auth with your local broker's settings, and use `zigbee2mqtt/{friendlyName}/get` as the topic with no prefix.)

Z2M sends ZCL read requests to the bulb and publishes one or more responses with the current state. One `/get` can produce 2–4 publishes back as Z2M polls different attribute clusters in sequence — that's normal.

This is local Z2M-side verification — it generates a publish that Chirp consumes. It's not a Chirp API control surface.

## When a Zigbee device won't pair at all

Pairing failures are entirely a Z2M / coordinator / device problem — Chirp isn't involved. The usual culprits:

* **Permit join is closed.** The 180-second window has expired. Click Permit join again in the Z2M web UI.
* **Device is already paired to another network.** Many Zigbee devices remember the last network they joined. Factory-reset the device first (procedure varies — check the manufacturer's instructions or the device's [Z2M page](https://www.zigbee2mqtt.io/supported-devices/)).
* **Coordinator range too short.** Move the device within 1–2 meters of the coordinator for initial pairing. After joining, Zigbee mesh routing handles distance — but the first join needs proximity.
* **Wrong reset procedure.** Different devices need different reset sequences. Bulbs often require a 5×-power-cycle pattern. Sensors usually have a small button. Always follow the manufacturer's guide.

For the Paulmann 50064 specifically, see the [tested device guide](/devices/tested-device-guides/zigbee/paulmann-50064-light-bulb) — the 5×-cycle-then-stop procedure is documented there with the timing details.

## Resetting Cloud MQTT credentials

If the Cloud MQTT password is lost or compromised:

1. Open the connector in Chirp.
2. In edit mode, regenerate the password.
3. Copy the new password.
4. Update Z2M's `configuration.yaml` (`mqtt: password:`).
5. Restart the Z2M container: `docker compose restart zigbee2mqtt`.

The username and Topic prefix don't change on rotation.

## Where to go next

* Back to [Topics and device routing](/connectors/mqtt-connector/topics-and-device-routing) — to confirm the Device ID Topic pattern and friendly-name rules.
* [External MQTT](/connectors/mqtt-connector/external-mqtt) — for broker-side issues with self-hosted brokers.
* [Setting up Zigbee2MQTT](/connectors/mqtt-connector/zigbee2mqtt) — to recheck the Z2M install.


# Emulator Connector

Try Chirp before your sensors arrive — pretend sensors that make up their own readings, so your dashboards and alerts are ready on day one.

You have ordered a leak sensor. It arrives on Thursday. Until now there was nothing to do until then — no dashboard to arrange, no alert to set up, nothing to look at.

The Emulator fixes that. It gives you **pretend sensors that invent their own readings**, so you can lay out your dashboard, write your alerts, and watch them actually go off — days before anything turns up in the post. And when the real sensor does arrive, you point that same device at it and keep everything you set up.

<figure><img src="/files/ShhXmqjaK2wKMdfZ8YIf" alt="The Connectors page in Chirp showing an Emulator connection alongside Tracker and LoRaWAN"><figcaption></figcaption></figure>

## Why you would use it

* **To try Chirp properly before buying anything.** Set up the home you are thinking about and see whether it works the way you want.
* **To get everything ready while you wait for delivery.** The fiddly part of a new sensor is not sticking it to the wall — it is deciding what should happen when it reads something. Do that first.
* **To test an alert without ruining a Sunday.** Want to know your leak alert really reaches your phone? You do not have to pour water on the floor. Type the number and watch it fire.

## Setting it up

Go to **Connectors → Add connector** and pick **Emulator**. That's it — there is nothing to fill in, no account to link, no code to copy. One per home.

## Then make a pretend sensor

Everything else happens on the sensor itself, not here. Once the connection exists you add a sensor, point it at the Emulator, choose what it measures, and drive its readings from its own **Emulator** tab.

**See** [**Pretend Sensors**](/devices/pretend-sensors) for the whole thing: making one, picking a real sensor model, sending a reading to test an alert, and switching it over to the real sensor when it turns up.

## See also

* [Pretend Sensors](/devices/pretend-sensors) — make one, and make it send something
* [Adding Sensors](/devices/adding-sensors) — the normal way, once your hardware is here
* [Rules Engine](/rules-engine) — the automations you can now build early
* [Alarms](/alarm) — and the alerts you can finally test properly


# Devices

Every sensor in your home gets its own profile — name, photos, readings, and full history in one place.

Every sensor you add to Chirp gets its own profile — a complete record of its name, connection, measurements, photos, and full data history. Even when a sensor sleeps between transmissions, its profile keeps everything organized and ready for your dashboards and automations.

<figure><img src="/files/m9T0Y4fivfmat2lrZfif" alt="Chirp Sensors page showing the list of connected devices with their status and latest readings"><figcaption><p>The Sensors page lists every device connected to your home</p></figcaption></figure>

From here you can add new sensors, configure how they report data, organize them into rooms, and manage their details over time.

## What's in this section

* [Adding Sensors](/devices/adding-sensors) — register a sensor and map what it measures
* [Pretend Sensors](/devices/pretend-sensors) — get set up before your hardware arrives
* [Data Templates](/devices/data-templates) — what your readings mean, with the right units
* [What Your Device Is Sending](/devices/what-your-device-is-sending) — see the fields your sensor reports, and what they say
* [Sensor Details](/devices/sensor-details) — live readings, settings and full history
* [Connection Diagnostics](/devices/connection-diagnostics) — added a sensor but nothing's showing up?
* [Rooms](/devices/rooms) — group sensors by where they are
* [Favorite Devices](/devices/favorite-devices) — star the ones you check most
* [Controlling Your Devices](/devices/commands) — turn things on and off, not just watch them
* [Tested Device Guides](/devices/tested-device-guides) — sensors we've paired end-to-end ourselves


# Adding Sensors

Register a LoRaWAN, tracker, MQTT or pretend sensor in Chirp and map its readings, step by step.

Every sensor you add to Chirp gets its own profile — a record that remembers the sensor's name, connection details, measurement settings, and full data history. Even when a sensor goes to sleep between transmissions, its profile keeps everything organized and ready for dashboards and automation. Because the physical sensor binding is optional, you can create and configure a sensor profile before the actual hardware is connected — so you can plan your setup first and plug in the sensors when you're ready.

## Before you start

You'll need:

* **A connection** set up — an LNS connection for LoRaWAN sensors, a Tracker connection for vehicle trackers, an MQTT connector (Cloud or External) for Zigbee2MQTT and other MQTT-publishing hardware, or an Emulator connection if your sensor hasn't arrived yet. See [Setting Up a Connection](/connectors/setting-up-a-connection) and the [MQTT Connector](/connectors/mqtt-connector) docs.
* **Your sensor's identifiers** — for LoRaWAN sensors: the **Device EUI** and **AppKey**, usually printed on the sensor or its packaging. For trackers: the **Unique ID** from the manufacturer. For MQTT sensors: the **device-level topic identifier** that the device publishes under — for Zigbee2MQTT this is the friendly name. The Device ID field in Chirp must match it byte-for-byte (no whitespace). A [pretend sensor](/devices/pretend-sensors) needs none of this — you choose its Device ID yourself, within the naming rules on that page.
* **For MQTT sensors only — the device must be publishing before you can finish mapping.** The Connector key dropdown in the Mapping tab is populated from payload keys actually received from the device. See the [MQTT-specific note](#a-note-for-mqtt-sensors) further down for the two-pass save flow.

## Where to add a sensor

There are several ways to start — they all open the same registration dialog:

* **Devices in the sidebar** — Click **Devices**, then click **Add device** in the top-right corner.
* **From a connection** — Open your LNS or Tracker connection, then click the **+** (Add device) button on the connection row, or open the connection and click **Add device** in the Connected Devices tab.

## Step 1 — Create the sensor profile

The dialog opens in Add mode, showing only the basic sensor info. No tabs or navigation are visible yet.

* **Device photos** — Snap a picture of the sensor so you can easily identify it later. Helpful when you have several similar-looking sensors.
* **Device name** — Give it a name that tells you what it is and where it is. "Kitchen Temperature" is much more useful than "Sensor 4."

Enter a name for your sensor and click **Save**. The profile is created and the dialog transitions to edit mode.

## Step 2 — Configure the connection and details

After the first save, the dialog reopens with **Device info**, **Connection**, **Metrics** and **Logs** tabs, and a **Next** button for navigating between them. Two more appear when they apply: **Commands & States** on a device you can switch on and off, and **Emulator** on a pretend sensor.

### Connection

Click the **Connection** tab to link your sensor to the thing that feeds it.

**For LoRaWAN sensors (LNS connection):**

1. Select your **LNS** connection from the **Connector type** dropdown (if you only have one, it may be pre-selected).
2. Enter the **Device EUI** — the unique identifier from your sensor's label (a string of hexadecimal characters, usually printed on the sensor or its packaging). Once entered and saved, this field locks to prevent accidental changes. Capital and lowercase letters are treated the same here, so it doesn't matter which your label uses — just copy it carefully.

   **Or skip the typing entirely.** Most sensors carry a QR code on the label or the box. Click **Scan QR code**, point your laptop or phone camera at it, and Chirp fills the identifiers in for you — no squinting at sixteen characters of hex, no transposed digits to hunt down later. If your device doesn't have a camera available, you'll see "QR code scanner is not found. Please try again." — just type the values in by hand instead.
3. Choose how to set up the sensor profile:

   **Option A: Use device profile templates** — Check the **Use device profile templates** box to select from a library of known sensors. This is the easiest approach if your sensor brand is in the library.

   * Pick the **Brand**, **Model**, and **Profile** from the dropdowns. These selections identify which template to load.
   * Once all three are selected, Chirp fetches the matching template and fills in the sensor's settings automatically — including the LoRaWAN class, frequency band, and a **codec** (the decoding logic that translates the sensor's raw data into readable fields).

   Templates are provided as convenience helpers. If a template's codec doesn't produce the correct readings for your sensor — for example, if values look wrong or fields are missing — you can edit the **Code functions** field directly (see below).

   **Option B: Manual setup** — Leave the checkbox unchecked to enter details yourself:

   * **Class** — Choose the LoRaWAN device class:
     * **Class A** — The sensor sleeps between transmissions and only briefly wakes to listen for responses. This is extremely power-efficient — most battery-powered home sensors use Class A and can run for years on a single battery.
     * **Class C** — The sensor keeps its receiver on continuously, so it can receive commands from Chirp at any time. Because the radio is always listening, Class C sensors use significantly more power and are typically plugged into mains power. Choose Class C for devices that need to respond to commands instantly, such as smart switches or displays. A Class C sensor gets a **Commands & States** tab so you can control it — see [Controlling Your Devices](/devices/commands).
   * **Brand** and **Model** — Type the sensor manufacturer and model name.
   * **Band** — Select the LoRaWAN frequency band for your region. Sensors purchased from a local supplier are almost always on the correct band already. Available options: EU868 (Europe), US915 (USA), AU915 (Australia), AS923 (Asia), KR920 (South Korea), IN865 (India), RU864 (Russia), CN470 (China), CN779 (China), EU433 (Europe 433 MHz), ISM2400 (2.4 GHz global). For a complete list by country, see [LoRaWAN Frequencies](/connectors/lns-connector/lorawan-frequencies).
   * **AppKey** — The encryption key for your sensor, typically found on the sensor's packaging or in its documentation.

#### Keep the identifiers somewhere safe

Once you've entered the sensor's identifiers, click **Add to Vault**. Chirp saves the EUI and its key together in your Key Vault, so you can look them up later without hunting for the box in the loft or unscrewing the sensor off the wall. For LoRaWAN sensors it stores the AppKey alongside the Device EUI.

It's worth doing at the moment you have the label in your hand — that's the one time the numbers are easy to get at. See [Key Vault](/reports/key-vault).

#### Code functions (codec)

The **Code functions** field contains the logic that decodes your sensor's raw data into readable fields. Think of it as a translator — your sensor sends its readings as compact binary data, and the codec turns that into named values like `temperature`, `humidity`, or `battery`.

When you pick a device profile template, this field is filled in automatically. If you set up manually, it starts empty — you may need to paste a codec from your sensor's manufacturer documentation.

If the readings in the Metrics tab don't look right after connecting your sensor — values seem wrong, some fields are missing, or names don't match what you expected — you can open this field and edit the code. The field is a text editor with a code-friendly monospace font.

#### Data sending interval

Every sensor sends on its own schedule — some every few minutes, some once a day, some once a month. That schedule is set **on the sensor itself**, and it differs from brand to brand: some sensors arrive with it already set by the manufacturer, others you set yourself when you install the sensor. The **Data sending interval** field is simply where you tell Chirp what that schedule is.

Set it to match how the sensor is actually configured to send. A sensor that reports once a day → **1 day**; once a month → **1 month**. The field starts at **1 hour** by default, but that's only a placeholder — Chirp has no way to know your sensor's real schedule, so replace it with the right value.

If nothing arrives within the interval, the sensor shows as offline in your sensor list and the Devices card on your home overview flags it. Getting this right is what stops a perfectly healthy sensor from looking offline just because it's quiet between its scheduled reports.

Pick a number and a unit: **minute**, **hour**, **day**, **week**, or **month**.

A [pretend sensor](/devices/pretend-sensors) is the exception: there is no hardware keeping a schedule, so this field *is* the schedule — Chirp sends on it.

**For vehicle trackers (Tracker connection):**

1. Select your **Tracker** connection from the **Connector type** dropdown.
2. Enter the **Unique ID** for your tracker.
3. Select a **Device model** by searching the tracker library.
4. A **Url for GPS tracker** panel appears — copy this URL and configure your tracker to send data to it.

**For MQTT sensors (Cloud or External MQTT):**

1. Select your **MQTT** connection from the **Connector type** dropdown.
2. Enter the **Device ID** — the device-level part of the topic your sensor publishes under. For Zigbee2MQTT that's the friendly name, and it has to match byte-for-byte.
3. Save, and let the sensor publish at least once before you map its readings — see [A note for MQTT sensors](#a-note-for-mqtt-sensors) below.

**For pretend sensors (Emulator connection):**

1. Select your **Emulator** connection from the **Connector type** dropdown.
2. Choose a **Device ID** — up to 64 characters (letters, numbers, spaces, dots, underscores, dashes), unique across all of Chirp. See [Pretend Sensors](/devices/pretend-sensors).
3. Say **how often it reports**, and either tick **Use device preset** to borrow a real model's readings or add them yourself.

Chirp then invents the readings for you, and an extra **Emulator** tab appears so you can push a value whenever you want to test something. This is how you get your dashboards and alerts working before the hardware arrives — and you can switch the same sensor over to the real one when it does. See [Pretend Sensors](/devices/pretend-sensors).

### Metrics

Click the **Metrics** tab to map your sensor's raw data to measurement definitions. If you selected a device profile template, the mappings may already be filled in. Otherwise, you can assign data templates manually here or come back to it later.

#### See what your sensor is sending

Once your sensor is connected and transmitting, the Metrics tab shows a live view of the raw data — a table listing every field your sensor sends, its current value, and when it last updated. You see exactly what's coming in, with the actual field names the sensor uses (like `t`, `hum`, `battery_mv`, or whatever the manufacturer chose).

Come back to this table any time you need to know what a device reports and how it words it — writing an automation condition, or setting up a check on a command. See [What Your Device Is Sending](/devices/what-your-device-is-sending).

#### Map raw fields to your data templates

This is where cryptic sensor output becomes something you can actually read. When you map a raw field like `t` to a data template called "Temperature" with the unit °C, Chirp starts displaying that reading as "Temperature (°C)" everywhere — in dashboards, automations, alerts, and history charts. You're giving each raw field a proper name, unit, and format.

To set up a mapping:

1. **Add a metric** — Click **Add key** and pick a data template from the dropdown (e.g., "Temperature", °C, Float). The Unit, Type, and Data type columns fill in automatically from the template. If you need a template that doesn't exist yet, create one in [Data Templates](/devices/data-templates).
2. **Choose the matching field** — In the **Connector key** dropdown, pick the raw field name that carries this measurement (e.g., pick `t` if your sensor sends temperature as `t`).
3. **Save** — The data starts flowing immediately through your dashboards, automations, alerts, and history.

If the Connector key is not filled in, the data for that metric will be ignored.

Add as many metrics as your sensor reports — you can map them all in one go.

#### Works with any sensor — even prototypes

This is not limited to sensors in Chirp's device library. If you're testing a prototype sensor that doesn't have a standard codec, a DIY sensor with custom firmware, or older hardware that sends cryptic field codes instead of readable names — it all works. As long as Chirp receives the data, you see the fields and map them.

For details on data templates, see [Data Templates](/devices/data-templates).

#### A note for MQTT sensors

Two things behave differently for sensors connected through the [MQTT connector](/connectors/mqtt-connector), worth knowing before you start mapping:

* **The Connector key dropdown is empty until your sensor has published at least once.** The dropdown lists keys actually received from your device. For a brand-new MQTT device, that means a two-pass save: add a row per metric and pick a normalized template, leave the Connector key blank, save, ensure your device is publishing, reopen the device — the dropdown now lists the payload keys, match each row, save again.
* **The Mapping tab Value column and the Logs tab show different things.** The Value column is a live snapshot of the most recent payload. The Logs tab is per-sensor history, populated only by publishes that arrive *after* you save the Connector keys. Older publishes don't fill in retroactively — generate a fresh publish (use a Z2M web UI control, send a `/get` poll, or wait for the device's next scheduled report — don't rely on a wall-switch toggle, which doesn't generate a publish on many Zigbee bulbs) after saving Connector keys to populate the Logs tab.
* **Mapping is iterative.** The first publish may reveal payload keys you didn't anticipate. Return to the device's Mapping tab whenever you want to add more fields — review the Connector key dropdown and Value column, add rows for the keys you missed, set the right Data type, save, and generate another publish so the Logs tab starts collecting history for the new mappings.

For full details, see [Topics and device routing](/connectors/mqtt-connector/topics-and-device-routing).

### Logs

The Logs tab is empty until your sensor starts sending data. Once it does, raw readings appear here grouped by timestamp.

Click **Save** again to persist the connection and metrics configuration.

## After saving

Your sensor's profile appears in the sensor lists throughout Chirp.

For LoRaWAN sensors, data starts flowing once the sensor powers on and connects to your gateway. For trackers, data flows once the physical device starts reporting to the URL you configured.

Worth knowing about that LoRaWAN connection: registering the sensor here sets Chirp up to recognize it, but the sensor still has to *join* the network itself before it sends anything. A sensor straight out of the box does that on its own the moment you power it up. A sensor with a past life — second-hand, inherited with the house, or previously set up on something else — is still joined to that old network and needs a reset before it will join yours. See [First things first: joining the network](/devices/connection-diagnostics#first-things-first-joining-the-network).

**Saved everything and still seeing no readings?** Don't start pulling batteries out. Open the sensor's **Connection** tab — Chirp will tell you exactly where the data has stopped and what to do about it. See [Connection Diagnostics](/devices/connection-diagnostics).

The registration dialog works comfortably on a phone, so you can add a sensor while you're standing at the spot where you're installing it.

## What's next

* **Customize data templates** if Chirp doesn't automatically recognize what your sensor measures. See [Data Templates](/devices/data-templates).
* **View and edit your sensor** anytime. See [Sensor Details](/devices/sensor-details).
* **Nothing showing up?** See [Connection Diagnostics](/devices/connection-diagnostics).


# Pretend Sensors

Make a pretend sensor in Chirp that invents its own readings, so your dashboards and alerts are ready before the real one arrives.

You have ordered a leak sensor. It arrives on Thursday. A pretend sensor lets you get everything ready in the meantime — lay out your dashboard, write your alerts, and watch them actually go off — days before anything turns up in the post.

A pretend sensor behaves like a real one in every way that matters. It appears in your sensor list, it reports on a schedule, its readings land on your dashboards, and your alerts fire off them. The only difference is where the numbers come from: Chirp makes them up instead of a device sending them.

<figure><img src="/files/s6gL7FxxGqzX2bgrifHF" alt="A pretend sensor set up from a real model, listing its readings and their value types"><figcaption></figcaption></figure>

## Before you start

You need an **Emulator** connection. It takes two clicks and there is nothing to fill in — no account to link, no keys to copy. See [Emulator Connector](/connectors/emulator-connector).

That's the whole list. No sensor, no gateway, no identifiers off the back of a box.

## Making one

Add a sensor as usual, then on its **Connection** tab choose **Emulator**. You will be asked for:

* **Device ID** — a name of your own, so you can tell your pretend sensors apart. Up to 64 characters, using letters, numbers, spaces, dots, underscores and dashes. It has to be unique across all of Chirp — not just your home — so something like `garage-temp-01` will be accepted where `sensor1` may already be taken.
* **How often it reports** — a number and a unit, like every 10 minutes. Match roughly what the real sensor will do, so your alerts behave realistically. Unlike a real sensor, this genuinely is the schedule — Chirp sends on it.
* **Support commands** — switch this on if you want to practise turning the thing on and off, not just reading from it. See [Controlling Your Devices](/devices/commands).
* **Use device preset** — the quick way. Pick a real sensor model and Chirp fills in the readings that model actually sends.

### Starting from a real sensor model

Tick **Use device preset** and pick from the list of real sensor models, and you get that model's genuine set of readings — a multi-sensor gives you temperature, humidity, CO2 and air quality, each with the right kind of value. It saves typing, and it means the names on your dashboard are the ones the real sensor will use when it arrives.

Worth knowing: picking a preset **replaces** anything you typed in by hand, including how often it reports. Choose the preset first, then adjust.

### Or type the readings yourself

Use **Add device data key** and give each reading a name — `temperature`, `humidity`, whatever you like — and say what kind of value it is. Pick **Float** for anything with a decimal point. A whole-number reading will quietly drop the decimals: type 1.5 and you get 1. See [Data Templates](/devices/data-templates) for how value types work.

## Making it send something

Open the sensor's **Emulator** tab and you will see each reading with a box next to it:

* **Save** parks a value there. The sensor keeps reporting it, which is how you hold the basement at 85% humidity while you check your damp alert behaves.
* **Send once** fires a single reading and goes back to normal. This is the one for "does my alert actually work?"

<figure><img src="/files/qSDmmgmVgcsERU1DcwVK" alt="The Emulator tab with a temperature value typed in, ready to send"><figcaption></figcaption></figure>

Sending a value counts as changing something, so a household member with view-only access can watch a pretend sensor but cannot push readings into it.

## When the real sensor arrives

Open the sensor, go to its **Connection** tab, and change it from **Emulator** to the real connection — then enter the details that came with it.

Everything else stays exactly as you left it: the dashboard, the widgets, the alerts, who gets told. You are swapping out where the numbers come from, nothing else. Your Thursday delivery becomes a five-minute job instead of an evening.

You can go the other way too, putting a real sensor back on the emulator for a moment if you want to test something without waiting for the house to cooperate.

## Copying one

Copying a sensor gets you part of the way, but not all of it — worth knowing before you set one up carefully and expect five free copies.

The copy arrives with the original's name, its reading rows, its connection and its photos. What it does **not** bring is the pretend setup itself: the readings it invents, how often it reports, and whether it accepts commands all go back to their defaults. Until you set those up again, the copy sits there quietly and sends nothing.

The mapping between raw fields and your data templates does not survive the save either, so redo that on the copy too.

See [Sensor Details](/devices/sensor-details).

## Just ask the helper

You do not have to do any of this by hand. Ask your [AI helper](/ai-assistant) to set up a pretend sensor and it will — choosing a model, creating the sensor, sending a reading to test an alert, and later taking it live onto your LoRaWAN connection. Asking the helper to switch a pretend sensor to a tracker or an MQTT sensor is the one part it cannot do for you; do that yourself on the Connection tab.

> *"Make a pretend temperature sensor for the garage and send a reading of 2 degrees."*

## What's next

* [Tracking What Matters](/dashboards/tracking-what-matters) — build the dashboard you have been waiting to build
* [Alarms](/alarm) — and the alerts you can finally test properly
* [Adding Sensors](/devices/adding-sensors) — the normal way, once your hardware is here


# Data Templates

Data templates tell Chirp what your sensors measure, so readings show up labeled with the right units.

Data templates tell Chirp what your sensors are measuring and how to display it. They're the reason a temperature reading shows up as "22.5 °C" instead of a mysterious number — and why a humidity sensor from one manufacturer shows the same kind of data as a humidity sensor from a completely different brand.

Many common sensor types come pre-configured, so you might never need to touch data templates at all. But if you're using a less common sensor or want to customize how measurements are labeled, this is where you do it.

## How to get there

There are two ways to reach data templates:

* **From a sensor list** — When viewing your sensors in a connection's **Connected Devices** tab, click the **Metrics Templates** button in the top-right area.
* **Direct URL** — Navigate to `/metrics` in your browser.

## The three tabs

Data templates are organized into three tabs, each handling a different layer:

### Units

Units define the measurement units available in Chirp — things like °C, °F, %, lux, mV, and so on.

**What you see:** A table with **Name** and **Symbol** columns, plus edit and delete buttons.

**To add a unit:**

1. Click **Add Unit**.
2. Enter a **Name** (e.g., "Celsius") and **Symbol** (e.g., "°C").
3. Click **Save**.

Some units come built in and can't be edited — these cover the most common measurements.

### Normalized Keys

Normalized keys are standard names for what a measurement represents. Instead of every sensor using its own name for temperature (one might call it `temp`, another `temperature`, another `t_celsius`), you create one normalized key called `temperature` and map all of them to it.

**What you see:** A table with **Normalized Key** and **Type** columns, plus edit and delete buttons.

**To add a key:**

1. Click **Add Normalized Key**.
2. Enter a name — use something descriptive and lowercase, like `temperature`, `humidity`, `soil_moisture`, or `battery_level`.
3. Click **Save**.

Built-in keys cover common measurements and can't be edited.

### Metrics

Metrics (also called sensor templates) combine a normalized key, a unit, a value type, and a data type into a complete measurement definition. When you add a sensor, this is what gets attached to map the sensor's raw output into something meaningful.

**What you see:** A table with columns for **Normalized key**, **Unit of measurement**, **Type**, **Data type**, and action buttons.

**To add a metric:**

1. A new row appears at the top of the table.
2. **Normalized key** — Select an existing key or create a new one right from the dropdown.
3. **Unit of measurement** — Pick from your units list (e.g., °C, %, lux).
4. **Type** — This tells Chirp what kind of number or value to expect. Pick the one that matches your sensor's output:
   * **Integer** — Whole numbers with no decimal point. Use for readings that are always whole numbers. Examples: battery percentage (85), signal strength (-120), count of events (42).
   * **Float** — Numbers with a decimal point. Use for readings that need fractional precision. Examples: temperature (22.5), humidity (67.3), voltage (3.28). **This is the most common choice for sensor readings.**
   * **String** — Text. Use for readings reported as words or codes. Examples: door status ("open" / "closed"), firmware version ("1.2.3"), device mode ("standby").
   * **Boolean** — True or false. Use for simple yes/no or on/off states. Examples: motion detected (true/false), alarm active (true/false), window open (true/false).
5. **Data type** — This tells Chirp how to treat the measurement:
   * **Telemetry** — Regular sensor readings that change over time. This is the most common type — temperature, humidity, battery level, soil moisture, air quality, and similar readings all use Telemetry.
   * **Device Metadata** — Information the sensor reports about itself that doesn't change often. Examples: firmware version, hardware revision, signal strength. You won't need this for most home sensors.
   * **User Metadata** — Properties you add yourself, not sent by the sensor. Examples: "Installed: March 2025", "Battery type: CR2032", "Location: back garden". Useful for keeping notes attached to a sensor.
6. Click save on the row.

**Filtering:** Use the dropdown filters above the table to narrow the list by type or data type.

## Do I need to set this up?

For most common LoRaWAN sensors, Chirp comes with built-in templates that cover standard measurements. When you register a sensor using a device profile template, the right data templates are often assigned automatically.

You'll want to create custom data templates if:

* Your sensor measures something unusual (e.g., a specific industrial gas)
* You want different display units (e.g., Fahrenheit instead of Celsius)
* You're using a sensor brand that isn't in the template library

For how data templates connect to individual sensors, see [Adding Sensors](/devices/adding-sensors) and [Sensor Details](/devices/sensor-details).


# What Your Device Is Sending

See exactly what your sensor is reporting and in what form, and why the name Chirp shows you isn't the name inside the device's own messages.

Your sensor sends a very short message — a few bytes, or a small bundle of text. Something has to unpack that into readings you can actually use, and that something is the device's decoder. Everything you see afterwards, on a dashboard or in an automation, started life as one of the fields it produced.

There are two names for the same reading, and they're usually different:

* The **field name** is what comes out of the decoder — things like `t`, `socket_status`, or `humidity_pct`. That comes from whoever made the device.
* The **measurement name** is what you called it when you set the device up — *Temperature*, *Plug status*. This is the one you see everywhere else in Chirp.

Knowing which is which — and what the readings actually look like — is what saves you a puzzled ten minutes when a condition never seems to match.

## Have a look at what's arriving

Open the device and go to its **Mapping** section. There's a table there listing every field the device has sent, with:

* the **field name**, exactly as the device sends it
* what it's **saying right now**
* when it **last updated**

It's live, so it refreshes as new messages come in. This is the quickest way to answer "what does this thing report, and what does it look like?" — and it's worth a glance whenever you're about to compare a reading to something, whether that's an automation condition or a check on a command.

If a device has never sent anything, there's nothing to show yet. Wait for its next update.

## Where the decoder lives

The decoder sits in the **Code functions** box on the device's connection settings. Picking a ready-made device profile fills it in for you. Setting a device up by hand leaves it empty, and you paste in the code from the manufacturer's instructions or a community collection.

You can change it whenever you like. If readings are missing, look wrong, or the names don't match what the manufacturer describes, edit it and save — the device's next message comes through your version.

See [Adding Sensors](/devices/adding-sensors) for the whole setup walkthrough.

## Giving the fields proper names

Mapping is where you connect a field to a data template, so a cryptic `t` turns into *Temperature* with a unit and a type. After that, it shows up under its friendly name everywhere.

You do that from the same Mapping section — see [Adding Sensors](/devices/adding-sensors) for the steps, and [Data Templates](/devices/data-templates) if you need a template that doesn't exist yet.

A field you never map keeps arriving but has nowhere to go: it won't turn up in automations, on dashboards, or in a command check.

## Readings keep the shape they arrived in

Chirp keeps what the decoder produced, exactly as it was. If your plug reports the word `on`, the measurement holds the word `on` — not `true`, and not `1`. If it reports the number `1`, you get a number.

That matters any time you compare something:

* **In an automation**, compare a word to a word: `vars.socket_status == "on"`.
* **On a command**, what you type as the expected value has to match how the device says it — see [Making sure it worked](/devices/commands/verification#what-to-type-as-the-expected-value).
* **On a dashboard**, the same goes for conditions.

When a comparison never seems to match, go and read the current value in the Mapping table and write yours to match.

## When the fields aren't what you expected

**Readings are arriving but nothing shows up in automations or on dashboards.** They haven't been mapped yet. Open the Mapping section and map the ones you want.

**The names aren't the ones you were expecting.** The decoder is producing different field names than your measurements are looking for — which usually means the code was written for a different version of the device. Compare the names in the table against what you've mapped, and either fix the mapping or swap the code.

**Nothing's being decoded at all.** Check the device is actually sending, then check the code. [Connection Diagnostics](/devices/connection-diagnostics) shows what arrived most recently and whether anything came out of it.

## See also

* [Adding Sensors](/devices/adding-sensors) — Setting a device up, decoders and mapping
* [Data Templates](/devices/data-templates) — Friendly names, units and types
* [Connection Diagnostics](/devices/connection-diagnostics) — What turned up last, and whether it decoded
* [Making sure it worked](/devices/commands/verification) — Using a measurement to check a command


# Sensor Details

Open any sensor to view live readings, edit its settings, and browse its full data history.

Every sensor in Chirp has a detail view where you can see everything about it — its name, photos, connection settings, what it measures, and its complete data history. This is the same dialog you used when first adding the sensor, but now it shows live data and lets you make changes.

## Opening sensor details

There are several ways to open a sensor's details:

* **From Devices** — Click **Devices** in the sidebar, then click any sensor row to open its detail dialog.
* **From a connection** — Open your LNS connection's **Connected Devices** tab, or open your Tracker connection's sensor list, and click a sensor row.
* **Edit button** — Click the pencil icon on any sensor row to jump straight into editing.

## The tabs

### Device info

This is where you manage the sensor's identity:

* **Photos** — Add or change photos of the sensor. This is handy when you have several similar-looking sensors and need to tell them apart during a battery change or troubleshooting.
* **Device name** — Update the name anytime. If you originally called it "Sensor 3," now's a good time to rename it to something more useful like "Kitchen Temperature" or "Basement Humidity."
* **Location** — Where the sensor lives. You can set it, change it, or clear it entirely at any point, so a sensor that moves from the hallway to the garage doesn't have to keep pretending otherwise. Removing the location leaves the sensor unplaced without touching its readings or history. See [Rooms](/devices/rooms).

### Connection

This tab shows how the sensor connects to Chirp and lets you adjust its profile. It also carries the sensor's connection diagnostics, which tell you whether data is arriving and being saved — the place to look when a sensor is quiet or a reading is missing. See [Connection Diagnostics](/devices/connection-diagnostics).

**For LoRaWAN sensors:**

* **Connector type** — Shows which connection this sensor uses — LNS, Tracker, MQTT or Emulator. You can switch a [pretend sensor](/devices/pretend-sensors) over to the real connection here when your hardware arrives (and back again if you want to test something).
* **Device EUI** — The unique identifier that links this profile to the physical sensor. This field is locked once set. If you need to change it (for example, if you're replacing a broken sensor with a new one), click the **detach** button (X icon) to unbind the physical sensor first. The profile and all its history are preserved.
* **Device profile** — Switch between template-based and manual configuration. If you originally set up the sensor manually, you can switch to a template later (or vice versa).
* **Data sending interval** — Where you tell Chirp how often this sensor sends. A sensor's sending schedule is set on the sensor itself and varies by brand — sometimes preconfigured by the manufacturer, sometimes set when you install it — so enter the schedule the sensor is actually on. A daily sensor → **1 day**, a monthly one → **1 month**. The field defaults to **1 hour**, but that's only a placeholder. If nothing arrives within the interval the sensor shows as offline; entering the right schedule keeps a healthy sensor from looking offline between reports. Pick a number and a unit (minute, hour, day, week, or month).
* **Code functions** — The sensor's payload codec: the logic that decodes raw data into the named fields you see in the Metrics tab. When a device profile template is selected, this field is pre-filled with the template's codec. If your readings look wrong — missing fields, incorrect values — you can edit the code directly. For the full explanation, see [Adding Sensors](/devices/adding-sensors).

**For tracker devices:**

* **Unique ID** — The tracker's identifier (locked once set).
* **Device model** — The selected tracker model.
* **Url for GPS tracker** — The endpoint your tracker sends data to. You can copy this again if you need to reconfigure the tracker.

### Metrics

This tab shows what the sensor measures and how each measurement is mapped to a data template.

**Table columns:** Metrics template, Unit, Type, Data type, Connector key, Value, Last update.

Here's what each column means:

* **Metrics template** — The data template assigned to this measurement. Select from the dropdown to change it.
* **Connector key** — The raw name the sensor uses for this reading (e.g., `temp_c`). Map it to the right template so Chirp knows what the number means.
* **Value** — The most recent reading for this measurement.
* **Last update** — When the last reading came in.

You can add new measurement rows or remove existing ones. Removing a data template row takes effect on the server immediately. Other changes are saved when you click **Save**.

Below the main metrics table, a **User Metadata** section lets you add your own notes or tags to the sensor — things like "Installed: March 2025" or "Battery type: CR2032."

### Logs

The Logs tab is your sensor's raw data diary. Every reading the sensor has sent is recorded here, grouped by the minute — readings that arrive in the same minute are gathered under one heading, so a busy minute stays tidy instead of sprawling. A little status indicator in the sensor's header shows its live connection, so you can see at a glance whether it's sending data right now.

Click a minute to expand it and see the individual readings:

| Column     | What it shows                                             |
| ---------- | --------------------------------------------------------- |
| **Key**    | The raw measurement name from the sensor                  |
| **Type**   | The data type of the value                                |
| **Value**  | The actual reading                                        |
| **Status** | Processing status (currently empty for standard readings) |

**Date filtering:** Click the date button in the top-right corner to pick a time range — useful for investigating when something happened. Choose a preset like "Last week" or set a custom date range.

If the Logs tab is empty and you're not sure why, the Connection tab's diagnostics will tell you whether anything is reaching Chirp in the first place. See [Connection Diagnostics](/devices/connection-diagnostics).

## Quick actions from sensor lists

You don't always need to open the full detail view. From any sensor list, the row action buttons let you:

* **Edit** (pencil icon) — Open the full detail dialog
* **Copy** (clone icon) — Create a new sensor pre-filled with the same settings
* **Delete** (trash icon) — Remove the sensor (with a confirmation dialog)

For more about what your sensors measure and how to customize it, see [Data Templates](/devices/data-templates). To organize sensors by room, see [Rooms](/devices/rooms).


# Connection Diagnostics

Added a sensor but no readings appear? Read the Connection tab and get your data flowing.

You unboxed the sensor, stuck it on the wall, typed in its numbers, hit **Save** — and the readings are still blank. It's the moment every home setup runs into at least once, and it used to leave you guessing whether the problem was the battery, the gateway, the keys, or Chirp itself.

Connection diagnostics answers that question for you. Open any sensor, go to its **Connection** tab, and Chirp tells you in plain words where your sensor's data is right now: whether anything has arrived at all, whether Chirp understood it, and whether it's being saved to your history. Every state comes with a short list of things to try — so you always know what to do next, not just what went wrong.

## Why this is worth two minutes of your time

Without it, a silent sensor is a mystery with a dozen possible causes. Is the wine cellar monitor out of range? Did you mistype one character of a 16-character code? Is it sending fine and just not being recorded? Those are wildly different problems with wildly different fixes, and hunting through them one at a time is how a fifteen-minute setup turns into a lost evening.

The Connection tab collapses all of that into one screen. It tells you which of those three things is actually happening, and then it tells you which one to fix. Most of the time you'll be done before you've finished your coffee.

## Where to find it

1. Click **Devices** in the sidebar.
2. Click the sensor you're worried about to open its detail dialog.
3. Click the **Connection** tab.

Diagnostics appear right there alongside the sensor's connection settings. Three blocks stack down the tab:

* **Reception status** — the headline: is data arriving, and is it being kept?
* **Pipeline** — the counts, showing how many messages made it through each stage recently.
* **Event feed** — the message-by-message diary, newest first.

## Block 1 — Reception status

This is the one to read first. It's a single sentence that names your situation, with a supporting line underneath and a couple of numbers for context.

You'll see one of these headlines:

| Headline                                     | What's actually happening                                                                                                                                                                                                                                                                                              |
| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Receiving & storing**                      | The happy ending. Data is arriving, Chirp understands it, and your history is filling up. The line beside it reads `{{count}} sensors mapped · last value {{last}}`.                                                                                                                                                   |
| **Sending data — set up mapping to keep it** | Your sensor is alive and talking — Chirp just doesn't know what its readings mean yet, so nothing is being saved. Shown as `{{count}} keys decoded · none mapped yet`.                                                                                                                                                 |
| **Data arrives but nothing is stored**       | "Data is arriving but nothing is stored yet." Messages are landing, but none of them are turning into readings you can chart.                                                                                                                                                                                          |
| **Hasn't reported — device looks offline**   | "Device was reporting but has gone quiet." It used to work. Something changed.                                                                                                                                                                                                                                         |
| **Waiting for first data**                   | Nothing has come in yet. You may also see **Waiting for the first uplink** or **No uplinks received yet** — same meaning. If it never moves off this state, the sensor may still be joined to a network it used before Chirp — see [First things first: joining the network](#first-things-first-joining-the-network). |
| **Reached network — waiting for data**       | "Joined the network · no uplinks yet" — a LoRaWAN sensor that has successfully introduced itself to your gateway but hasn't sent an actual reading yet. Genuinely good news.                                                                                                                                           |

Around the headline you'll also spot a few supporting details:

* **Expected every {{interval}} {{unit}} · last seen {{last}}** — the schedule you told Chirp this sensor is on, next to when it actually last showed up. If those two disagree badly, the schedule in your settings is probably wrong, not the sensor.
* **{{count}} sensors configured · 0 receiving values** — you've set up readings, but none of them are being filled in.
* **{{count}} more keys available, unmapped** — your sensor is sending extra readings you haven't claimed yet. Often a pleasant surprise: a leak detector quietly reporting its battery level too.
* **LIVE**, **NO DATA**, **Live**, **Idle**, **RECEPTION** — small indicators marking whether things are moving right now.
* **Loading reception status…** — just fetching. Give it a second.
* **Diagnostics unavailable** — the check itself couldn't run. Close the dialog, reopen the sensor, and try the Connection tab again.

### The two guidance blocks

Right beside the status you'll find **WHAT TO CHECK** and **WHILE YOU WAIT** — short, concrete checklists that change depending on what's going on. They're the whole point of the page, so don't skim past them.

For a sensor that hasn't shown up, they'll suggest things like:

* Confirm the device is powered on and transmitting
* Check the device power or battery
* Make sure it is within range of a gateway
* Check that AppKey and DevEUI match the device
* Give it one reporting interval to transmit

For a sensor that has gone quiet after working fine:

* Check the device power or battery
* Confirm it is still within range of a gateway
* Confirm the device is sending on its schedule
* Make sure the sending schedule has not changed

For data arriving that isn't turning into readings:

* Check the payload decoder matches this device
* Map at least one incoming key to a sensor
* Check that the connection settings are correct

### If your sensor connects over MQTT

MQTT sensors have their own set of messages, because there's a broker in the middle:

| Message                                                                   | What it means and what to do                                                                                                                                                                                 |
| ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Broker connected** — "Your broker is reachable and Chirp is subscribed" | All good on the broker side.                                                                                                                                                                                 |
| **Connecting to your broker…**                                            | Chirp is dialing in. Wait a moment.                                                                                                                                                                          |
| **Chirp can't reach your broker**                                         | "Check the broker URL and credentials in the connector settings." Open the connector and re-copy the address, username, and password — a stray space at the end of a pasted password is the classic culprit. |
| **Waiting for the device to publish to the Chirp broker…**                | Connection's fine, the device just hasn't said anything yet. It is connected with its generated MQTT credentials.                                                                                            |
| **A message arrived on a topic this device isn't set up for**             | "Update the topic above, or change where the device publishes." Compare the **Expected topic** field with **Published to** — they need to line up.                                                           |
| **No publish topic is configured yet — set one above.**                   | Fill in the topic field on this tab, save, and the messages will start matching.                                                                                                                             |

When things are working, MQTT diagnostics confirm all three of these: the device publishes to the expected topic, the payload is valid JSON, and the device ID resolves as configured.

## First things first: joining the network

There's a step people miss because nothing in the setup form hints at it. A LoRaWAN sensor doesn't simply start broadcasting readings the moment it has power. It has to **join** a network first.

Here's how that goes. When the sensor wakes up, it sends out a **join request** — a little "hello, may I?" message carrying its identity. Your gateway passes it along, Chirp checks it against the Device EUI and AppKey you typed into the sensor form, and if those match, Chirp sends back a join accept. Only *after* that handshake does the sensor start sending actual readings.

Which is why the states at the top of this tab read the way they do. They're that handshake, in order:

1. **Waiting for first data** — the handshake hasn't happened. Chirp has heard nothing from this sensor at all.
2. **Reached network — waiting for data** (shown as "Joined the network · no uplinks yet") — the handshake worked. The sensor is on your network, it just hasn't reached its next scheduled report.
3. **Receiving & storing** — readings are flowing in and going into your history.

### A sensor can only belong to one network at a time

Here's the part that trips people up. Once a sensor joins a network, it settles in and stops asking. Its firmware is satisfied: it has a network, thank you, no need to knock on any more doors.

So if your sensor has had a previous life — you found it on eBay, it was already screwed to the wall when you bought the house, it came off a different app or platform, or it's a returned or demo unit that someone else set up first — it is still, as far as it's concerned, joined to that old network. Adding it to Chirp doesn't undo that. You've told Chirp all about the sensor, but nobody has told the sensor about Chirp, and it isn't going to ask.

The symptom is unmistakable once you know it: **Waiting for first data**, indefinitely, while every single thing you can check looks right. EUI correct. AppKey correct. Battery in. Sitting a meter from the gateway. Three reporting intervals have come and gone. Nothing. That's not a mistake you can find by checking harder — the sensor is simply talking to somewhere else.

Worth saying plainly: Chirp can only report on what reaches it. It has no way to see that your sensor is quietly still attached to a previous owner's network, so it can't warn you about this one. That's what this section is for.

### The fix: make it ask again

Reset the sensor. A reset clears the old session and puts the sensor back to square one, where it sends a fresh join request — and this time your Device EUI and AppKey are waiting for it in Chirp.

How you do that depends entirely on who made it. There's no universal button. Depending on the model it might be:

* a magnet swiped past a specific spot on the casing
* a button held down for a set number of seconds
* a reed switch or a pinhole reset under the cover
* a power cycle of a particular length, or repeated a particular number of times

Look up the reset procedure for your exact model in the manufacturer's instructions — it's usually in the quick-start leaflet or on the maker's support page. One detail worth watching for: plenty of sensors treat "restart" and "rejoin" as two different things. Pulling the battery for a second may just restart it, leaving the old network session intact, and it'll come back exactly as silent as before. You want the full reset that clears the session.

Once it's done, watch the Connection tab. You should see the status move to **Reached network — waiting for data** within a minute or two — that's the join accept landing. From there it's just waiting for the sensor's next report.

### Two lookalikes that aren't this

* **A sensor that worked for a while and then went quiet** is a different problem. Sensors don't quietly un-join a network on their own, so this isn't it. That case shows up as **Hasn't reported — device looks offline**, and it's almost always the battery, something new blocking the signal, or a schedule that's changed. Don't reset it — you'll just make more work for yourself.
* **A sensor that joins, then drops back to "Waiting for first data" again and again** usually has a typo in its identifiers. One wrong character in the Device EUI or AppKey and the handshake can't complete. Re-enter both with **Scan QR code** on the sensor form rather than retyping — then reset the sensor once more so it tries again with the corrected values.

## Block 2 — Pipeline

The Pipeline block counts how many messages made it through each stage: **Routed**, **Mapped**, and **Stored**. Reading it left to right shows you exactly where things stop.

If Routed is climbing but Stored is stuck at zero, your sensor is talking and Chirp is listening — the readings just aren't being recorded, which almost always means mapping. If Routed itself is zero, nothing is reaching Chirp at all, and the problem is out at the sensor, the battery, or the gateway.

One thing worth knowing: these counts are labeled **Stats over the last {{days}} days**. They cover a recent rolling window — the number of days shown in that label — not everything the sensor has ever sent. A brand-new zero doesn't mean the sensor never worked; it means it hasn't done anything within that window.

## Block 3 — Event feed

Where the Pipeline gives you totals, the event feed gives you the individual messages. It's a table:

| Column      | What it shows                                     |
| ----------- | ------------------------------------------------- |
| **Time**    | When the message arrived                          |
| **Stage**   | Which step of the journey this row describes      |
| **Outcome** | How that step turned out                          |
| **Detail**  | The specifics — helpful when the outcome isn't OK |

Below the table, a legend titled **What these statuses mean** spells out every term. Here it is:

| Term        | Meaning                                                                                                          |
| ----------- | ---------------------------------------------------------------------------------------------------------------- |
| **Routed**  | the message reached the platform and was matched to this device.                                                 |
| **Mapped**  | incoming keys were matched to your configured sensors.                                                           |
| **Stored**  | sensor values were saved to history.                                                                             |
| **OK**      | this step completed successfully.                                                                                |
| **Skipped** | intentionally not processed (for example, no matching mapping or an unexpected topic). Not necessarily an error. |
| **Error**   | this step failed and needs attention.                                                                            |

That **Skipped** row deserves a moment. Seeing it doesn't mean anything is broken — it usually just means a reading arrived that you haven't asked Chirp to keep. If you'd like to keep it, map it (see below). If you don't care about it, leave it alone; Skipped is a perfectly healthy thing to see.

If the sensor is brand new you'll see **No events yet** with "Events will appear here once the device sends data." — nothing to fix, just nothing to show.

The feed loads a chunk at a time. Click **Load more** to fetch older entries; you'll see **Loading…** briefly and **All records loaded** once you've reached the end. **No pipeline data** means there's nothing recorded for this sensor in the window at all.

## What "mapping" actually means

Half the messages on this page mention mapping, so it's worth a plain-language explanation.

Your sensor doesn't send tidy labels. A garden soil probe might send something like `sm` and `bat` — not "Soil Moisture" and "Battery." Mapping is you telling Chirp: *that `sm` number is the soil moisture reading, in percent.* Once you've done that, Chirp knows what the number is, stores it in your history, draws it on your dashboard, and lets your automations react to it.

Until you map at least one reading, Chirp receives your sensor's messages and politely sets them aside, because it has no idea what they represent. That's exactly the **Sending data — set up mapping to keep it** state — and it's the single most common reason a healthy sensor shows no readings.

Good news: **Connector keys appear here automatically once the device transmits.** You don't have to know your sensor's field names in advance. Let it send once, and the list fills itself in.

## Fixing things without leaving the tab

Diagnostics don't just describe problems — they hand you the button. Depending on the situation you'll see:

* **Fix** / **Fix mapping** / **Set up mapping** / **Map a key** — jump straight to where you match your sensor's readings to what you want to see. This is the fix for anything mapping-related.
* **Details** — expand a row to see the full story behind an outcome.
* **Hide** — collapse a block once you've read it, to get the Connection tab back to a working size.
* **See reception status** — jump back up to the headline from further down the tab.

## What to do when it says…

**"Waiting for first data" / "No uplinks received yet"** — Give it one full reporting interval before doing anything; a sensor set to report once an hour will look silent for an hour, and that's correct. If it stays silent past that, check the battery is in the right way round, confirm the sensor is within range of your gateway, and double-check the Device EUI and AppKey character by character against the sensor's label. If typing them was the risky part, re-enter them with **Scan QR code** on the sensor form — see [Adding Sensors](/devices/adding-sensors). And if all of that checks out and it's *still* silent, stop checking and reset the sensor so it sends a fresh join request — this is the usual ending for any sensor that had an owner before you. See [First things first: joining the network](#first-things-first-joining-the-network).

**"Reached network — waiting for data"** — Relax. Your LoRaWAN sensor found the gateway and joined successfully, which is the hard part. It's simply waiting for its next scheduled report. Come back after one interval.

**"Sending data — set up mapping to keep it"** — This is the best kind of problem: everything works, you just need to claim the readings. Click **Set up mapping** (or **Map a key**), pick the readings you want from the list that's now populated, save, and your history starts filling from the next report onward.

**"Data arrives but nothing is stored"** — Messages are landing but not becoming readings. Check the payload decoder matches this device — a template meant for a different model will produce nothing useful — and make sure at least one incoming key is mapped to a sensor. Both live on this same dialog.

**"Hasn't reported — device looks offline"** — It worked before, so start with the physical world: battery first, then range. A wine cellar monitor that stopped reporting the same week you rearranged the shelves is probably behind something now. Also confirm the sending schedule hasn't changed — if you reconfigured the sensor to report daily but Chirp still expects hourly, it'll look offline while being perfectly fine. Fix the **Data sending interval** on this tab to match reality.

**"Chirp can't reach your broker"** — MQTT only. Open the connector settings and recheck the broker URL and credentials. See [MQTT Troubleshooting](/connectors/mqtt-connector/troubleshooting).

**"A message arrived on a topic this device isn't set up for"** — MQTT only. Compare **Expected topic** with **Published to**. Either update the topic here to match what your device actually sends, or reconfigure the device to publish where Chirp is listening. Either works — pick whichever is easier to change.

**"Diagnostics unavailable"** — The check couldn't complete. Reopen the sensor and try again. Your data isn't affected either way — this only concerns the diagnostic view.

## Checking the connector, not just the sensor

Sometimes the sensor is fine and the connection itself is the issue. MQTT connectors have their own **Connector diagnostics** area with **Source health**, **Incoming**, and **Activity** tabs, showing whether the connector is receiving anything at all ("{{count}} seen", or **No activity yet** when it isn't), a **Connect device** shortcut, and its own **Diagnostics unavailable** state when the check can't run. Other connection types simply show their settings.

If every one of your MQTT sensors looks silent, start at the connector rather than the sensors. See [MQTT Troubleshooting](/connectors/mqtt-connector/troubleshooting).

## Tips

* **Read top to bottom, fix bottom to top.** The reception status names the problem, the pipeline shows where it stops, the event feed proves it. But the fix almost always sits at the earliest stage that isn't OK.
* **Get the reporting interval right first.** More "offline" sensors are misconfigured schedules than dead batteries. A monthly water meter set to an hourly interval will look broken 720 times a month.
* **Don't panic at Skipped.** It's informational. Errors are the ones that want attention.
* **Take the free readings.** When you see "{{count}} more keys available, unmapped", have a look — battery level is often sitting there unclaimed, and it's the reading that warns you before a sensor goes quiet.
* **Check here before replacing hardware.** A sensor that says "Sending data — set up mapping to keep it" is a working sensor. Nothing on it needs replacing.

## What's next

* [Adding Sensors](/devices/adding-sensors) — register a sensor and map its readings.
* [Sensor Details](/devices/sensor-details) — the rest of the sensor dialog, including Logs.
* [MQTT Troubleshooting](/connectors/mqtt-connector/troubleshooting) — broker-side problems in depth.


# Rooms

Group your sensors into rooms like Living Room, Kitchen, and Garden so everything's easy to find.

As your smart home grows, organizing sensors by room keeps everything easy to find. Instead of scrolling through a flat list, you can group sensors into rooms like Living Room, Kitchen, Garden, and Garage — so you always know where each sensor lives.

In Chirp, rooms are managed through **Settings → Locations**. Think of each location as a room or area of your home. The interface uses the term "Location settings," but throughout this guide we'll call them rooms because that's how most home users think about them.

## Getting to the rooms page

1. Click **Settings** in the sidebar.
2. Click **Locations** (or go directly to `/settings/locations`).

The page title reads **Location settings** with the subtitle "Manage your locations."

## Adding a room

1. Click **Add location** in the top-right corner.
2. In the dialog, enter a name for the room — something that matches how you think about your home: "Living Room," "Kitchen," "Garden," "Garage," "Basement."
3. Click **Save**.

The room appears in the list. If this is your first one, it replaces the empty state message ("You don't have locations yet").

## Editing a room

Each room in the list shows:

* **Name** — An editable text field. Just click it, type a new name, and click away to save.
* **Delete** — Click the trash icon to remove the room (a confirmation dialog appears first).
* **Expand** — Click the chevron to reveal details and sub-rooms.

### Setting a location on the map

When you expand a room, a search/coordinates field appears. You can:

* Type an address or place name to search
* Enter latitude and longitude directly

This places the room on a map, which helps when viewing sensor data spatially (covered in the Home Dashboards section).

## Sub-rooms

Sub-rooms let you add a layer of detail within a room. For example:

| Room   | Sub-rooms                     |
| ------ | ----------------------------- |
| Garden | Greenhouse, Lawn, Raised Beds |
| House  | Upstairs, Downstairs, Attic   |
| Garage | Workshop, Storage             |

**To add a sub-room:**

1. Expand the parent room by clicking the chevron.
2. Click the **+** button that appears below the sub-room list.
3. Enter a name and click **Save**.

Sub-rooms appear nested under their parent. Each can be renamed or deleted independently.

### Showing and hiding sub-rooms

The **Show sub-locations** toggle at the top of the page controls whether sub-rooms are visible. Turn it off for a clean overview of just your main rooms; turn it on to see the full hierarchy.

This toggle is on by default.

## Tips

* **Name rooms like you talk about them.** "Kitchen" is better than "Room 3." Future you will thank present you.
* **Start simple.** You don't need sub-rooms right away. Add them later if your setup gets complex enough to need them.
* **Rooms help everywhere.** Once set up, rooms can be used to organize dashboards, filter sensor data, and group automations (covered in later sections).


# Favorite Devices

Star the devices and gateways you check most in Chirp — saved and shown right on their cards for quick access.

Favorites let you mark the devices and gateways you care about most by starring them. It's a quick way to flag the ones you check often.

## How to favorite something

Both **devices** and **gateways** can be favorited. Look for the **star icon** on a device card, a gateway card, or a gateway's detail page:

* **Star outline** = not favorited. Tooltip: **"Add to favorites."**
* **Star filled** = favorited. Tooltip: **"Remove from favorites."**

Click the star to favorite it; click it again to remove. Your choice is saved, and the filled or outlined star shows the current state wherever that device or gateway appears.

## Good to know

There isn't a separate "Favorites" page that lists everything you've starred — the star marks the item in place. On the Home Overview you'll see summary cards for devices and gateways rather than a dedicated favorites panel.

## Tips

* **Star the things you rely on.** A filled star makes the devices and gateways you watch most stand out at a glance.
* **Keep it focused.** Starring a handful of key items is more useful than starring everything.


# Controlling Your Devices

Control your devices from Chirp — turn things on or off, dim lights, or just ask the AI helper to do it for you.

Up to now, Chirp has mostly listened — gathering readings from your sensors and showing them on your dashboards. **Commands** flip that around. They let Chirp *talk back* to your devices, so the same app that tells you the living room is chilly can also turn the heater on.

If a device can be told to do something, Chirp can do it for you: flick a smart plug on or off, dim the bedroom lights to 30%, warm a bulb's color temperature for movie night, nudge a thermostat to a new target, or send a setting to almost anything in your home. It works whether your device connects over Zigbee/MQTT or LoRaWAN — you don't have to think about the plumbing.

<figure><img src="/files/xdX3BT2TOovEO7RRUIvj" alt="A device&#x27;s Commands &#x26; States tab, with its commands and recent actions"><figcaption></figcaption></figure>

## Why you'll love it

Before, controlling a smart device usually meant juggling apps — one for the lights, another for the plugs, a third for the thermostat. Chirp brings the controls into the same place you already watch your home:

* **One home, one place to control it.** Define what a device can do once, then operate it with a tap — no fiddling with technical settings every time.
* **Tap-friendly controls.** You see a simple, friendly action ("Turn on", "Set brightness") — Chirp handles the messy details behind the scenes.
* **Know it actually happened.** Chirp can check that the device really responded, not just that the message was sent (see [Making sure it worked](/devices/commands/verification)).
* **A tidy history.** Every action you send is logged, so you can always see what changed and when.

## Where to find it

Open a device, and look for the **Commands & States** tab. It has two parts:

* **Commands** — where you set up the actions a device can do. See [Setting up a command](/devices/commands/creating-commands).
* **States** — where you actually press the buttons and see what happened. See [Sending a command](/devices/commands/executing-commands).

You'll see the **Commands & States** tab on devices that can be controlled:

* **Smart home devices connected over MQTT** — most Zigbee devices (through Zigbee2MQTT), DIY ESP32 builds, Tasmota plugs, and similar.
* **Class C LoRaWAN devices** — these listen all the time, so they're always ready to receive a command. (Battery-saving Class A LoRaWAN sensors only wake briefly, so they can't be controlled on demand.)
* **Pretend sensors with Support commands switched on** — a [pretend sensor](/devices/pretend-sensors) behaves like the real thing, so you can practise the whole business before the hardware turns up.

Once a device has at least one command set up, it becomes *controllable* — and you can also drop it onto a dashboard as a [Control widget](/dashboards/adding-widgets/control-widget).

## Before you start

To control a device, you'll want:

1. **A device that can receive commands** — connected over MQTT, a Class C LoRaWAN device, or a [pretend sensor](/devices/pretend-sensors) with commands switched on.
2. **At least one command set up** — a brand-new device has no actions yet. Start with [Setting up a command](/devices/commands/creating-commands).
3. **Permission to control it** — managing and sending commands follows your home's sharing settings.
4. **Sensible values** — if a command takes an input (like a brightness level), it has to be within the allowed range before Chirp will send it.

## Five ways to control a device

Commands are the foundation, and you can run them from five places:

* **On the device** — open it, go to **States**, and press a command.
* **On a dashboard** — add a [Control widget](/dashboards/adding-widgets/control-widget) so a light switch or button sits right next to your readings.
* **From an automation** — the [Rules engine](/rules-engine) can now press a command for you, automatically, the moment something happens. The same command you'd tap yourself gets sent with nobody home — so a leak at 3 a.m. shuts the water off on its own. See [When an Automation Runs a Command](/rules-engine/reference/automation-runs-a-command).
* **By asking the helper** — say *"turn on the lamp"* and your [AI helper](/ai-assistant) does it, after showing you what it's about to send and checking afterwards that the device got it. See [Ask It to Turn Things On](/ai-assistant/let-ai-set-it-up).
* **From your own AI app** — connect ChatGPT, Claude or anything else that speaks MCP and ask it the same thing from wherever you already work. See [Your Own AI App](/api/mcp-server).

All five end up in the same place: the commands you set up here, sent the same way, logged the same way.

Alerts still have their place alongside all of them: an automation can act *and* tell you about it — shut the water off **and** send you a heads-up — so the problem's handled and you're never left in the dark.

Ready? Head to [Setting up a command](/devices/commands/creating-commands).


# Setting up a command

Set up a device command in Chirp — name it, pick the device, add inputs like brightness, and test before you save.

A command is a saved action with a friendly name — "Turn on", "Set brightness", "Warm white" — that you create once and then use again and again. After it's set up, you (or anyone you share your home with) can run it without ever seeing the technical bits.

Open the device, go to the **Commands & States** tab, stay on the **Commands** part, and tap **Add new command**. The setup screen is split into four short steps.

<figure><img src="/files/VsAS9JQpq4u3WSlA1Ms3" alt="The command setup screen with the name, where-to-send, and message steps"><figcaption></figcaption></figure>

## 1. Name it

* **Command name** — Required. Pick something you'll recognize at a glance, like `Turn on` or `Movie lighting`. Each command on a device needs its own name.
* **Description** — Optional. A quick note about what it does.

## 2. Point it at your device

This tells Chirp how to reach the device. What you see depends on how the device is connected.

### Devices on MQTT (most smart home gear)

* **MQTT topic** — The address the message is sent to.
  * On Chirp's hosted broker, the first part of the address (the prefix) is filled in for you; you add the rest, like `living-room-lamp/set`. Your device needs to be listening on the full address.
  * On your own broker, type the full topic exactly as your device expects it.
  * Keep it under 500 characters, leave out the `#` and `+` symbols, don't leave an empty gap between slashes, and don't start it with `iot/`, `external/` or `external-downlink/` — those are reserved.
* If another command already uses the same address, Chirp gives you a heads-up so two actions don't clash.

### Devices on LoRaWAN

* **fPort** — A number from **1 to 223** that tells the device which "channel" the message is for. Your device's manual will tell you which to use.
* **Confirmed downlink** — A switch: leave it **On** to have the network wait for the device to confirm it got the message, or **Off** to simply send and move on. Turn it **On** if you plan to pick *Ask the device* in step 4 — that check waits for the confirmation, so it can't be saved without one.
* LoRaWAN messages always go out as raw bytes, so they always go through a converter. The send-as-is option only applies to MQTT devices.

### Devices that can't be controlled

Some devices only ever report in — there's no way to send anything back to them, so they don't offer commands at all.

## 3. What the command does

This is where you set up any choices the command offers and the message it sends.

### Inputs (parameters)

If your command needs a value — a brightness level, a color temperature, a mode — add it as a **parameter** with **Add Parameter**. For each one:

* Give it a **Name** and a short **Description** (the description is what you'll see when you run the command).
* Pick a **Type**:
  * **Integer** or **Float** for numbers, with an optional smallest (**Min**), largest (**Max**), and starting (**Default**) value — great for a 0–100 brightness.
  * **String** for text, with an optional list of allowed choices (an **Enum** like `auto, manual, off`).
  * **Boolean** for a simple on/off or true/false.

Setting a Min and Max means you can never accidentally send a brightness of 500% — Chirp keeps the value sensible for you.

### The message itself

For MQTT devices, you choose how the message is built:

* **Send as-is** — send the message straight through (best when your device understands plain JSON).
* **Process with encoder** — run it through a small converter first.

When a converter is used (and it always is for LoRaWAN, where messages have to be turned into raw bytes), you write a short **template** with `{{ placeholders }}` that get filled in with your inputs — so a "set brightness" command drops the brightness number into the right spot. Most of the time the converter that came with your device's setup is all you need; advanced users can supply their own.

## 4. Decide how Chirp checks it worked

The last step is where you say whether Chirp should confirm the command actually did something — send and forget, wait for the device's next update, or ask the device outright. It's also where you pick which reading should change and what it should say.

It has a page of its own: [Making sure it worked](/devices/commands/verification). To find out what your device reports back and how it writes it, see [What Your Device Is Sending](/devices/what-your-device-is-sending).

## Test it before you save

Whenever a converter is involved, there's a **Try it** tool right in the setup screen. Put in some test values and run it to see exactly what will be sent — including the technical form of the message and whether it ran cleanly. It's a no-risk way to be sure the command is right *before* it ever reaches your device.

## Save

Tap **Save**. The command shows up straight away in your list of commands and on the **States** tab, ready to use. You can **Edit** it later, or **Delete** it if you no longer need it.

## What's next

* Decide how Chirp confirms the command worked — [Making sure it worked](/devices/commands/verification).
* Actually press the button — [Sending a command](/devices/commands/executing-commands).


# Making sure it worked

Tell Chirp how to confirm a command really worked — skip the check, wait for the next reading, or ask the device.

Pressing "Turn on" is satisfying — but did the light actually come on? Sometimes a device is asleep, out of range, or just doesn't get the message. Chirp can check for you, so a command is only marked as done when there's real proof behind it.

You set this up when you create a command, in the fourth step. There are three choices.

<figure><img src="/files/uNvDPjaFosBMs8H0IrYm" alt="The verification step with don&#x27;t check, wait for the next reading, and ask the device options"><figcaption></figcaption></figure>

## Don't check

Send it and move on. Chirp won't verify anything.

With this option, the command shows as **Delivered** the moment it's sent on its way — *not* when the device actually does something. (Delivered means "sent, but not checked" — it's a step short of **Confirmed**, which only happens when you set up a check.) It's fine for harmless, everyday actions where it doesn't matter much if one tap is missed, but don't rely on it when you really need to know something changed.

## Wait for the next reading

After the command goes out, Chirp waits for the device's next normal update and checks whether it reflects the change you asked for. When the reading matches, the command is confirmed.

This works nicely for devices that report their status as part of their regular updates — like a plug that tells Chirp whether it's currently on.

## Ask the device

The most thorough choice. After the device confirms it received the command, Chirp sends a quick follow-up question and checks the answer.

On a LoRaWAN device, switch **Confirmed downlink** on back in the routing step before you choose this. The follow-up only goes out once the device says it got the command, so there has to be a confirmation to wait for — otherwise the command won't save, and *Wait for the next reading* is the one to use.

* **Follow-up command** — pick a command to use as the question, or create one right there. A follow-up question is a simple kind of command: it just asks the device for its current state, so there's nothing to fill in when it runs, and it needs no checking of its own — the device's answer *is* the check. Once saved, it's kept for reuse with any other command.
* When you create one, you write the short message that asks the device. For sensors on a cloud or external connection, you can send that message exactly as you wrote it, or let Chirp encode it first.
* Chirp matches the device's answer against what you expect to see.

Use this for devices that don't mention their status on their own but will tell you if you ask.

## What "worked" looks like

For both checking options, you tell Chirp what a successful result looks like by adding one or more expected readings. Add at least one — the command won't save without it.

### Which reading to pick

Pick the measurement the command actually changes. For a smart plug that's whatever reports on or off — not its battery or its signal strength.

The list shows the device's measurements under the names you gave them when you set the device up. Those aren't the names hidden inside the device's own messages: a plug that sends `socket_status` might show up here as *Plug status*. To see which is which, open the device's Mapping section — see [What your device is sending](/devices/what-your-device-is-sending).

Pick a measurement that's actually set up and getting readings. Ones you haven't mapped yet still show in the list, and a command checked against one of those never gets anything to compare, so it always ends up as *Soft warning*. If nothing is mapped yet, Chirp offers you a link to go and do that first.

### What to type as the expected value

Type what the device should be reporting once the command has done its job — written the same way the device writes it. The quickest way to get that right is to open the device's Mapping section and look at what the measurement says right now.

**If it's a word**, just type it. Capital letters don't matter, so `on` matches a device saying `ON`.

**If it's a number, or an on/off true-or-false**, don't type it — point at one of your inputs instead. Put `{{ inputName }}` in the box and set that input up as a number or a true/false in the previous step. Anything you type in by hand counts as a word, so a typed `1` looks for the word `1` and won't match a device reporting the number 1.

**To follow whatever the person entered**, use that same `{{ inputName }}` — a "set brightness" command can then check the device reports whichever brightness was asked for. The name has to match one of your inputs, and Chirp flags it if it doesn't.

| The device says        | Type this                                          |
| ---------------------- | -------------------------------------------------- |
| `on` or `ON`           | `on`                                               |
| `open`                 | `open`                                             |
| `60` (a number)        | `{{ level }}`, with **level** set up as a number   |
| `true` (true or false) | `{{ state }}`, with **state** set up as true/false |

If a command keeps coming back as *Soft warning* even though the device clearly did the thing, this box is the first place to look — compare what you typed against what the measurement is really reporting.

## How long to wait

Chirp waits a little while for the device to catch up before deciding.

* Leave the wait time empty to use the sensible default (about 1.5 times how often the device normally reports). Make sure that reporting interval is set correctly on the device — where it's missing, the default stretches out to an hour and a half.
* Or set your own wait, up to a day.
* If the time runs out without a match, the command is marked **Soft warning** instead of failed — meaning "we couldn't confirm it," not "it definitely didn't work." Often it did; it's just worth a glance.
* Nothing gets sent a second time. If a command wasn't confirmed, send it again yourself or let an automation do it.

## Quick guide

| Choice                    | Confirms                        | Good for                                   |
| ------------------------- | ------------------------------- | ------------------------------------------ |
| Don't check               | Only that it was sent           | Simple, low-stakes taps                    |
| Wait for the next reading | The device's next normal update | Devices that report their status regularly |
| Ask the device            | A direct answer from the device | Devices that respond when asked            |

Next: [Sending a command](/devices/commands/executing-commands).


# Sending a command

Send a command from the States tab in Chirp, fill in any values, and see whether it worked in your activity history.

Once a device has commands set up, the **States** part of the **Commands & States** tab is your remote control. It shows what you can do, lets you do it, and keeps a tidy record of everything you've sent.

<figure><img src="/files/RuldZ3ZBobALexaM02EB" alt="The Execute command dialog, setting a value before sending"><figcaption></figcaption></figure>

## What you can do

The **Available commands** list shows every action set up for the device — its name, what it does, how many inputs it needs, and a **Execute** button to run it. If the list is empty, the device doesn't have any commands yet; pop over to the **Commands** part to set one up (see [Setting up a command](/devices/commands/creating-commands)).

## Pressing the button

Tap **Execute** next to a command.

* If it doesn't need any inputs, just confirm and it's on its way.
* If it does — say, a brightness level — fill in the **value**. Chirp shows the allowed range (like `Min: 0 - Max: 100`) and won't let you send something the device can't handle.
* Tap **Execute** to send, or **Cancel** to change your mind.

## If the device is offline

If Chirp hasn't heard from the device recently, you'll see a note at the top saying it's offline and when it was last seen. You can't send a command to a sleeping device on the spot — but anything you've queued will be sent automatically the moment it wakes up and reconnects, so nothing gets lost.

## Your activity history

Everything you send is listed in **Recent executions**, so you always have a record of what happened:

* **Command** — what you ran
* **Started** — when you sent it
* **Updated** — when its status last changed
* **Status** — how it turned out
* **Details** — a plain-language note

A command's status will be one of:

* **Pending** — on its way.
* **Confirmed** — done, and the check you set up saw the device's reading match.
* **Delivered** — sent on its way. You didn't set up a check, so Chirp isn't confirming the result — just that the command went out.
* **Soft warning** — it was sent and received, but Chirp couldn't confirm the result in time. Often it worked anyway — just worth a peek.
* **Failed** — it didn't go through. The **Details** note tells you why.

### What the Details note can say

When something needs a second look — a **Soft warning** or a **Failed** — the Details note explains why in plain language. The ones you'll run into most:

| If you see…                                                     | It means…                                                                    |
| --------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Device downlink queue is full.                                  | The device has too many messages waiting — give it a moment, then try again. |
| Validation failed.                                              | Something in the command wasn't right — check its settings.                  |
| Payload too large for the device.                               | The message is bigger than the device can take — trim it down.               |
| Sent, but the device didn't confirm receipt.                    | It went out, but the device never said "got it."                             |
| Sent, but the device didn't confirm the expected state in time. | It went out, but the reading you were expecting didn't show up in time.      |
| Device offline — command not delivered in time.                 | The device was asleep or out of reach, so it didn't arrive.                  |
| No gateway available to reach the device.                       | No gateway was nearby to pass the message along.                             |
| Broker authentication failed.                                   | The connection was refused — check your MQTT login details.                  |
| The command couldn't be sent. Please try again later.           | A temporary hiccup — give it another go.                                     |
| Invalid payload — check the command.                            | The message didn't come out right — take another look at the command.        |

These are the common ones — you might occasionally see a different note, since Chirp passes along whatever reason it gets.

## Control from your dashboard

For everyday use, you don't even need to open the device. Add a [Control widget](/dashboards/adding-widgets/control-widget) to a dashboard and you'll have a light switch or button sitting right next to your readings — same actions, same history, one tap away.

## See also

* [Setting up a command](/devices/commands/creating-commands)
* [Making sure it worked](/devices/commands/verification)
* [Example: Switching a Lamp](/devices/commands/lamp-example) — two commands set up and checked, start to finish
* [Control widget](/dashboards/adding-widgets/control-widget)


# Example: Switching a Lamp

Set up on and off commands for a smart lamp from start to finish, and have Chirp confirm the lamp really switched.

This walks through two commands on one device and gets Chirp confirming they worked. It uses a smart lamp that reports whether it's currently lit, but the same steps suit anything you switch — a heater, a pump, a socket.

Do the parts in order; each one gives you something the next part needs.

## Before you start

* The lamp is already added and sending updates.
* You can see its readings in the device's **Mapping** section.

## 1. Find out how the lamp says "on"

Open the lamp and go to **Mapping**. Look down the list of fields for the one that reports whether it's lit, and note two things: what the field is called, and what it says right now.

For this lamp:

| Field        | Right now |
| ------------ | --------- |
| `lamp_state` | `off`     |

That's the value a check will be looking for later, so copy it down exactly as it appears — `off`, not `OFF` or `false`.

If the field hasn't been mapped to a measurement yet, do that now. Commands pick their readings by measurement name, so an unmapped field can't be used to check anything. See [What Your Device Is Sending](/devices/what-your-device-is-sending).

In this example `lamp_state` is mapped to a measurement called **Lamp state**.

## 2. Set up "Turn on"

Open **Commands & States → Commands** and tap **Add new command**.

**1. Name it**

* **Command name** — `Turn on`

**2. Point it at your device**

* On MQTT: the address your lamp listens on, like `living-room-lamp/set`.
* On LoRaWAN: the fPort from the lamp's manual, with **Confirmed downlink** switched on.

**3. What the command does**

This one always does the same thing, so it needs no inputs at all — leave the parameters empty and just write the message that switches the lamp on.

Use **Try it** before you save. It shows you exactly what will be sent, so you can check the message is right while nothing has left the app yet.

**4. Decide how Chirp checks it worked**

Pick **Wait for the next reading** — the lamp mentions its state in every normal update, so there's no need to go asking.

Under the expected readings, add one:

* **Reading** — *Lamp state*
* **Expected value** — `on`

Type it the way the lamp says it. Capitals don't matter here, so `on` also matches a lamp reporting `ON` — but words and numbers aren't interchangeable, so `1` wouldn't match. See [Making sure it worked](/devices/commands/verification#what-to-type-as-the-expected-value).

Tap **Save**.

## 3. Set up "Turn off"

Same again, with three changes:

* **Command name** — `Turn off`
* **The message** — the one that switches the lamp off
* **Expected value** — `off`

Everything else stays as it was.

## 4. Try them out

Go to the **States** tab, find **Turn on**, and tap **Execute**.

Watch it appear in the recent list:

1. It sits at **Pending** while the message is on its way.
2. When the lamp's next update arrives saying `lamp_state: on`, it turns **Confirmed** — Chirp has seen the lamp in the state you asked for.

Run **Turn off** and you'll see the same thing the other way round.

## If it never confirms

A command that isn't confirmed before the wait runs out shows as **Soft warning** — it went out, but Chirp couldn't prove anything changed. Work down this list:

1. **Check the value.** Open Mapping and see what `lamp_state` says now. If the lamp switched but reports `1` rather than `on`, your expected value needs to match that — and since anything you type counts as a word, point at an input set up as a number or true/false instead.
2. **Check the reading.** Make sure the measurement you picked is the one fed by `lamp_state`, and that it's mapped and getting updates.
3. **Check the wait.** The default is about 1.5 times how often the lamp normally reports. If that interval isn't set on the device, set it.
4. **Check the message.** Run **Try it** again and compare against the manufacturer's instructions.

## What's next

* Put both commands on a dashboard so anyone at home can use them without opening the device.
* Let an automation switch the lamp for you — see [An Automation Runs a Command](/rules-engine/reference/automation-runs-a-command).


# Tested Device Guides

Hands-on walkthroughs for specific sensors and bulbs we paired end-to-end with Chirp at home.

These walkthroughs cover end devices we have tested end-to-end on Chirp. They are not the supported device list — Chirp's MQTT and LoRaWAN connectors work with thousands of devices across many brands, and you don't need to find your specific hardware in this section before adding it. The point of these pages is simply that **if you happen to have one of these exact devices**, the pairing procedure, configuration values, and quirks are documented here so you don't have to figure them out yourself.

For the standard registration flow that applies to any device, see [Adding Sensors](/devices/adding-sensors). For Zigbee devices specifically, [Setting up Zigbee2MQTT](/connectors/mqtt-connector/zigbee2mqtt) explains the generic pairing pattern and links you to your device's manufacturer instructions.

## What's in this section

### [Zigbee devices](/devices/tested-device-guides/zigbee)

Walkthroughs for Zigbee end devices we tested through a Zigbee2MQTT hub. Currently:

* [Paulmann 50064 light bulb](/devices/tested-device-guides/zigbee/paulmann-50064-light-bulb) — a CCT (tunable-white) Zigbee bulb.

If you have a different Zigbee device, follow your manufacturer's pairing instructions and the [generic Z2M setup page](/connectors/mqtt-connector/zigbee2mqtt). The registration steps in Chirp are the same for every Zigbee device — the only piece that's device-specific is how the device enters pairing mode and what payload keys it publishes.

## How a tested-device walkthrough is structured

Each page covers four things:

1. **What the device is** — quick orientation, what to expect, what works and what doesn't (e.g., bulbs that don't publish on physical wall-switch toggles).
2. **The pairing procedure** — exactly what we did to get the device joined and named in Z2M. Includes specific gotchas, like reset patterns and timing.
3. **The capability profile** — every payload key the device publishes, with type, range, and what it means.
4. **Registering it in Chirp** — values to use in the device form (Device ID, Device ID Topic, mappings) and a confirmation that the readings flow into the Mapping tab.

If you want to add a device that isn't covered here, the same four-part shape applies — the manufacturer's documentation will tell you (1), (2), and (3), and the [MQTT connector documentation](/connectors/mqtt-connector) covers (4) for any MQTT-bridged device.


# Zigbee Devices

Zigbee bulbs and sensors we paired through a Zigbee2MQTT hub — pairing quirks and payload details.

Zigbee end devices we have paired and registered end-to-end on Chirp through a Zigbee2MQTT hub. These pages cover the device-specific parts — pairing procedures, payload formats, behavioral quirks. The protocol-level setup (Z2M install, MQTT connector configuration, Chirp device registration flow) is the same for every Zigbee device and lives in [Setting up Zigbee2MQTT](/connectors/mqtt-connector/zigbee2mqtt) and [Topics and device routing](/connectors/mqtt-connector/topics-and-device-routing).

## In this section

* [Paulmann 50064 light bulb](/devices/tested-device-guides/zigbee/paulmann-50064-light-bulb) — Tunable-white CCT bulb. Covers the 5-cycle factory-reset pattern, the full payload field set, the Mirek-scale color-temperature mapping, and the behavioral quirk where physical wall-switch toggles don't generate MQTT publishes.

## Don't have one of these?

That's the normal case. The [Zigbee2MQTT supported devices list](https://www.zigbee2mqtt.io/supported-devices/) covers thousands of devices — anything in there works with Chirp. The procedure for registering a new Zigbee device is:

1. Pair the device through Z2M, following the manufacturer's instructions for entering pairing mode.
2. Rename it in the Z2M web UI to a whitespace-free friendly name.
3. Register it in Chirp using the friendly name as the Device ID and `zigbee2mqtt/{{deviceId}}` as the Device ID Topic — the same values as for any other Z2M-bridged device.
4. Map the payload keys the device publishes to your chosen normalized metrics.

The only thing that changes between devices is step 1 (pairing varies by manufacturer) and the specific payload keys at step 4 (they differ by device class). Steps 2 and 3 are universal.

If you'd find a walkthrough for your specific hardware useful, the [Paulmann 50064 page](/devices/tested-device-guides/zigbee/paulmann-50064-light-bulb) is a good template for what one of these looks like — the structure transfers cleanly to other devices.


# Paulmann 50064 Light Bulb

Pair, register, and map the Paulmann 50064 tunable-white Zigbee bulb in Chirp, with all the quirks.

This is a hardware-specific walkthrough for the **Paulmann SmartHome LED spot, model 50064** — a Zigbee 3.0 CCT (tunable-white) bulb we tested end-to-end with Zigbee2MQTT and Chirp's MQTT connector. If you have this exact bulb, follow these steps to pair it, register it in Chirp, and map its readings.

If you have a **different Zigbee bulb or device**, you don't need this page — the generic flow applies. Pair the device through Z2M following your manufacturer's instructions, then [register it in Chirp](/connectors/mqtt-connector/topics-and-device-routing) the same way as any other Z2M-bridged device. The Paulmann 50064 happens to be the bulb we had in hand for the testing — the procedure transfers cleanly to other Zigbee devices.

## What this bulb is

* **Type:** CCT (correlated color temperature) tunable-white LED. Adjusts brightness and color temperature, but not color (no RGB).
* **Color temperature range:** 150–500 mired (about 6667K daylight to 2000K candle-warm).
* **Power:** mains, screw-in fitting (varies by region — E14, E27, GU10 versions exist).
* **Zigbee profile:** Zigbee 3.0, identifies as `Paulmann SmartHome led spot (50064)` in Z2M.
* **Z2M auto-identifies it** — once paired, Z2M shows the brand and model in the Devices tab without manual selection.

What works:

* Brightness and color-temperature control via the Z2M web UI, MQTT `/set` commands, or any home-automation system that publishes to MQTT.
* State changes initiated via MQTT or the Z2M web UI generate confirmation publishes that flow through Chirp into the Mapping tab and Logs tab.

Behavioral quirk to know up front: **physical wall-switch toggles do not generate MQTT publishes** on this bulb. The bulb's firmware only reports state changes that arrived over Zigbee, not changes caused by mains power-cycling. If you flip a wall switch and then check the Logs tab, expect to see nothing new — that's the bulb's design, not a Chirp or Z2M bug. To verify state in Chirp during setup, drag the brightness slider in the Z2M web UI or send a `/get` poll. See [Troubleshooting](/connectors/mqtt-connector/troubleshooting) for the full list of "what counts as a publish."

## Prerequisites

* Z2M is installed and running. If not, follow [Setting up Zigbee2MQTT](/connectors/mqtt-connector/zigbee2mqtt) and the [Sonoff ZBDongle-E coordinator walkthrough](/gateways/zigbee2mqtt-hubs/sonoff-zbdongle-e-coordinator) (or the equivalent for your coordinator) before continuing here.
* The bulb is screwed in and the wall switch is in the **on** position. It's powered, even if it's currently lit on factory-default settings.
* The bulb is within \~2 meters of the coordinator for initial pairing. After joining, you can move it anywhere — Zigbee mesh routing handles range.

## Pairing

The Paulmann 50064 uses a 5-cycle reset pattern.

1. **Open Permit join in Z2M first.** In the Z2M web UI at `http://localhost:8080`, click the green shield icon at the top labeled **Permit join (All)**. The Zigbee network is now open for 180 seconds.
2. **Power-cycle the bulb through 5 on-cycles.** Use the wall switch:
   * on → off → on → off → on → off → on → off → on
   * That's 5 on-states with an off-state between each. Hold each state for \~2 seconds. Don't rush — too fast and the bulb may not register the cycle.
3. **On the 5th on-cycle, the bulb blinks rapidly.** This is the factory-reset confirmation. Pairing mode is now active and the bulb is on.
4. **Stop. Leave the bulb on. Don't touch the switch.** This is the most common mistake — people see the blink and immediately do another off/on cycle, which restarts the reset sequence and aborts the join attempt.
5. **Wait 10–30 seconds.** The bulb joins the Zigbee network and appears in Z2M's Devices tab, identified by its IEEE address (`0x...`).
6. Z2M auto-identifies the model. The Devices tab shows `Paulmann SmartHome led spot (50064)` next to the device.

If pairing doesn't happen within \~60 seconds:

* The 180-second Permit join window may have closed. Click Permit join again.
* The bulb may already be paired to a previous Zigbee network (rare for new bulbs but possible if you bought it second-hand). Repeat the 5-cycle reset to factory-default it again.
* Some Paulmann firmware revisions require 10 cycles instead of 5. Try 10 if 5 doesn't trigger the blink.
* Move the bulb closer to the coordinator. 1–2 meters is the safest range for first pairing.

## Renaming the device

When the bulb pairs, its initial friendly name is its IEEE address. Rename it to something readable — that name will become the device-level MQTT topic Z2M publishes to AND the Device ID you'll use in Chirp.

In the Z2M web UI:

1. Click the bulb's row in the Devices tab.
2. Click the pencil icon next to the name at the top of the detail panel.
3. Type a new name. **Avoid spaces** — Chirp's Device ID input strips whitespace, which causes silent topic-match failures. Use CamelCase (`TableLampLivingRoom`) or snake\_case (`table_lamp_living_room`).
4. Press Enter or click the checkmark.

The example friendly name we'll use in this page: **`TableLampLivingRoom`**.

After renaming, Z2M publishes to:

```
zigbee2mqtt/TableLampLivingRoom        (External MQTT)
{Topic prefix}/zigbee2mqtt/TableLampLivingRoom   (Cloud MQTT)
```

## What the bulb publishes

When the Paulmann 50064 sends a state update, the payload looks like this:

```json
{
  "brightness": 254,
  "color_mode": "color_temp",
  "color_temp": 392,
  "color_temp_startup": 65535,
  "linkquality": 212,
  "state": "ON"
}
```

Full field reference:

| Field                | Type            | Range                                                                        | Notes                                                                                                                                                                                                                                                                                                                                                                           |
| -------------------- | --------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `state`              | string          | `"ON"`, `"OFF"`, `"TOGGLE"`                                                  | **String, not boolean.** Map to a String-typed metric in Chirp.                                                                                                                                                                                                                                                                                                                 |
| `brightness`         | integer         | 0–254                                                                        | 0 turns the bulb off on some firmware versions. Note: 0–254, not 0–255 or 0–100.                                                                                                                                                                                                                                                                                                |
| `color_temp`         | integer         | 150–500 mired                                                                | See the Mirek-scale table below.                                                                                                                                                                                                                                                                                                                                                |
| `color_temp_startup` | integer or null | 150–500, `65535`, or `null`                                                  | "Start Up Color" — what color temperature the bulb turns on as when power is restored. `null` = not configured; the bulb uses its firmware default on cold power-on. `65535` = sentinel for "restore previous color temperature." Any number in 150–500 = a fixed mired value to apply on every power-on. Set via a `/set` command with an explicit numeric value to configure. |
| `power_on_behavior`  | enum            | `off`, `on`, `toggle`, `previous`                                            | Behavior after a power loss. Send via `/set` to configure.                                                                                                                                                                                                                                                                                                                      |
| `effect`             | enum            | `blink`, `breathe`, `okay`, `channel_change`, `finish_effect`, `stop_effect` | One-shot effects. Send via `/set` to trigger.                                                                                                                                                                                                                                                                                                                                   |
| `linkquality`        | integer         | 0–255                                                                        | Zigbee link quality. Diagnostic only — not user-facing.                                                                                                                                                                                                                                                                                                                         |
| `color_mode`         | string          | `"color_temp"`                                                               | **Always present in payloads even though it's not on the** [**zigbee2mqtt.io device page**](https://www.zigbee2mqtt.io/devices/50064.html)**.** Trust the actual payload over the device page when they disagree.                                                                                                                                                               |

### Mirek scale (`color_temp` values)

The Mirek (or "mired") scale is the inverse of Kelvin: lower Mirek = cooler/bluer light, higher Mirek = warmer/more amber. The formula is mired = 1,000,000 / Kelvin.

Z2M ships named presets for the Paulmann 50064:

| Preset name | Mired | Approximate Kelvin | Description           |
| ----------- | ----- | ------------------ | --------------------- |
| coolest     | 150   | 6667K              | Daylight / blue-white |
| cool        | 250   | 4000K              | Natural white         |
| neutral     | 370   | 2703K              | Warm white            |
| warm        | 454   | 2203K              | Candle-like           |
| warmest     | 500   | 2000K              | Very warm amber       |

When you map `color_temp` in Chirp, choose a Number-typed metric. The unit is mired (lower = cooler).

## Registering the bulb in Chirp

Once Z2M is publishing to a topic Chirp can see (verify via the connector's **Last data received**), register the device:

1. **Connectors → your MQTT connector → Add device.**
2. **Device ID:** `TableLampLivingRoom` (or whatever whitespace-free friendly name you chose). It must match the Z2M friendly name byte-for-byte.
3. Open the **Mapping** tab. You land on the **Topic** sub-tab first.
4. **Topic sub-tab:**
   * **Device ID Topic:** `zigbee2mqtt/{{deviceId}}`
   * **Where to get the device ID:** `Topic` (default).
   * **Telemetry topics:** leave empty. The Paulmann publishes a flat JSON payload — Chirp parses all keys automatically.
5. Click **Next** or the inner **Mapping** sub-tab to reach the per-key rows.
6. **Mapping sub-tab — Pass 1:** add a row per metric you want, but **leave Connector key empty**. Recommended initial set:

   | Normalized key    | Type   | Data type      |
   | ----------------- | ------ | -------------- |
   | State             | String | Reported State |
   | Brightness        | Number | Reported State |
   | Color Temperature | Number | Reported State |
   | Color Mode        | String | Telemetry      |
   | Link Quality      | Number | Telemetry      |

   If a normalized key you want doesn't exist, use **+ Add new metric** and create one. The modal handles both the normalized name and the underlying sensor template.

   > **Color Mode must be a String, not an Integer.** It's tempting to default to a numeric type for what looks like a small enumerated value, but the actual payload value is a string (`"color_temp"`). A Number-typed metric will report null. The same is true for `state` (`"ON"`/`"OFF"`).
7. Click **Save**.
8. **Generate a publish.** Open the bulb in the Z2M web UI and drag the brightness slider, or use the on/off toggle. Z2M sends a `/set` command, the bulb confirms the new state, and Z2M publishes the confirmed payload — that's the publish Chirp needs.
9. **Mapping sub-tab — Pass 2:** reopen the device record. The **Connector key** dropdowns now list the keys received from the bulb. Match each row:

   | Mapping row       | Connector key |
   | ----------------- | ------------- |
   | State             | `state`       |
   | Brightness        | `brightness`  |
   | Color Temperature | `color_temp`  |
   | Color Mode        | `color_mode`  |
   | Link Quality      | `linkquality` |
10. Click **Save** again.

### Pass 3 — add Start Up Color after the first publishes arrive

Once the bulb has been publishing for a little while, the Connector key dropdown shows one more useful field: **`color_temp_startup`**. The bulb only emits this in some payloads — typically after a `/get` poll or after explicitly setting it — so it often isn't visible during Pass 2. Treat it as a third pass:

11. Reopen the device record. Confirm the Connector key dropdown now lists `color_temp_startup` as an option (if not, force a publish that includes it: send a `/get` request, or send a `/set` with a `color_temp_startup` value).
12. Click **Add key** in the Mapping sub-tab.
13. Pick or create a **Start Up Color** normalized key (Number type, Reported State data type).
14. Set the Connector key to `color_temp_startup`.
15. Click **Save**.

| Mapping row    | Connector key        | Type   | Data type      |
| -------------- | -------------------- | ------ | -------------- |
| Start Up Color | `color_temp_startup` | Number | Reported State |

**What "Start Up Color" means:** the color temperature the bulb turns on as when power is restored. A specific number (150–500 mired) means "always cold-start at this color." `65535` means "remember the previous setting and restore it on power-on." `null` means it isn't configured — the bulb uses its firmware default. Useful in homes where you want the lamp to always come on warm regardless of how it was last left.

This three-pass progression — register the obvious fields first, fill in Connector keys after the first publish, then add the late-discovered field — is normal for MQTT mapping. Most devices have at least one field you'll only see once data is flowing.

After the three passes, the **Value** column on the Mapping tab populates with the bulb's current state across all six metrics. Generate one more publish (drag the Z2M slider) to confirm records arrive in the **Logs** tab — that's your end-to-end verification.

## Things that look like problems but aren't

* **Mapping tab Value column updates but Logs tab is empty.** Normal after Pass 2 if you saved Connector keys after the most recent publish. Generate a fresh publish from the Z2M web UI.
* **`color_mode` always shows `"color_temp"`.** This bulb has no RGB capability. The field is always `color_temp` for CCT bulbs.
* **`color_temp_startup` shows `65535` or `null`.** `65535` is the sentinel for "restore previous color temperature on power-on." `null` means it hasn't been configured and the bulb uses its firmware default. Set a specific number (150–500 mired) via `/set` if you want a fixed color on every cold power-on.
* **`color_temp_startup` doesn't appear in early payloads.** The bulb only emits this field in certain payloads — typically after a `/get` poll or after the field has been explicitly set. If your Connector key dropdown doesn't show it during Pass 2, that's normal — see Pass 3 above.
* **Multiple publishes from one `/get` request.** Z2M polls Zigbee attribute clusters separately, so one `/get` produces 2–4 publishes back as the cluster responses arrive. Normal — not an error.
* **Wall-switch toggle produces no Logs entry.** As covered above — this bulb doesn't publish on physical power-cycle. Use the Z2M web UI to generate publishes for setup-time verification.

## Where to go next

* [MQTT Troubleshooting](/connectors/mqtt-connector/troubleshooting) — when something isn't working.
* [Topics and device routing](/connectors/mqtt-connector/topics-and-device-routing) — the protocol-level reference for the registration concepts above.
* [Zigbee2MQTT setup](/connectors/mqtt-connector/zigbee2mqtt) — to recheck the Z2M install or to pair another device.


# Gateways

Gateways bring your sensors into Chirp — choose between a LoRaWAN gateway and a Zigbee2MQTT hub.

Gateways are the connectivity hardware that brings sensors and end devices into Chirp. Different protocols use different kinds of gateways, but they share the same role: they sit in your home, listen for the radios your sensors use, and forward what they hear to Chirp.

Chirp supports two categories of gateway today, organized in this section by the protocol they handle:

## In this section

### [LoRaWAN gateways](/gateways/lorawan-gateways)

The original Chirp gateway category. A small box — usually about the size of a paperback book — that listens for LoRaWAN radio signals from sensors anywhere in your home. One gateway is typically enough for a house or apartment; LoRaWAN signals reach far on tiny amounts of power, and a battery-powered sensor can last years on one charge.

* [Setting up a LoRaWAN gateway](/gateways/lorawan-gateways/setting-up-a-lorawan-gateway)
* [Checking LoRaWAN gateway health](/gateways/lorawan-gateways/checking-lorawan-gateway-health)
* [Compatible LoRaWAN gateways](/gateways/lorawan-gateways/compatible-lorawan-gateways)

### [Zigbee2MQTT hubs](/gateways/zigbee2mqtt-hubs)

A different kind of "gateway" for Zigbee devices: a small computer (a Raspberry Pi, a home server, an old laptop) running Zigbee2MQTT software, with a USB or network-attached Zigbee coordinator. Together, the host machine plus the coordinator plus Z2M form what we call a "Zigbee2MQTT hub" — it joins your Zigbee devices into a mesh and publishes their data to MQTT, which Chirp then ingests through the [MQTT connector](/connectors/mqtt-connector).

* [Sonoff ZBDongle-E coordinator](/gateways/zigbee2mqtt-hubs/sonoff-zbdongle-e-coordinator) — the specific coordinator we tested with. Other Zigbee2MQTT-supported coordinators follow the same pattern.

## Which kind do I need?

It depends on the sensors and devices you want to connect:

* **LoRaWAN sensors** — long-battery-life devices designed for whole-home or whole-property coverage. A LoRaWAN gateway is the right kind.
* **Zigbee devices** — typically smart bulbs, smart plugs, and battery sensors from brands like Aqara, IKEA, Sonoff, Philips Hue, Paulmann. A Zigbee2MQTT hub is the right kind.
* **Both** — many homes run both. A LoRaWAN gateway and a Zigbee2MQTT hub coexist without conflict; they listen on different radios.

If you're not sure what your sensor uses, check the manufacturer's listing or the product packaging — it's almost always stated clearly.

## Secure by design

Both kinds of gateway connect to Chirp over encrypted channels:

* LoRaWAN gateways download a certificate file during setup that keeps the connection encrypted and authenticated. Only your registered gateway can send data to your account.
* Zigbee2MQTT hubs use TLS-protected MQTT (`mqtts://` on port 1884) to publish to Chirp's managed broker, with credentials unique to your connector.

In both cases, nobody on the public internet can eavesdrop on your sensor readings or inject fake data — the channel is encrypted and the credentials are yours alone.


# LoRaWAN Gateways

One small LoRaWAN gateway covers a whole home — learn how it works and how coverage spreads.

A LoRaWAN gateway is the small box that listens for radio signals from your battery-powered sensors and forwards them to Chirp. If you have door sensors, leak detectors, temperature probes, or any other LoRaWAN-based devices in your home, a gateway is what makes them visible to Chirp.

This sub-section covers everything specific to LoRaWAN gateways:

* [**Setting up a LoRaWAN gateway**](/gateways/lorawan-gateways/setting-up-a-lorawan-gateway) — Register your gateway with Chirp, download the certificate, and get it connected.
* [**Checking LoRaWAN gateway health**](/gateways/lorawan-gateways/checking-lorawan-gateway-health) — Confirm it's online, see how long it's been running, and check how much data it's handling.
* [**Compatible LoRaWAN gateways**](/gateways/lorawan-gateways/compatible-lorawan-gateways) — What to look for when choosing one.

## How LoRaWAN coverage works

One LoRaWAN gateway is usually enough for a typical home, apartment, or small property. The radios used by LoRaWAN sensors are tuned for range over throughput — they pass through walls, floors, and ceilings well, and a centrally-placed gateway can often cover every room in your house plus the garden, garage, or shed.

If you have an unusually large property, multiple separate buildings, or thick walls (stone, concrete, or basements), you may benefit from a second gateway. Chirp doesn't require you to do anything special — multiple gateways forwarding the same sensor's data simply give Chirp a stronger picture of where the sensor is reporting from.

## Secure by design

Chirp requires LoRaWAN gateways that use the Basics Station protocol, which connects over encrypted TLS/WSS. The certificate download step during gateway registration provides the TLS credentials for that secure connection. Older gateway protocols that send data unencrypted (the legacy UDP Packet Forwarder) are not supported.

In practice this means most modern indoor home gateways work fine — Compatible LoRaWAN gateways covers what to look for if you're shopping.

## How this differs from a Zigbee2MQTT hub

Zigbee2MQTT hubs are a separate kind of gateway covered in [Zigbee2MQTT hubs](/gateways/zigbee2mqtt-hubs). They're for Zigbee devices specifically — smart bulbs, smart plugs, Aqara/IKEA/Sonoff sensors. A LoRaWAN gateway and a Zigbee2MQTT hub can coexist in the same home and complement each other.


# Setting Up a LoRaWAN Gateway

Register your home gateway in Chirp, download its security certificate, and get it online in minutes.

Getting your gateway connected to Chirp takes just a few minutes. You'll register it in the app, download a security certificate, and then configure the gateway hardware to talk to Chirp.

## What you'll need

* Your gateway hardware, plugged in and connected to your home internet (Ethernet or Wi-Fi, depending on the model)
* The **Gateway EUI** — a 16-character code printed on a sticker on the gateway itself or on its packaging. It looks something like `A8:40:41:FF:FE:12:34:56`.

## Register your gateway in Chirp

1. Click **Gateways** in the sidebar.
2. Click **Add gateway**.
3. Enter a **Name** for your gateway — something that helps you remember where it is. For example, "Living Room Gateway" or "Garage Hub."
4. Select your **Region** from the dropdown. This needs to match the frequency your gateway was built for. If you bought it for use in your country, the right option is usually clear:

   | If you're in... | Select             |
   | --------------- | ------------------ |
   | Europe          | EU868              |
   | United States   | US915-0 or US915-1 |
   | Australia       | AU915-0            |
   | Asia-Pacific    | AS923 or AS923-2   |
   | India           | IN865              |
   | South Korea     | KR920              |

   Not sure? Check the label or spec sheet that came with your gateway — it will mention the frequency band.
5. Enter your **Gateway EUI** — the 16-character identifier from the gateway label.
6. Click **Next**.

## Download your security certificate

After registering, Chirp shows a confirmation screen with:

* Your gateway's **Name**, **Region**, and **Gateway EUI** for you to double-check.
* An **LNS Address** — click the copy icon to save this to your clipboard. You'll need it in a moment.
* A **certs.zip** file — click the download icon to save this certificate bundle to your computer.

Click **Continue** to finish registration in Chirp. You'll see a message confirming your gateway was added successfully.

## Configure your gateway hardware

Now you need to tell your gateway where to send data:

1. Open your gateway's settings page — this is usually a web interface you access by typing the gateway's IP address into your browser. Check your gateway's quick-start guide for how to reach it.
2. Find the LoRaWAN or Basics Station settings section.
3. Paste the **LNS Address** you copied from Chirp.
4. Upload the certificates from the **certs.zip** file you downloaded.
5. Save and restart the gateway if it asks you to.

The exact screens look different for each gateway brand — your gateway's own manual will show you exactly where to paste the address and upload the certificates.

## Verify it's working

Within a few minutes, your gateway should appear as online in the **Gateways** list in Chirp. If you don't see it come online:

* Double-check that the LNS Address was pasted correctly (no extra spaces)
* Make sure the certificate files were uploaded to the right place
* Confirm your gateway is connected to the internet
* Try restarting the gateway

Once it's online, your gateway is ready to start receiving sensor data. Head to [Connections](/connectors) to set up the link between your gateway and Chirp's sensor management.

These steps are the current gateway setup path. Other options you might see in the app that aren't related to smart home setup can be safely skipped.

## Tips for best coverage

* **Put it up high.** A shelf, wall mount, or the top of a bookcase — higher placement means better range.
* **Central is best.** If your gateway is in the middle of your home, signals can reach every direction.
* **One is usually enough.** A single gateway can cover a typical house or apartment. LoRaWAN signals go through walls, so you don't need one per room.
* **Keep the certificates safe.** The `certs.zip` file is like a key to your gateway's connection. Don't share it. If you ever need a fresh one, you can regenerate it from your gateway's settings page.


# Checking LoRaWAN Gateway Health

Check whether your home gateway is online, see its uptime, and know when a dip is worth a look.

Once your gateway is registered, you can check on it anytime to see whether it's online, how long it's been running, and how much sensor data it's handling.

## Finding your gateway

Click **Gateways** in the sidebar to see all your gateways. Each one shows its name, current status (online or offline), and when it was last seen. Click any gateway to open its detail page.

## The gateway detail page

Your gateway's detail page shows an overview card at the top and several health cards below it.

### Overview card

The overview card shows your gateway's photo (if you've added one), its name, and its current status. You can also star your gateway from here to mark it as a favorite — see [Favorite Devices](/devices/favorite-devices).

### Availability

The Availability card shows your gateway's uptime — how reliably it's been connected to Chirp over time. A healthy home gateway should show high availability. If you see dips, it usually means the gateway lost internet or power during those periods.

### Traffic

The Traffic card shows how much data your gateway has handled. This gives you a sense of how active your sensors are. If you have several sensors reporting regularly, you'll see steady traffic here.

### Pings

The Pings card shows the history of connectivity checks between your gateway and Chirp. Regular successful pings mean your gateway's connection is stable. Gaps in pings might indicate intermittent internet issues.

## When to worry (and when not to)

**Normal behavior:**

* Brief offline periods during internet outages or router restarts
* Small dips in availability after a power cut — the gateway reconnects automatically
* Traffic that varies depending on how many sensors you have and how often they report

**Worth investigating:**

* Gateway shows offline for more than an hour when your internet is working fine
* Availability drops significantly over several days
* No traffic at all even though you have active sensors

If your gateway stays offline, try the troubleshooting steps in [Setting Up a LoRaWAN Gateway](/gateways/lorawan-gateways/setting-up-a-lorawan-gateway) — the most common fix is verifying the LNS address and certificates.

## Gateway settings

From the gateway detail page, you can also access the **Settings** section where you can:

* Update the gateway's name
* Change its assigned location (room)
* Download or regenerate certificates if you need to reconfigure the hardware
* View the gateway's unique identifier (EUI) and region
* Delete the gateway if you no longer need it


# Compatible LoRaWAN Gateways

What to look for when buying a LoRaWAN gateway for your home — Basics Station, band, and placement.

Chirp works with LoRaWAN gateways that support the **Basics Station** protocol. This is the key thing to check when buying a gateway for your smart home.

## What is Basics Station?

Basics Station is a modern, secure way for gateways to connect to a LoRaWAN network. It uses encrypted connections (TLS), which means your sensor data is protected in transit — nobody can intercept readings between your gateway and Chirp.

Some older gateways use a different protocol called UDP Packet Forwarder, which sends data without encryption. **Chirp does not support UDP Packet Forwarder.** If a gateway only supports the legacy UDP protocol, it won't be able to connect.

## What to look for when buying

When shopping for a gateway, check for these features:

| Feature                 | What to look for                                                                                                                 |
| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| **Protocol**            | Must support **LoRa Basics Station** (sometimes listed as "LNS protocol" or "Basics Station compatible")                         |
| **Frequency band**      | Must match your region — EU868 for Europe, US915 for the United States, etc.                                                     |
| **Internet connection** | Ethernet or Wi-Fi — choose based on where you plan to place it                                                                   |
| **Power**               | Most home gateways use a simple wall adapter. Check that one is included or that you have the right plug for your country        |
| **Indoor vs outdoor**   | For most homes, an indoor gateway is fine. Outdoor-rated gateways are useful if you want to cover a large garden or outbuildings |

## How to check if your existing gateway is compatible

If you already have a LoRaWAN gateway, check its documentation or settings page for a Basics Station option. Many gateways support multiple protocols and can be switched to Basics Station through a firmware update or configuration change.

Look for settings labels like:

* "Basics Station"
* "LNS mode"
* "Semtech LNS"
* "CUPS/LNS"

If your gateway only mentions "Packet Forwarder" or "Semtech UDP" without a Basics Station option, it may need a firmware update or may not be compatible.

## One gateway is enough for most homes

LoRaWAN has impressive range — a single indoor gateway typically covers:

* An entire apartment
* A multi-story house
* A house plus garden and garage

Signals pass through walls, floors, and ceilings, so you generally don't need one per room. Start with a single gateway placed centrally and at a moderate height (a shelf or wall mount works well). If you find that sensors in far corners aren't connecting reliably, you can always add a second gateway later.


# Zigbee2MQTT Hubs

A Zigbee2MQTT hub — a small computer plus a coordinator — brings your Zigbee devices into Chirp.

A Zigbee2MQTT hub is a small always-on computer in your home — a Raspberry Pi, a home server, an old laptop, an Intel NUC — running Zigbee2MQTT software and connected to a Zigbee coordinator radio (usually a USB stick). Together, the host machine, the coordinator, and Z2M form what we call a "Zigbee2MQTT hub": the gateway that brings your Zigbee devices into Chirp.

If you have Zigbee bulbs, Zigbee smart plugs, Zigbee sensors from brands like Aqara, IKEA, Sonoff, Philips Hue, or Paulmann, this is the kind of gateway you need. Once your hub is running and joined to your devices, every Zigbee message reaches Chirp through the [MQTT connector](/connectors/mqtt-connector).

## What's in this sub-section

* [**Sonoff ZBDongle-E coordinator**](/gateways/zigbee2mqtt-hubs/sonoff-zbdongle-e-coordinator) — Step-by-step physical setup for the specific Zigbee coordinator we tested with. If you have this exact dongle, this page covers everything from plugging it in to confirming Linux sees it.

The pages here are tested-hardware walkthroughs. If you have one of the specific coordinators below, follow the page for the detail. If you have a different supported coordinator, the [generic Zigbee2MQTT setup page](/connectors/mqtt-connector/zigbee2mqtt) covers the broader install — pair the device through Z2M, register it in Chirp, the rest is identical.

## What a Zigbee2MQTT hub actually is

Three things, working together:

1. **A host machine.** The computer Z2M runs on. Linux is the most common (Raspberry Pi, NUC, mini-PC), but macOS and Windows also work. The machine needs a USB port (for USB coordinators) or network access (for network-attached coordinators), Docker installed, and a stable always-on connection. It does not need to be powerful — a 5-year-old Raspberry Pi handles a typical home Zigbee mesh fine.
2. **A Zigbee coordinator.** A small USB or network-attached radio that speaks Zigbee. The Sonoff ZBDongle-E and ZBDongle-P are the most common starter coordinators; SMLIGHT SLZB-06 is a popular network-attached option. Any [Zigbee2MQTT-supported coordinator](https://www.zigbee2mqtt.io/guide/adapters/) works.
3. **Zigbee2MQTT itself** — the software, running in Docker on the host machine. Z2M opens the coordinator's serial port (or network connection), joins Zigbee devices, and translates their messages into MQTT publishes that Chirp consumes.

```
Zigbee bulbs, sensors  →  [Zigbee mesh]
                                ↓
                          Coordinator radio (USB or network)
                                ↓
                          Host machine running Z2M
                                ↓
                          MQTT  →  Chirp
```

The coordinator alone doesn't reach Chirp. USB coordinators (ZBDongle-E, ZBDongle-P, ConBee II, SkyConnect) have no IP stack, no Wi-Fi, no Ethernet — they're pure Zigbee radios speaking serial over USB. Network-attached coordinators (SMLIGHT SLZB-06 and similar) do have an IP interface, but only as transport between the radio and Z2M; they don't run MQTT either. In both cases, the coordinator is the Zigbee radio bridge and Z2M is what turns the Zigbee mesh into MQTT publishes. They are always two separate things working together.

## Why "hub" and not "gateway"?

Both words describe what this hardware does, but we use "hub" specifically for the Zigbee2MQTT setup to distinguish it from LoRaWAN gateways:

* A **LoRaWAN gateway** is a single integrated box that listens for sensors and forwards their data over your home internet. The hardware does the whole job.
* A **Zigbee2MQTT hub** is a host machine plus a coordinator plus software. The pieces are visible and configurable — you choose the host, you choose the coordinator, you configure Z2M.

Both connect into Chirp; they're just different shapes.

## How this differs from LoRaWAN gateways

Different radios, different range characteristics:

|                            | LoRaWAN gateway                                                 | Zigbee2MQTT hub                                                 |
| -------------------------- | --------------------------------------------------------------- | --------------------------------------------------------------- |
| Protocol                   | LoRaWAN (LoRa physical layer)                                   | Zigbee 3.0                                                      |
| Range from one gateway/hub | Whole home, garden, often more                                  | Per device hop — most rooms, ceilings/walls reduce range        |
| Mesh                       | No (star topology — every sensor talks to the gateway directly) | Yes (devices forward for each other)                            |
| Hardware                   | Single integrated box                                           | Host machine + coordinator + Z2M software                       |
| Typical battery life       | Years on a single charge                                        | Months to a year for sensors; mains-powered for bulbs and plugs |
| Best for                   | Whole-property coverage with battery sensors                    | Indoor smart home — bulbs, plugs, room sensors                  |

A home can run both side by side. The two networks don't interfere — they use different parts of the radio spectrum and don't share airtime.

## What's next

If you're starting from scratch and you have a Sonoff ZBDongle-E (the dongle we tested with), open the [Sonoff ZBDongle-E coordinator](/gateways/zigbee2mqtt-hubs/sonoff-zbdongle-e-coordinator) page for physical setup, then the generic [Setting up Zigbee2MQTT](/connectors/mqtt-connector/zigbee2mqtt) page for the software install.

For other coordinators, head straight to the generic Z2M setup page; the procedure is identical except for the `serial.adapter` value, which depends on your coordinator's chip family.


# Sonoff ZBDongle-E Coordinator

Plug in the Sonoff ZBDongle-E, confirm Linux sees it, and get ready to run your Zigbee2MQTT hub.

This is a hardware-specific walkthrough for setting up a **Sonoff ZBDongle-E** — the Zigbee coordinator dongle we tested our Zigbee2MQTT-on-Chirp setup with. If you have this exact dongle, follow these steps to confirm it's plugged in correctly and Linux sees it. Then continue to [Setting up Zigbee2MQTT](/connectors/mqtt-connector/zigbee2mqtt) for the software install — Z2M is generic across coordinators, so once your dongle is detected, the rest of the setup follows the same flow as any other supported coordinator.

If you have a **different coordinator** — Sonoff ZBDongle-P, SLZB-06, ConBee II, SkyConnect, etc. — you don't need this page. Z2M supports many coordinators, and the [Z2M adapter guide](https://www.zigbee2mqtt.io/guide/adapters/) covers them all. The Sonoff ZBDongle-E happens to be the one we tested with — others work just as well.

## What's in the box

The Sonoff ZBDongle-E ("Dongle Plus MG24") ships with:

* The USB dongle (antenna built in)
* A short USB-A extension cable

That's it. No driver disc, no software, no batteries.

## Step 1 — plug it in (use the extension cable)

**Always use the included extension cable.** Plugging the dongle directly into a motherboard USB port causes the metal of your computer chassis to attenuate the 2.4 GHz Zigbee signal. The cable physically moves the antenna away from interference, and the difference in pairing reliability and range is significant.

1. Connect the short extension cable to the dongle.
2. Plug the cable into any available USB-A port on your machine.
3. Watch the LED on the dongle:
   * **Solid blue** — powered up and running coordinator firmware.
   * **No light** — check the cable and try a different USB port.
4. Wait about 3 seconds for Linux to enumerate the device.

That's the entire physical install. No driver to download, no installer to run, no reboot needed.

## Step 2 — confirm Linux sees the dongle

The CP210x USB-UART chip used in the ZBDongle-E is supported natively by the Linux kernel since version 3.x. The driver loads automatically.

```bash
ls /dev/tty* | grep -E "USB|ACM"
```

You should see `/dev/ttyUSB0`. (If you have other USB-serial devices already plugged in, your dongle will be the highest-numbered `/dev/ttyUSBN`.)

```bash
lsusb | grep -i silicon
```

Expected output:

```
Bus 003 Device 004: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
```

The `10c4:ea60` USB ID is the CP210x chip — used by both the ZBDongle-E **and** the ZBDongle-P. You **cannot** tell the two dongles apart from `lsusb` alone. The packaging or the label on the dongle body is the only reliable way:

| Dongle                                                       | Radio chip | Z2M `serial.adapter:` value |
| ------------------------------------------------------------ | ---------- | --------------------------- |
| **ZBDongle-E** (look for "MG24" or "EFR32" on the packaging) | EFR32MG24  | `ezsp`                      |
| ZBDongle-P (look for "CC2652P")                              | CC2652P    | `zstack`                    |

Picking the wrong adapter value in `configuration.yaml` causes Z2M to log `Error: Failed to find adapter` and exit. **For the ZBDongle-E it's `ezsp`** — write that down for the next step.

## Step 3 — verify the driver

Optional but useful for confirming everything is healthy:

```bash
cat /sys/class/tty/ttyUSB0/device/uevent
```

Expected line:

```
DRIVER=cp210x
```

```bash
ls -la /dev/ttyUSB0
```

Expected output (the exact group may be `dialout` or `uucp` depending on distribution):

```
crw-rw---- 1 root dialout 188, 0 ... /dev/ttyUSB0
```

## Step 4 — Linux permissions (if running Z2M outside Docker)

If you'll run Z2M in **Docker** (the recommended path), you can skip this step — the Docker container runs as root inside its namespace and reaches the device through the `devices:` mapping in `docker-compose.yml`. Host-side `dialout` membership doesn't matter.

If you're running Z2M directly on the host (not in a container), your user needs to be in the `dialout` group:

```bash
id $USER | grep dialout
```

If you don't see `dialout` in the output, add yourself:

```bash
sudo usermod -aG dialout $USER
```

Log out and back in to apply the change.

## Step 5 — does any of this run MQTT? (No — and why this matters)

A common confusion at this point is "I plugged in the dongle, where is the MQTT?"

The answer: **the dongle doesn't speak MQTT.** It has no IP stack, no Wi-Fi, no Ethernet, no operating system. It's a Zigbee radio with firmware, communicating with your machine over USB serial using a binary protocol called EZSP. That's all.

MQTT runs in the Zigbee2MQTT software you'll install next. The full data flow looks like this:

```
Zigbee bulb / sensor  →  [Zigbee 2.4 GHz radio]
                              ↓
                          Sonoff ZBDongle-E (radio + EZSP firmware, USB)
                              ↓
                          /dev/ttyUSB0 (serial)
                              ↓
                          Zigbee2MQTT (Docker container on your host)
                              ↓
                          MQTT (TCP/TLS)
                              ↓
                          Chirp
```

The dongle's only job is translating between the Zigbee radio signal and the EZSP serial commands Z2M understands. All the intelligence — device identification, pairing, friendly names, MQTT publishing — lives in Z2M.

Practical implication: if you stop the Z2M container, MQTT stops. The dongle's LED stays on (it's still running) but nothing reaches Chirp. The dongle is passive hardware; Z2M is the active link.

## Step 6 — what about firmware?

The ZBDongle-E ships from the factory with Zigbee coordinator firmware pre-installed. **You do not need to flash it** before use. Firmware updates are only needed for specific known bugs in old versions, which you're unlikely to hit with a freshly-purchased dongle.

If you're curious what firmware version your dongle is running, you'll see it in the Z2M startup logs once Z2M is installed:

```
z2m: Coordinator firmware version: ... type EZSP v13
```

`EZSP v13` confirms the chip is an EFR32MG family (matches `adapter: ezsp` in `configuration.yaml`). The build number (e.g. `7.4.5.0 build 0`) is the actual firmware version.

## What's next

The dongle is plugged in, detected, and ready. Time to install the software.

Continue to [Setting up Zigbee2MQTT](/connectors/mqtt-connector/zigbee2mqtt) for the Docker Compose setup, `configuration.yaml` template, and first-publish verification. The page is generic across coordinators — when it asks for `serial.adapter:` and `serial.port:`, use:

```yaml
serial:
  port: /dev/ttyUSB0
  adapter: ezsp
```

After Z2M is running and your first device is paired, the [Paulmann 50064 walkthrough](/devices/tested-device-guides/zigbee/paulmann-50064-light-bulb) covers a tested end-device pairing flow if you have that specific bulb. For other devices, follow the manufacturer's pairing instructions — once Z2M sees the device, registering it in Chirp is the same regardless of make or model.


# Alarm

See how Chirp turns sensor readings into home alerts, with an Inbox, alarm rules, and contact settings.

Your sensors watch your home around the clock, but you are not always looking at the dashboard. The Alarm section bridges that gap — when a reading crosses a threshold you care about, Chirp notifies you through the channels you choose so you can act before a small problem becomes a bigger one.

> **How triggers and response work together:** The [Rules Engine](/rules-engine) decides *when* an alarm is raised — it evaluates sensor data and fires an alarm when conditions are met. The Alarm section defines *what happens after* the alarm fires: who gets notified, through which channels, how often, how escalation proceeds if nobody responds, and when notifications are suppressed.

## What you will find here

The Alarm page has three tabs:

* **Inbox** — Every alarm event that has fired, with its current status. Filter by severity or status, search by title, resolve alarms, or jump to the originating rule.
* **Alarm definitions** — Your alarm configurations. Each definition sets the severity, escalation chain, notification schedule, suppression window, and message for a specific type of alert. Click **Add alarm rule** to create a new one.
* **Settings** — Your contact methods. Add or verify email and SMS contacts, enable or disable delivery per channel, and manage push notification delivery through the [Chirp Alerts app](/alarm/chirp-alerts-app).

A **Notification Severity** button in the page header (visible on all tabs) opens a separate modal for controlling how often each severity level repeats.

## Severity levels

Chirp uses five severity levels to prioritize alarms:

| Level        | When to use it                                                                             |
| ------------ | ------------------------------------------------------------------------------------------ |
| **Critical** | Emergencies requiring immediate action — water leaks, fire alarms, security breaches       |
| **High**     | Urgent situations that need prompt attention — freezer temperature spikes, failing sensors |
| **Medium**   | Important but not time-critical — humidity drifting out of range, unusual energy use       |
| **Low**      | Routine awareness — minor fluctuations, scheduled check-ins                                |
| **Info**     | Background monitoring — status confirmations, periodic health reports                      |

Each level has its own notification repeat policy that you can configure in [Notification Severity](/alarm/notification-severity).

## Escalation

When an alarm fires and nobody resolves it, Chirp can escalate — notifying additional people through additional channels after a configurable delay. This means your home is never left unattended just because one person missed a notification.

For full details, see [Escalation Chains](/alarm/escalation-chains).

## Where to go next

* [Set Up a Home Alert](/alarm/set-up-a-home-alert) — Walk through creating an alarm definition: name, severity, escalation chain, schedule, message.
* [Escalation Chains](/alarm/escalation-chains) — How multi-step escalation works for unresolved alarms.
* [Notification Severity](/alarm/notification-severity) — Configure how often each severity level repeats.
* [Check and Clear Alerts](/alarm/check-and-clear-alerts) — Review what has happened, resolve alarms, and keep your inbox manageable.
* [Manage Contact Methods](/alarm/manage-contact-methods) — Add email addresses, verify them, and manage notification channels.
* [Chirp Alerts App](/alarm/chirp-alerts-app) — Install the mobile app for push notifications. Critical alerts ring with an alarm sound and vibration until silenced or acknowledged.


# Set Up a Home Alert

Create an alarm definition that sets severity, channels, schedule, and message for a home alert.

An alarm definition tells Chirp what to do when an automation in the [Rules Engine](/rules-engine) fires an alarm — who to notify, how urgently, through which channels, and what happens if nobody responds.

To create one, open the **Alarm** page from the sidebar, switch to the **Alarm definitions** tab, and click **Add alarm rule**.

## Alarm name

Give your alarm a clear name that describes what it watches for. This name appears in the Inbox when the alarm fires, so make it specific enough to act on at a glance.

| Field          | Detail                                           |
| -------------- | ------------------------------------------------ |
| **Alarm name** | Text field. Placeholder: *Enter name*. Required. |

## Severity

Choose how urgent this alarm is. The severity level controls how often notifications repeat (based on your [Notification Severity](/alarm/notification-severity) settings), how the alarm appears in the Inbox, and how push notifications behave on the [Chirp Alerts app](/alarm/chirp-alerts-app/alert-behavior).

| Field               | Detail                                                          |
| ------------------- | --------------------------------------------------------------- |
| **Choose severity** | Dropdown. Options: Critical, High, Medium, Low, Info. Required. |

After you select a severity, a note appears below the dropdown showing the current repeat policy for that level — for example, how frequently notifications re-send if the alarm stays active. You can override this with a custom interval (see below).

## Custom notification interval

By default, the alarm uses the repeat policy from your [Notification Severity](/alarm/notification-severity) settings. Turn this on to override that policy for this specific alarm.

| Field                            | Detail                                                                                                                                                                                                                            |
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Custom Notification interval** | Toggle (Off by default). When On, shows interval and one-time controls.                                                                                                                                                           |
| **Interval**                     | Number + unit (Hours or Days).                                                                                                                                                                                                    |
| **One-time notification**        | Toggle. When On, the alarm sends one notification and does not repeat. A message appears confirming: *"\[Severity] notifications are sent once. You can change it below."* — where \[Severity] matches the severity you selected. |

## Escalation chain

The escalation chain determines who gets notified and when. The first step fires immediately. If the alarm is not resolved, additional steps fire after configurable delays.

This section is covered in detail on the [Escalation Chains](/alarm/escalation-chains) page. In brief:

* The first step is always **Immediate** and cannot be removed.
* Click **Add step** to add escalation tiers with configurable delays.
* Each step has: **Notify** (recipients — **required**, you must select at least one person), **Via** (channels — Email and SMS are selectable; Push when enabled).
* Unresolved alarms continue through the configured chain until someone marks the event as resolved in the [Inbox](/alarm/check-and-clear-alerts).

## Schedule

Control when this alarm is active. By default, alarms are active 24/7.

| Field               | Detail                                                                             |
| ------------------- | ---------------------------------------------------------------------------------- |
| **Schedule**        | Shows the current schedule or "24/7 by default".                                   |
| **Change schedule** | Button that opens a popover with day-of-week toggles and a time range (From / To). |

Use scheduling for alarms that only matter during certain hours — for example, a "front door opened" alarm that you only want between 11 PM and 6 AM.

## Suppress duplicates

Prevent the same alarm from firing repeatedly within a short window. This is useful for sensors that report frequently — without suppression, a sensor reading every 30 seconds could generate dozens of identical alarms.

| Field                                                   | Detail                       |
| ------------------------------------------------------- | ---------------------------- |
| **Suppress duplicates within this window (in minutes)** | Slider. Range: 1–60 minutes. |

## Message

The message appears in every notification sent by this alarm. Write it so the recipient immediately understands what happened and what to do.

| Field            | Detail                                                                                   |
| ---------------- | ---------------------------------------------------------------------------------------- |
| **Theme**        | The notification subject line. Placeholder: *Fire alarm in the kitchen*. Required.       |
| **Message body** | The notification body text (multiline, 3 rows). Placeholder: *Your text here*. Required. |

## Saving and managing

Click **Add new alarm rule** to create the definition (or **Save** if editing an existing one). Click **Cancel** to discard changes.

Once created, your alarm definition appears in the **Alarm definitions** tab:

* **Toggle** the switch to enable or disable the alarm without deleting it.
* **Edit** to reopen the definition and change any field.
* **Delete alarm** (available inside the edit form) permanently removes the definition.

## Home examples

* **Basement flood alarm:** Severity Critical, immediate notification to homeowner via email and push, escalation to partner via SMS if unresolved. Schedule: 24/7. Suppression: 5 minutes.
* **Freezer temperature spike:** Severity High, notify homeowner. Theme: "Freezer temperature rising." Message: "The kitchen freezer sensor has reported an unusual reading."
* **Front door after bedtime:** Severity Medium, schedule active 11 PM – 6 AM only. Notify both household members immediately.


# Escalation Chains

Build a step-by-step chain so an unresolved home alert reaches more people until someone responds.

When an alarm fires and nobody resolves it, you do not want it to disappear into a missed notification. Escalation chains make sure the right people find out — starting with the first person who should know, and reaching out to others if the alarm stays unresolved.

## How escalation works

Every alarm definition includes an **Escalation chain** — a sequence of steps that tell Chirp who to notify and when.

The first step always fires **immediately** when the alarm is triggered. If nobody resolves the alarm within a configurable delay, the next step fires, notifying additional recipients through additional channels. This continues through each step until the alarm is either resolved or every step has been executed.

**Resolving an alarm stops escalation.** Once you or another household member marks the alarm as resolved in the [Inbox](/alarm/check-and-clear-alerts), no further escalation steps fire for that event.

## Setting up an escalation chain

When you [create or edit an alarm definition](/alarm/set-up-a-home-alert), the **Escalation chain** section appears in the alarm form.

### The first step

The first step is always present and cannot be removed. Its delay is set to **Immediate** — recipients in this step are notified the moment the alarm fires.

For each step, you configure:

* **Notify** — Select one or more household members from the **Choose recipients** dropdown. **Required** — you must select at least one person or the definition cannot be saved.
* **Via** — Select the delivery channels. Email and SMS are selectable in every step. Push notifications are delivered through the [Chirp Alerts app](/alarm/chirp-alerts-app) and appear when enabled for your account (see [Manage Contact Methods](/alarm/manage-contact-methods)).

### Adding more steps

Click **Add step** to add an escalation step. Each additional step has:

* **After** — A configurable delay. This is how long Chirp waits after the previous step before firing this one. The alarm must still be unresolved for this step to execute.
* **Notify** — Recipients for this step (can be different from earlier steps).
* **Via** — Channels for this step (can also be different).

You can add as many steps as your household needs. Only the first step is permanent — additional steps can be removed with the delete button.

### Reordering and removing

Additional steps appear in order below the first step. Remove a step by clicking the trash icon on its row. The first step cannot be removed.

## Example: household escalation

Imagine a water leak sensor in the basement triggers an alarm at 2 AM:

1. **Step 1 (Immediate):** Notify the homeowner via email and push notification.
2. **Step 2 (after a configurable delay):** If the alarm is still unresolved, notify the homeowner's partner via SMS.
3. **Step 3 (after another configurable delay):** If still unresolved, notify a trusted neighbor or caretaker via email and SMS.

Without escalation, that 2 AM leak notification might sit unread until morning. With a well-configured chain, someone in your household or support network will know about it — even if the first person misses the alert.

## Tips

* **Put the most likely responder in the first step.** They get the notification immediately and can resolve the alarm before anyone else is disturbed.
* **Use different channels for different steps.** If the first step sends email and the second sends SMS, you increase the chance that someone actually sees the notification.
* **Keep escalation chains short and purposeful.** Two or three steps cover most home scenarios. Each step should reach someone who can actually act on the alarm.
* **Test your escalation.** Trigger a test alarm and walk through the chain to make sure each step reaches the right person through the right channel.


# Notification Severity

Set the five severity levels and choose how often each one re-sends a reminder while an alarm stays active.

Chirp uses five severity levels to classify alarms by urgency. Each level carries its own notification repeat policy — how often Chirp re-sends the notification while the alarm stays active. You can adjust these policies to match how your household responds to different kinds of alerts.

## Opening the severity settings

Click the **Notification Severity** button in the Alarm page header. This button is visible on all tabs (Inbox, Alarm definitions, and Settings). It opens a modal titled **Notification severity** with the subtitle: *"Choose how often notifications should be sent. You can enable a one-time notification or set a repeat interval."*

## The five severity levels

| Level        | Typical use                                                                                                                |
| ------------ | -------------------------------------------------------------------------------------------------------------------------- |
| **Critical** | Emergencies — water leaks, smoke detection, security breaches. You want to know immediately and be reminded until you act. |
| **High**     | Urgent — freezer temperature spikes, failed sensors. Needs prompt attention but may not be a safety issue.                 |
| **Medium**   | Notable — humidity drifting outside comfort range, unusual energy patterns. Worth knowing about, but action can wait.      |
| **Low**      | Routine — minor fluctuations, background conditions changing. Awareness-level information.                                 |
| **Info**     | Background — periodic status updates, sensor health confirmations. No action expected.                                     |

## Configuring repeat behavior

For each severity level, you can set:

* **One-time notification** — Toggle this On to send a single notification when the alarm fires. No repeats. Turn it Off to use a recurring interval.
* **Repeat interval** — When one-time is Off, set how often the notification re-sends (a number + unit: Hours or Days). The alarm keeps repeating at this interval until someone resolves it.

## Per-alarm overrides

The severity policy sets the default repeat behavior for every alarm at that level. If a specific alarm needs different timing, you can override the policy directly in the [alarm definition](/alarm/set-up-a-home-alert) using the **Custom Notification interval** toggle.

When an alarm has a custom interval, it uses that setting instead of the global policy for its severity level.

## Tips

* **Start with one-time for Info and Low.** These are awareness-level notifications — repeated reminders for background information can become noise.
* **Use recurring intervals for Critical and High.** You want persistent reminders for emergencies and urgent issues until someone resolves them.
* **Revisit your settings after the first week.** Once you see how your alarms behave in practice, adjust the intervals to match your household's response patterns.
* **Severity also controls push behavior.** If you use the [Chirp Alerts app](/alarm/chirp-alerts-app/alert-behavior), the severity you assign here determines whether an alert triggers a full-screen alarm on your phone (critical), a prominent notification (important), or a quiet notification (information).


# Check and Clear Alerts

Review what fired in your Inbox, filter by severity or status, and resolve home alerts to stop escalation.

When an alarm fires, Chirp records it in your Inbox. This is where you see what happened, when it happened, and whether it still needs your attention. Resolving an alarm stops its [escalation chain](/alarm/escalation-chains) — no further steps fire once the event is marked as resolved.

The Inbox is the default tab when you open the **Alarm** page from the sidebar.

## Filtering

Two dropdown filters sit above the alarm list:

| Filter       | Options                                         |
| ------------ | ----------------------------------------------- |
| **Severity** | All severity, Critical, High, Medium, Low, Info |
| **Status**   | All status, Active, Resolved                    |

Use these to focus on what matters right now — for example, show only **Critical** + **Active** to see emergencies that still need attention.

## Searching

A search input lets you filter by alarm title. Start typing and the list narrows to matching results. If nothing matches, Chirp shows: *"We can't find your alarm."*

## Alarm list

On desktop, each alarm appears as a row with these columns:

| Column            | What it shows                                                                                                                        |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| **Alarm**         | The alarm title (or definition name), with a status indicator — a warning triangle for active alarms, a checkmark for resolved ones. |
| **Message**       | The notification message body.                                                                                                       |
| **Severity**      | The severity level, color-coded.                                                                                                     |
| **First trigger** | When the alarm first fired.                                                                                                          |
| **Last trigger**  | When the alarm most recently fired.                                                                                                  |
| **Actions**       | **Mark as resolved** button and a link to the originating rule.                                                                      |

On mobile, alarms appear as compact cards with the same information in a condensed layout.

### Empty state

If no alarms have fired yet, the Inbox shows: *"No alarms yet — To see alarms, create a rule and let it generate activity."*

## Resolving an alarm

Click **Mark as resolved** on an active alarm to mark it as resolved. This does two things:

1. The alarm status changes from **Active** to **Resolved** — the indicator switches from a warning triangle to a checkmark.
2. Any remaining [escalation steps](/alarm/escalation-chains) for this event are cancelled. No further notifications are sent.

Resolved alarms stay in the Inbox for your records. They do not disappear.

## Going to the originating rule

Each alarm has a link that navigates to the automation in the Rules Engine that triggered it (at `/rules/:ruleId/view`). This is useful when you need to understand why the alarm fired — what conditions were met, what sensor data triggered it, and whether the rule logic needs adjusting.

## Tips

* **Resolve alarms when the issue is handled.** An unresolved alarm continues to escalate and re-send notifications. Resolving it is how you tell Chirp "I've seen this and it's under control."
* **Use severity filters during busy periods.** If you have many alarms, filter to Critical and High first to prioritize what needs immediate action.
* **Check the originating rule if an alarm seems wrong.** If an alarm fires unexpectedly, the Rules Engine rule might have a condition that is too sensitive or a sensor that is reporting unexpected data.
* **Resolve alerts from your phone.** If you have the [Chirp Alerts app](/alarm/chirp-alerts-app/managing-alerts) installed, you can resolve and manage alerts directly from your phone without opening the web platform.


# Manage Contact Methods

Add and verify email and SMS contacts, then choose which channels deliver your home alerts.

When Chirp fires an alarm, notifications go to the contact methods you have set up. The **Settings** tab on the Alarm page is where you manage these contacts — add new ones, verify them, control which channels are active, and remove contacts you no longer need.

## Email

Email is the baseline notification channel.

### Enabling and disabling

An **On/Off** toggle at the top of the Email section controls whether email notifications are delivered. Turning it **Off** stops ALL alarm notifications via email — a confirmation dialog appears before this takes effect. Turn it back **On** to resume delivery. The toggle may be disabled if no email contacts are configured or if the channel is not available in the current account context.

### Adding a contact

Click the add button to enter a new email address. Chirp sends a verification email immediately. The contact appears in your list with an unverified indicator until the recipient clicks the verification link.

### Verification

Each email address must be verified before it receives alarm notifications. Unverified contacts show a warning indicator. If a verification email was not received, you can resend it.

### Removing a contact

Click the remove button next to a contact to delete it. A confirmation dialog appears before the contact is removed. Your primary email contact (the first one in the list) cannot be removed.

Contacts cannot be edited after creation. To change an email address, remove the old one and add the new one.

## SMS

SMS is present in the Alarm settings and selectable as a delivery channel in [escalation steps](/alarm/escalation-chains). The SMS section works the same way as Email: add contacts, verify them, enable or disable the channel with the On/Off toggle, and remove contacts you no longer need.

Turning SMS **Off** stops all alarm notifications via SMS. The same confirmation dialog appears before disabling.

## Push Notifications

Push notifications are delivered through the **Chirp Alerts** mobile app, available for [iPhone](https://apps.apple.com/us/app/chirp-alerts/id6756504956) and [Android](https://play.google.com/store/apps/details?id=io.chirpwireless.alarm).

### Setup

1. Install the Chirp Alerts app on your phone and sign in with your Chirp credentials.
2. In the Chirp web platform, go to **Alarm** → **Settings** tab. The **Push** section shows download links and an **On/Off** toggle.
3. Once the web platform detects your device, the toggle becomes usable. Turn it **On** to enable push delivery.

### Enabling and disabling

The **On/Off** toggle in the Push section controls whether push notifications are delivered. Turning it **Off** stops ALL alarm notifications via push. Turning it back **On** resumes delivery. This works the same way as the Email and SMS toggles.

### Using push in escalation steps

Once push is enabled, it appears as a selectable delivery channel when configuring [escalation steps](/alarm/escalation-chains). You can route critical alarms through push alongside email and SMS, or use push as a standalone channel.

For the full mobile experience — how alerts appear on your phone, the alarm screen, inbox, and rule management — see the [Chirp Alerts App](/alarm/chirp-alerts-app) section.

## How contacts and channels connect to alarms

The contacts you set up here are the people available in the **Choose recipients** dropdown when you configure [escalation steps](/alarm/escalation-chains) in an alarm definition. Each escalation step can select different recipients and different channels, so you can route Critical alarms to one set of contacts and Low-priority alarms to another.

If you turn a channel **Off** in Settings, that channel is disabled for delivery across ALL alarm definitions and ALL escalation steps that use it. Turning the channel back On resumes delivery for all affected alarms.


# Chirp Alerts App

Get Chirp alerts on your phone with the IoT Alerts app — critical alarms ring until you respond.

Your sensors don't wait for you to be at a screen, and neither should your alerts. The mobile app puts your home's alarms straight on your phone — and when something serious happens, it doesn't just buzz once and hope you notice. A critical alert rings with an alarm sound and keeps going until you check it, even if your phone is on silent.

Think of it as the difference between a text you might glance at later and a smoke detector going off. The app delivers both: gentle, quiet notes for the everyday stuff, and a loud, can't-miss-it alarm for the emergencies.

## One app for home and business

The app you install is called **IoT Alerts**, and the first time you open it, it asks how you'll use it. For your Chirp smart home, choose **Home Use**. That tells the app to sign you in to your Chirp account and show your home's alerts. (The other option, Business Use, is for the Kilo platform — you won't need it for your home.)

## Get the app

* **iPhone:** [App Store](https://apps.apple.com/us/app/chirp-alerts/id6756504956)
* **Android:** [Google Play](https://play.google.com/store/apps/details?id=io.chirpwireless.alarm)

You might see the app listed under the name **Chirp Alerts** while the new name rolls out — it's the same app, so go ahead and install it. After it's open, pick **Home Use**.

It's the same Chirp login you already use. Whatever email and password (or Google or Apple sign-in) gets you into Chirp on the web works here too, and you'll see the same homes you already belong to.

## Why critical alerts can wake your phone

Phones normally keep notifications quiet when they're on silent or in a Focus / Do Not Disturb schedule — which is great for spam, but not for a flooding basement. Apple only lets a handful of trusted apps override that, and the IoT Alerts app has been granted that **Critical Alerts** approval. So when you mark an alarm as critical, it can ring through even a silenced phone — as long as you say yes to the alert permission when the app asks.

The everyday alerts still respect your quiet settings. Only the critical ones break through. [Alert Behavior](/alarm/chirp-alerts-app/alert-behavior) walks through exactly what each level does.

## A few examples

* **Basement water leak** → set it **critical**. Your phone rings like an alarm clock until you look.
* **Garage door still open at bedtime** → set it **important**. A noticeable notification nudges you, no full alarm.
* **Front door opened during the afternoon** → set it **information**. A quiet note you'll spot when you next pick up your phone.

## What's inside the app

* **Inbox** — every alert and whether it's still active. Resolve the ones you've handled or clear old ones.
* **Alert Definitions** — the alarms you set up on the web. Flip any one off from your phone if it's getting noisy.
* **Home switching** — belong to more than one home? Switch between them from the menu.

## Where to do what

You build and fine-tune your alarms on the Chirp web platform; the app is where they land and where you respond.

* **On the web:** [Set Up a Home Alert](/alarm/set-up-a-home-alert) · [Escalation Chains](/alarm/escalation-chains) · [Notification Severity](/alarm/notification-severity) · [Manage Contact Methods](/alarm/manage-contact-methods)
* **In the app:** [Getting Started](/alarm/chirp-alerts-app/getting-started) · [Alert Behavior](/alarm/chirp-alerts-app/alert-behavior) · [Managing Alerts](/alarm/chirp-alerts-app/managing-alerts)


# Getting Started

Install IoT Alerts, pick Home Use, sign in to Chirp, and get your phone ready for alerts.

You can be up and running in about five minutes. Once the app is installed and push is switched on, your phone is ready to catch alerts from your home sensors — day or night. If more than one person in your household wants alerts, have each of them follow these same steps on their own phone.

## Step 1 — Install the app

* **iPhone:** [App Store](https://apps.apple.com/us/app/chirp-alerts/id6756504956)
* **Android:** [Google Play](https://play.google.com/store/apps/details?id=io.chirpwireless.alarm)

If the store still shows the name **Chirp Alerts**, that's fine — it's the same app while the new name rolls out.

## Step 2 — Choose Home Use

The first time you open the app, it asks **"How will you use the app?"** Tap **Home Use** — the option labeled *Chirp Wireless — alerts for your home IoT devices* — then tap **Continue**. This sets the app up for your Chirp home.

<figure><img src="/files/KMhaqLKq0CHB7zW3sCXt" alt="IoT Alerts mode-select screen — choose Home Use for Chirp" width="300"><figcaption></figcaption></figure>

You can change this later under **Settings → Platform**, but switching to Business mode signs you out, so there's no reason to touch it for your home setup.

## Step 3 — Sign in

Sign in with the same Chirp account you use on the web — there's no new account to create:

* **Email and password** — the same login you use at [app.chirpwireless.io](https://app.chirpwireless.io)
* **Google** or **Apple** — if you linked your Chirp account to one of them

Once you're in, you'll see the same homes you belong to on the web.

<figure><img src="/files/1rVRXxsC7Ik0KkCUevvq" alt="Chirp Alerts sign-in screen with Google, Apple, and email options" width="300"><figcaption></figcaption></figure>

## Step 4 — Say yes to notifications (and Critical Alerts)

The app will ask for two things, and you want to allow both:

* **Notifications** — without this, the app simply can't reach your phone.
* **Critical Alerts** — this is the special permission that lets an emergency alarm ring through even when your phone is on silent or Do Not Disturb. If you skip it, your critical alarms will be held quiet by your phone just like any other notification.

Tapped the wrong button by accident? You can turn them back on later:

* **iPhone:** Settings → Notifications → IoT Alerts → turn on Allow Notifications and Critical Alerts
* **Android:** Settings → Apps → IoT Alerts → Notifications → turn on

## Step 5 — Flip on push on the web

One last switch on the web tells Chirp it's allowed to send alerts to your phone:

1. Open [app.chirpwireless.io](https://app.chirpwireless.io) and go to the **Alarm** page.
2. Open the **Settings** tab.
3. Find the **Push** section — it becomes available once Chirp notices your phone is signed in — and turn it **On**.

That's it. From now on, push is one of the channels you can pick when you set up [escalation steps](/alarm/escalation-chains), right alongside email and text. For more on choosing channels, see [Manage Contact Methods](/alarm/manage-contact-methods).

## Got more than one home?

Tap the menu icon in the top-left and pick a home from the list. The Inbox and Alert Definitions switch to show that home's alerts.

## Languages

The app speaks English, German, Spanish, French, and Portuguese, following your phone's language.


# Alert Behavior

Which alerts ring through on silent and which arrive quietly — set by the severity you choose.

Here's the thing that makes the app genuinely useful: not every alert treats your phone the same way. A leaking water heater should wake you up; a door opening in the afternoon shouldn't. You decide which is which by the **severity** you give each alarm when you set it up on the web — and that single choice controls how loud (or quiet) the alert is on your phone.

## The quick version

| You set the alarm to… | …and your phone does this                                                                                                                                                         |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Critical**          | Opens a full-screen alarm with a sound that loops and vibration, and keeps going until you respond. This is the **only** level that rings through silent mode and Do Not Disturb. |
| **Important**         | Shows a prominent notification with a sound and a buzz — more noticeable than usual, but no full-screen alarm and no looping.                                                     |
| **Information**       | Drops a quiet notification into your normal list — no sound, no vibration. You'll see it next time you glance at your phone.                                                      |

If an alert ever comes through without a severity set, the app plays it safe and treats it as **critical** — better a false alarm than a missed flood.

## Critical — the wake-you-up alarm

A critical alert takes over the screen: a pulsing warning, the device name, the message, and the time, with the alarm sound looping and the phone vibrating. It's built to get your attention when your phone is face-down, locked, or silenced.

This is the level that uses the app's **Critical Alerts** approval from Apple, which is what lets it ring through a silent phone or a Do Not Disturb schedule. It only works if you allowed Critical Alerts when the app asked (Step 4 of [Getting Started](/alarm/chirp-alerts-app/getting-started)) — if you didn't, your phone's quiet settings will hold even critical alarms back.

When the alarm is ringing, you've got two choices:

* **Close** — hushes the alarm on your phone, but the alert stays active in Chirp. Other people in the house still see it, and the alert keeps escalating if you set that up.
* **Dismiss & Acknowledge** — hushes the alarm and marks the alert resolved for everyone in the home.

Save critical for the real emergencies: water leaks, fire, a security breach, a freezer that's failing.

## Important — a firm tap on the shoulder

An important alert pops up clearly, with sound and vibration, but it won't take over your screen or loop. It's for things you should look at soon but that aren't a wake-the-house emergency — a temperature spike, a sensor acting up, a reading that's drifting.

## Information — a quiet heads-up

An information alert slips in quietly, no sound or buzz. It's a normal notification you can read whenever — not a hidden background message, just a calm one. Use it for the everyday: a door opening during the day, a routine check-in, the kind of thing you like to know about but don't need to jump on.

## It all comes from severity

Every behavior above traces back to the severity you pick when you [create the alarm](/alarm/set-up-a-home-alert). Want it louder? Bump the severity up. Too noisy? Bring it down. For how severity also controls how often an alert repeats, see [Notification Severity](/alarm/notification-severity).

## When delivery can lag

Push depends a little on your phone's mood:

* If you've force-stopped the app (Android) or swiped it away (iPhone), alerts may not arrive until you open it again.
* Some Android phones aggressively save battery and can delay alerts — letting the app run in the background fixes that.
* The surest setup is to keep the app installed on everyone's phone and use [escalation chains](/alarm/escalation-chains), so if one person misses an alert, it moves on to the next.


# Managing Alerts

View, resolve, and quiet your home alerts from the app's Inbox and Alert Definitions tabs.

Once alerts start landing on your phone, the app gives you everything you need to deal with them on the spot — no need to open a laptop. There are two tabs: **Inbox** for the alerts themselves, and **Alert Definitions** for the alarms you've set up.

## Inbox

The **Inbox** lists every alert for the home you're currently viewing, newest first, and refreshes itself while the app is open — so new alerts just appear.

<figure><img src="/files/jPc0Bvv6yvgxVaQ76Oq3" alt="Chirp Alerts Inbox tab beside the Alert Definitions tab, showing an empty alert list" width="300"><figcaption></figcaption></figure>

Each one shows:

* **What happened** — the alert title and message
* **When** — the time it fired
* **Whether it's handled** — a red dot for still-active, green for resolved

### Marking an alert as handled

Tap an active alert to resolve it. You'll get a quick confirmation, then it's marked **resolved for the whole home** — the dot turns green, everyone else sees it as handled, and any further escalation stops. It's the same as tapping **Dismiss & Acknowledge** on the alarm screen.

A good habit: only resolve an alert once it's genuinely sorted, since resolving it calls off the alert for everyone else too.

### Clearing one out

Swipe left on an alert to remove it from your list. There's a confirmation first, since this clears it from your inbox for good.

## Alert Definitions

The **Alert Definitions** tab lists the alarms you've created on the web. Use the search box to find one by name, and the toggle next to it to **turn it on or off**.

This is the quick fix for an alarm that won't stop pinging you — switch it off right from your phone, then fine-tune it properly on the web later. You create and edit the alarms themselves on the web platform; here you've just got the on/off switch. Haven't made any yet? Head to [Set Up a Home Alert](/alarm/set-up-a-home-alert) to create your first.

## Switching homes (and platforms)

* **Home** — if you're part of more than one home, switch between them from the menu; the Inbox and Alert Definitions follow along.
* **Platform** — under **Settings → Platform** you could switch to Business (Kilo) mode, but that signs you out and is meant for the Kilo platform, not your home.

<figure><img src="/files/2K9eFxOEDEI42xrV7zfF" alt="Chirp Alerts Settings screen showing the Platform section, Change mode, app version, and account options" width="300"><figcaption></figcaption></figure>

## Close, resolve, delete — what's the difference?

| What you tap              | What happens                                                                       | Where             |
| ------------------------- | ---------------------------------------------------------------------------------- | ----------------- |
| **Close**                 | Quiets the alarm on your phone only — the alert stays active and keeps escalating. | Alarm screen      |
| **Dismiss & Acknowledge** | Quiets the alarm and resolves it for the whole home.                               | Alarm screen      |
| **Tap to resolve**        | Resolves the alert for the whole home.                                             | Inbox             |
| **Swipe to delete**       | Removes the alert from your inbox for good.                                        | Inbox             |
| **Toggle off**            | Stops an alarm from firing until you turn it back on.                              | Alert Definitions |


# Rules engine

Let your home act on its own — automations that watch your sensors and respond, from an alert to flipping a switch.

Your sensors are always listening — temperature shifts, doors opening, moisture creeping into the basement. Automations let your home **react** to those readings on its own. Instead of checking the dashboard yourself, Chirp watches for the conditions you care about and takes action the moment they happen.

An automation is a set of instructions you build once: "when this sensor reads something I care about, do this." And "do this" now really means *do*. An automation can send you a notification when the basement gets too humid — or it can switch the dehumidifier on by itself; it can warn you about a leak, or shut the water off the moment the sensor gets wet. Your home doesn't just tell you something's happening anymore — it can handle it. See [When an Automation Runs a Command](/rules-engine/reference/automation-runs-a-command).

## What You Get

**A visual workflow designer.** Every automation is a visual flowchart built using BPMN (Business Process Model and Notation), an industry-standard way to represent workflows. You can see the entire chain of "if this, then that" at a glance. Drag nodes onto a canvas, connect them with arrows, and watch your logic take shape. Most home automations can be built this way without writing traditional code.

**Smart expressions with CEL.** When simple thresholds are not enough, you can write conditions using [CEL](https://cel.dev) (Common Expression Language) — a safe, sandboxed expression language for precise logic inside the visual workflow. CEL lets you combine sensor values, compare readings from different rooms, calculate differences between indoor and outdoor temperatures, classify readings into severity levels, and build exactly the logic you need. That means Chirp is not limited to simple "if value > X" rules — you can model sophisticated home automations with branching, fallbacks, and dynamic alert messages.

**Your home can act, not just alert.** An automation doesn't have to stop at telling you something's wrong — it can do something about it. With an Execute Command step it can flip a switch, dim a light, or nudge the thermostat on its own, the moment a condition is met. "If the basement gets damp, turn on the dehumidifier" is a single automation now, start to finish. See [When an Automation Runs a Command](/rules-engine/reference/automation-runs-a-command).

**Build before it goes live.** Nothing runs until you say so. After designing your automation, you build and deploy it explicitly. This means you can experiment freely in the editor without worrying about accidentally triggering alerts or actions in your home.

**Version history and easy recovery.** Every save is recorded. If you change something and your automation stops behaving the way you want, you can look back at previous versions and restore any one of them. Your saved work is always recoverable.

## How Automations Fit Together

Automations sit between your sensors and what happens next. Your sensors send data to Chirp continuously. When a reading arrives, Chirp checks it against any running automations. If the conditions match, the automation takes action — sending you an alert, acting on a device itself, or both.

```
Sensor reading arrives
       |
  Automation evaluates conditions
       |
  Conditions met? --> Send an alert  and/or  run a command on a device
       |
  Not met? --> No action, wait for next reading
```

You build the automations. You choose the sensors, define the conditions, and decide what happens — an alert, an action on a device, or both. Chirp handles the rest — around the clock, whether you are home or away.

## Getting Started

This section walks you through everything from your very first automation to advanced patterns:

* [**Your First Automation**](/rules-engine/your-first-automation) — A hands-on tutorial that takes you from a blank canvas to a working humidity alert in minutes. Start here.
* [**Going Deeper**](/rules-engine/going-deeper) — Learn how to pull data from multiple sensors, write richer expressions, and publish your automation so it runs on live data.
* [**Managing Automations**](/rules-engine/managing-automations) — Keep things organized with version history, editing controls, and recovery options.
* [**Examples**](/rules-engine/examples) — Ready-to-adapt automation ideas for comfort, energy, and safety around the home.

## Finding the Automation Page

In the Chirp sidebar, click **Rules engine**. This opens the automation page at `/rules`, where all your automations live. From here you can create new automations, manage existing ones, check what is running, and browse the trash for anything you have deleted.

## Looking something up?

If you need to check how a specific node works, what a CEL expression does, or what a build error means, head to the [Reference](/rules-engine/reference) section.


# Your First Automation

A ten-minute tutorial to build your first automation — a basement humidity alert, from blank canvas to working rule.

The best way to learn how automations work is to build one. In this tutorial, you will create a simple automation that watches a humidity sensor in your basement and raises an alert when the reading gets too high.

By the end, you will have a complete automation that:

1. Listens for humidity readings from a basement sensor
2. Checks whether the humidity is above 70%
3. Raises an alert if it is, or does nothing if the reading is normal

Do not worry about getting everything perfect on your first try. You can always edit your automation later, undo changes, or restore a previous version. The editor saves your work automatically, and nothing runs in your home until you explicitly build and deploy it.

## What You Will Need

* A sensor already registered in Chirp (any humidity or temperature sensor will do — the steps are the same regardless of sensor type)
* An alert rule set up in the [Alerts](/alarm) section (the automation will trigger this alert when the condition is met)

If you do not have an alert rule yet, you can still follow along and add it later.

## The Three Steps

We will build this automation in three short steps:

1. [**Create an Automation**](/rules-engine/your-first-automation/create-an-automation) — Open the editor, name your automation, and choose which sensor to watch.
2. [**Add Conditions and Branches**](/rules-engine/your-first-automation/add-conditions-and-branches) — Set up a decision point that checks the humidity level and routes to different actions depending on the reading.
3. [**Trigger Alarms and Actions**](/rules-engine/your-first-automation/trigger-alarms-and-actions) — Connect your conditions to an alert so Chirp notifies you when something needs attention.

Each step builds on the previous one, so follow them in order. The whole process takes about ten minutes.


# Create an Automation

Open the editor, name your automation, pick the sensor that triggers it, and save your first draft.

This page walks you through opening the automation editor, naming your first automation, choosing the sensor that triggers it, and saving your initial draft.

## Open the Rules Engine

1. Click **Rules engine** in the Chirp sidebar. This takes you to `/rules`.
2. Click the **Add Rule** button. A new blank editor opens.

You are now looking at the visual workflow canvas — a large open area with a small palette of node types on the left. The canvas already contains a **Start Event** node (a circle with an envelope icon). This is where every automation begins.

## Name Your Automation

At the top of the editor, you will see a name field. Click it and type a name that tells you what this automation does — for example:

* "Basement Humidity Alert"
* "Living Room Temp Warning"
* "Garden Moisture Check"

You can also add a description: click the three-dot menu next to the name and select **Edit description**. This is optional but helpful if you have several automations and want to remember the purpose of each one.

## Choose Your Sensor

The Start Event is the trigger for your automation. It decides which sensor's readings will kick off the logic every time new data arrives.

1. Click the **Start Event** node on the canvas (the circle with the envelope icon).
2. A properties panel opens on the right side of the screen.
3. In the **Device** dropdown, search for and select the device you want to monitor (for our example, the basement humidity sensor).
4. In the **Sensor** dropdown, select the specific sensor on that device (this dropdown becomes available after you pick a device).

That is all you need for a basic trigger. Every time your basement sensor sends a new humidity reading, this automation will evaluate it.

At this stage, you are still working entirely visually. As you build more advanced automations, some fields let you add CEL expressions for precise conditions or message text, but most of the structure stays BPMN-based and easy to follow.

### Optional: Restrict When It Runs

If you only want this automation to run during certain hours — for example, only overnight when you are not home to check things yourself — toggle the **Enable Schedule** switch in the Start Event properties. You can pick a time range and time zone.

For now, leave the schedule off so the automation evaluates every reading around the clock.

## Save Your Work

Click the **Save** button in the top-right corner of the editor. Your automation is saved as its first version.

You will notice the editor shows a save indicator in the header area — it cycles through **Saving...** and then **Saved** to confirm your work is persisted. From this point on, Chirp also autosaves periodically while you are working, so you do not need to worry about losing progress if you step away.

## View Mode vs. Edit Mode

Now that your automation exists, there are two ways to look at it:

* **View mode** — Opens when you click an automation's name in the list. You can see the full diagram, inspect node properties, and browse version history, but you cannot change anything. This is useful for reviewing automations without accidentally modifying them.
* **Edit mode** — Opens when you click the **Edit** button or use the mode selector in the editor header. In this mode you can change the diagram, update properties, and save new versions.

While you are in edit mode, the automation is locked to you — nobody else in your household can edit it at the same time. The lock is released automatically when you leave the editor or when the session times out after inactivity.

## What You Have So Far

Your automation is saved and ready for logic. Right now it has a Start Event bound to your sensor — but it does not do anything with the data yet. In the next step, you will add a decision point that checks whether the reading is above your threshold.

For a full tour of the canvas, palette, and properties sidebar, see the [Visual Editor](/rules-engine/reference/visual-editor) reference.

**Next:** [Add Conditions and Branches](/rules-engine/your-first-automation/add-conditions-and-branches)


# Add Conditions and Branches

Add a Script Task and a gateway so your automation classifies a reading and sends it down the right path.

Your automation has a Start Event that listens for sensor readings. Now you need to tell it what to do with those readings. In this step, you will add a decision point that checks the humidity value and sends the automation down different paths depending on the result.

## Add a Script Task to Prepare the Data

Before branching, it helps to classify the incoming reading so the decision logic stays clean and readable.

1. From the palette on the left, drag a **Script Task** node onto the canvas (it looks like a rounded rectangle with a document icon).
2. Draw a connection (arrow) from the **Start Event** to the Script Task — hover over the Start Event until the connection handle appears, then drag to the Script Task.
3. Click the Script Task to open its properties panel.
4. Set the **Name** to something descriptive, like "Classify reading."
5. In the **Script** field, enter this CEL expression:

```cel
{"level": vars.value > 70 ? "high" : "normal"}
```

6. Click **Save** in the properties panel.

This expression looks at the sensor's reading (`vars.value`) and creates a variable called `level`. If the humidity is above 70%, `level` is set to `"high"`. Otherwise, it is `"normal"`. Every node after this one can use `vars.level` to make decisions.

### What Is CEL?

[CEL](https://cel.dev) (Common Expression Language) is a simple, safe expression language that Chirp uses for conditions and data transformation. You do not need to be a programmer to use it — if you have ever written a spreadsheet formula, CEL will feel familiar. Chirp still stays visual-first: you build the automation on the canvas, then use CEL only in the places where you need exact logic.

A few things CEL can do:

* Compare values: `vars.value > 70`
* Combine conditions: `vars.value > 70 && vars.level == "high"`
* Do basic math: `vars.value - 20`
* Build text: `"Reading is " + string(vars.value)`
* Use ternary logic: `vars.value > 70 ? "high" : "normal"`

Because CEL supports nested logic, computed values, and multi-sensor comparisons, the automations you can build go well beyond simple thresholds. You will see more examples as you explore the [Going Deeper](/rules-engine/going-deeper) section.

## Add an Exclusive Gateway

An Exclusive Gateway is a decision diamond that routes the automation down exactly one path based on conditions you define.

1. Drag an **Exclusive Gateway** from the palette (it looks like a diamond shape).
2. Draw a connection from the **Script Task** to the Exclusive Gateway.
3. Now draw **two outgoing connections** from the gateway — one going to where you will put your alarm action (we will add that node in the next step), and one going to an **End Event** (drag an End Event from the palette first — it is a circle with a bold border).

You should now have two paths leaving the gateway: one for "humidity is high" and one for "everything is fine."

## Configure the Gateway Conditions

1. Click the **Exclusive Gateway** to open its properties panel.
2. You will see a list of **Flows** — one for each outgoing connection you drew. Each flow has fields for a label, a color, and a condition expression.

Set them up like this:

| Flow   | Label         | Color         | Condition              |
| ------ | ------------- | ------------- | ---------------------- |
| Flow 1 | High humidity | Red or orange | `vars.level == "high"` |
| Flow 2 | Normal        | Green         | *(set as default)*     |

3. For Flow 2, click **Set as default**. This makes it the fallback path — it runs when no other condition matches.
4. Click **Save** in the properties panel.

### How Conditions Are Evaluated

The gateway checks conditions **from top to bottom**. The first condition that evaluates to `true` wins, and the automation follows that path. All other paths are skipped.

The default flow has no condition — it catches everything that did not match the conditions above it. Always include a default flow so your automation has somewhere to go even when readings are normal.

You can reorder flows by grabbing the **drag handle** on each flow row and moving it up or down in the properties panel. This matters because the first match wins. For example, if you had both `vars.value > 50` and `vars.value > 70`, putting the > 70 check first ensures critical readings are caught before the less urgent condition.

### Labels and Colors

Labels appear on the arrows in your visual diagram, and colors help you see at a glance which path is which. Using a red or orange arrow for the alert path and a green arrow for the normal path makes the automation easy to read weeks or months later.

## What Your Automation Looks Like Now

```
Start Event (Basement Sensor)
       |
  Script Task ("Classify reading")
       |
  Exclusive Gateway
      / \
     /   \
  [High]  [Normal - Default]
    |         |
   ???     End Event
```

The "High humidity" path does not lead anywhere useful yet — it needs an alarm action. That is exactly what you will add next.

For the full details on how gateways evaluate conditions, see the [Automation Node Guide](/rules-engine/reference/automation-node-guide). For expression syntax, see [CEL for Home Automations](/rules-engine/reference/cel-for-home-automations).

**Next:** [Trigger Alarms and Actions](/rules-engine/your-first-automation/trigger-alarms-and-actions)


# Trigger Alarms and Actions

Add a Set Alarm node and a motivation message so your automation notifies you when the basement gets too humid.

Your automation can now tell the difference between a normal humidity reading and a high one. The last piece is connecting the "high humidity" path to an action that actually notifies you. In this step, you will add a Set Alarm node so Chirp sends an alert when the basement gets too humid.

## Prerequisites: You Need an Alert Rule

The Set Alarm node triggers an existing **Alarm Definition** — it does not create one from scratch. Before continuing, make sure you have at least one alert rule configured in the [Alerts](/alarm) section.

If you followed the alerts guide and created a rule for basement humidity, you are all set. If not, head over to [Set Up a Home Alert](/alarm/set-up-a-home-alert), create a quick alert rule, and come back. The automation will reference that rule.

## Add a Set Alarm Node

1. From the palette, drag a **Set Alarm** node onto the canvas (it looks like a rounded rectangle with a bell icon).
2. Connect the "High humidity" path from your Exclusive Gateway to this Set Alarm node — draw an arrow from the gateway's high-humidity branch to the Set Alarm node.
3. Click the **Set Alarm** node to open its properties panel.

## Configure the Alarm

In the properties panel you will see a header that reads: **"Select an alarm. A new alarm can be created on the Alarms page."** This is a reminder that the Set Alarm node triggers an existing Alarm Definition — it does not define severity, notification channels, or escalation steps. All of that is configured once in the [Alerts](/alarm) section and reused by every automation that references it.

Fill in the following fields:

| Field                  | What to enter                                                                                                                                                                    |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name**               | A label for this node on the canvas — for example, "Alert: high humidity"                                                                                                        |
| **Choose Alarm**       | A searchable autocomplete field — start typing an alarm name and select the one you created in the Alerts section.                                                               |
| **Motivation Message** | A multiline CEL expression that builds the notification text. The placeholder shows an example: `"Temperature is " + string(vars.temp) + " degrees"`. See below for more detail. |

### Writing a Motivation Message

The motivation message is what you (and anyone else in your household) will see when the alert arrives. The field is multiline, so you can write longer messages comfortably. This is one of the places where Chirp uses CEL inside the visual automation: the workflow stays drag-and-drop, but the message field can generate text dynamically from the live sensor data.

Because it is a CEL expression, you can include the actual sensor reading in the text:

```cel
"Humidity is " + string(vars.value) + "% in the basement"
```

When the sensor reads 78%, the notification will say: **Humidity is 78% in the basement**

You can make the message as detailed as you like:

```cel
"Basement humidity reached " + string(vars.value) + "% — check for leaks or ventilation issues"
```

Click **Save** in the properties panel.

## Add an End Event After the Alarm

Every path in your automation needs to end somewhere. After the Set Alarm node, add an **End Event** so the automation knows this branch is complete.

1. Drag an **End Event** from the palette.
2. Connect the Set Alarm node to this End Event.

You can name the End Event by clicking it and typing a label like "Alert sent" in the properties panel. This is optional but makes the diagram easier to read.

## The Complete Automation

Your finished automation looks like this:

```
Start Event (Basement Humidity Sensor)
       |
  Script Task ("Classify reading")
       |
  Exclusive Gateway
      / \
     /   \
  [High]  [Normal - Default]
    |         |
 Set Alarm   End Event
 ("Alert:     ("No action")
  high
  humidity")
    |
 End Event
 ("Alert sent")
```

Every time the basement sensor sends a reading:

* If humidity is above 70%, the automation takes the left path, triggers the alarm, and you get a notification.
* If humidity is at or below 70%, the automation takes the right path and ends quietly.

## Save and Review

Click **Save** to persist your work. Take a moment to look at the diagram — can you follow the logic from start to finish? Are both paths connected to End Events? Do the labels make sense?

This is a good time to double-check the gateway conditions: click the Exclusive Gateway and verify the condition on the "High humidity" flow is `vars.level == "high"` and the "Normal" flow is set as the default.

## What Happens Next: Building and Deploying

Your automation is saved, but it is **not running yet**. Saving keeps your design safe in Chirp — it does not start processing live sensor data.

To make your automation live:

1. Click the **Build** button to validate your automation and create a deployable artifact
2. Deploy the artifact so it starts evaluating incoming sensor data

This build-before-deploy approach means you can freely experiment in the editor without worrying about triggering accidental alerts. When you are confident the automation is correct, you publish it.

The full walkthrough for building and deploying is in [Publish and Run an Automation](/rules-engine/going-deeper/publish-and-run-an-automation).

## You Did It

You have built a complete automation from scratch — one that watches a real sensor, evaluates a condition, and raises an alert when something needs your attention. From here, you can:

* [**Go deeper**](/rules-engine/going-deeper) — Learn how to pull data from multiple sensors, write richer expressions, and manage the build-deploy lifecycle.
* [**Browse examples**](/rules-engine/examples) — See ready-made automation ideas for comfort, energy, and safety around the home.
* **Edit and improve** — Your automation is saved and versioned. Come back anytime to adjust thresholds, add more branches, or change the alert message.


# Going Deeper

Go beyond single-sensor rules — pull in other sensors, do the math, and publish automations that run live.

Your first automation watches a single sensor and reacts to a simple threshold. That covers a lot of useful scenarios — but sometimes you need your home to be smarter than that.

What if you want to compare the temperature inside your home with the temperature outside before deciding whether something is wrong? Or check the humidity in your wine cellar against a recommended range that depends on the season? These situations call for automations that pull data from more than one source and do a bit of math before making a decision.

This section covers the tools that make that possible:

* [**Data Enrichment and Expressions**](/rules-engine/going-deeper/data-enrichment-and-expressions) — Fetch readings from other sensors inside the same automation, transform data with CEL expressions, and handle what happens when a sensor is offline. This is how you build automations that consider the full picture, not just one number.
* [**Publish and Run an Automation**](/rules-engine/going-deeper/publish-and-run-an-automation) — Your automation does not go live until you build and deploy it. This page walks through the entire publish lifecycle — building, deploying, stopping, and understanding what the Artifacts tab shows you.

Through CEL expressions, the logic you can model is very flexible — nested conditions, computed values, severity classifications, and dynamic alert messages that include live sensor readings. Once you are comfortable with these concepts, you will be able to build automations that handle real-world home situations with confidence, even when one sensor reading alone is not enough to tell the full story.


# Data Enrichment and Expressions

Combine readings from several sensors, transform them with CEL, and handle offline sensors with a fallback path.

A single sensor reading tells you what is happening in one spot. But your home is a system of connected spaces — the basement humidity matters more when you also know it has been raining, and the living room temperature means something different when the outdoor reading is 35 degrees versus 15 degrees.

Enrichment nodes and Script Tasks let you build automations that consider multiple data points before making a decision. Together, they turn a simple "is this number too high?" check into a thoughtful, context-aware response.

This is also where the balance becomes clear: Chirp remains a visual automation builder, but CEL lets you express very sophisticated logic when you need it — nested conditions, computed derived values, multi-sensor delta calculations, severity classifications, and dynamic alert messages that include live readings. The range of automations you can build goes well beyond simple thresholds.

## Enrichment: Pulling Data from Another Sensor

An **Enrichment** node fetches the most recent reading from a different sensor — one that is not the trigger sensor for this automation. This lets you bring in context from anywhere in your home.

### How to Add an Enrichment Node

1. Drag an **Enrichment** node from the palette onto the canvas (it has a download icon).
2. Connect it to the flow where you need the additional data — typically right after the Start Event, before any decision-making.
3. Click the Enrichment node to open its properties panel.
4. Configure:

| Field             | What to enter                                                                                                       |
| ----------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Name**          | A descriptive label — for example, "Get outdoor temperature"                                                        |
| **Device**        | A searchable autocomplete dropdown — start typing and select the device that has the sensor you want to fetch from. |
| **Sensor**        | A filtered dropdown that appears after you choose a device — select the specific sensor on that device.             |
| **Variable name** | The name you will use to reference this data in later nodes — for example, `outdoor_temp`                           |

5. Click **Save** in the properties panel.

### Using the Enriched Data

After the Enrichment node runs, the fetched reading is available to every downstream node as `vars.<variable_name>`. For example, if your variable name is `outdoor_temp`, you can reference:

| Variable                         | What it contains                          |
| -------------------------------- | ----------------------------------------- |
| `vars.outdoor_temp.value`        | The sensor's most recent reading          |
| `vars.outdoor_temp.sensor_id`    | The sensor's identifier                   |
| `vars.outdoor_temp.timestamp_ms` | When the reading was taken (milliseconds) |

You can use these in any CEL expression downstream — in Script Tasks, gateway conditions, or alarm messages.

## Script Tasks: Transforming and Computing

A **Script Task** runs a CEL expression that can transform data, compute new values, or prepare variables for decisions. You already used one in the first tutorial to classify a reading. Here, Script Tasks become even more useful because you can combine data from the trigger sensor and the enriched sensor.

You are still not writing an application from scratch here. The automation remains a visual BPMN flow, and the Script Task is the focused place where you add the exact expression the flow needs.

### Example: Compute a Temperature Difference

After enriching your automation with the outdoor temperature, you might want to know how much warmer or cooler your home is compared to outside:

```cel
{"temp_delta": vars.value - vars.outdoor_temp.value}
```

This creates a new variable, `vars.temp_delta`, that holds the difference. A downstream Exclusive Gateway can then check:

* `vars.temp_delta > 10` — "The house is more than 10 degrees warmer than outside" (possible heating issue in summer)
* `vars.temp_delta < -5` — "The house is more than 5 degrees cooler than outside" (possible heating failure in winter)

### Example: Classify a Wine Cellar Reading

If you monitor both temperature and humidity in your wine cellar (with enrichment for humidity and temperature as the trigger), you could classify the overall condition:

```cel
{"cellar_status": vars.value > 18 ? "too_warm" : vars.value < 10 ? "too_cold" : "ideal"}
```

Then in a second Script Task or the gateway conditions, combine it with humidity:

```cel
{"needs_attention": vars.cellar_status != "ideal" || vars.humidity_reading.value > 75}
```

### More CEL Patterns for Home Use

Here are some expressions that come in handy around the house:

**Percentage calculation:**

```cel
{"moisture_pct": (vars.value / 1023.0) * 100}
```

**Rounding a number to a readable string:**

```cel
{"display_temp": string(int(vars.value * 10) / 10.0)}
```

**Combining text with values for alarm messages:**

```cel
"Indoor: " + string(vars.value) + " / Outdoor: " + string(vars.outdoor_temp.value) + " (delta: " + string(vars.temp_delta) + ")"
```

## Putting It Together: Indoor vs. Outdoor Temperature

Here is a complete automation pattern that compares indoor and outdoor temperature and alerts you if the difference is unusually large:

```
Start Event (Living Room Temp Sensor)
       |
  Enrichment ("Get outdoor temperature")
       |
  Script Task ("Compute delta")
       |
  Exclusive Gateway
      / \
     /   \
  [Large   [Normal - Default]
   delta]       |
    |        End Event
 Set Alarm
 ("Unusual temp difference")
    |
 End Event
```

The Script Task contains:

```cel
{"temp_delta": vars.value - vars.outdoor_temp.value}
```

The gateway condition for the alert path:

```cel
vars.temp_delta > 15 || vars.temp_delta < -10
```

The Set Alarm motivation message:

```cel
"Indoor temperature is " + string(vars.value) + " but outdoor is " + string(vars.outdoor_temp.value) + " — difference of " + string(vars.temp_delta) + " degrees"
```

## Handling Errors: What If a Sensor Is Offline?

The outdoor sensor might be offline, out of battery, or temporarily unreachable. If the Enrichment node cannot fetch a reading, what happens?

Without error handling, that path of your automation simply stops — no alert, no notification, just silence. That is not ideal.

The solution is a **Boundary Error Event** — a small error-catching node that attaches to the Enrichment node and gives you a fallback path.

### How to Add Error Handling

1. Drag a **Boundary Error Event** from the palette and drop it onto your Enrichment node. It snaps to the edge of the node (a small circle with a lightning bolt).
2. Click the Boundary Error Event to open its properties panel. You will see three fields:

| Field          | Purpose                                                                                                                                                                                                   |
| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name**       | A label for this error catch on the canvas — for example, "Sensor offline"                                                                                                                                |
| **Error code** | A label you can use to describe the error type for your own reference. This is for documentation purposes only — the boundary event catches all errors from its parent node regardless of the code value. |
| **Message**    | A label for the error scenario. Like the error code, this is for your own reference and does not affect which errors are caught.                                                                          |

3. Draw a single outgoing connection from the Boundary Error Event to a fallback action — this could be a Set Alarm node that tells you the sensor is offline, or an End Event if you simply want to skip the automation when data is missing.

For the fallback alarm, you might use a motivation message like:

```cel
"Could not reach the outdoor temperature sensor — automation skipped this cycle"
```

### The Pattern with Error Handling

```
Start Event (Living Room Temp Sensor)
       |
  Enrichment ("Get outdoor temperature")
       |                \
       |           [Error] Boundary Error Event
       |                         |
  Script Task              Set Alarm ("Sensor offline")
       |                         |
  Exclusive Gateway          End Event
      / \
     /   \
  [Alert] [Normal]
    |       |
    ...    ...
```

This way, you are covered whether the second sensor is working or not. Your automation handles the happy path and the failure path gracefully.

## Tips

* **Name your enrichment variables clearly.** `outdoor_temp` is much easier to work with than `enrichment_1` when you revisit the automation weeks later.
* **Place enrichment early in the flow.** Fetch additional data before you need it — do not place an Enrichment node inside a branch that might not execute.
* **Always add error handling to enrichment nodes.** Sensors go offline. Batteries die. A brief fallback path takes two minutes to set up and saves you from silent failures.
* **Keep Script Task expressions focused.** One transformation per Script Task is easier to understand and debug than cramming everything into a single expression.

For a complete list of CEL operators, functions, and patterns, see the [CEL for Home Automations](/rules-engine/reference/cel-for-home-automations) reference. For details on how each node type behaves, see the [Automation Node Guide](/rules-engine/reference/automation-node-guide).




---

[Next Page](/llms-full.txt/1)

