Published fields#

Each published document contains an entity's state, its Home Assistant registry metadata, and details about how it was collected. Use these fields to filter documents in Discover and build visualizations in Lens. See Using Kibana to create a data view first.

Fields whose values are unavailable, null, or empty lists or objects are omitted. For example, an entity without a device has no hass.entity.device.* fields, and an entity without labels has no hass.entity.labels field.

Entity identity and metadata#

Label values are registry IDs, such as energy_monitoring, rather than display names such as Energy monitoring. Entity labels and device labels are published separately; neither list includes the other's labels or labels assigned to an area.

Areas, floors, and coordinates#

The published entity area and floor describe only the entity's own area assignment. If the entity has no directly assigned area, those fields are omitted even when its device has an area. The device's area and floor remain available under hass.entity.device.area.*.

The publish target filters use the device's area and floor when the entity has no area of its own. This fallback determines which events are published; it does not copy device metadata into the entity's fields.

State values#

The original value is always published. The integration attempts conversions in this order: boolean, number, then datetime. The first successful conversion determines which valueas.* fields appear. A datetime conversion produces all three of datetime, date, and time; otherwise, only one converted field is published.

Boolean conversion recognizes true, on, locked, above_horizon, open, and home as true; false, off, unlocked, unknown, below_horizon, closed, and not_home as false. Other states are tried as numbers and datetimes before falling back to a string.

State attributes#

Other supported state attributes appear under hass.entity.attributes.*. Attribute names are normalized to lowercase ASCII, with punctuation and whitespace replaced by underscores. For example, Fan Speed becomes hass.entity.attributes.fan_speed. If two names normalize to the same key, the later attribute replaces the earlier one.

The following attributes are excluded from this object:

When updating older dashboards, use hass.entity.friendly_name instead of hass.entity.attributes.friendly_name. Device class and unit of measurement also have dedicated fields rather than copies under attributes.

Attributes are dynamically mapped as text with a .keyword subfield by default. Numeric state attributes therefore need a custom attribute mapping if you want numeric aggregations. Dictionary-valued attributes are serialized as JSON strings; sets are converted to sorted lists. Attributes with unsupported value types or non-string or blank keys are skipped.

Date and time values nested inside list or dictionary attributes are serialized as ISO 8601 strings.

Outside the attributes object, extra fields without an explicit mapping are kept in the stored document but are not indexed for searching or aggregations. Add a custom mapping if you need to query those fields.

To reduce storage, you can drop attributes with an ingest pipeline while keeping entity states and metadata.

Event, data stream, and host details#

Host details and tags are gathered when the integration starts. Data stream fields determine the destination, such as metrics-homeassistant.sensor-default.

Example document#

This example shows a temperature entity assigned directly to the Living Room area, with an associated device in the same area. The area belongs to the Ground Floor. Host details are left out for brevity. Documents use dotted field names:

{
  "@timestamp": "2026-11-06T18:00:00+00:00",
  "event.action": "State change",
  "event.kind": "event",
  "event.type": "change",
  "data_stream.type": "metrics",
  "data_stream.dataset": "homeassistant.sensor",
  "data_stream.namespace": "default",
  "hass.entity.id": "sensor.living_room_temperature",
  "hass.entity.object.id": "living_room_temperature",
  "hass.entity.domain": "sensor",
  "hass.entity.friendly_name": "Living Room Temperature",
  "hass.entity.name": "Temperature",
  "hass.entity.platform": "esphome",
  "hass.entity.device_class": "temperature",
  "hass.entity.unit_of_measurement": "°C",
  "hass.entity.labels": ["indoor"],
  "hass.entity.area.id": "living_room",
  "hass.entity.area.name": "Living Room",
  "hass.entity.area.floor.id": "ground_floor",
  "hass.entity.area.floor.name": "Ground Floor",
  "hass.entity.device.id": "abc123",
  "hass.entity.device.name": "Living Room Sensor",
  "hass.entity.device.labels": ["environment"],
  "hass.entity.device.area.id": "living_room",
  "hass.entity.device.area.name": "Living Room",
  "hass.entity.device.area.floor.id": "ground_floor",
  "hass.entity.device.area.floor.name": "Ground Floor",
  "hass.entity.attributes.battery_level": 95,
  "hass.entity.value": "21.5",
  "hass.entity.valueas.float": 21.5,
  "tags": ["home"]
}

Filter by floor or label in Kibana#

Use these examples in Discover's KQL search bar, replacing IDs with values from your documents.

To find entities on the Ground Floor, using the entity's own floor when assigned and otherwise the device's floor:

hass.entity.area.floor.id: "ground_floor" or
(not hass.entity.area.id: * and hass.entity.device.area.floor.id: "ground_floor")

To find entities labeled indoor either directly or through their device:

hass.entity.labels: "indoor" or hass.entity.device.labels: "indoor"