Home Assistant integration for the Whisker Labs Ting electrical-fire-safety sensor. Ting plugs into an outlet and continuously monitors your home's electrical system for the arcing and power-quality problems that precede electrical fires. This integration connects to the Ting cloud service on your behalf and exposes real-time voltage readings plus electrical, utility, and power-quality hazard status as native Home Assistant entities.
- Real-time voltage monitoring via a WebSocket connection to the Ting cloud
- Current voltage, voltage high/low, and average peak voltage
- Fire hazard status monitoring
- Electrical Fire Hazard (EFH) detection
- Utility Fire Hazard (UFH) detection
- Learning-mode status
- Power quality hazard and frozen pipe risk detection (site-level)
- Connectivity sensor — reflects whether the real-time data stream is live
- Device diagnostics — firmware version, WiFi/Bluetooth MAC addresses (also registered as device connections), serial number, subscription start date, and account group
Whisker Ting is not (yet) in the default HACS store, so add it as a custom repository:
- Open HACS in Home Assistant.
- Click the three-dot menu in the top right corner and select Custom repositories.
- Add
https://github.com/billda/ha-ting-fireas the repository URL, choose Integration as the category, and click Add. - Find Whisker Ting in HACS and click Download.
- Restart Home Assistant.
- Download the latest release from GitHub, or clone the repository.
- Copy the
custom_components/whisker_tingfolder into your Home Assistantconfig/custom_components/directory. - Restart Home Assistant.
- Go to Settings → Devices & Services and click + Add Integration.
- Search for Whisker Ting.
- Enter your Ting account credentials:
| Field | Description |
|---|---|
| The email address for your Whisker Labs / Ting account. | |
| Password | The password for that account — the same credentials you use in the Ting mobile app. |
These credentials are verified against the Ting cloud during setup; setup will not complete with incorrect credentials.
After setup, open Settings → Devices & Services → Whisker Ting and click Configure to change:
| Option | Description |
|---|---|
| Update interval | How often, in seconds, the integration polls the Ting API for hazard and diagnostic data. Range 30–3600, default 60. Real-time voltage sensors are unaffected by this setting — they update continuously from the WebSocket stream. |
| Alert notifications | Post a Home Assistant persistent notification for each new significant Ting alert — power outages, restorations, fire, and frozen-pipe alerts. Off by default (opt-in). Brownouts (Sag/Swell) and weather alerts are never posted this way by design; automate on the Alerts event entity or the Last brownout / Last weather alert sensors instead — see Automations below. |
- Go to Settings → Devices & Services.
- Find the Whisker Ting integration card, open its three-dot menu, and select Delete.
- If it was installed through HACS, open HACS → Integrations, find Whisker Ting, open its three-dot menu, and select Remove to remove the repository and files.
Each Ting device is added to Home Assistant as its own device, named after its Ting site (e.g. "Kitchen", "Garage") rather than one shared account name — so accounts with multiple sensors get distinguishable devices, and entity IDs are prefixed with the site's slug (e.g. binary_sensor.kitchen_power_outage). This follows normal Home Assistant rename semantics: upgrading does not rename entities you already have just because the underlying device name changed — only entities created fresh (a new install, a newly added device, or a newly enabled entity) pick up the site-based name.
| Name | Description | Category | Enabled by default |
|---|---|---|---|
| Current voltage | Real-time line voltage from the WebSocket stream | — | Yes |
| Voltage high | Real-time peak high voltage from the WebSocket stream | — | Yes |
| Voltage low | Real-time peak low voltage from the WebSocket stream | — | Yes |
| Average peaks max | Rolling average of peak voltage from the WebSocket stream | — | No |
| Hazard Status | Overall hazard status: no_hazards, hazard_detected, reviewed_not_fire, or learning |
— | Yes |
| Hazard Message | Human-readable hazard summary from Ting | — | Yes |
| Electrical Fire Hazard Status | Raw EFH status code from Ting | — | Yes |
| Electrical Fire Hazard Message | Human-readable EFH message | — | Yes |
| Electrical Fire Hazard Level | EFH severity level | — | Yes |
| Utility Fire Hazard Status | Raw UFH status code from Ting | — | Yes |
| Utility Fire Hazard Message | Human-readable UFH message | — | Yes |
| Device Type | Ting device type reported by the API | Diagnostic | Yes |
| Firmware Version | Installed firmware version | Diagnostic | No |
| WiFi MAC Address | Device's WiFi MAC address (also registered as a device connection) | Diagnostic | No |
| Bluetooth MAC Address | Device's Bluetooth MAC address (also registered as a device connection) | Diagnostic | No |
| Serial Number | Device serial number | Diagnostic | No |
| Subscription Start | Timestamp the Ting subscription began | Diagnostic | No |
| Group | Ting account group/location name | Diagnostic | No |
| Last brownout | Timestamp of the most recent brownout (voltage sag/swell) notification from Ting; the notification message is in the message attribute |
— | Yes |
| Last weather alert | Timestamp of the most recent weather-alert notification relayed by Ting; the alert's title and message are in attributes |
— | Yes |
| Name | Description | Category | Enabled by default |
|---|---|---|---|
| Fire Hazard | On when Ting reports any active fire hazard | — | Yes |
| Electrical Fire Hazard | On when an electrical fire hazard (EFH) is active | — | Yes |
| Utility Fire Hazard | On when a utility-side fire hazard (UFH) is active | — | Yes |
| Frozen Pipe Risk | On when Ting detects a frozen-pipe risk condition | — | Yes |
| Power Quality Hazard | On when a site-level power-quality hazard is detected | — | Yes |
| Power outage | On while the device's most recent power event is an unrestored outage, derived from Ting's PowerOutage/PowerRestored/PowerOutageAndRestored notifications (per Ting, unplugging the sensor itself also trips this) |
— | Yes |
| Connectivity | On while the real-time WebSocket stream is live | Diagnostic | Yes |
| Learning Mode | On while Ting is in its initial learning period | — | Yes |
| HVAC Verified | On when Ting has verified HVAC equipment on the circuit | Diagnostic | No |
| Is Owner | On when this account is the device owner (vs. a shared/guest user) | Diagnostic | No |
Note: the Utility Fire Hazard binary sensor's entity ID keeps the legacy
unverified_fire_hazardkey for backward compatibility with existing installs — only its display name changed.
| Name | Description | Category | Enabled by default |
|---|---|---|---|
| Alerts | Fires once for each new Ting notification. event_type is one of PowerOutage, PowerOutageAndRestored, PowerRestored, Sag, Swell, WeatherAlert, FireHazard, FrozenPipe, or unknown (for any type Ting adds that this integration doesn't yet recognize) |
— | Yes |
Each fired event also carries the notification's details as attributes: title, subtitle, message, category (Ting's event category, e.g. PowerQuality), raw_event_type (Ting's original type string — useful when event_type above is unknown), timestamp (when Ting recorded the event), notification_id, acknowledged, and cleared.
- Home Assistant 2024.12.0 or newer
- A Whisker Labs Ting device
- A Whisker Labs account
The entities above are built to be automated against directly — no template sensors required. Each example below is a single automation's config, as you'd paste into Home Assistant's Edit in YAML automation editor; if you're editing automations.yaml directly, wrap it in a list item under the top-level automation: key. Replace <device> with your device's slug — the lowercase, underscore-separated form of its name as shown in Settings → Devices & Services (e.g. kitchen, living_room); see Multi-device installs above if you have more than one Ting device.
The Alerts event entity fires on every new Ting notification. Trigger on any state change of the entity and filter by event_type in a condition, rather than scoping the trigger to that attribute directly — an attribute:-scoped state trigger only re-fires when the attribute's value changes, so it would silently miss a second PowerOutage notification arriving without a PowerRestored in between:
alias: "Ting: notify on power outage"
trigger:
- platform: state
entity_id: event.<device>_alerts
condition:
- condition: template
value_template: "{{ trigger.to_state.attributes.event_type == 'PowerOutage' }}"
action:
- service: notify.mobile_app_phone
data:
title: Ting power outage
message: "{{ trigger.to_state.attributes.message }}"The Power outage binary sensor is a plain on/off state, so a regular for:-qualified state trigger works well here — this waits 5 minutes before notifying, to skip momentary blips:
alias: "Ting: notify on sustained power outage"
trigger:
- platform: state
entity_id: binary_sensor.<device>_power_outage
to: "on"
for: "00:05:00"
action:
- service: notify.mobile_app_phone
data:
title: Ting power outage
message: "{{ state_attr(trigger.entity_id, 'friendly_name') }} has been without power for 5 minutes."Last brownout and Last weather alert hold the timestamp of the most recent occurrence rather than an on/off state, so freshness is a template condition, not a trigger. This example escalates the (Phase 1) Power Quality Hazard binary sensor into a notification only when a brownout was also recorded in the last 10 minutes:
alias: "Ting: escalate power-quality hazard after a recent brownout"
trigger:
- platform: state
entity_id: binary_sensor.<device>_power_quality_hazard
to: "on"
condition:
- condition: template
value_template: "{{ (now() - states.sensor.<device>_last_brownout.state | as_datetime) < timedelta(minutes=10) }}"
action:
- service: notify.mobile_app_phone
data:
title: Ting power-quality hazard
message: A power-quality hazard was flagged shortly after a brownout was recorded.Last brownout reads unknown until the first brownout notification ever arrives, which makes the condition above evaluate to false rather than error.
For the common case — notify on outage, optionally notify on restore — skip writing YAML: in Home Assistant, go to Settings → Automations & Scenes → Blueprints → Import Blueprint and import power_outage_notification.yaml from this repository (or copy it into your config/blueprints/automation/whisker_ting/ folder). It asks for your Power outage binary sensor and a notify target, and handles the rest.
Turn on Alert notifications under Settings → Devices & Services → Whisker Ting → Configure to have the integration post an HA persistent notification for each new significant alert itself — see Options above.
This is normal — the integration waits for the WebSocket connection to receive its first data packet before displaying values.
The real-time voltage sensors depend on a live WebSocket stream. If the stream disconnects and cannot be re-established, these sensors report unavailable (rather than a frozen last value) until the stream recovers. The hazard and diagnostic sensors continue to update from the regular API poll regardless of stream state.
Ensure you're using the same email and password you use in the Whisker Labs / Ting mobile app. If your password has changed, Home Assistant will prompt you to reauthenticate the integration; repeated errors after reauthenticating usually mean the credentials themselves are incorrect.
This integration is not affiliated with or endorsed by Whisker Labs, Inc.
- Original integration by Aiden Mitchell.
- Fixes adopted from forks by simplytoast1 and adamjthompson, including the SignalR stream authorization header that restores real-time voltage data.
MIT License — see LICENSE for details.