A small tweak to the Predbat Table Card has enabled a really cool new use-case – MINI Predbat table cards!
Github user @stiplady made a request to add a limit to the number of rows the plan returns, for "quick look" style functionality. A pretty easy change, but has unlocked some very cool functionality.
Predbat mini card on a home assistant dashboard
By limiting the number of rows, users can now combine this functionality with custom columns and font size to create a mini Predbat table card on bigger dashboards.
Previous to this, while you could limit the columns, the plan was usually 24 hours long, so at least 48 rows of data – which was not great for dashboards with other cards in place.
Close up of the Predbat Table Card MINI
As you can see in the images above, placing the table card nicely in a dashboard is now super easy!
Here’s the YAML you can use to get started – obviously feel free to customise the YAML to meet your needs according to the spec.
Tracking daily weather extremes in Home Assistant can be a really useful addition to your dashboard, especially if you’re keen to understand trends over time or highlight key information visually.
In my case, I wanted a lightweight, efficient way to display the maximum temperature, minimum temperature, and maximum wind speed recorded during the day. Not only does this create a simple historical snapshot, but it also enables me to power Mushroom Template Cards with rich attribute data, without needing to rely on external integrations or long-term statistics.
The Template Sensor
Here’s the YAML I used to create a template sensor that records today’s key weather stats. This sensor uses a combination of state and time-based triggers to reset at midnight and accumulate data throughout the day.
- trigger:
- platform: state
entity_id:
- sensor.tempest_temperature
- sensor.tempest_wind_speed
- platform: time
at: "00:00:00"
sensor:
- name: 'Today Weather Statistics'
unique_id: today_weather_statistics
state: "OK"
attributes:
max_temp: >
{% set t_new = states('sensor.tempest_temperature') | float(-99) %}
{% set prev = this.attributes.max_temp | float(-99) %}
{{ [t_new, prev] | max if trigger.platform != 'time' else t_new }}
min_temp: >
{% set t_new = states('sensor.tempest_temperature') | float(99) %}
{% set prev = this.attributes.min_temp | float(99) %}
{{ [t_new, prev] | min if trigger.platform != 'time' else t_new }}
max_wind: >
{% set w_new = states('sensor.tempest_wind_speed') | float(-1) %}
{% set prev = this.attributes.max_wind | float(-1) %}
{{ [w_new, prev] | max if trigger.platform != 'time' else w_new }}
How it works
State triggers respond to changes in sensor.tempest_temperature and sensor.tempest_wind_speed. Every time they update, the template checks if the new value exceeds (or undercuts) the previous attribute value and stores the result.
Midnight reset is achieved via a time-based trigger at 00:00:00. At this point, the values reset to the current readings (effectively seeding the day).
The state is set to "OK" as a placeholder—it’s not used for charting or display, but helps avoid null states.
Home Assistant issues with adding new attributes
I found (randomly it seems not predictably) that some of the new attributes would not be created on their first load, once I restarted Home Assistant. It was very frustrating to debug, the logic is to set a variable from a entity state, or otherwise set a float – but something is failing. If you too are finding that the attribute isnt appearing, instead – establish the attribute more simply with a default value. Restart HA and confirm the attribute now shows up. E.g.
max_wind: >
{{ float(0) }}
This creates the new max_wind attribute with a default value of 0.0. Now update your YAML per the above with the logic to capture the maximum wind speed, this time it should update without issue.
Using This Sensor in Mushroom Cards
Now that the max and min values are stored in the attributes, you can easily access them in mushroom-template-card components. Here’s an example that shows the max temperature for today:
Predbat is brilliant at building smart charging and discharging plans for my home battery system, based on real-time energy costs, predicted house load, and solar forecasts. It uses Solcast data to predict generation and works out the best times to import, export, or hold energy.
But while Solcast takes weather into account when generating its solar forecast, I often found myself wondering why a particular slot was being scheduled a certain way. Was it cloudy? Raining? Very hot? All of these could affect either solar production or battery efficiency.
That’s when I decided to bring weather information directly into the Predbat Table Card.
Why Add Weather to the Table?
Although Predbat itself does not use the weather entity directly, it’s still useful to overlay forecast conditions with the battery plan. This extra context helps me better understand why certain slots are heavy on import or export, especially when the solar forecast looks optimistic but the weather conditions are less than ideal.
By seeing temperature, cloud cover, or rain in each 30-minute slot, I can cross-reference the charging plan with real-world weather, and make sense of some edge-case decisions.
How the Integration Works
The Predbat Table Card supports optional weather and temperature columns through two features I added:
weather-column: shows a weather icon for the slot
temp-column: shows the predicted temperature
rain-column: shows the predicted chance of rain
To enable them, you need a valid forecast-capable weather entity in Home Assistant and to define it using weather_entity.
You can of course rearrange or add more columns like export-column, load-column, or soc-column etc as needed.
Notes on Forecast Compatibility
This feature only works with forecast-style weather entities that follow the Home Assistant spec. Tested working examples include:
weather.met_home (from Met.no)
weather.weatherflow_forecast (from the WeatherFlow integration)
weather.met_office_yourlocation (from the Met Office weather integration)
If the weather forecast does not cover the full duration of the Predbat plan (e.g. forecast ends before the plan does), then no weather icon or temperature will show for those slots.
Colour-Coding and Hover Details
To quickly spot critical conditions, the table applies colour coding:
Red: temperature over 25°C – which could reduce solar panel efficiency
Blue: temperature below 0°C – which could reduce battery efficiency
Each icon also supports mouse-over tooltips, where you can view the detailed weather condition and temperature value.
If you want to try this yourself, grab the latest version of Predbat Table Card and follow the weather column documentation.
This guide walks you through how I created a clean, monthly temperature overview card in Home Assistant, showing maximum, minimum, and average temperatures across the year – with a live annotation for the current reading.
The chart provides a fantastic visual snapshot of temperature trends throughout the year and uses the excellent apexcharts-card combined with config-template-card for dynamic annotations.
Why I Built This
I wanted a quick way to compare month-to-month temperatures for 2025 – not just the highs and lows, but also how the average temperatures trend over time. And with the real-time temperature annotated on the chart, it’s easy to see how the current conditions stack up against the year so far.
A temperature sensor that reports regularly (e.g., sensor.tempest_temperature in my case)
How Monthly Max, Min, and Average Temperatures Work
The magic behind this chart lies in the use of Home Assistant’s built-in long-term statistics capability, which powers the statistics: feature of apexcharts-card.
Each series uses the following:
type: max and type: min with period: month to extract monthly maximum and minimum temperatures respectively
type: mean along with group_by.func: avg to generate a monthly average line (in white)
This means you’re not visualising raw sensor data points, but summarised monthly metrics – ideal for year-on-year comparisons or spotting unusual weather patterns.
You can control how values are aggregated using align: start or align: end, which defines where in the month each value is anchored on the timeline.
How the Live Annotation Works
This chart includes a live annotation showing the current temperature as a small dot with a label.
This is done using the annotations: section of ApexCharts, made dynamic by wrapping the entire card in a config-template-card.
Here’s what happens:
We define datenow using JavaScript to get the timestamp for the first day of the current month
We read the current value from the sensor (sensor.tempest_temperature) using states[...]
We format that value to one decimal place and append the unit (°C)
These variables (${datenow}, ${temp}, ${tempString}) are injected into the chart’s annotations dynamically
Without config-template-card, you couldn’t do this interpolation – it’s what allows us to reference JavaScript and Home Assistant state directly within the card definition.
Customising the X-Axis Labels
A small detail, but one that makes a big visual difference: the X-axis month labels are rotated and styled for clarity.
Uses short month format (e.g. Jan, Feb, Mar) for a cleaner look
Applies smaller font size to avoid clutter
This is particularly useful when plotting an entire year, where 12 data points can otherwise get cramped.
YAML Configuration
Below is the full YAML you can drop into your dashboard. I used sensor.tempest_temperature as the data source, but you can replace it with any temperature sensor you have.
This kind of chart makes your Home Assistant dashboard much more informative. With a little templating and the power of ApexCharts, you can surface meaningful trends without needing to dive into graphs or statistics manually.
The addition of dynamic annotations, paired with Home Assistant’s native statistics engine, creates a beautiful and functional visual that updates automatically.
As part of my growing Home Assistant dashboard, I’ve built a custom section to track the mileage of my electric vehicle (EV), a Tesla Model Y. It helps me visualise how I’m progressing against my lease’s mileage allowance – not just the total driven, but also how I’m pacing day to day.
This dashboard has become one of the most valuable tools in my setup, especially with a leased EV where tracking your usage is critical to avoiding end-of-term penalties.
Data Source: Tessie Integration
I’m using the excellent Tessie integration to pull live data from my Tesla. It provides an entity for the odometer (sensor.none_odometer in my case), which powers all the mileage tracking. none here is the car’s name – I hadn’t named it when I installed the integration, and now its stuck there in the entity names.
Lease Parameters
Start date: 10 February 2024
End date: 9 February 2027
Total allowed: 45,000 miles (15,000 miles per year)
What I Show on the Dashboard
My Tesla mileage dashboard includes:
Odometer: current total mileage (live from Tessie)
Daily Avg: my average daily mileage since delivery
Days Owned: how many days since I took delivery
Target Daily Avg: how many miles I can drive per day from today to stay within my lease cap
ApexCharts Graph: daily mileage (bars) vs. target daily average (dotted line)
This gives me a clear visual indication of whether I’m tracking well or over-driving. The Target Daily Avg is based on how many miles I have used so far, and calculating the number of days remaining in the lease, so dividing mileage remaining / days left.
ApexCharts Graph
I use the apexcharts-card custom card to plot two data series:
Daily mileage from a helper or automation that tracks daily odometer deltas
Target average from a template sensor (see below)
The bar chart gives a good at-a-glance view, with the dotted line acting as a benchmark to compare against.
Template Sensors
These sensors do the logic for tracking averages.
1. Daily Average Since Delivery
- sensor:
- name: "Average Tesla Mileage"
unique_id: average_tesla_mileage
state_class: "total"
device_class: "distance"
unit_of_measurement: "mi"
state: >
{% set specific_date = "2024-02-10" %}
{% set current_date = now().date() %}
{% set specific_date_obj = as_timestamp(specific_date) %}
{% set current_date_obj = as_timestamp(current_date) %}
{% set days_since_specific_date = ((current_date_obj - specific_date_obj) / 86400) | round(0, 'ceil') %}
{% set mileage = states('sensor.none_odometer') | int %}
{{ (mileage / days_since_specific_date) }}
icon: mdi:car
2. Target Daily Allowance Until Lease Ends
- sensor:
- name: "Average Tesla Mileage Remaining"
unique_id: average_tesla_mileage_remaining
state_class: "total"
device_class: "distance"
unit_of_measurement: "mi"
state: >
{% set specific_date = "2027-02-09" %}
{% set current_date = now().date() %}
{% set specific_date_obj = as_timestamp(specific_date) %}
{% set current_date_obj = as_timestamp(current_date) %}
{% set days_until_specific_date = ((specific_date_obj - current_date_obj) / 86400) | round(0, 'ceil') %}
{% set mileage = states('sensor.none_odometer') | int %}
{% set mileage_remaining = 45000 - mileage %}
{{ (mileage_remaining / days_until_specific_date) }}
icon: mdi:car
Markdown Card: Days Owned
This card is created using a simple markdown card that calculates the number of days since delivery:
- type: markdown
content: >-
#### Days Owned
{% set specific_date = "2024-02-10" %}
{% set current_date = now().date() %}
{% set specific_date_obj = as_timestamp(specific_date) %}
{% set current_date_obj = as_timestamp(current_date) %}
{% set days_since_specific_date = ((current_date_obj - specific_date_obj) / 86400) | round(0, 'ceil') %}
# {{ days_since_specific_date }}
It displays a nice clean numeric summary alongside the stats and graph.
Example Stats (as of today)
Odometer: 20,946 miles
Daily Avg: 36.75 miles
Target Avg: 45.73 miles
Days Owned: 570 days
So I’m under the target, which gives me some breathing room for long trips.
One of the most satisfying parts of running a home solar setup is being able to visualise how your system performs compared to the forecast, how its performing financially, and how might it perform in the next few days.
In this walkthrough I’ll explain at a high level how I’ve combined Solcast, Predbat & Octopus Energy integrations, with Bar Card, Apex Charts and more to get a really great looking dashboard. I’ll do a deeper dive on how its all possible soon.
Live PV Overview Using Bar Card
At the top of this section, I use a compact bar-card layout to display:
PV Power: current output from my solar inverter
PV Max: the peak output so far today
Income: estimated real-time value in £/hour based on grid interaction
These are not standard stat cards. They are styled bar-card elements, which give me better layout control and a consistent visual design.
The live PV data (including PV Power and Max) comes from my GivEnergy system, using the excellent GivTCP integration. GivTCP is a local MQTT-based integration that makes real-time data from both the GivEnergy battery and inverter available in Home Assistant. It is fast, reliable, and fully local, which is ideal for anyone running GivEnergy hardware.
The income figure is calculated using a template sensor that combines live import/export power with live tariff rates from the Octopus Energy integration. This gives a real-time estimate of financial benefit, whether from exported power or avoided import during peak rates. It updates every few seconds and is one of the most useful numbers on the dashboard. The bar card also dynamically changes colour, red for import, green for export.
Solar PV Forecast vs Actual Chart
This section is powered by ApexCharts Card and visualises:
Solcast Forecast (grey)
10% Confidence Range (dark grey)
Actual PV Today (orange)
PV from Yesterday (white dotted line)
It provides a live comparison throughout the day. I can instantly see whether production is tracking above or below expectations, and by how much.
The forecast data is retrieved via Predbat. Predbat serves as the bridge between Solcast and Home Assistant, pulling in high-resolution forecasts and exposing them as sensors. I then feed these directly into the chart.
5-Day Forecast Using Bar Card
Just below the chart, I show a 5-day solar forecast using bar-card again. This includes:
The Forecast for today and the next 4 days
Colour-coded bars based on expected total generation
Each bar represents total energy (kWh) for the day, with dynamic colouring applied using templates. Lower days show in red, wheras higher days in orange. I’ve configured these in such a way that it uses entities for max PV values (35 kWh in my case) as well as my "threshold" for minimum (around your average use). This enables the dynamic colour coding of the bars.
How to access and format forecast data from Predbat
Template examples for value display and colour thresholds
Complete YAML for the 5-day bar-card layout
Forecast vs Reality Delta
At the bottom of this section, I include a summary of:
Forecasted PV power for right now
Forecasted PV energy for right now
Percentage difference between the forecast and reality
For example, as of this image I am 38% up on the forecasted PV energy generation today. These numbers dynamically change as the hours go during the day, giving me a strong signal for how much better or worse reality is compared to the prediction.
If you’re looking to add real-time UK rainfall data to your Home Assistant setup, the Environment Agency (EA) offers a beta API that exposes official rain gauge readings from across England. This post explains how to access that data, find your nearest measurement station, and integrate it into Home Assistant using a REST sensor.
What Is the EA Rainfall API?
The EA’s Flood Monitoring API includes rainfall measurements from hundreds of monitoring stations across the UK. You can query specific stations to retrieve rainfall data from the past 24 hours.
Note:
This API is officially in beta, which means it’s not guaranteed to be available 24/7. The service occasionally times out or becomes unresponsive, so any sensors you create may intermittently return "unknown" or fail to update.
Step 1: Find Your Nearest Rainfall Station
To begin, you’ll need the station ID of the rainfall monitor closest to your location.
Use the search bar for your location / home / postcode.
In the results page, choose the Rainfall tab.
Click on a nearby station marker to bring up its detail page. It will look like this: https://check-for-flooding.service.gov.uk/rainfall-station/E1234
The ID at the end (E1234 in this example) is what you’ll use in your sensor configuration.
You can also test live readings using this format: https://environment.data.gov.uk/flood-monitoring/id/stations/E1234/readings?parameter=rainfall&today
Step 2: Add the REST Sensor in Home Assistant
Once you’ve chosen a suitable station ID, add the following to your Home Assistant configuration.yaml under sensor: (or a new YAML file if using rest: integration directly):
- platform: rest
name: Rainfall Today (EA)
unique_id: rainfall_today_ea
resource: https://environment.data.gov.uk/flood-monitoring/id/stations/YOUR_STATION_ID/readings?parameter=rainfall&today
method: GET
value_template: >
{% set readings = value_json["items"] | default([]) %}
{% if readings %}
{% set total = readings
| map(attribute='value')
| map('float')
| sum %}
{{ '%.2f' | format(total) }}
{% else %}
0.00
{% endif %}
unit_of_measurement: mm
device_class: precipitation
state_class: total
scan_interval: 900
Important: Replace YOUR_STATION_ID with your chosen ID (e.g., E1234).
Important: Restart Home Assistant to enable the new sensor.
Step 3: Display on a Dashboard
Now that the sensor is added, you can display the total rainfall for today using any standard card in Lovelace, using the entity sensor.rainfall_today_ea. You could also combine it with daily or weekly trend charts for deeper insight.
Troubleshooting Tips
If the sensor value shows as "unknown" or doesn’t update, it’s likely due to temporary API downtime.
Double-check that the station you’ve chosen reports rainfall and not only water level or flow.
You can test the API manually in your browser to confirm it’s returning valid JSON.
Using the EA’s beta rainfall API is a great way to get highly localised, official rainfall data into your smart home dashboard. While it’s not perfect due to its beta status, it adds valuable environmental awareness to any Home Assistant setup.
If you’ve found a reliable station near you, this integration can help you:
Track rainfall for automation purposes
Cross-check rainfall against your garden’s needs
Build weather prediction models using historical patterns
I am also using it to compare to the rainfall totals I get through my Weatherflow Tempest device. It uses haptics to measure rainfall which is not as exact as I hoped. Comparing its results with the official "close by" EA measurement station helped me understand how accurate it really was… in short – its close enough!
I’ve been playing around with ways to better visualise upcoming rainfall. The main weather integrations in Home Assistant often focus on current conditions or broad daily forecasts, but I wanted something more granular.
Specifically, I wanted to see hourly rainfall predictions for the next 24 hours in a compact, clean, and useful format. Ideal for deciding if I need to bring the washing in or delay watering the garden. Here’s how I set it up.
Step 1: Create the Input Text Helper (YAML)
First, we need a place to store the hourly rainfall values. I created a simple input_text helper in configuration.yaml. This holds a JSON string that we can read later in the chart.
Note: The default limit is 255 characters, which fits roughly 24 hourly values. If you want to expand this for a longer range, you can increase the max value — for example, set max: 1024 for future-proofing.
Once added, restart Home Assistant to activate the helper.
Step 2: Pull the Hourly Forecast Data
Next, I created an automation that fetches the next 24 hours of hourly weather data from my forecast provider. It extracts just the precipitation values and stores them as a JSON array in the helper.
This gives you a neat string like [0.0, 0.2, 0.4, 0.0, ...] representing each hour’s predicted rainfall in millimetres.
Step 3: Display the Chart with ApexCharts
I wanted the final chart to be small, clean, and focused. Using apexcharts-card, I built a column chart that only shows hours where rain is expected — zeroes are filtered out to reduce clutter.
This chart gives a very quick heads-up on upcoming rain intensity. Because it only shows hours with rain (zero values are filtered out), it’s minimal and takes up little space. It works well on both mobile and wall-mounted dashboards.
More importantly, it pulls real hourly forecast data rather than estimates or summaries. You get the precise precipitation expected in millimetres for each hour. Handy if you’re deciding whether to pause a garden irrigation schedule or go out for a walk.
As part of refining my Home Assistant dashboards, I wanted a lightweight, dynamic card to show current wind conditions from my Weatherflow Tempest.
There are plenty of ways to visualise weather data, but most are either too large, too basic, or just not very readable. I wanted something compact, clean, and glanceable. A quick read, no fluff, and no wasted screen space.
This is where the Mushroom Template Card really shines. It’s incredibly flexible, looks modern, and lets you pack a surprising amount of intelligence into a small card.
What I Wanted
The goal was simple:
Show the wind speed in mph.
Display a directional icon based on wind direction.
Change the icon colour if wind speed is high.
Keep it compact, no charts, no clutter.
All powered by the Tempest sensors I already had in place.
The secondary line uses Jinja2 to pull the wind speed and round it to two decimal places. I like that this keeps it readable without unnecessary decimals.
Directional Icon Logic
The icon is where it gets a bit more clever. If the wind sensor is reporting a valid direction and the wind isn’t zero, we map it to a directional arrow.
icon: >-
{% set raw_dir = states('sensor.tempest_wind_direction') %}
{% set raw_speed = states('sensor.tempest_wind_speed') %}
{% if raw_dir in ['unknown', 'unavailable', 'none', ''] or raw_speed | float == 0 %}
mdi:compass
{% else %}
{% set d_from = ((raw_dir | float) % 360 + 360) % 360 %}
{% set d_to = (d_from + 180) % 360 %}
{% set idx = (((d_to + 22.5) % 360) // 45) | int %}
{% set icons = [
'mdi:arrow-up-circle-outline',
'mdi:arrow-top-right-thin-circle-outline',
'mdi:arrow-right-circle-outline',
'mdi:arrow-bottom-right-thin-circle-outline',
'mdi:arrow-down-circle-outline',
'mdi:arrow-bottom-left-thin-circle-outline',
'mdi:arrow-left-circle-outline',
'mdi:arrow-top-left-thin-circle-outline'
] %}
{{ icons[idx] }}
{% endif %}
Let me break that down:
If the direction or speed is unknown or zero, we show a generic compass icon.
Otherwise, we:
Calculate the direction the wind is going to (not coming from).
Convert it into an index between 0–7.
Map that to one of eight arrow icons using Material Design Icons (MDI).
This gives a visual indication of direction without needing to read degrees.
Icon Colour Based on Wind Speed
Just for a bit of extra UX, I wanted the icon to go red if the wind is high (10+ mph). Otherwise, it uses the theme’s default colour.
icon_color: >-
{% set raw_speed = states('sensor.tempest_wind_speed') | float %}
{% if raw_speed >= 10 %}
red
{% else %}
"var(text-primary-color)"
{% endif %}
This makes it easy to spot when it’s particularly gusty outside without taking up extra space or alerting.
Final Touch
Finally, I added a tap action to bring up the more-info panel when you tap the card.
tap_action:
action: more-info
That way, if I want to see the raw data or history graph, it’s just a tap away.
Result
What I ended up with is a sleek little wind tile that blends into my dashboard, gives me useful info at a glance, and doesn’t crowd the interface.
It’s one of those tiny details that makes the whole dashboard feel more alive.
