mirror of
https://github.com/jpawlowski/hass.tibber_prices.git
synced 2026-05-28 18:43:40 +00:00
docs(user): collapse code blocks and normalize labels
Wrap most user-guide code examples in collapsible details sections to reduce visual noise while keeping Mermaid diagrams expanded. Standardized summary labels across the user docs to a small set of readable patterns and removed technical or awkward wording from visible collapse titles. Impact: User documentation is easier to scan, with long examples hidden by default and more consistent expand/collapse labels.
This commit is contained in:
Julian Pawlowski
parent
f6a49d9cf3
commit
999ecd358f
22 changed files with 385 additions and 90 deletions
|
|
@ -62,7 +62,7 @@ gantt
|
|||
This automation starts a flexible load when the best price period begins, but keeps it running as long as prices remain favorable — even after the period ends.
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Heat pump — extended cheap period</summary>
|
||||
<summary>Show YAML: Ride the Full Cheap Wave</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -123,7 +123,7 @@ automation:
|
|||
Use the trend to start slightly before the cheapest period — useful for appliances with warm-up time:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Water heater — pre-heat before cheapest window</summary>
|
||||
<summary>Show YAML: Pre-Emptive Start</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -159,7 +159,7 @@ automation:
|
|||
Stop or reduce consumption when prices are climbing:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: EV charger — stop when prices rising</summary>
|
||||
<summary>Show YAML: Protect Against Rising Prices</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -199,7 +199,7 @@ Combine short-term and long-term trend sensors for smarter decisions. This examp
|
|||
- If long-term says `falling` → cheaper hours ahead, no rush
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Heat pump — multi-window trend strategy</summary>
|
||||
<summary>Show YAML: Multi-Window Trend Strategy</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -299,7 +299,7 @@ On days with low price variation, the difference between "cheap" and "expensive"
|
|||
**Best Practice:** Instead of checking a numeric percentage, this automation checks the sensor's classified state. This makes the automation simpler and respects the volatility thresholds you have configured centrally in the integration's options.
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Home battery — charge on best price (volatility-aware)</summary>
|
||||
<summary>Show YAML: Meaningful Price Variations</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -346,7 +346,7 @@ automation:
|
|||
This is the most robust approach. It trusts the "Best Price" classification on volatile days but adds a backup absolute price check for low-volatility days. This handles situations where prices are globally low, even if the daily variation is minimal.
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: EV charging — combined volatility + absolute price strategy</summary>
|
||||
<summary>Show YAML: Volatility and Absolute Price Check</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -396,7 +396,7 @@ automation:
|
|||
For maximum simplicity, you can use the attributes of the `best_price_period` sensor itself. It contains the volatility classification for the day the period belongs to. This is especially useful for periods that span across midnight.
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Heat pump — smart heating using period volatility attribute</summary>
|
||||
<summary>Show YAML: Period Volatility Attribute</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -437,7 +437,7 @@ automation:
|
|||
Use future average sensors to determine the cheapest upcoming window for a timed appliance (e.g., dishwasher with 2-hour ECO program):
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Dishwasher — schedule for cheapest 2h window</summary>
|
||||
<summary>Show YAML: Best Time for an Appliance</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -479,7 +479,7 @@ automation:
|
|||
Get a push notification when the best price period begins:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Notification — when cheap window starts</summary>
|
||||
<summary>Show YAML: Cheap Window Notification</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
|
|||
|
|
@ -24,6 +24,9 @@ Actions for generating chart data and ApexCharts configurations from your Tibber
|
|||
|
||||
**Basic Example:**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Chart Data Action</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.get_chartdata
|
||||
data:
|
||||
|
|
@ -33,8 +36,13 @@ data:
|
|||
response_variable: chart_data
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Response Format:**
|
||||
|
||||
<details>
|
||||
<summary>Show JSON: Chart Data Response</summary>
|
||||
|
||||
```json
|
||||
{
|
||||
"data": [
|
||||
|
|
@ -50,6 +58,8 @@ response_variable: chart_data
|
|||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Common Parameters:**
|
||||
|
||||
| Parameter | Description | Default |
|
||||
|
|
@ -66,7 +76,7 @@ response_variable: chart_data
|
|||
Omit the `day` parameter to get a dynamic 48-hour rolling window that automatically adapts to data availability:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (rolling window mode)</summary>
|
||||
<summary>Show YAML: Rolling Window Mode</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.get_chartdata
|
||||
|
|
@ -90,7 +100,7 @@ This is useful for charts that should always show a 48-hour window without manua
|
|||
Get best price periods as summaries instead of intervals:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (period filter)</summary>
|
||||
<summary>Show YAML: Period Filter</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.get_chartdata
|
||||
|
|
@ -108,7 +118,7 @@ response_variable: periods
|
|||
**Advanced Filtering:**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (advanced filtering)</summary>
|
||||
<summary>Show YAML: Advanced Filtering</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.get_chartdata
|
||||
|
|
@ -139,7 +149,7 @@ You can include the raw energy price (spot price) and/or tax component in chart
|
|||
**Example: Chart with price composition**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (include energy and tax fields)</summary>
|
||||
<summary>Show YAML: Energy and Tax Fields</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.get_chartdata
|
||||
|
|
@ -155,6 +165,9 @@ response_variable: chart_data
|
|||
|
||||
Returns data points like:
|
||||
|
||||
<details>
|
||||
<summary>Show JSON: Returns data points like</summary>
|
||||
|
||||
```json
|
||||
{
|
||||
"start_time": "2025-11-17T14:00:00+01:00",
|
||||
|
|
@ -164,6 +177,8 @@ Returns data points like:
|
|||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Use case — Solar feed-in chart:** Overlay the energy price (what you earn by exporting) alongside the total price to visualize the best export windows. See [Energy & Tax Attributes](sensors-energy-tax.md) for more use cases.
|
||||
|
||||
---
|
||||
|
|
@ -194,6 +209,9 @@ Returns data points like:
|
|||
|
||||
**Quick Example:**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Quick Example</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.get_apexcharts_yaml
|
||||
data:
|
||||
|
|
@ -204,6 +222,8 @@ data:
|
|||
response_variable: apexcharts_config
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Day Parameter Options:**
|
||||
|
||||
- **Fixed days** (`yesterday`, `today`, `tomorrow`): Static 24-hour views, no additional dependencies
|
||||
|
|
@ -224,7 +244,7 @@ Rolling window configurations automatically integrate with the `chart_metadata`
|
|||
**Example: Today's Prices (Static View)**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (today, static view)</summary>
|
||||
<summary>Show YAML: Today Static View</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.get_apexcharts_yaml
|
||||
|
|
@ -244,7 +264,7 @@ type: custom:apexcharts-card
|
|||
**Example: Rolling 48h Window (Dynamic View)**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (rolling 48h dynamic view)</summary>
|
||||
<summary>Show YAML: Rolling 48h Dynamic View</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.get_apexcharts_yaml
|
||||
|
|
|
|||
|
|
@ -41,6 +41,9 @@ The integration can generate 4 different chart modes, each optimized for specifi
|
|||
**Dependencies:** ApexCharts Card only
|
||||
|
||||
**Generate:**
|
||||
<details>
|
||||
<summary>Show YAML: Today's Prices (Static)</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.get_apexcharts_yaml
|
||||
data:
|
||||
|
|
@ -50,6 +53,8 @@ data:
|
|||
highlight_best_price: true
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Screenshot:**
|
||||
|
||||
|
||||
|
|
@ -72,7 +77,7 @@ data:
|
|||
|
||||
**Generate:**
|
||||
<details>
|
||||
<summary>Show YAML example (generate rolling 48h window)</summary>
|
||||
<summary>Show YAML: Rolling 48h Window</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.get_apexcharts_yaml
|
||||
|
|
@ -111,7 +116,7 @@ data:
|
|||
|
||||
**Generate:**
|
||||
<details>
|
||||
<summary>Show YAML example (generate rolling auto-zoom)</summary>
|
||||
<summary>Show YAML: Rolling Auto-Zoom</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.get_apexcharts_yaml
|
||||
|
|
@ -177,6 +182,9 @@ Based on **absolute price ranges** (calculated from daily min/max):
|
|||
Rolling window modes (2 & 3) automatically integrate with the `chart_metadata` sensor for optimal visualization:
|
||||
|
||||
**Without chart_metadata sensor (disabled):**
|
||||
<details>
|
||||
<summary>Show chart illustration: Without Chart Metadata</summary>
|
||||
|
||||
```
|
||||
┌─────────────────────┐
|
||||
│ │ ← Lots of empty space
|
||||
|
|
@ -187,7 +195,12 @@ Rolling window modes (2 & 3) automatically integrate with the `chart_metadata` s
|
|||
0 100 ct
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**With chart_metadata sensor (enabled):**
|
||||
<details>
|
||||
<summary>Show chart illustration: With Chart Metadata</summary>
|
||||
|
||||
```
|
||||
┌─────────────────────┐
|
||||
│ ___ │ ← Y-axis fitted to data
|
||||
|
|
@ -197,6 +210,8 @@ Rolling window modes (2 & 3) automatically integrate with the `chart_metadata` s
|
|||
18 28 ct ← Optimal range
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Requirements:**
|
||||
|
||||
- ✅ The `sensor.<home_name>_chart_metadata` must be **enabled** (it's enabled by default!)
|
||||
|
|
@ -213,6 +228,9 @@ Rolling window modes (2 & 3) automatically integrate with the `chart_metadata` s
|
|||
When `highlight_best_price: true`, vertical bands overlay the chart showing detected best price periods:
|
||||
|
||||
**Example:**
|
||||
<details>
|
||||
<summary>Show chart illustration: Best Price Period Highlights</summary>
|
||||
|
||||
```
|
||||
Price
|
||||
│
|
||||
|
|
@ -226,6 +244,8 @@ Price
|
|||
06:00 12:00 18:00
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Features:**
|
||||
- Automatic detection based on your configuration (see [Period Calculation Guide](period-calculation.md))
|
||||
- Tooltip shows "Best Price Period" label
|
||||
|
|
@ -239,19 +259,29 @@ Price
|
|||
### Required for All Modes
|
||||
|
||||
- **[ApexCharts Card](https://github.com/RomRider/apexcharts-card)**: Core visualization library
|
||||
<details>
|
||||
<summary>Show shell command: Prerequisite for All Modes</summary>
|
||||
|
||||
```bash
|
||||
# Install via HACS
|
||||
HACS → Frontend → Search "ApexCharts Card" → Download
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### Required for Rolling Window Modes Only
|
||||
|
||||
- **[Config Template Card](https://github.com/iantrich/config-template-card)**: Enables dynamic configuration
|
||||
<details>
|
||||
<summary>Show shell command: Rolling Window Prerequisite</summary>
|
||||
|
||||
```bash
|
||||
# Install via HACS
|
||||
HACS → Frontend → Search "Config Template Card" → Download
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Note:** Fixed day views (`today`, `tomorrow`) work with ApexCharts Card alone!
|
||||
|
||||
---
|
||||
|
|
@ -263,7 +293,7 @@ Price
|
|||
Edit the `colors` array in the generated YAML:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (custom color palette)</summary>
|
||||
<summary>Show YAML: Custom Color Palette</summary>
|
||||
|
||||
```yaml
|
||||
apex_config:
|
||||
|
|
@ -280,7 +310,7 @@ apex_config:
|
|||
Add to the card configuration:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (custom chart height)</summary>
|
||||
<summary>Show YAML: Custom Chart Height</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:apexcharts-card
|
||||
|
|
@ -300,7 +330,7 @@ apex_config:
|
|||
Wrap in a vertical stack for dashboard integration:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (vertical stack integration)</summary>
|
||||
<summary>Show YAML: Vertical Stack Integration</summary>
|
||||
|
||||
```yaml
|
||||
type: vertical-stack
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ Create `input_number` helpers in Home Assistant for each fee component. This way
|
|||
| Verkoopvergoeding | `input_number.verkoopvergoeding` | 0 | 1 | 0.0001 | €/kWh | 0.0205 |
|
||||
|
||||
<details>
|
||||
<summary>Alternative: YAML configuration for input_number helpers</summary>
|
||||
<summary>Show YAML: Input Number Helpers</summary>
|
||||
|
||||
If you prefer YAML configuration over the UI, add these to your `configuration.yaml`:
|
||||
|
||||
|
|
@ -105,7 +105,7 @@ input_number:
|
|||
These template sensors calculate what you **earn** per kWh when feeding solar power back to the grid.
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Template sensors for feed-in with and without saldering</summary>
|
||||
<summary>Show YAML: Feed-In Compensation Sensors</summary>
|
||||
|
||||
```yaml
|
||||
template:
|
||||
|
|
@ -156,7 +156,7 @@ template:
|
|||
Now you can use these sensors to make smarter decisions about when to export solar power vs. charge a battery:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Smart export automation</summary>
|
||||
<summary>Show YAML: Feed-In Automation</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -188,7 +188,7 @@ automation:
|
|||
To understand the financial impact of the saldering phase-out, you can create a dashboard comparing both scenarios side by side:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Dashboard comparison card</summary>
|
||||
<summary>Show YAML: Preparing for the End of Saldering</summary>
|
||||
|
||||
```yaml
|
||||
type: entities
|
||||
|
|
@ -233,7 +233,7 @@ In Germany, the electricity price includes numerous components bundled into `tax
|
|||
A simple template sensor showing what percentage of your total price is the actual energy cost:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Spot price share template sensor</summary>
|
||||
<summary>Show YAML: Spot Price Share</summary>
|
||||
|
||||
```yaml
|
||||
template:
|
||||
|
|
|
|||
|
|
@ -154,10 +154,15 @@ The integration allows you to choose how average price sensors display their val
|
|||
#### Why This Matters
|
||||
|
||||
Consider a day with these hourly prices:
|
||||
<details>
|
||||
<summary>Show example: Mean vs Median</summary>
|
||||
|
||||
```
|
||||
10, 12, 13, 15, 80 ct/kWh
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
- **Median = 13 ct/kWh** ← "Typical" price (middle value, ignores spike)
|
||||
- **Mean = 26 ct/kWh** ← Average cost (spike pulls it up)
|
||||
|
||||
|
|
@ -168,7 +173,7 @@ The median tells you the price was **typically** around 13 ct/kWh (4 out of 5 ho
|
|||
**Both values are always available as attributes**, regardless of your display choice:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (median and mean attributes)</summary>
|
||||
<summary>Show YAML: Median and Mean Attributes</summary>
|
||||
|
||||
```yaml
|
||||
# These attributes work regardless of display setting:
|
||||
|
|
@ -263,7 +268,7 @@ Each configuration entity includes a detailed description attribute explaining w
|
|||
### Example: Seasonal Automation
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (seasonal runtime override)</summary>
|
||||
<summary>Show YAML: Seasonal Runtime Override</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -296,7 +301,7 @@ If you frequently adjust these settings via automations or want to track configu
|
|||
However, if you prefer to **completely exclude** these entities from the recorder (no history graph, no database entries), add this to your `configuration.yaml`:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (exclude runtime config entities from recorder)</summary>
|
||||
<summary>Show YAML: Exclude Runtime Config Entities</summary>
|
||||
|
||||
```yaml
|
||||
recorder:
|
||||
|
|
|
|||
|
|
@ -10,6 +10,9 @@ Beautiful dashboard layouts using Tibber Prices sensors.
|
|||
|
||||
Simple card showing current price with dynamic color:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Current Price Card</summary>
|
||||
|
||||
```yaml
|
||||
type: entities
|
||||
title: Current Electricity Price
|
||||
|
|
@ -23,10 +26,15 @@ entities:
|
|||
name: Next Price
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
## Period Status Cards
|
||||
|
||||
Show when best/peak price periods are active:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Best and Peak Period Card</summary>
|
||||
|
||||
```yaml
|
||||
type: horizontal-stack
|
||||
cards:
|
||||
|
|
@ -40,12 +48,14 @@ cards:
|
|||
icon: mdi:alert
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
## Custom Button Card Examples
|
||||
|
||||
### Price Level Card
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Price level card with color gradients (custom:button-card)</summary>
|
||||
<summary>Show YAML: Price Level Card</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:button-card
|
||||
|
|
@ -74,7 +84,7 @@ styles:
|
|||
Optimized for mobile devices:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Compact mobile layout</summary>
|
||||
<summary>Show YAML: Optimized for mobile devices</summary>
|
||||
|
||||
```yaml
|
||||
type: vertical-stack
|
||||
|
|
@ -101,7 +111,7 @@ cards:
|
|||
Full-width layout for desktop:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Desktop 3-column grid layout</summary>
|
||||
<summary>Show YAML: Full-width layout for desktop</summary>
|
||||
|
||||
```yaml
|
||||
type: grid
|
||||
|
|
@ -136,7 +146,7 @@ cards:
|
|||
Using the `icon_color` attribute for dynamic colors:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Dynamic icon colors with mushroom chips</summary>
|
||||
<summary>Show YAML: Icon Color Integration</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:mushroom-chips-card
|
||||
|
|
@ -163,7 +173,7 @@ See [Icon Colors](icon-colors.md) for detailed color mapping.
|
|||
Advanced interactive dashboard:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Picture elements interactive dashboard</summary>
|
||||
<summary>Show YAML: Advanced interactive dashboard</summary>
|
||||
|
||||
```yaml
|
||||
type: picture-elements
|
||||
|
|
@ -193,7 +203,7 @@ elements:
|
|||
Automatically list all price sensors:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Auto-entities card for all price sensors</summary>
|
||||
<summary>Show YAML: Auto-Entities Sensor List</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:auto-entities
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Actions for fetching raw price data and managing integration state.
|
|||
**Example:**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (get_price)</summary>
|
||||
<summary>Show YAML: Get Price</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.get_price
|
||||
|
|
@ -34,6 +34,9 @@ response_variable: price_data
|
|||
|
||||
**Response Format:**
|
||||
|
||||
<details>
|
||||
<summary>Show JSON: Get Price Response</summary>
|
||||
|
||||
```json
|
||||
{
|
||||
"home_id": "abc-123",
|
||||
|
|
@ -51,6 +54,8 @@ response_variable: price_data
|
|||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Use cases:**
|
||||
- Fetching historical price data for analysis
|
||||
- Comparing prices across arbitrary date ranges
|
||||
|
|
@ -67,7 +72,7 @@ response_variable: price_data
|
|||
**Example:**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (refresh_user_data)</summary>
|
||||
<summary>Show YAML: Refresh User Data</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.refresh_user_data
|
||||
|
|
|
|||
|
|
@ -39,6 +39,9 @@ To see which icon a sensor currently uses:
|
|||
|
||||
Dynamic icons work automatically in standard Home Assistant cards:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Standard Entity Cards</summary>
|
||||
|
||||
```yaml
|
||||
type: entities
|
||||
entities:
|
||||
|
|
@ -48,12 +51,14 @@ entities:
|
|||
- entity: binary_sensor.<home_name>_best_price_period
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
The icons will update automatically as the sensor states change.
|
||||
|
||||
### Glance Card
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (Glance card)</summary>
|
||||
<summary>Show YAML: Glance Card</summary>
|
||||
|
||||
```yaml
|
||||
type: glance
|
||||
|
|
@ -71,7 +76,7 @@ entities:
|
|||
### Custom Button Card
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (custom button card)</summary>
|
||||
<summary>Show YAML: Custom Button Card</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:button-card
|
||||
|
|
@ -86,7 +91,7 @@ show_state: true
|
|||
### Mushroom Entity Card
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (Mushroom entity card)</summary>
|
||||
<summary>Show YAML: Mushroom Entity Card</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:mushroom-entity-card
|
||||
|
|
@ -104,7 +109,7 @@ If you want to use a fixed icon instead of the dynamic one:
|
|||
### In Entity Cards
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (fixed icon in entity card)</summary>
|
||||
<summary>Show YAML: Fixed Icon in Entity Card</summary>
|
||||
|
||||
```yaml
|
||||
type: entities
|
||||
|
|
@ -118,7 +123,7 @@ entities:
|
|||
### In Custom Button Card
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (fixed icon in button card)</summary>
|
||||
<summary>Show YAML: Fixed Icon in Button Card</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:button-card
|
||||
|
|
@ -137,7 +142,7 @@ Dynamic icons work great together with dynamic colors! See the **[Dynamic Icon C
|
|||
**Example: Dynamic icon AND color**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (dynamic icon + dynamic color)</summary>
|
||||
<summary>Show YAML: Dynamic Icon and Color</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:button-card
|
||||
|
|
|
|||
|
|
@ -118,6 +118,9 @@ If you see unexpected units, check your configuration in the integration options
|
|||
|
||||
### How do I run dishwasher during cheap period?
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Dishwasher During Cheap Period</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
- alias: "Dishwasher during Best Price"
|
||||
|
|
@ -134,12 +137,17 @@ automation:
|
|||
entity_id: switch.dishwasher
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
See [Automation Examples](automation-examples.md) for more recipes.
|
||||
|
||||
### Can I avoid peak prices automatically?
|
||||
|
||||
Yes! Use Peak Price Period binary sensor:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Avoid Peak Prices Automatically</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
- alias: "Disable charging during peak prices"
|
||||
|
|
@ -153,6 +161,8 @@ automation:
|
|||
entity_id: switch.ev_charger
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
💡 **Still need help?**
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ The colors adapt to the sensor's state - cheaper prices typically show green, ex
|
|||
**Example of when NOT to use icon_color:**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML comparison (complex conversion vs direct state logic)</summary>
|
||||
<summary>Show YAML: Conversion vs Direct State Logic</summary>
|
||||
|
||||
```yaml
|
||||
# ❌ DON'T: Converting icon_color requires if/else anyway
|
||||
|
|
@ -104,6 +104,9 @@ The [custom:button-card](https://github.com/custom-cards/button-card) from HACS
|
|||
|
||||
**Example: Icon color only**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Icon color only</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:button-card
|
||||
entity: sensor.<home_name>_current_price_level
|
||||
|
|
@ -118,10 +121,12 @@ styles:
|
|||
]]]
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Example: Icon AND state value with same color**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (button-card icon + state text in same color)</summary>
|
||||
<summary>Show YAML: Button Card Icon and State Text</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:button-card
|
||||
|
|
@ -150,7 +155,7 @@ styles:
|
|||
Use Home Assistant's built-in entities card with card_mod for icon and state colors:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Entities card with card_mod</summary>
|
||||
<summary>Show YAML: Entities Card with card-mod</summary>
|
||||
|
||||
```yaml
|
||||
type: entities
|
||||
|
|
@ -177,7 +182,7 @@ The [Mushroom cards](https://github.com/piitaya/lovelace-mushroom) support card_
|
|||
**Icon color only:**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (Mushroom icon color only)</summary>
|
||||
<summary>Show YAML: Mushroom Icon Color Only</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:mushroom-entity-card
|
||||
|
|
@ -196,7 +201,7 @@ card_mod:
|
|||
**Icon and state value:**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Mushroom card — icon and state value with same color</summary>
|
||||
<summary>Show YAML: Icon and state value</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:mushroom-entity-card
|
||||
|
|
@ -217,7 +222,7 @@ card_mod:
|
|||
Combine multiple sensors with dynamic colors:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Glance card with card_mod for multiple sensors</summary>
|
||||
<summary>Show YAML: Multi-Sensor Dynamic Colors</summary>
|
||||
|
||||
```yaml
|
||||
type: glance
|
||||
|
|
@ -245,7 +250,7 @@ card_mod:
|
|||
Here's a complete example combining multiple sensors with dynamic colors:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Complete dashboard with dynamic colors for all sensor types</summary>
|
||||
<summary>Show YAML: Complete Dashboard Example</summary>
|
||||
|
||||
```yaml
|
||||
type: vertical-stack
|
||||
|
|
@ -352,7 +357,7 @@ If you want to override the theme colors with your own, you have two options:
|
|||
Define custom colors in your theme configuration (`themes.yaml`):
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (theme-level color overrides)</summary>
|
||||
<summary>Show YAML: Theme-Level Color Overrides</summary>
|
||||
|
||||
```yaml
|
||||
my_custom_theme:
|
||||
|
|
@ -374,7 +379,7 @@ Instead of using `icon_color`, read the sensor state and apply your own colors:
|
|||
**Example: Custom colors for price level**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Price level — 5-color JavaScript mapping</summary>
|
||||
<summary>Show YAML: Custom colors for price level</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:button-card
|
||||
|
|
@ -401,7 +406,7 @@ styles:
|
|||
**Example: Custom colors for binary sensor**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Binary sensor — on/off color + background highlight</summary>
|
||||
<summary>Show YAML: Custom colors for binary sensor</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:button-card
|
||||
|
|
@ -428,7 +433,7 @@ styles:
|
|||
**Example: Custom colors for volatility**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Volatility sensor — 4-level color mapping</summary>
|
||||
<summary>Show YAML: Custom colors for volatility</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:button-card
|
||||
|
|
@ -453,7 +458,7 @@ styles:
|
|||
**Example: Custom colors for price rating**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Price rating — 3-state color mapping</summary>
|
||||
<summary>Show YAML: Custom colors for price rating</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:button-card
|
||||
|
|
|
|||
|
|
@ -16,9 +16,14 @@
|
|||
2. Go to **Integrations**
|
||||
3. Click the **⋮** menu (top right) → **Custom repositories**
|
||||
4. Add the repository URL:
|
||||
<details>
|
||||
<summary>Show example: Repository URL</summary>
|
||||
|
||||
```
|
||||
https://github.com/jpawlowski/hass.tibber_prices
|
||||
```
|
||||
|
||||
</details>
|
||||
Category: **Integration**
|
||||
5. Click **Add**
|
||||
6. Find **Tibber Price Information & Ratings** in the integration list
|
||||
|
|
@ -42,6 +47,9 @@ If you prefer not to use HACS:
|
|||
1. Download the [latest release](https://github.com/jpawlowski/hass.tibber_prices/releases/latest) from GitHub
|
||||
2. Extract the `custom_components/tibber_prices/` folder
|
||||
3. Copy it to your Home Assistant `config/custom_components/` directory:
|
||||
<details>
|
||||
<summary>Show example: Folder Structure</summary>
|
||||
|
||||
```
|
||||
config/
|
||||
└── custom_components/
|
||||
|
|
@ -52,6 +60,8 @@ If you prefer not to use HACS:
|
|||
├── binary_sensor/
|
||||
└── ...
|
||||
```
|
||||
|
||||
</details>
|
||||
4. **Restart Home Assistant**
|
||||
5. Continue with [Configuration](configuration.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -57,6 +57,9 @@ The integration sets different **initial defaults** because the features serve d
|
|||
|
||||
### Example Timeline
|
||||
|
||||
<details>
|
||||
<summary>Show example: Timeline</summary>
|
||||
|
||||
```
|
||||
00:00 ████████████████ Best Price Period (cheap prices)
|
||||
04:00 ░░░░░░░░░░░░░░░░ Normal
|
||||
|
|
@ -66,6 +69,8 @@ The integration sets different **initial defaults** because the features serve d
|
|||
20:00 ████████████████ Best Price Period (cheap prices)
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
## How It Works
|
||||
|
|
@ -116,26 +121,39 @@ Think of it like this:
|
|||
|
||||
**Best Price:** How much MORE than the daily minimum can a price be?
|
||||
|
||||
<details>
|
||||
<summary>Show example: Search Range Flexibility</summary>
|
||||
|
||||
```
|
||||
Daily MIN: 20 ct/kWh
|
||||
Flexibility: 15% (default)
|
||||
→ Search for times ≤ 23 ct/kWh (20 + 15%)
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Peak Price:** How much LESS than the daily maximum can a price be?
|
||||
|
||||
<details>
|
||||
<summary>Show example: Peak Price Flexibility</summary>
|
||||
|
||||
```
|
||||
Daily MAX: 40 ct/kWh
|
||||
Flexibility: -15% (default)
|
||||
→ Search for times ≥ 34 ct/kWh (40 - 15%)
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Why flexibility?** Prices rarely stay at exactly MIN/MAX. Flexibility lets you capture realistic time windows.
|
||||
|
||||
#### 2. Ensure Quality (Distance from Average)
|
||||
|
||||
Periods must be meaningfully different from the daily average:
|
||||
|
||||
<details>
|
||||
<summary>Show example: Distance from Average</summary>
|
||||
|
||||
```
|
||||
Daily AVG: 30 ct/kWh
|
||||
Minimum distance: 5% (default)
|
||||
|
|
@ -144,12 +162,17 @@ Best Price: Must be ≤ 28.5 ct/kWh (30 - 5%)
|
|||
Peak Price: Must be ≥ 31.5 ct/kWh (30 + 5%)
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Why?** This prevents marking mediocre times as "best" just because they're slightly below average.
|
||||
|
||||
#### 3. Check Duration
|
||||
|
||||
Periods must be long enough to be practical:
|
||||
|
||||
<details>
|
||||
<summary>Show example: Minimum Period Duration</summary>
|
||||
|
||||
```
|
||||
Default: 60 minutes minimum
|
||||
|
||||
|
|
@ -157,6 +180,8 @@ Default: 60 minutes minimum
|
|||
90-minute period → Kept ✓
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
#### 4. Apply Optional Filters
|
||||
|
||||
You can optionally require:
|
||||
|
|
@ -167,6 +192,9 @@ You can optionally require:
|
|||
|
||||
Isolated price spikes are automatically detected and smoothed to prevent unnecessary period fragmentation:
|
||||
|
||||
<details>
|
||||
<summary>Show example: Automatic Price Spike Smoothing</summary>
|
||||
|
||||
```
|
||||
Original prices: 18, 19, 35, 20, 19 ct ← 35 ct is an isolated outlier
|
||||
Smoothed: 18, 19, 19, 20, 19 ct ← Spike replaced with trend prediction
|
||||
|
|
@ -174,6 +202,8 @@ Smoothed: 18, 19, 19, 20, 19 ct ← Spike replaced with trend predictio
|
|||
Result: Continuous period 00:00-01:15 instead of split periods
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Important:**
|
||||
- Original prices are always preserved (min/max/avg show real values)
|
||||
- Smoothing only affects which intervals are combined into periods
|
||||
|
|
@ -183,6 +213,9 @@ Result: Continuous period 00:00-01:15 instead of split periods
|
|||
|
||||
**Timeline for a typical day:**
|
||||
|
||||
<details>
|
||||
<summary>Show example: Timeline</summary>
|
||||
|
||||
```
|
||||
Hour: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23
|
||||
Price: 18 19 20 28 29 30 35 34 33 32 30 28 25 24 26 28 30 32 31 22 21 20 19 18
|
||||
|
|
@ -198,6 +231,8 @@ Peak Price (-15% flex = ≥29.75 ct):
|
|||
06:00-11:00 (5h)
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
## Configuration Guide
|
||||
|
|
@ -210,11 +245,16 @@ Peak Price (-15% flex = ≥29.75 ct):
|
|||
**Default:** 15% (Best Price), -15% (Peak Price)
|
||||
**Range:** 0-100%
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Flexibility</summary>
|
||||
|
||||
```yaml
|
||||
best_price_flex: 15 # Can be up to 15% more expensive than daily MIN
|
||||
peak_price_flex: -15 # Can be up to 15% less expensive than daily MAX
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**When to adjust:**
|
||||
|
||||
- **Increase (20-25%)** → Find more/longer periods
|
||||
|
|
@ -228,11 +268,16 @@ peak_price_flex: -15 # Can be up to 15% less expensive than daily MAX
|
|||
**Default:** 60 minutes (Best Price), 30 minutes (Peak Price)
|
||||
**Range:** 15-240 minutes
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Minimum Period Length</summary>
|
||||
|
||||
```yaml
|
||||
best_price_min_period_length: 60
|
||||
peak_price_min_period_length: 30
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**When to adjust:**
|
||||
|
||||
- **Increase (90-120 min)** → Only show longer periods (e.g., for heat pump cycles)
|
||||
|
|
@ -244,11 +289,16 @@ peak_price_min_period_length: 30
|
|||
**Default:** 5%
|
||||
**Range:** 0-20%
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Distance from Average</summary>
|
||||
|
||||
```yaml
|
||||
best_price_min_distance_from_avg: 5
|
||||
peak_price_min_distance_from_avg: 5
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**When to adjust:**
|
||||
|
||||
- **Increase (5-10%)** → Only show clearly better times
|
||||
|
|
@ -265,7 +315,7 @@ peak_price_min_distance_from_avg: 5
|
|||
**Options:** `any` | `cheap` | `very_cheap` (Best Price) | `expensive` | `very_expensive` (Peak Price)
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (level filter)</summary>
|
||||
<summary>Show YAML: Level Filter</summary>
|
||||
|
||||
```yaml
|
||||
best_price_max_level: any # Show any period below average
|
||||
|
|
@ -285,7 +335,7 @@ best_price_max_level: cheap # Only show if at least one interval is CHEAP
|
|||
**Range:** 0-10
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (gap tolerance)</summary>
|
||||
<summary>Show YAML: Gap Tolerance</summary>
|
||||
|
||||
```yaml
|
||||
best_price_max_level: cheap
|
||||
|
|
@ -305,7 +355,7 @@ When you're not happy with the default behavior, adjust settings in this order:
|
|||
If you're not finding enough periods:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (relaxation defaults)</summary>
|
||||
<summary>Show YAML: Relaxation Defaults</summary>
|
||||
|
||||
```yaml
|
||||
enable_min_periods_best: true # Already default!
|
||||
|
|
@ -322,7 +372,7 @@ relaxation_attempts_best: 11 # Already default!
|
|||
If periods are too short/long for your use case:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (longer or shorter periods)</summary>
|
||||
<summary>Show YAML: Longer or Shorter Periods</summary>
|
||||
|
||||
```yaml
|
||||
best_price_min_period_length: 90 # Increase from 60 for longer periods
|
||||
|
|
@ -339,7 +389,7 @@ best_price_min_period_length: 45 # Decrease from 60 for shorter periods
|
|||
If you consistently want more/fewer periods:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (flexibility tuning)</summary>
|
||||
<summary>Show YAML: Flexibility Tuning</summary>
|
||||
|
||||
```yaml
|
||||
best_price_flex: 20 # Increase from 15% for more periods
|
||||
|
|
@ -356,7 +406,7 @@ best_price_flex: 10 # Decrease from 15% for stricter selection
|
|||
Only if periods seem "mediocre" (not really cheap/expensive):
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (distance from average)</summary>
|
||||
<summary>Show YAML: Distance from Average</summary>
|
||||
|
||||
```yaml
|
||||
best_price_min_distance_from_avg: 10 # Increase from 5% for stricter quality
|
||||
|
|
@ -371,7 +421,7 @@ best_price_min_distance_from_avg: 10 # Increase from 5% for stricter quality
|
|||
Only if you want absolute quality requirements:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (strict level filter)</summary>
|
||||
<summary>Show YAML: Strict Level Filter</summary>
|
||||
|
||||
```yaml
|
||||
best_price_max_level: cheap # Only show objectively CHEAP periods
|
||||
|
|
@ -419,6 +469,9 @@ On days with a sharp price dip (e.g. solar midday surplus), the Best Price Perio
|
|||
|
||||
**Configuration:**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Simple Best Price</summary>
|
||||
|
||||
```yaml
|
||||
# Use defaults - no configuration needed!
|
||||
best_price_flex: 15 # (default)
|
||||
|
|
@ -426,6 +479,8 @@ best_price_min_period_length: 60 # (default)
|
|||
best_price_min_distance_from_avg: 5 # (default)
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**What you get:**
|
||||
|
||||
- 1-3 periods per day with prices ≤ MIN + 15%
|
||||
|
|
@ -435,7 +490,7 @@ best_price_min_distance_from_avg: 5 # (default)
|
|||
**Automation example:**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML automation example (run dishwasher in best price period)</summary>
|
||||
<summary>Show YAML: Dishwasher in Best Price Period</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -464,7 +519,7 @@ automation:
|
|||
This is **expected behavior** on days with very uniform electricity prices. When prices vary by less than ~10% across the day (e.g. on sunny spring days with high solar generation), there is no meaningful second "cheap window" – all hours are equally cheap. The integration automatically reduces the target to 1 period for that day.
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (flat day detection)</summary>
|
||||
<summary>Show YAML: Flat Day Detection</summary>
|
||||
|
||||
```yaml
|
||||
min_periods_configured: 2
|
||||
|
|
@ -582,7 +637,7 @@ Relaxation tried all configured attempts but couldn't reach your target. Options
|
|||
**Key attributes to check:**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Sensor attribute reference for best_price_period</summary>
|
||||
<summary>Show YAML: Key attributes to check</summary>
|
||||
|
||||
```yaml
|
||||
# Entity: binary_sensor.<home_name>_best_price_period
|
||||
|
|
@ -619,7 +674,7 @@ relaxation_incomplete: true # Some days couldn't reach the configured ta
|
|||
These two values together quickly show whether the calculation achieved its goal:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML examples (configured target vs. found periods)</summary>
|
||||
<summary>Show YAML: Configured Target vs Found Periods</summary>
|
||||
|
||||
```yaml
|
||||
min_periods_configured: 2 # You asked for 2 periods per day
|
||||
|
|
@ -640,7 +695,7 @@ Note that `periods_found_total` counts **all periods across today and tomorrow**
|
|||
This is the most important diagnostic for days with very uniform prices (e.g. sunny spring/summer days with high solar generation):
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (flat_days_detected)</summary>
|
||||
<summary>Show YAML: Flat Days Detected Attribute</summary>
|
||||
|
||||
```yaml
|
||||
min_periods_configured: 2
|
||||
|
|
@ -659,7 +714,7 @@ When prices barely change across the day – typically a variation of less than
|
|||
This flag appears when even after all relaxation attempts, at least one day could not reach the configured minimum number of periods:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (relaxation_incomplete)</summary>
|
||||
<summary>Show YAML: Relaxation Incomplete Attribute</summary>
|
||||
|
||||
```yaml
|
||||
min_periods_configured: 2
|
||||
|
|
@ -697,7 +752,7 @@ This is **mathematically correct behavior** caused by how electricity prices are
|
|||
**Example:**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: How identical prices can flip between best/peak across midnight</summary>
|
||||
<summary>Show YAML: Midnight Price Classification Changes</summary>
|
||||
|
||||
```yaml
|
||||
# Day 1 (low volatility, narrow range)
|
||||
|
|
@ -728,7 +783,7 @@ Daily average: 19 ct/kWh
|
|||
Check the volatility sensors to understand if a period flip is meaningful:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (daily volatility check)</summary>
|
||||
<summary>Show YAML: Daily Volatility Check</summary>
|
||||
|
||||
```yaml
|
||||
# Check daily volatility (available in integration)
|
||||
|
|
@ -748,7 +803,7 @@ sensor.<home_name>_tomorrow_s_price_volatility: 7.9% # Also low
|
|||
You can make your automations volatility-aware:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: 3 automation strategies for volatility-aware period control</summary>
|
||||
<summary>Show YAML: Volatility-Aware Automation</summary>
|
||||
|
||||
```yaml
|
||||
# Option 1: Only act on high-volatility days
|
||||
|
|
@ -805,7 +860,7 @@ automation:
|
|||
Each period sensor exposes day volatility and price statistics:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (per-period volatility attributes)</summary>
|
||||
<summary>Show YAML: Per-Period Volatility Attributes</summary>
|
||||
|
||||
```yaml
|
||||
binary_sensor.<home_name>_best_price_period:
|
||||
|
|
|
|||
|
|
@ -14,12 +14,17 @@ Sometimes, strict filters find too few periods (or none). **Relaxation automatic
|
|||
|
||||
## How to Enable
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Enable Relaxation</summary>
|
||||
|
||||
```yaml
|
||||
enable_min_periods_best: true
|
||||
min_periods_best: 2 # Try to find at least 2 periods per day
|
||||
relaxation_attempts_best: 11 # Flex levels to test (default: 11 steps = 22 filter combinations)
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Good news:** Relaxation is **enabled by default** with sensible settings. Most users don't need to change anything here!
|
||||
|
||||
Set the matching `relaxation_attempts_peak` value when tuning Peak Price periods. Both sliders accept 1-12 attempts, and the default of 11 flex levels translates to 22 filter-combination tries (11 flex levels × 2 filter combos) for each of Best and Peak calculations. Lower it for quick feedback, or raise it when either sensor struggles to hit the minimum-period target on volatile days.
|
||||
|
|
@ -99,18 +104,26 @@ Each attempt adds +3% flexibility and tries two filter combinations. The system
|
|||
|
||||
**Critical:** Each day relaxes **independently**:
|
||||
|
||||
<details>
|
||||
<summary>Show formula: Each day relaxes independently</summary>
|
||||
|
||||
```
|
||||
Day 1: Finds 2 periods with flex 15% (original) → No relaxation needed
|
||||
Day 2: Needs flex 21% + level=any → Uses relaxed settings
|
||||
Day 3: Finds 2 periods with flex 15% (original) → No relaxation needed
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Why?** Price patterns vary daily. Some days have clear cheap/expensive windows (strict filters work), others don't (relaxation needed).
|
||||
|
||||
## Diagnosing Relaxation Behavior
|
||||
|
||||
Check the period sensor attributes to understand what happened:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Diagnosing Relaxation Behavior</summary>
|
||||
|
||||
```yaml
|
||||
# Entity: binary_sensor.<home_name>_best_price_period
|
||||
|
||||
|
|
@ -120,6 +133,8 @@ min_periods_configured: 2 # Your target
|
|||
periods_found_total: 3 # What was actually found
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
| Attribute | Meaning |
|
||||
|-----------|---------|
|
||||
| `relaxation_active: false` | Original filters were sufficient |
|
||||
|
|
|
|||
|
|
@ -53,6 +53,9 @@ The simplest approach — use `search_scope` for common time ranges:
|
|||
| `next_24h` | Now | Now + 24 hours |
|
||||
| `next_48h` | Now | Now + 48 hours |
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Quick Scopes</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.find_cheapest_block
|
||||
data:
|
||||
|
|
@ -60,12 +63,14 @@ data:
|
|||
search_scope: tomorrow
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### Explicit Start/End
|
||||
|
||||
For full control, specify exact datetime values:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (explicit start and end datetimes)</summary>
|
||||
<summary>Show YAML: Explicit Start and End</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.find_cheapest_block
|
||||
|
|
@ -82,7 +87,7 @@ data:
|
|||
Schedule relative to today using time + day offset:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (time-of-day with day offset)</summary>
|
||||
<summary>Show YAML: Time of Day with Offset</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.find_cheapest_block
|
||||
|
|
@ -100,7 +105,7 @@ data:
|
|||
For relative searches:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (relative minute offsets)</summary>
|
||||
<summary>Show YAML: Relative Minute Offsets</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.find_cheapest_block
|
||||
|
|
@ -139,6 +144,9 @@ These parameters are available across all scheduling actions:
|
|||
|
||||
Restrict the search to specific Tibber price levels. Levels from lowest to highest: `very_cheap`, `cheap`, `normal`, `expensive`, `very_expensive`.
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Price Level Filtering</summary>
|
||||
|
||||
```yaml
|
||||
# Only search within cheap or very cheap intervals
|
||||
service: tibber_prices.find_cheapest_block
|
||||
|
|
@ -148,12 +156,14 @@ data:
|
|||
max_price_level: cheap # Exclude normal, expensive, very_expensive
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### Power Profile
|
||||
|
||||
By default, cost estimates assume a constant 1 kW load. If your appliance has variable power draw, provide a power profile — **one watt value per 15-minute interval**:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (power profile per 15-minute interval)</summary>
|
||||
<summary>Show YAML: Power Profile</summary>
|
||||
|
||||
```yaml
|
||||
# Washing machine: high power for heating, then less
|
||||
|
|
@ -187,6 +197,9 @@ Finds the single cheapest **contiguous** time window of a given duration.
|
|||
|
||||
### Basic Example
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Find Cheapest Block</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.find_cheapest_block
|
||||
data:
|
||||
|
|
@ -195,10 +208,12 @@ data:
|
|||
response_variable: result
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### Example with All Options
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (find_cheapest_block with all options)</summary>
|
||||
<summary>Show YAML: Cheapest Block with All Options</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.find_cheapest_block
|
||||
|
|
@ -216,6 +231,9 @@ response_variable: result
|
|||
|
||||
### Response
|
||||
|
||||
<details>
|
||||
<summary>Show JSON: Cheapest Block Example Response</summary>
|
||||
|
||||
```json
|
||||
{
|
||||
"home_id": "abc-123",
|
||||
|
|
@ -255,6 +273,8 @@ response_variable: result
|
|||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Key response fields:**
|
||||
|
||||
| Field | Description |
|
||||
|
|
@ -269,7 +289,7 @@ response_variable: result
|
|||
### Use in Automations
|
||||
|
||||
<details>
|
||||
<summary>Show YAML automation example (start dishwasher at cheapest time)</summary>
|
||||
<summary>Show YAML: Dishwasher Automation</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -310,6 +330,9 @@ Finds the cheapest N minutes of intervals within a search range. Intervals **do
|
|||
|
||||
### Basic Example
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Find Cheapest Hours</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.find_cheapest_hours
|
||||
data:
|
||||
|
|
@ -318,10 +341,15 @@ data:
|
|||
response_variable: result
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### With Minimum Segment Duration
|
||||
|
||||
Some devices shouldn't cycle on/off too rapidly. Use `min_segment_duration` to ensure each contiguous run is at least a minimum length:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: With Minimum Segment Duration</summary>
|
||||
|
||||
```yaml
|
||||
# EV charger: 3 hours total, but each charging session at least 30 min
|
||||
service: tibber_prices.find_cheapest_hours
|
||||
|
|
@ -332,8 +360,13 @@ data:
|
|||
response_variable: result
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### Response
|
||||
|
||||
<details>
|
||||
<summary>Show JSON: Cheapest Hours Example Response</summary>
|
||||
|
||||
```json
|
||||
{
|
||||
"home_id": "abc-123",
|
||||
|
|
@ -389,6 +422,8 @@ response_variable: result
|
|||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Key response fields:**
|
||||
|
||||
| Field | Description |
|
||||
|
|
@ -416,6 +451,9 @@ Schedules **multiple appliances** within the same search range, ensuring they do
|
|||
|
||||
### Basic Example
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Find Cheapest Schedule</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.find_cheapest_schedule
|
||||
data:
|
||||
|
|
@ -428,10 +466,12 @@ data:
|
|||
response_variable: result
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### With Gap and Power Profiles
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (multi-appliance schedule with gaps and power profiles)</summary>
|
||||
<summary>Show YAML: With Gap and Power Profiles</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.find_cheapest_schedule
|
||||
|
|
@ -457,6 +497,9 @@ response_variable: result
|
|||
|
||||
### Response
|
||||
|
||||
<details>
|
||||
<summary>Show JSON: Cheapest Schedule Example Response</summary>
|
||||
|
||||
```json
|
||||
{
|
||||
"home_id": "abc-123",
|
||||
|
|
@ -514,6 +557,8 @@ response_variable: result
|
|||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Key response fields:**
|
||||
|
||||
| Field | Description |
|
||||
|
|
@ -548,6 +593,9 @@ The opposite of `find_cheapest_block` — finds the most expensive contiguous wi
|
|||
|
||||
**Response:** Same structure. The `price_comparison` compares against the cheapest block.
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Find Most Expensive Block</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.find_most_expensive_block
|
||||
data:
|
||||
|
|
@ -556,6 +604,8 @@ data:
|
|||
response_variable: peak
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Use cases:**
|
||||
- "When should I definitely NOT run my washing machine?"
|
||||
- Schedule battery discharge during peak prices
|
||||
|
|
@ -571,6 +621,9 @@ The opposite of `find_cheapest_hours` — finds the most expensive intervals (no
|
|||
|
||||
**Response:** Same structure. The `price_comparison` compares against the cheapest hours.
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Find Most Expensive Hours</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.find_most_expensive_hours
|
||||
data:
|
||||
|
|
@ -579,6 +632,8 @@ data:
|
|||
response_variable: peak
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Use cases:**
|
||||
- Battery discharge optimization: sell stored energy during the most expensive 4 hours
|
||||
- Demand response: reduce consumption during the most expensive periods
|
||||
|
|
@ -593,7 +648,7 @@ response_variable: peak
|
|||
Schedule dishwasher + washing machine to run overnight at cheapest prices, with a 15-minute gap between them:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML automation example (overnight appliance scheduling)</summary>
|
||||
<summary>Show YAML: Overnight Appliance Scheduling</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -630,7 +685,7 @@ automation:
|
|||
### EV Charging During Cheapest 4 Hours
|
||||
|
||||
<details>
|
||||
<summary>Show YAML automation example (EV charging in cheapest 4 hours)</summary>
|
||||
<summary>Show YAML: EV Charging in Cheapest 4 Hours</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -668,7 +723,7 @@ automation:
|
|||
### Peak Price Warning
|
||||
|
||||
<details>
|
||||
<summary>Show YAML automation example (peak price warning)</summary>
|
||||
<summary>Show YAML: Peak Price Warning</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -709,7 +764,7 @@ All durations are rounded **up** to the nearest 15 minutes because Tibber price
|
|||
Add `include_comparison_details: true` to `find_cheapest_block` or `find_cheapest_hours` to get extra fields in the comparison:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (comparison details enabled)</summary>
|
||||
<summary>Show YAML: Comparison Details</summary>
|
||||
|
||||
```yaml
|
||||
service: tibber_prices.find_cheapest_block
|
||||
|
|
|
|||
|
|
@ -27,6 +27,9 @@ All average sensors support **two different calculation methods** for the state
|
|||
|
||||
**Why two values matter:**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Why two values matter</summary>
|
||||
|
||||
```yaml
|
||||
# Example price data for one day:
|
||||
# Prices: 10, 12, 13, 15, 80 ct/kWh (one extreme spike)
|
||||
|
|
@ -35,6 +38,8 @@ All average sensors support **two different calculation methods** for the state
|
|||
# Mean = 26 ct/kWh ← Mathematical average (affected by spike)
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
The median shows you what price level was **typical** during that period, while the mean shows the actual **average cost** if you consumed evenly throughout the period.
|
||||
|
||||
## Configuring the Display
|
||||
|
|
@ -54,6 +59,9 @@ You can choose which value is displayed in the sensor state:
|
|||
|
||||
Both `price_mean` and `price_median` are always available as attributes:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Mean and Median in Automations</summary>
|
||||
|
||||
```yaml
|
||||
# Example: Get both values regardless of display setting
|
||||
sensor:
|
||||
|
|
@ -75,6 +83,8 @@ sensor:
|
|||
{% endif %}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
## Practical Examples
|
||||
|
||||
**Example 1: Smart dishwasher control**
|
||||
|
|
@ -82,7 +92,7 @@ sensor:
|
|||
Run dishwasher only when price is significantly below the daily typical level:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Automation — start dishwasher when cheap</summary>
|
||||
<summary>Show YAML: Practical Examples</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -110,7 +120,7 @@ automation:
|
|||
Use mean for actual cost calculations:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Automation — cost-aware heating control</summary>
|
||||
<summary>Show YAML: Mean for Cost Calculations</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
@ -137,7 +147,7 @@ automation:
|
|||
Use trailing average to understand recent price trends:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Automation — EV charging based on rolling average</summary>
|
||||
<summary>Show YAML: Practical Examples</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
|
|||
|
|
@ -6,10 +6,15 @@
|
|||
|
||||
Most price sensors include **energy price** and **tax** attributes that break down the total price into its components:
|
||||
|
||||
<details>
|
||||
<summary>Show formula</summary>
|
||||
|
||||
```
|
||||
total = energy_price + tax
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
These attributes appear on **all price sensors that display a raw price** (not on percentage, level, or trend sensors). The `energy_price` is the raw spot/market price, while `tax` includes all fees, surcharges, and taxes added by your electricity provider.
|
||||
|
||||
:::note Transition After Update
|
||||
|
|
@ -35,7 +40,7 @@ After updating the integration, the `energy_price` and `tax` attributes will app
|
|||
In countries like the Netherlands, solar feed-in compensation is based on the **raw energy/spot price**, not the total consumer price. The `energy_price` attribute gives you exactly this value — no more reverse-engineering from the total price with fragile template calculations.
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Automation — solar export or consume decision</summary>
|
||||
<summary>Show YAML: Solar Feed-In and Net Metering</summary>
|
||||
|
||||
```yaml
|
||||
# Example: Decide whether to export solar power or consume it
|
||||
|
|
@ -65,7 +70,7 @@ automation:
|
|||
Understand how your electricity price is structured — useful for comparing across days or spotting trends in market prices vs. fees:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Template sensor — electricity tax share percentage</summary>
|
||||
<summary>Show YAML: Price Composition Analysis</summary>
|
||||
|
||||
```yaml
|
||||
# Template sensor showing tax share
|
||||
|
|
@ -89,6 +94,9 @@ template:
|
|||
|
||||
Show users how today's average price splits into energy vs. tax:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Daily Cost Breakdown</summary>
|
||||
|
||||
```yaml
|
||||
# Mushroom chips card showing the split
|
||||
type: custom:mushroom-chips-card
|
||||
|
|
@ -103,6 +111,8 @@ chips:
|
|||
🏛️ {{ state_attr('sensor.<home_name>_price_today', 'tax_mean') | round(1) }} ct
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
## Country-Specific Calculations
|
||||
|
||||
The composition of the `tax` field varies by country (Norway, Sweden, Germany, Netherlands each have different fee structures). For detailed examples of how to build country-specific calculations using `input_number` helpers and template sensors — including **Dutch solar feed-in compensation (saldering)** — see the **[Community Examples](community-examples.md#country-specific-price-calculations)** page.
|
||||
|
|
|
|||
|
|
@ -156,6 +156,9 @@ See the `tibber_prices.get_chartdata` action documentation for a complete list o
|
|||
|
||||
**Example Usage:**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Example Usage</summary>
|
||||
|
||||
```yaml
|
||||
# ApexCharts card consuming the sensor
|
||||
type: custom:apexcharts-card
|
||||
|
|
@ -165,10 +168,15 @@ series:
|
|||
return entity.attributes.data;
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Migration Path:**
|
||||
|
||||
If you're currently using this sensor, consider migrating to the action:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Chart Data Export</summary>
|
||||
|
||||
```yaml
|
||||
# Old approach (sensor)
|
||||
- service: apexcharts_card.update
|
||||
|
|
@ -183,3 +191,5 @@ If you're currently using this sensor, consider migrating to the action:
|
|||
output_format: array_of_objects
|
||||
response_variable: chart_data
|
||||
```
|
||||
|
||||
</details>
|
||||
|
|
|
|||
|
|
@ -33,10 +33,15 @@ Rating sensors classify prices relative to the **trailing 24-hour average**, ans
|
|||
|
||||
The integration calculates a **percentage difference** between the current price and the trailing 24-hour average:
|
||||
|
||||
<details>
|
||||
<summary>Show formula: How Ratings Work</summary>
|
||||
|
||||
```
|
||||
difference = ((current_price - trailing_avg) / abs(trailing_avg)) × 100%
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
This percentage is then classified:
|
||||
|
||||
| Rating | Condition (default) | Meaning |
|
||||
|
|
@ -88,6 +93,9 @@ stateDiagram-v2
|
|||
|
||||
**Best Practice:** Always use the `rating_level` attribute (lowercase English) instead of the sensor state (which is translated to your HA language):
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Usage in Automations</summary>
|
||||
|
||||
```yaml
|
||||
# ✅ Correct — language-independent
|
||||
condition:
|
||||
|
|
@ -102,6 +110,8 @@ condition:
|
|||
state: "Low" # "Niedrig" in German, "Lav" in Norwegian...
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### Configuration
|
||||
|
||||
Rating thresholds can be adjusted in the options flow:
|
||||
|
|
|
|||
|
|
@ -39,6 +39,9 @@ For each period type (Best Price and Peak Price):
|
|||
|
||||
### Show Countdown to Next Cheap Window
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Countdown to Next Cheap Window</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:mushroom-entity-card
|
||||
entity: sensor.<home_name>_best_price_next_in_minutes
|
||||
|
|
@ -46,10 +49,12 @@ name: Next Cheap Window
|
|||
icon: mdi:clock-fast
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### Display Period Progress Bar
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Bar card for period progress</summary>
|
||||
<summary>Show YAML: Display Period Progress Bar</summary>
|
||||
|
||||
```yaml
|
||||
type: custom:bar-card
|
||||
|
|
@ -74,7 +79,7 @@ severity:
|
|||
### Notify When Period Is Almost Over
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Automation — notify when best price period is ending</summary>
|
||||
<summary>Show YAML: Period Ending Notification</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
|
|
|
|||
|
|
@ -192,6 +192,9 @@ A **countdown timer** companion to the Next Price Trend Change sensor above. Ins
|
|||
|
||||
**Example automation:**
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Example automation</summary>
|
||||
|
||||
```yaml
|
||||
trigger:
|
||||
- platform: numeric_state
|
||||
|
|
@ -203,6 +206,8 @@ action:
|
|||
message: "Price trend is about to change direction!"
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
**Tip:** Use this sensor for "HOW LONG" and the Next Price Trend Change sensor (timestamp) for "WHEN".
|
||||
|
||||
---
|
||||
|
|
@ -233,6 +238,9 @@ A natural intuition is to treat trend states like a stock ticker:
|
|||
|
||||
For most appliances (dishwasher, washing machine, dryer), a single outlook sensor is enough:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: Basic Automation Pattern</summary>
|
||||
|
||||
```yaml
|
||||
# Example: Start dishwasher when prices are favorable
|
||||
trigger:
|
||||
|
|
@ -250,6 +258,8 @@ action:
|
|||
entity_id: switch.dishwasher
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### Combining Multiple Windows
|
||||
|
||||
When short-term and long-term trends disagree, you get richer insight:
|
||||
|
|
|
|||
|
|
@ -61,6 +61,9 @@ For automations, it is strongly recommended to use the `price_volatility` attrib
|
|||
|
||||
**Good Example (Robust Automation):**
|
||||
This automation triggers only if the volatility is classified as `high` or `very_high`, respecting your central settings and working independently of the system language.
|
||||
<details>
|
||||
<summary>Show YAML: Good Example (Robust Automation)</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
- alias: "Enable battery optimization only on volatile days"
|
||||
|
|
@ -73,6 +76,8 @@ automation:
|
|||
entity_id: input_boolean.battery_optimization_enabled
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
### Avoid Hard-Coding Numeric Thresholds
|
||||
|
|
@ -83,6 +88,9 @@ You might be tempted to use the numeric `price_coefficient_variation_%` attribut
|
|||
|
||||
**Bad Example (Brittle Automation):**
|
||||
This automation uses a hard-coded value. If you later change the "High" threshold in the integration's options to 35%, this automation will not respect that change and might trigger at the wrong time.
|
||||
<details>
|
||||
<summary>Show YAML: Bad Example (Brittle Automation)</summary>
|
||||
|
||||
```yaml
|
||||
automation:
|
||||
- alias: "Brittle - Enable battery optimization"
|
||||
|
|
@ -99,4 +107,6 @@ automation:
|
|||
entity_id: input_boolean.battery_optimization_enabled
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
By following the "Good Example", your automations become simpler, more readable, and much easier to maintain.
|
||||
|
|
|
|||
|
|
@ -73,6 +73,9 @@ When reporting issues, debug logs help identify the problem quickly.
|
|||
|
||||
Add this to your `configuration.yaml`:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML: configuration.yaml Logging</summary>
|
||||
|
||||
```yaml
|
||||
logger:
|
||||
default: warning
|
||||
|
|
@ -80,6 +83,8 @@ logger:
|
|||
custom_components.tibber_prices: debug
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
Restart Home Assistant for the change to take effect.
|
||||
|
||||
### Targeted Logging
|
||||
|
|
@ -87,7 +92,7 @@ Restart Home Assistant for the change to take effect.
|
|||
For specific subsystems, you can enable logging selectively:
|
||||
|
||||
<details>
|
||||
<summary>Show YAML example (targeted subsystem logging)</summary>
|
||||
<summary>Show YAML: Targeted Subsystem Logging</summary>
|
||||
|
||||
```yaml
|
||||
logger:
|
||||
|
|
|
|||
Loading…
Reference in a new issue