diff --git a/docs/user/docs/automation-examples.md b/docs/user/docs/automation-examples.md index 6342831..22ef52b 100644 --- a/docs/user/docs/automation-examples.md +++ b/docs/user/docs/automation-examples.md @@ -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.
-Show YAML: Heat pump — extended cheap period +Show YAML: Ride the Full Cheap Wave ```yaml automation: @@ -123,7 +123,7 @@ automation: Use the trend to start slightly before the cheapest period — useful for appliances with warm-up time:
-Show YAML: Water heater — pre-heat before cheapest window +Show YAML: Pre-Emptive Start ```yaml automation: @@ -159,7 +159,7 @@ automation: Stop or reduce consumption when prices are climbing:
-Show YAML: EV charger — stop when prices rising +Show YAML: Protect Against Rising Prices ```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
-Show YAML: Heat pump — multi-window trend strategy +Show YAML: Multi-Window Trend Strategy ```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.
-Show YAML: Home battery — charge on best price (volatility-aware) +Show YAML: Meaningful Price Variations ```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.
-Show YAML: EV charging — combined volatility + absolute price strategy +Show YAML: Volatility and Absolute Price Check ```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.
-Show YAML: Heat pump — smart heating using period volatility attribute +Show YAML: Period Volatility Attribute ```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):
-Show YAML: Dishwasher — schedule for cheapest 2h window +Show YAML: Best Time for an Appliance ```yaml automation: @@ -479,7 +479,7 @@ automation: Get a push notification when the best price period begins:
-Show YAML: Notification — when cheap window starts +Show YAML: Cheap Window Notification ```yaml automation: diff --git a/docs/user/docs/chart-actions.md b/docs/user/docs/chart-actions.md index d287318..1c217bf 100644 --- a/docs/user/docs/chart-actions.md +++ b/docs/user/docs/chart-actions.md @@ -24,6 +24,9 @@ Actions for generating chart data and ApexCharts configurations from your Tibber **Basic Example:** +
+Show YAML: Chart Data Action + ```yaml service: tibber_prices.get_chartdata data: @@ -33,8 +36,13 @@ data: response_variable: chart_data ``` +
+ **Response Format:** +
+Show JSON: Chart Data Response + ```json { "data": [ @@ -50,6 +58,8 @@ response_variable: chart_data } ``` +
+ **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:
-Show YAML example (rolling window mode) +Show YAML: Rolling Window Mode ```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:
-Show YAML example (period filter) +Show YAML: Period Filter ```yaml service: tibber_prices.get_chartdata @@ -108,7 +118,7 @@ response_variable: periods **Advanced Filtering:**
-Show YAML example (advanced filtering) +Show YAML: Advanced Filtering ```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**
-Show YAML example (include energy and tax fields) +Show YAML: Energy and Tax Fields ```yaml service: tibber_prices.get_chartdata @@ -155,6 +165,9 @@ response_variable: chart_data Returns data points like: +
+Show JSON: Returns data points like + ```json { "start_time": "2025-11-17T14:00:00+01:00", @@ -164,6 +177,8 @@ Returns data points like: } ``` +
+ **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:** +
+Show YAML: Quick Example + ```yaml service: tibber_prices.get_apexcharts_yaml data: @@ -204,6 +222,8 @@ data: response_variable: apexcharts_config ``` +
+ **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)**
-Show YAML example (today, static view) +Show YAML: Today Static View ```yaml service: tibber_prices.get_apexcharts_yaml @@ -244,7 +264,7 @@ type: custom:apexcharts-card **Example: Rolling 48h Window (Dynamic View)**
-Show YAML example (rolling 48h dynamic view) +Show YAML: Rolling 48h Dynamic View ```yaml service: tibber_prices.get_apexcharts_yaml diff --git a/docs/user/docs/chart-examples.md b/docs/user/docs/chart-examples.md index ac8d607..957ead6 100644 --- a/docs/user/docs/chart-examples.md +++ b/docs/user/docs/chart-examples.md @@ -41,6 +41,9 @@ The integration can generate 4 different chart modes, each optimized for specifi **Dependencies:** ApexCharts Card only **Generate:** +
+Show YAML: Today's Prices (Static) + ```yaml service: tibber_prices.get_apexcharts_yaml data: @@ -50,6 +53,8 @@ data: highlight_best_price: true ``` +
+ **Screenshot:** ![Today's Prices - Static 24h View](/img/charts/today.jpg) @@ -72,7 +77,7 @@ data: **Generate:**
-Show YAML example (generate rolling 48h window) +Show YAML: Rolling 48h Window ```yaml service: tibber_prices.get_apexcharts_yaml @@ -111,7 +116,7 @@ data: **Generate:**
-Show YAML example (generate rolling auto-zoom) +Show YAML: Rolling Auto-Zoom ```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):** +
+Show chart illustration: Without Chart Metadata + ``` ┌─────────────────────┐ │ │ ← Lots of empty space @@ -187,7 +195,12 @@ Rolling window modes (2 & 3) automatically integrate with the `chart_metadata` s 0 100 ct ``` +
+ **With chart_metadata sensor (enabled):** +
+Show chart illustration: With Chart Metadata + ``` ┌─────────────────────┐ │ ___ │ ← 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 ``` +
+ **Requirements:** - ✅ The `sensor._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:** +
+Show chart illustration: Best Price Period Highlights + ``` Price │ @@ -226,6 +244,8 @@ Price 06:00 12:00 18:00 ``` +
+ **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 +
+Show shell command: Prerequisite for All Modes + ```bash # Install via HACS HACS → Frontend → Search "ApexCharts Card" → Download ``` +
+ ### Required for Rolling Window Modes Only - **[Config Template Card](https://github.com/iantrich/config-template-card)**: Enables dynamic configuration +
+Show shell command: Rolling Window Prerequisite + ```bash # Install via HACS HACS → Frontend → Search "Config Template Card" → Download ``` +
+ **Note:** Fixed day views (`today`, `tomorrow`) work with ApexCharts Card alone! --- @@ -263,7 +293,7 @@ Price Edit the `colors` array in the generated YAML:
-Show YAML example (custom color palette) +Show YAML: Custom Color Palette ```yaml apex_config: @@ -280,7 +310,7 @@ apex_config: Add to the card configuration:
-Show YAML example (custom chart height) +Show YAML: Custom Chart Height ```yaml type: custom:apexcharts-card @@ -300,7 +330,7 @@ apex_config: Wrap in a vertical stack for dashboard integration:
-Show YAML example (vertical stack integration) +Show YAML: Vertical Stack Integration ```yaml type: vertical-stack diff --git a/docs/user/docs/community-examples.md b/docs/user/docs/community-examples.md index 1ed5fcb..e2e5b17 100644 --- a/docs/user/docs/community-examples.md +++ b/docs/user/docs/community-examples.md @@ -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 |
-Alternative: YAML configuration for input_number helpers +Show YAML: Input Number Helpers 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.
-Show YAML: Template sensors for feed-in with and without saldering +Show YAML: Feed-In Compensation Sensors ```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:
-Show YAML: Smart export automation +Show YAML: Feed-In Automation ```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:
-Show YAML: Dashboard comparison card +Show YAML: Preparing for the End of Saldering ```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:
-Show YAML: Spot price share template sensor +Show YAML: Spot Price Share ```yaml template: diff --git a/docs/user/docs/configuration.md b/docs/user/docs/configuration.md index 9ce775e..fc84848 100644 --- a/docs/user/docs/configuration.md +++ b/docs/user/docs/configuration.md @@ -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: +
+Show example: Mean vs Median + ``` 10, 12, 13, 15, 80 ct/kWh ``` +
+ - **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:
-Show YAML example (median and mean attributes) +Show YAML: Median and Mean Attributes ```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
-Show YAML example (seasonal runtime override) +Show YAML: Seasonal Runtime Override ```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`:
-Show YAML example (exclude runtime config entities from recorder) +Show YAML: Exclude Runtime Config Entities ```yaml recorder: diff --git a/docs/user/docs/dashboard-examples.md b/docs/user/docs/dashboard-examples.md index b016765..7ad62bf 100644 --- a/docs/user/docs/dashboard-examples.md +++ b/docs/user/docs/dashboard-examples.md @@ -10,6 +10,9 @@ Beautiful dashboard layouts using Tibber Prices sensors. Simple card showing current price with dynamic color: +
+Show YAML: Current Price Card + ```yaml type: entities title: Current Electricity Price @@ -23,10 +26,15 @@ entities: name: Next Price ``` +
+ ## Period Status Cards Show when best/peak price periods are active: +
+Show YAML: Best and Peak Period Card + ```yaml type: horizontal-stack cards: @@ -40,12 +48,14 @@ cards: icon: mdi:alert ``` +
+ ## Custom Button Card Examples ### Price Level Card
-Show YAML: Price level card with color gradients (custom:button-card) +Show YAML: Price Level Card ```yaml type: custom:button-card @@ -74,7 +84,7 @@ styles: Optimized for mobile devices:
-Show YAML: Compact mobile layout +Show YAML: Optimized for mobile devices ```yaml type: vertical-stack @@ -101,7 +111,7 @@ cards: Full-width layout for desktop:
-Show YAML: Desktop 3-column grid layout +Show YAML: Full-width layout for desktop ```yaml type: grid @@ -136,7 +146,7 @@ cards: Using the `icon_color` attribute for dynamic colors:
-Show YAML: Dynamic icon colors with mushroom chips +Show YAML: Icon Color Integration ```yaml type: custom:mushroom-chips-card @@ -163,7 +173,7 @@ See [Icon Colors](icon-colors.md) for detailed color mapping. Advanced interactive dashboard:
-Show YAML: Picture elements interactive dashboard +Show YAML: Advanced interactive dashboard ```yaml type: picture-elements @@ -193,7 +203,7 @@ elements: Automatically list all price sensors:
-Show YAML: Auto-entities card for all price sensors +Show YAML: Auto-Entities Sensor List ```yaml type: custom:auto-entities diff --git a/docs/user/docs/data-actions.md b/docs/user/docs/data-actions.md index a048f2e..3fe9054 100644 --- a/docs/user/docs/data-actions.md +++ b/docs/user/docs/data-actions.md @@ -19,7 +19,7 @@ Actions for fetching raw price data and managing integration state. **Example:**
-Show YAML example (get_price) +Show YAML: Get Price ```yaml service: tibber_prices.get_price @@ -34,6 +34,9 @@ response_variable: price_data **Response Format:** +
+Show JSON: Get Price Response + ```json { "home_id": "abc-123", @@ -51,6 +54,8 @@ response_variable: price_data } ``` +
+ **Use cases:** - Fetching historical price data for analysis - Comparing prices across arbitrary date ranges @@ -67,7 +72,7 @@ response_variable: price_data **Example:**
-Show YAML example (refresh_user_data) +Show YAML: Refresh User Data ```yaml service: tibber_prices.refresh_user_data diff --git a/docs/user/docs/dynamic-icons.md b/docs/user/docs/dynamic-icons.md index 2e7a5b4..c187c80 100644 --- a/docs/user/docs/dynamic-icons.md +++ b/docs/user/docs/dynamic-icons.md @@ -39,6 +39,9 @@ To see which icon a sensor currently uses: Dynamic icons work automatically in standard Home Assistant cards: +
+Show YAML: Standard Entity Cards + ```yaml type: entities entities: @@ -48,12 +51,14 @@ entities: - entity: binary_sensor._best_price_period ``` +
+ The icons will update automatically as the sensor states change. ### Glance Card
-Show YAML example (Glance card) +Show YAML: Glance Card ```yaml type: glance @@ -71,7 +76,7 @@ entities: ### Custom Button Card
-Show YAML example (custom button card) +Show YAML: Custom Button Card ```yaml type: custom:button-card @@ -86,7 +91,7 @@ show_state: true ### Mushroom Entity Card
-Show YAML example (Mushroom entity card) +Show YAML: Mushroom Entity Card ```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
-Show YAML example (fixed icon in entity card) +Show YAML: Fixed Icon in Entity Card ```yaml type: entities @@ -118,7 +123,7 @@ entities: ### In Custom Button Card
-Show YAML example (fixed icon in button card) +Show YAML: Fixed Icon in Button Card ```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**
-Show YAML example (dynamic icon + dynamic color) +Show YAML: Dynamic Icon and Color ```yaml type: custom:button-card diff --git a/docs/user/docs/faq.md b/docs/user/docs/faq.md index 49a3be4..28b5c9d 100644 --- a/docs/user/docs/faq.md +++ b/docs/user/docs/faq.md @@ -118,6 +118,9 @@ If you see unexpected units, check your configuration in the integration options ### How do I run dishwasher during cheap period? +
+Show YAML: Dishwasher During Cheap Period + ```yaml automation: - alias: "Dishwasher during Best Price" @@ -134,12 +137,17 @@ automation: entity_id: switch.dishwasher ``` +
+ See [Automation Examples](automation-examples.md) for more recipes. ### Can I avoid peak prices automatically? Yes! Use Peak Price Period binary sensor: +
+Show YAML: Avoid Peak Prices Automatically + ```yaml automation: - alias: "Disable charging during peak prices" @@ -153,6 +161,8 @@ automation: entity_id: switch.ev_charger ``` +
+ --- 💡 **Still need help?** diff --git a/docs/user/docs/icon-colors.md b/docs/user/docs/icon-colors.md index b0bb51a..a3a76f3 100644 --- a/docs/user/docs/icon-colors.md +++ b/docs/user/docs/icon-colors.md @@ -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:**
-Show YAML comparison (complex conversion vs direct state logic) +Show YAML: Conversion vs Direct State Logic ```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** +
+Show YAML: Icon color only + ```yaml type: custom:button-card entity: sensor._current_price_level @@ -118,10 +121,12 @@ styles: ]]] ``` +
+ **Example: Icon AND state value with same color**
-Show YAML example (button-card icon + state text in same color) +Show YAML: Button Card Icon and State Text ```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:
-Show YAML: Entities card with card_mod +Show YAML: Entities Card with card-mod ```yaml type: entities @@ -177,7 +182,7 @@ The [Mushroom cards](https://github.com/piitaya/lovelace-mushroom) support card_ **Icon color only:**
-Show YAML example (Mushroom icon color only) +Show YAML: Mushroom Icon Color Only ```yaml type: custom:mushroom-entity-card @@ -196,7 +201,7 @@ card_mod: **Icon and state value:**
-Show YAML: Mushroom card — icon and state value with same color +Show YAML: Icon and state value ```yaml type: custom:mushroom-entity-card @@ -217,7 +222,7 @@ card_mod: Combine multiple sensors with dynamic colors:
-Show YAML: Glance card with card_mod for multiple sensors +Show YAML: Multi-Sensor Dynamic Colors ```yaml type: glance @@ -245,7 +250,7 @@ card_mod: Here's a complete example combining multiple sensors with dynamic colors:
-Show YAML: Complete dashboard with dynamic colors for all sensor types +Show YAML: Complete Dashboard Example ```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`):
-Show YAML example (theme-level color overrides) +Show YAML: Theme-Level Color Overrides ```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**
-Show YAML: Price level — 5-color JavaScript mapping +Show YAML: Custom colors for price level ```yaml type: custom:button-card @@ -401,7 +406,7 @@ styles: **Example: Custom colors for binary sensor**
-Show YAML: Binary sensor — on/off color + background highlight +Show YAML: Custom colors for binary sensor ```yaml type: custom:button-card @@ -428,7 +433,7 @@ styles: **Example: Custom colors for volatility**
-Show YAML: Volatility sensor — 4-level color mapping +Show YAML: Custom colors for volatility ```yaml type: custom:button-card @@ -453,7 +458,7 @@ styles: **Example: Custom colors for price rating**
-Show YAML: Price rating — 3-state color mapping +Show YAML: Custom colors for price rating ```yaml type: custom:button-card diff --git a/docs/user/docs/installation.md b/docs/user/docs/installation.md index 00cc47b..4ed754e 100644 --- a/docs/user/docs/installation.md +++ b/docs/user/docs/installation.md @@ -16,9 +16,14 @@ 2. Go to **Integrations** 3. Click the **⋮** menu (top right) → **Custom repositories** 4. Add the repository URL: +
+Show example: Repository URL + ``` https://github.com/jpawlowski/hass.tibber_prices ``` + +
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: +
+Show example: Folder Structure + ``` config/ └── custom_components/ @@ -52,6 +60,8 @@ If you prefer not to use HACS: ├── binary_sensor/ └── ... ``` + +
4. **Restart Home Assistant** 5. Continue with [Configuration](configuration.md) diff --git a/docs/user/docs/period-calculation.md b/docs/user/docs/period-calculation.md index 87fb88e..cc09f31 100644 --- a/docs/user/docs/period-calculation.md +++ b/docs/user/docs/period-calculation.md @@ -57,6 +57,9 @@ The integration sets different **initial defaults** because the features serve d ### Example Timeline +
+Show example: Timeline + ``` 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) ``` +
+ --- ## 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? +
+Show example: Search Range Flexibility + ``` Daily MIN: 20 ct/kWh Flexibility: 15% (default) → Search for times ≤ 23 ct/kWh (20 + 15%) ``` +
+ **Peak Price:** How much LESS than the daily maximum can a price be? +
+Show example: Peak Price Flexibility + ``` Daily MAX: 40 ct/kWh Flexibility: -15% (default) → Search for times ≥ 34 ct/kWh (40 - 15%) ``` +
+ **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: +
+Show example: Distance from Average + ``` 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%) ``` +
+ **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: +
+Show example: Minimum Period Duration + ``` Default: 60 minutes minimum @@ -157,6 +180,8 @@ Default: 60 minutes minimum 90-minute period → Kept ✓ ``` +
+ #### 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: +
+Show example: Automatic Price Spike Smoothing + ``` 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 ``` +
+ **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:** +
+Show example: Timeline + ``` 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) ``` +
+ --- ## Configuration Guide @@ -210,11 +245,16 @@ Peak Price (-15% flex = ≥29.75 ct): **Default:** 15% (Best Price), -15% (Peak Price) **Range:** 0-100% +
+Show YAML: Flexibility + ```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 ``` +
+ **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 +
+Show YAML: Minimum Period Length + ```yaml best_price_min_period_length: 60 peak_price_min_period_length: 30 ``` +
+ **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% +
+Show YAML: Distance from Average + ```yaml best_price_min_distance_from_avg: 5 peak_price_min_distance_from_avg: 5 ``` +
+ **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)
-Show YAML example (level filter) +Show YAML: Level Filter ```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
-Show YAML example (gap tolerance) +Show YAML: Gap Tolerance ```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:
-Show YAML example (relaxation defaults) +Show YAML: Relaxation Defaults ```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:
-Show YAML example (longer or shorter periods) +Show YAML: Longer or Shorter Periods ```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:
-Show YAML example (flexibility tuning) +Show YAML: Flexibility Tuning ```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):
-Show YAML example (distance from average) +Show YAML: Distance from Average ```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:
-Show YAML example (strict level filter) +Show YAML: Strict Level Filter ```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:** +
+Show YAML: Simple Best Price + ```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) ``` +
+ **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:**
-Show YAML automation example (run dishwasher in best price period) +Show YAML: Dishwasher in Best Price Period ```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.
-Show YAML example (flat day detection) +Show YAML: Flat Day Detection ```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:**
-Show YAML: Sensor attribute reference for best_price_period +Show YAML: Key attributes to check ```yaml # Entity: binary_sensor._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:
-Show YAML examples (configured target vs. found periods) +Show YAML: Configured Target vs Found Periods ```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):
-Show YAML example (flat_days_detected) +Show YAML: Flat Days Detected Attribute ```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:
-Show YAML example (relaxation_incomplete) +Show YAML: Relaxation Incomplete Attribute ```yaml min_periods_configured: 2 @@ -697,7 +752,7 @@ This is **mathematically correct behavior** caused by how electricity prices are **Example:**
-Show YAML: How identical prices can flip between best/peak across midnight +Show YAML: Midnight Price Classification Changes ```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:
-Show YAML example (daily volatility check) +Show YAML: Daily Volatility Check ```yaml # Check daily volatility (available in integration) @@ -748,7 +803,7 @@ sensor._tomorrow_s_price_volatility: 7.9% # Also low You can make your automations volatility-aware:
-Show YAML: 3 automation strategies for volatility-aware period control +Show YAML: Volatility-Aware Automation ```yaml # Option 1: Only act on high-volatility days @@ -805,7 +860,7 @@ automation: Each period sensor exposes day volatility and price statistics:
-Show YAML example (per-period volatility attributes) +Show YAML: Per-Period Volatility Attributes ```yaml binary_sensor._best_price_period: diff --git a/docs/user/docs/period-relaxation.md b/docs/user/docs/period-relaxation.md index 9b995a8..f2b47f6 100644 --- a/docs/user/docs/period-relaxation.md +++ b/docs/user/docs/period-relaxation.md @@ -14,12 +14,17 @@ Sometimes, strict filters find too few periods (or none). **Relaxation automatic ## How to Enable +
+Show YAML: Enable Relaxation + ```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) ``` +
+ **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**: +
+Show formula: Each day relaxes independently + ``` 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 ``` +
+ **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: +
+Show YAML: Diagnosing Relaxation Behavior + ```yaml # Entity: binary_sensor._best_price_period @@ -120,6 +133,8 @@ min_periods_configured: 2 # Your target periods_found_total: 3 # What was actually found ``` +
+ | Attribute | Meaning | |-----------|---------| | `relaxation_active: false` | Original filters were sufficient | diff --git a/docs/user/docs/scheduling-actions.md b/docs/user/docs/scheduling-actions.md index 239e121..c9fd2e4 100644 --- a/docs/user/docs/scheduling-actions.md +++ b/docs/user/docs/scheduling-actions.md @@ -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 | +
+Show YAML: Quick Scopes + ```yaml service: tibber_prices.find_cheapest_block data: @@ -60,12 +63,14 @@ data: search_scope: tomorrow ``` +
+ ### Explicit Start/End For full control, specify exact datetime values:
-Show YAML example (explicit start and end datetimes) +Show YAML: Explicit Start and End ```yaml service: tibber_prices.find_cheapest_block @@ -82,7 +87,7 @@ data: Schedule relative to today using time + day offset:
-Show YAML example (time-of-day with day offset) +Show YAML: Time of Day with Offset ```yaml service: tibber_prices.find_cheapest_block @@ -100,7 +105,7 @@ data: For relative searches:
-Show YAML example (relative minute offsets) +Show YAML: Relative Minute Offsets ```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`. +
+Show YAML: Price Level Filtering + ```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 ``` +
+ ### 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**:
-Show YAML example (power profile per 15-minute interval) +Show YAML: Power Profile ```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 +
+Show YAML: Find Cheapest Block + ```yaml service: tibber_prices.find_cheapest_block data: @@ -195,10 +208,12 @@ data: response_variable: result ``` +
+ ### Example with All Options
-Show YAML example (find_cheapest_block with all options) +Show YAML: Cheapest Block with All Options ```yaml service: tibber_prices.find_cheapest_block @@ -216,6 +231,9 @@ response_variable: result ### Response +
+Show JSON: Cheapest Block Example Response + ```json { "home_id": "abc-123", @@ -255,6 +273,8 @@ response_variable: result } ``` +
+ **Key response fields:** | Field | Description | @@ -269,7 +289,7 @@ response_variable: result ### Use in Automations
-Show YAML automation example (start dishwasher at cheapest time) +Show YAML: Dishwasher Automation ```yaml automation: @@ -310,6 +330,9 @@ Finds the cheapest N minutes of intervals within a search range. Intervals **do ### Basic Example +
+Show YAML: Find Cheapest Hours + ```yaml service: tibber_prices.find_cheapest_hours data: @@ -318,10 +341,15 @@ data: response_variable: result ``` +
+ ### 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: +
+Show YAML: With Minimum Segment Duration + ```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 ``` +
+ ### Response +
+Show JSON: Cheapest Hours Example Response + ```json { "home_id": "abc-123", @@ -389,6 +422,8 @@ response_variable: result } ``` +
+ **Key response fields:** | Field | Description | @@ -416,6 +451,9 @@ Schedules **multiple appliances** within the same search range, ensuring they do ### Basic Example +
+Show YAML: Find Cheapest Schedule + ```yaml service: tibber_prices.find_cheapest_schedule data: @@ -428,10 +466,12 @@ data: response_variable: result ``` +
+ ### With Gap and Power Profiles
-Show YAML example (multi-appliance schedule with gaps and power profiles) +Show YAML: With Gap and Power Profiles ```yaml service: tibber_prices.find_cheapest_schedule @@ -457,6 +497,9 @@ response_variable: result ### Response +
+Show JSON: Cheapest Schedule Example Response + ```json { "home_id": "abc-123", @@ -514,6 +557,8 @@ response_variable: result } ``` +
+ **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. +
+Show YAML: Find Most Expensive Block + ```yaml service: tibber_prices.find_most_expensive_block data: @@ -556,6 +604,8 @@ data: response_variable: peak ``` +
+ **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. +
+Show YAML: Find Most Expensive Hours + ```yaml service: tibber_prices.find_most_expensive_hours data: @@ -579,6 +632,8 @@ data: response_variable: peak ``` +
+ **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:
-Show YAML automation example (overnight appliance scheduling) +Show YAML: Overnight Appliance Scheduling ```yaml automation: @@ -630,7 +685,7 @@ automation: ### EV Charging During Cheapest 4 Hours
-Show YAML automation example (EV charging in cheapest 4 hours) +Show YAML: EV Charging in Cheapest 4 Hours ```yaml automation: @@ -668,7 +723,7 @@ automation: ### Peak Price Warning
-Show YAML automation example (peak price warning) +Show YAML: Peak Price Warning ```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:
-Show YAML example (comparison details enabled) +Show YAML: Comparison Details ```yaml service: tibber_prices.find_cheapest_block diff --git a/docs/user/docs/sensors-average.md b/docs/user/docs/sensors-average.md index f5fadc0..b04daca 100644 --- a/docs/user/docs/sensors-average.md +++ b/docs/user/docs/sensors-average.md @@ -27,6 +27,9 @@ All average sensors support **two different calculation methods** for the state **Why two values matter:** +
+Show YAML: Why two values matter + ```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) ``` +
+ 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: +
+Show YAML: Mean and Median in Automations + ```yaml # Example: Get both values regardless of display setting sensor: @@ -75,6 +83,8 @@ sensor: {% endif %} ``` +
+ ## Practical Examples **Example 1: Smart dishwasher control** @@ -82,7 +92,7 @@ sensor: Run dishwasher only when price is significantly below the daily typical level:
-Show YAML: Automation — start dishwasher when cheap +Show YAML: Practical Examples ```yaml automation: @@ -110,7 +120,7 @@ automation: Use mean for actual cost calculations:
-Show YAML: Automation — cost-aware heating control +Show YAML: Mean for Cost Calculations ```yaml automation: @@ -137,7 +147,7 @@ automation: Use trailing average to understand recent price trends:
-Show YAML: Automation — EV charging based on rolling average +Show YAML: Practical Examples ```yaml automation: diff --git a/docs/user/docs/sensors-energy-tax.md b/docs/user/docs/sensors-energy-tax.md index 8e2c842..b9d633a 100644 --- a/docs/user/docs/sensors-energy-tax.md +++ b/docs/user/docs/sensors-energy-tax.md @@ -6,10 +6,15 @@ Most price sensors include **energy price** and **tax** attributes that break down the total price into its components: +
+Show formula + ``` total = energy_price + tax ``` +
+ 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.
-Show YAML: Automation — solar export or consume decision +Show YAML: Solar Feed-In and Net Metering ```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:
-Show YAML: Template sensor — electricity tax share percentage +Show YAML: Price Composition Analysis ```yaml # Template sensor showing tax share @@ -89,6 +94,9 @@ template: Show users how today's average price splits into energy vs. tax: +
+Show YAML: Daily Cost Breakdown + ```yaml # Mushroom chips card showing the split type: custom:mushroom-chips-card @@ -103,6 +111,8 @@ chips: 🏛️ {{ state_attr('sensor._price_today', 'tax_mean') | round(1) }} ct ``` +
+ ## 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. diff --git a/docs/user/docs/sensors-overview.md b/docs/user/docs/sensors-overview.md index bbbc268..0e020c3 100644 --- a/docs/user/docs/sensors-overview.md +++ b/docs/user/docs/sensors-overview.md @@ -156,6 +156,9 @@ See the `tibber_prices.get_chartdata` action documentation for a complete list o **Example Usage:** +
+Show YAML: Example Usage + ```yaml # ApexCharts card consuming the sensor type: custom:apexcharts-card @@ -165,10 +168,15 @@ series: return entity.attributes.data; ``` +
+ **Migration Path:** If you're currently using this sensor, consider migrating to the action: +
+Show YAML: Chart Data Export + ```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 ``` + +
diff --git a/docs/user/docs/sensors-ratings-levels.md b/docs/user/docs/sensors-ratings-levels.md index d4fa34c..af28e96 100644 --- a/docs/user/docs/sensors-ratings-levels.md +++ b/docs/user/docs/sensors-ratings-levels.md @@ -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: +
+Show formula: How Ratings Work + ``` difference = ((current_price - trailing_avg) / abs(trailing_avg)) × 100% ``` +
+ 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): +
+Show YAML: Usage in Automations + ```yaml # ✅ Correct — language-independent condition: @@ -102,6 +110,8 @@ condition: state: "Low" # "Niedrig" in German, "Lav" in Norwegian... ``` +
+ ### Configuration Rating thresholds can be adjusted in the options flow: diff --git a/docs/user/docs/sensors-timing.md b/docs/user/docs/sensors-timing.md index 98be0e2..6d27a91 100644 --- a/docs/user/docs/sensors-timing.md +++ b/docs/user/docs/sensors-timing.md @@ -39,6 +39,9 @@ For each period type (Best Price and Peak Price): ### Show Countdown to Next Cheap Window +
+Show YAML: Countdown to Next Cheap Window + ```yaml type: custom:mushroom-entity-card entity: sensor._best_price_next_in_minutes @@ -46,10 +49,12 @@ name: Next Cheap Window icon: mdi:clock-fast ``` +
+ ### Display Period Progress Bar
-Show YAML: Bar card for period progress +Show YAML: Display Period Progress Bar ```yaml type: custom:bar-card @@ -74,7 +79,7 @@ severity: ### Notify When Period Is Almost Over
-Show YAML: Automation — notify when best price period is ending +Show YAML: Period Ending Notification ```yaml automation: diff --git a/docs/user/docs/sensors-trends.md b/docs/user/docs/sensors-trends.md index 2909c8f..6e8879f 100644 --- a/docs/user/docs/sensors-trends.md +++ b/docs/user/docs/sensors-trends.md @@ -192,6 +192,9 @@ A **countdown timer** companion to the Next Price Trend Change sensor above. Ins **Example automation:** +
+Show YAML: Example automation + ```yaml trigger: - platform: numeric_state @@ -203,6 +206,8 @@ action: message: "Price trend is about to change direction!" ``` +
+ **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: +
+Show YAML: Basic Automation Pattern + ```yaml # Example: Start dishwasher when prices are favorable trigger: @@ -250,6 +258,8 @@ action: entity_id: switch.dishwasher ``` +
+ ### Combining Multiple Windows When short-term and long-term trends disagree, you get richer insight: diff --git a/docs/user/docs/sensors-volatility.md b/docs/user/docs/sensors-volatility.md index d1b9ee8..b18c723 100644 --- a/docs/user/docs/sensors-volatility.md +++ b/docs/user/docs/sensors-volatility.md @@ -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. +
+Show YAML: Good Example (Robust Automation) + ```yaml automation: - alias: "Enable battery optimization only on volatile days" @@ -73,6 +76,8 @@ automation: entity_id: input_boolean.battery_optimization_enabled ``` +
+ --- ### 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. +
+Show YAML: Bad Example (Brittle Automation) + ```yaml automation: - alias: "Brittle - Enable battery optimization" @@ -99,4 +107,6 @@ automation: entity_id: input_boolean.battery_optimization_enabled ``` +
+ By following the "Good Example", your automations become simpler, more readable, and much easier to maintain. diff --git a/docs/user/docs/troubleshooting.md b/docs/user/docs/troubleshooting.md index c8e016e..5cc609f 100644 --- a/docs/user/docs/troubleshooting.md +++ b/docs/user/docs/troubleshooting.md @@ -73,6 +73,9 @@ When reporting issues, debug logs help identify the problem quickly. Add this to your `configuration.yaml`: +
+Show YAML: configuration.yaml Logging + ```yaml logger: default: warning @@ -80,6 +83,8 @@ logger: custom_components.tibber_prices: debug ``` +
+ 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:
-Show YAML example (targeted subsystem logging) +Show YAML: Targeted Subsystem Logging ```yaml logger: