Templates¶
The Flexible Horseshoe Card supports two template systems:
- FHS templates define reusable configuration blocks, such as card templates, color stop templates, state map templates, and other named template parts.
- JavaScript templates make individual configuration values dynamic while the card is running.
FHS templates are stored in an fhs_templates section. This section can be placed in a view or at dashboard level, depending on where you want the templates to be available.
JavaScript templates are written directly inside card configuration values with triple brackets. They are used when a value should depend on an entity state, attribute, or another Home Assistant state.
FHS templates¶
FHS templates are named reusable configuration blocks.
They are always defined inside fhs_templates.templates:
1 2 3 4 5 6 | |
The template.type field defines what kind of template it is. A template can describe a complete card, but it can also describe reusable parts such as color_stops or state_maps.
Where to define fhs_templates¶
The fhs_templates section can be defined in a view or in the dashboard configuration.
Use a view-level fhs_templates section when the templates are only needed by cards in that view.
Use a dashboard-level fhs_templates section when several views should share the same templates.
The structure of the template itself stays the same in both cases:
1 2 3 4 5 6 7 8 | |
Template types¶
FHS templates can be used for different kinds of reusable configuration.
| Template type | Used for |
|---|---|
card | Reusing a complete or partial Flexible Horseshoe Card configuration |
color_stops | Reusing color stop definitions |
state_map / state_maps | Reusing state-to-value mappings |
| other supported template parts | Reusing other named configuration fragments supported by the card |
A card template contains a card section. Other template types use their own matching content section.
Template defaults and placeholders¶
Templates can define default values. These defaults can then be used inside the template content with placeholders.
Placeholders are written with double square brackets:
1 2 3 | |
Defaults are defined under template.defaults:
1 2 3 4 5 | |
When the template is used, the caller can override these values. Values that are not overridden fall back to the defaults.
Card templates¶
A card template defines reusable card configuration.
Use a card template when multiple cards share the same layout, styling, entities structure, constants, or other card options.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | |
This template defines a reusable card named awair_test.
The card template expects an entity value and has default values for label and max. Inside the template, these values are inserted with [[entity]], [[label]], and [[max]].
The example also shows that a card template can reference other templates. Both the states and names layout items use the same color_stops template named fhs_colorstops_awair_score.
Loading a card template¶
A card can load a named card template with the top-level template option.
1 2 3 4 5 6 | |
The template provides the reusable card configuration. The card instance provides the values that should be inserted into the placeholders.
Color stop templates¶
Color stop templates let you reuse the same color stop definition in multiple layout items or multiple cards.
A color stop template is useful when several states, names, horseshoes, or other visual elements should use the same value-to-color rules.
1 2 3 4 5 6 7 8 9 10 | |
You can then reference the template from a card or from another card template:
1 2 3 | |
This keeps repeated color logic in one place.
State map templates¶
State map templates let you reuse mappings from states to labels, icons, colors, styles, or other supported values.
Use them when the same state interpretation is needed in more than one card or layout item.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | |
A card or template can reference the state map by name:
1 2 3 | |
Use the singular or plural template type that matches the supported configuration field in your card version.
Compose multiple cards¶
You can define and place other cards inside a Flexible Horseshoe Card by using the top-level cards section.
Each composed card can have its own type, template, entities, position, and size.
1 2 3 4 5 6 7 8 9 10 11 12 | |
Composed cards are positioned on the parent card canvas. Use xpos and ypos to place the card, and width and height to control its size.
When to use FHS templates¶
Use FHS templates when configuration should be reusable before the card is rendered.
| Use | Best option |
|---|---|
| Reuse a complete or partial card configuration | type: card template |
| Create similar cards with different entities | Card template with placeholders |
| Create similar cards with different labels or limits | Card template with defaults and placeholders |
| Reuse the same color stop rules | type: color_stops template |
| Reuse the same state mapping | type: state_map or type: state_maps template |
| Place multiple reusable cards inside one card | cards with card templates |
FHS templates are static reusable definitions. They are resolved as part of the card configuration.
Use JavaScript templates when a value must be calculated dynamically while the card is active.
JavaScript templating¶
JavaScript templates make parts of the card configuration dynamic.
Most card configuration is static: it is read during card setup and stays the same until the card is reloaded. JavaScript templates are different. They can return values based on the current state of an entity, an attribute, or another Home Assistant state.
This is useful when a visual element should change while Home Assistant is running. For example, you can change a color, icon, animation, style value, or color stop definition based on an entity state.
Available since v5.4.1
JavaScript templates are supported in the styles section for dynamic styling based on entity or attribute values.
Later versions (as of v5.4.7) also add template support in other parts of the configuration, such as entity definitions, color stops, and reusable constants.
Breaking change in v5.4.7-dev.14
The variables are renamed to constants as variables are used by the Template engine to replace card, colors and more with a defined template. You have to move the stuff under variables to the constants section, and rename the variables[] to constants[]. The functinality remains the same!
JavaScript template syntax¶
A JavaScript template is written between triple brackets:
1 2 3 | |
In YAML, templates are usually written as a multiline value:
1 2 3 4 5 6 7 | |
The template must return the value that should be used by the card.
Available template variables¶
The following variables are available inside JavaScript templates:
| Variable | Description |
|---|---|
state | State or configured attribute of the entity connected to the current item |
entity | Complete Home Assistant state object connected to the current item |
entities | State objects for all entries in the card-level entities list |
states | All Home Assistant states from hass.states |
hass | Current Home Assistant frontend object |
config | Statically compiled card configuration |
constants | Values or JavaScript source stored in the card-level constants section |
item | Complete configuration component currently being evaluated |
user | Current Home Assistant user |
state¶
Use state when the template should respond to the entity connected to the current item through entity_index.
Example:
1 | |
states¶
Use states when the template needs to read another Home Assistant entity.
Example:
1 | |
Note
Entity IDs must be written as strings inside square brackets, for example states['sensor.battery_power'].
constants¶
Use constants when you want to reuse the same template or value in multiple places.
Example:
1 | |
Where JavaScript templates can be used¶
JavaScript templates can be placed in any field of the supported configuration sections below. Their results update when a configured entity changes.
| Configuration section | Supported items |
|---|---|
| Entity definitions | Items in entities |
| Layout tools | Items in horseshoes, horseshoes_v2, states, names, areas, circles, arcs, rectangles, lines, hlines, vlines, icons, and sparklines |
| Layout groups | Groups in layout.groups, including position, scale, and color filters |
| Animations | State items in animations |
| Card styles | The card-level styles block |
Register every states dependency
Every entity read through states['entity.id'] must also be present in the card-level entities list. Otherwise, changes to that entity do not update the card.
A constant containing JavaScript uses the entity belonging to the item where the constant is referenced. A returned value may contain another [[[ ... ]]] template.
Dynamic styling based on the current entity¶
This example changes the fill color of an entity name based on the state of the connected entity.
If the state is 4 or higher, the text uses --error-color. Otherwise, it uses --primary-text-color.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | |
Reading another entity with states¶
Use states when the style should depend on a different entity than the one connected to the current item.
In this example, the text color depends on sensor.battery_power. Negative values return a red color, positive values return a green color, and zero falls back to the default text color.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | |
Reusing JavaScript templates with constants¶
For larger cards, templates can become repetitive. The card-level constants section lets you define reusable templates or reusable values once and use them in multiple places.
This keeps the YAML easier to read and makes later changes safer.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 | |
Using reusable JavaScript templates¶
After defining reusable values or templates in constants, you can reference them elsewhere in the card.
This example uses a reusable animation template for the horseshoe state and a reusable color stop definition for the horseshoe colors.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | |
Advanced example: heavily templated battery card¶
The example below shows how far JavaScript templating can be taken. It combines reusable constants, dynamic entity icons, dynamic icon colors, state-based animations, and direct access to several Home Assistant states.
Advanced example
This example is intentionally large. It is meant to show what is possible, not as a recommended starting point for every card.
It was created before Reuseâ„¢ was implemented. When a card starts to contain many repeated templates, consider simplifying the logic, using constants, or moving repeated behavior into smaller reusable pieces.
Advanced example with a lot of templating!
| Advanced templated battery card | |
|---|---|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 | |
What this example demonstrates¶
This card uses JavaScript templating in several different places:
| Template location | Purpose |
|---|---|
constants.batteryLevel | Converts the battery state of charge to a rounded battery icon level |
constants.batteryCharging | Checks whether the battery is currently charging |
entities.icon | Selects different icons based on battery, grid, or power flow state |
animations.icons.icon | Updates icons as part of state-based animation rules |
animations.icons.styles.fill | Changes icon colors dynamically |
layout.icons.styles.fill | Applies dynamic fallback colors directly on layout icons |
The example also shows why constants are important. Without them, the same battery-level and charging logic would have to be repeated even more often.
Static configuration, FHS templates, and dynamic templates¶
FHS templates and JavaScript templates solve different problems.
Use static configuration when a value is known in advance. Use FHS templates when you want to reuse card configuration, color stops, state maps, or other named configuration fragments. Use JavaScript templates when a value depends on an entity state, attribute, or other dynamic data.
| Use | Best option |
|---|---|
| Reuse a complete or partial card configuration | FHS card template |
| Create multiple similar cards with different entities | FHS card template with placeholders |
| Create multiple similar cards with different limits or labels | FHS card template with defaults |
| Reuse the same color stop rules | FHS color_stops template |
| Reuse the same state mapping | FHS state_map or state_maps template |
| Place multiple reusable cards inside one card | cards with FHS card templates |
| Reuse the same static style block inside one card | constants and ref() |
| Calculate a fixed position or size | calc() |
| Copy similar layout items | same_as |
| Change a style based on an entity state | JavaScript template |
| Change an icon based on an entity state | JavaScript template |
| Reuse a dynamic expression inside one card | JavaScript template in constants |
Practical tips¶
Keep templates as small as possible. Short templates are easier to read, debug, and reuse.
Use card templates for repeated card structures. Use JavaScript templates only for values that need to change dynamically.
Convert numeric states with Number() before comparing them:
const value = Number(state);
Always return a valid value for the field you are templating. For example, a style property should return a valid CSS value, and an icon field should return a valid icon name or image URL.
When reading another entity through states, make sure that entity exists. Missing or unavailable entities can otherwise return unexpected values.
Tip
Use card templates for repeated card layouts. Use constants for templates or values that appear more than once inside a card.