Context

The context is the data a widget is given each time it is drawn. A template reads it by name: {{ device.name }}, {{ cap.measure_power.text }}, {% if settings.pump %}. The Data panel in the editor shows the same tree with live values for the device you preview with.

Nothing outside the context can be read, and nothing in it can be changed. Values that don’t exist are empty, not errors, so test for them where a widget has to work without.

Where each name can be read

An expression reads any variable of the template, including the ones you assign, let or loop over.

device

The tile’s own device: its names and state, without its readings, which are in cap. It is null for a widget without a device of its own, which reads everything from its settings.

cap

Every reading of the tile’s device, by its id: cap.onoff, cap.measure_power. A reading the device doesn’t have is missing, so {% if cap.dim %} tests whether the device can dim.

Each reading has these fields:

Written whole into an attribute, with no field after it, a reading turns into a live reference to it, such as @<device id>/<reading id>. That is how bind="{{ cap.dim }}" and <hd-series bind="{{ cap.measure_power }}"> know which reading you mean, whichever device it belongs to.

Sub-capabilities

Homey’s sub-capabilities have a dot in their id, such as measure_temperature.inside. Read them as plain paths, cap.measure_temperature.inside.value, when both parts are plain names and no part is named like one of the fields above. Otherwise use brackets, cap['meter_power.T1-high'].

A loop over cap sees only the main readings, and every sub-capability is also reachable the long way, cap['measure_temperature.inside'].

settings

What the tile chose for each setting the widget declares, by name: settings.title, settings.pump. What each kind reads as is in the settings reference. A setting that isn’t chosen, is gone from the Homey or no longer fits is null.

state and pending

item, devices and variables

A variable has name, value (a number, true or false, or text), text (ready to show: Yes or No, a number as it reads well), type (boolean, number or string) and lastUpdated, when Tiledash saw it change. Only the variables a template names are read, and they are followed live. The id stays the same when the variable is renamed in Homey. In the editor, the Data panel lists your variables by name, and typing variables[ offers them; either puts in the id. Make this a setting turns one into a value setting, so each tile picks its own.

flow and mood

Set for a widget of the kind flow or mood, null for the others.

dashboards

The Homey’s dashboards, a list of { id, name }, for a widget that points at one.

taps

The tap settings that do something on this tile, by their name: taps.lampTap. A tap that is set to nothing isn’t there, so {% if taps.lampTap %} tells you whether a part is worth showing as tappable. Each is an object with a type (toggle, history, device, dashboard, flow or mood) and what it acts on. The runtime runs these for the parts you mark with data-hd-tap, so you rarely need to read them.

now

When the data was put together, as an ISO time such as 2026-10-12T07:00:00.000Z. It moves on with each live update, not every second. Use it with since(), until() and isToday() or the date filter. A template that reads it is drawn again every minute.

Liquid’s own variables

Inside a {% for %}, forloop says where you are: index, index0, rindex, first, last and length. The loop variable you name, and anything you assign, capture or let, is a variable too.

prices

The Homey’s electricity prices, from the source chosen in Energy settings. It is null while there are none.

A slot has start, end, time (“13:00”), price, text (“€0.36”), cents, level, word, share, now and past. level is negative, cheap, normal or high, word is its name (“Cheap”), and share places the price on its day from 0, the lowest, to 1, the highest.

A day has label, start, step, values and levels (for hd-price-bars), its slots, low and high (each with price, text and time), average (price and text) and negative, the number of slots below zero.

A window has hours, start, end, from, to, when (“Today”, “Tonight”, “Tomorrow”), average, text, level, saving (how much cheaper than the average of the hours it was picked from, 0 to 100), running, startsIn in minutes, startsInText and complete, which is false while the hours it is picked from run past the prices known.

energy

The Homey’s electricity, gas, water, solar, battery and car today, from Homey’s own energy reports and the recorded meters. It is null while there is nothing.

An amount has value, text (“12.4”), unit (kWh, m³ or L), cost and costText. A change has percent, text (“−12 %”), direction (down, up or same) and good.

A meter (electricity, gas or water) has kind, label, icon, unit, then amounts for today, yesterday and sameTimeYesterday, a change against yesterday at the same time, and:

Solar also reads like a meter, as Energy today’s Solar row does: label, icon and unit, today (made so far), sameTimeYesterday, a change against it where more is good, bars for hd-bars (today’s hours over yesterday’s) and saved, what the power used at home was worth at the price of each hour (below zero, a cost; null without prices). What went to the grid is in earned, already off electricity’s cost. Like a period’s row, it says whether it is estimated.

energy.periods

energy.periods.today, .week, .month and .year are calendar periods as your Homey’s reports have them: today by the hour, a week from Monday and a month from the 1st by the day, a year by the month. Each has the same shape, so a template can pick one with energy.periods[key].

A row has kind, label, icon, unit and decimals, amounts for amount (so far), previous (the period before up to the same moment) and previousWhole, a change (where more is good for solar), bars for hd-bars (values, previous, labels, the running bar current and names for its tooltip), for solar, saved, and whether it is estimated.

Estimated amounts

Solar panels without an energy counter still count: their total is worked out from their power readings, hour by hour, which is a little less exact. The same goes for a meter Homey approximates in its own reports. energy.solar and every row of energy.periods say so:

The built-in energy widgets put a quiet ≈ before such an amount, explained in an hd-tip:

<span class="used">  {%- if m.estimated %}<hd-tip text="{{ m.estimatedText }}">≈</hd-tip>{% endif -%}  <hd-value value="{{ m.amount.value }}" decimals="{{ m.decimals }}"></hd-value> {{ m.unit }}</span>

A widget can step through the periods with its own state. Its manifest names the state key (hostData: { energyPeriodStep: 'back' }), and a value such as setState('back', 'week:3') makes the host build energy.periods with three weeks back in the week’s place, no further back than your Homey has reports. Nothing else in the state reaches the host.

weather

The weather of the Weather widget, and of widgets started from it. It is null for the others, and weatherNote holds a few calm words on why there is none yet (loading, no place) or null.

A look’s fields are the attributes of hd-weather-icon and hd-weather-sky.

appliance and alert

For a washer, a dryer or a dishwasher, the tile’s device is worked out as an appliance; for a motion, smoke, CO or water sensor, a siren or a doorbell, as an alert. Both are null for any other device.

tileChart

The chart the tile’s owner added in the Chart tab of its settings, for a device widget that has one. The tile’s frame draws it, so a template doesn’t need to.

event

Only in a change handler, the new value of the control that changed: event.value.