I’ve spent a long time building a highly advanced, local machine-learning model for Home Assistant that predicts your exact heating energy needs (in kWh). It learns your specific house’s thermal inertia, solar impact, and wind heat-loss over time.
It’s currently running flawlessly on my own setup (v1.1.0 is out on GitHub), but before I submit it as a default HACS repository, I have two requests for the community:
**1. Edge-case Testers wanted! ** My house is just one type of house. I need power-users with passive houses, heavy thermal mass (concrete), massive solar setups, or extreme weather conditions to run this. I want to see if the dynamic thermal inertia profile and the solar coefficients hold up in wildly different environments.
**2. Dashboard Wizards needed! ** I am a backend/math guy, not a frontend designer. The integration exposes a ton of extremely valuable data (hourly predicted kWh, efficiency tracking, thermodynamic states, and a new get_forecast service response). Currently, my suggested dashboard is just a raw Plotly graph and some Markdown. If there are any Lovelace or UI Blueprint wizards out there who want to build a beautiful dashboard or room-card using this data, I (and future users) would be eternally grateful!
Features:
Local ML correlation (Outdoor Temp, Wind, Solar → Heating kWh)
Fully offline (no cloud dependencies)
Adjustable Thermal Inertia (Fast/Normal/Slow)
Spike protection and Auxiliary heat (e.g., fireplace) suppoert
Please read the readme.md for full capability, or design.md for technical understanding of design choices.
Both, actually! The core is a temperature-correlation model that learns how much energy each heating unit needs per degree-day. On top of that it builds a daily kWh prediction from the weather forecast.
That prediction feeds two things:
Price optimization — knowing the expected load lets you shift as much as possible into cheap hours
PV self-consumption — the solar attenuation model estimates how much solar will cover during the day, so the prediction adjusts accordingly and you avoid over-buying at night
Would be great to compare notes — what approach are you taking for the learning part?
I started logging comsumtion data to prepare for variable energy tarif.
Then it tooks the energy supplyer neary to year to get smartmeter running.
So first I did after it was running is stupid querry the database for data that match the weather forecasts. Result wasnt that bad so far.
Then I started playing around with GitHub - Nixtla/neuralforecast: Scalable and user friendly neural forecasting algorithms. and combined it with an 3R2C Model and feed/train them with the historical data.
Im still in testing phase not sure whats better in the end.
Its currently not running 24h and not learning from its prediction errors I just play around with differend models.
In parallel I started using your integration.
In the End i want to use low price zone if not enough pv and pv only if enough and overheat is not too high.
I have a 2,3 m³ water puffer tank and an older on off ground water heat pump.
Not sure what would control that the best way considdering all needs at the moment.
That sounds like a really solid and methodical approach — logging first, then iterating. A lot of people skip straight to the fancy models without having the data foundation.
A few thoughts on where heating analytics like this works best:
Your setup is actually close to ideal conditions — a large buffer tank (2.3 m³ is generous), a ground water heat pump with stable COP, and a passive-ish building means the thermal system is slow and predictable. That’s exactly what these models need. The 3R2C model combined with NeuralForecast is a smart pairing — the physics-based model keeps the neural net honest when data is sparse.
You should consider some kind of template sensor or buffer telling heating analytics in kwh when you actually dispense the energy stored.
Where it gets tricky is if indoor temperature is being actively adjusted by occupant behaviour — opening windows, guests, cooking, etc. That kind of chaos breaks the prediction loop fast. If your household is fairly regular in behaviour, you’re in good shape.
On the on/off heat pump — this is actually a consideration worth keeping in mind. On/off compressors play less nicely with optimization than variable speed, because you’re forced into discrete operating windows. But with a 2.3 m³ buffer you have enough thermal storage to work around that — let the buffer absorb the coarse control.
The “learning from prediction errors” piece will be a big step when you get there — closing that loop is what takes it from a research project to something genuinely useful.
Unfortunately I have also some tricky conditions to deal with.
Im living in a Partially renovated old building.
Ground floor is ok isulated reacting slow.
The upper floor poor reacting fast specially on windy days.
Dimension of the radiators is good for still having low temperatures close to floor heating system.
COP is between 4,5 - 5,5.
Yes the idea of that combination was to take best of all worlds.
I have 3 buffer tanks with 4 temperature sensor on each.
I know their position and calculate the energy inside the buffer with that using cubic splines.
Currently I handle them as one big buffer with mean value at each high because they are connected according to the tichelman principle and the differences are not that big.
I use that for the calculation of the total energy and really available usable energy.
The deltas in changes in total energy is my energy meter I don’t have a real one but it produces reasonable values that way.
The Hea pump itself reports the energy it produces and if its running I calculate the energy quantities together to determine the consumption of the house.
There is a uncertainty but its not that big and will not influence the system in too bad way I hope.
Over 24h the difference between the heat pump report and what I measure as energy loss in the puffer is less than 5% most days.
If the water heating chimney is running, I stop calculation energy consumption as long as its running and start again after it cools down enough (exhaust sensor). That way I could theoretically calculate a part of the energy it pushed into the puffer by subtracting the generated heat by the heat pump.
You mention a point I didn’t consider that much until now I just used the mean temperature for each floor. So I should start to feed the temperature for each room into the model you suggest?
Open window is not a problem in my case I have a ventilation system with heat recovery.
Yes running the on off in the best operating window is a bit tricky. But I have a mixer after the buffers and the heat circuit of the whole house and all is working room controlled with the mean temperatures of colder floor. Rest is done by the individual room control.
I hope so the idea was to blend the predictions of the models and let the system find out in the feedback loop in addition to retrain what combination fits the best.
Your measurement setup is genuinely impressive – cubic splines on 12 sensors with Tichelmann balancing is a solid foundation, and <5% daily error without a real energy meter is better than many systems that have one.
On the room temperature question: I wouldn’t feed individual room temperatures into the model. The signal-to-noise ratio is poor and calibrating thermal characteristics per room is a rabbit hole. What I’d suggest instead is treating each physically distinct zone as a heating unit – a defined area with its own energy attribution and thermal behaviour.
In your case that split is already obvious from your description: ground floor (slow, well-insulated) and upper floor (fast, poorly insulated, wind-sensitive). These two zones behave differently enough that blending them into a single model forces it to fit a curve that doesn’t represent either one accurately.
That said, the per-unit learning loop should handle most of these concerns over time. As each heating unit accumulates data, the model adapts its coefficients to match the actual thermal behaviour of that specific area – including its inertia, wind sensitivity, and insulation characteristics – without you needing to specify them explicitly. The asymmetry between your floors will effectively be learned rather than hard-coded.
If you find the zones still diverge significantly after the learning period, one option worth considering is running two separate Heating Analytics integrations – one per floor. Each would then learn its own thermal time constant and model coefficients independently. This isn’t something that has been tested in a multi-instance setup yet, so it would be somewhat experimental, but architecturally there’s nothing preventing it.
Your chimney handling approach (stop/restart with exhaust sensor offset) is clever and should translate well into a per-zone energy ledger too.
The feedback loop and model blending you describe makes more sense with zone separation – the ensemble can weight each zone’s model differently as it learns.
I cant realy seperate the floors (or I have no Idea how) because the the heating circuit is not splitted between the floors.
All I think I can do is to work with that two mean temperatures and let the rest fix itself
If the physical plumbing isn’t split between floors, then a single global model is exactly the right approach – and it’s fully supported. Forcing a zone split in software when the actual water flow is shared usually just introduces noise. Working with a mean temperature and a global model is both valid and pragmatic.
The good news: since you already have reliable historical consumption data from your buffer tank calculations, you don’t need to wait weeks for the model to learn. You can have a fully trained global model and a 7-day hourly forecast running by tonight using the CSV import feature.
Fast-track approach:
Get historical weather – download hourly data for your exact location from Open-Meteo’s historical archive (free, no API key)
Merge your data – create a CSV pairing your hourly buffer tank energy consumption with the weather columns: outdoor temperature, wind speed, wind gust, and cloud coverage
Import – call the heating_analytics.import_from_csv service with a column_mapping matching your CSV headers. Set update_model: true to train the global model on import
Forecast – once imported, call heating_analytics.get_forecast (1–7 days ahead, hourly resolution)
On weather setup: for the most reliable forecasts, I’d recommend using my Open-Meteo integration as your primary weather entity – it unlocks hourly wind gust data, vertical solar calculations, and full 7-day hourly forecasts that most providers don’t offer.
One important caveat: a pure global model assumes the buffer tank accounts for all heating. Any unmeasured heat source – a bathroom panel heater, or your fireplace if it isn’t fully offset – will appear as unexplained consumption reduction and skew the thermodynamic baseline. Make sure your chimney/fireplace is handled via the auxiliary heating feature so those hours are correctly flagged and excluded from base model learning.
yes I saw that csv import feature but i would have to build a conversion first.
my heat counter ist ingreasing it just loggs the heat used in given time as single value. Need to grab and convert that all…
As weater source I use that integration:
Yes thats a valuable point with the chimney I considder it.
The weather-fusion-ai integration looks interesting, but since it’s protected by pyarmor I can’t inspect what data it actually exposes — horizon, resolution, which sources etc. are all opaque.
My open-meteo integration provides cloud cover (%) and a full 7-day hourly forecast, which the model uses directly for next-day predictions. Either way, the Weather Plan Today sensor exposes both primary_evaluation and secondary_evaluation attributes, so you’d be able to compare how well any weather source actually performs against real consumption — a concrete way to validate whether the AI blending adds value over a standard forecast.
I use it because at my House the temperature is often up much lower as the forecasted one.
Right now Open Meteo 7°C
Reality 2,4°C
Weater Fusion AI 5,2°C.
Hope it will get better with more training.
since few days I also use your integration together with your open-meteo integration.
We have a lot of sun the last days, but every value which has to do with solar is nearly zero:
The forecast at midday always looks like this with only very less solar impact. I think that it should be a lot more:
The likely cause is that your solar coefficients were learned against an older version of the solar factor model, which has since been corrected twice (v1.1.2 and v1.2.0). The coefficients learned then are no longer valid against the current physics-based model. Make sure you are running v1.2.1.
The cleanest fix is to re-run your original import — this will re-learn solar coefficients using the corrected model while also refreshing the base model from your historical data:
service: heating_analytics.import_from_csv
data:
file_path: /config/your_import_file.csv
update_model: true
column_mapping:
timestamp: ...
# (same mapping you used originally)
If you no longer have the CSV, the alternative is to manually remove solar_coefficients_per_unit and learning_buffer_solar_per_unit from .storage/heating_analytics.storage. Deactivate the integration first, backup the storage file and delete the offending solar factors. The model will then fall back to the defaults (0.35 kW/unit) and re-learn from live data over the coming sunny days.
Regarding the plots — these are in dashboard_heating.md (Lovelace YAML). Install Plotly Graph Card via HACS first, then import the dashboard YAML.
I realized I accidentally left the tools folder out of the repository. I’ve just updated it, so you should be able to find the dashboard_heating.md file there now. Sorry for the confusion!
I was wrong about re-running import_from_csv — that will not reset your solar coefficients. The import only trains the global base model and aux model; solar coefficients are exclusively learned during live operation. I apologize for the incorrect guidance.
The only way to reset solar learning is to manually edit the storage file:
Stop Home Assistant
Open .storage/heating_analytics.storage
Remove (or clear to {}) the two keys:
solar_coefficients_per_unit
learning_buffer_solar_per_unit
Save and restart Home Assistant
The system will fall back to the default solar coefficient (0.35 kW/unit) and re-learn from live data on the next sunny days.
I have a patch (v1.2.2) coming within the hour that will add a proper reset_solar_learning service so this can be done cleanly without touching the storage file directly.
Once you have updated the integration and restarted Home Assistant, you can safely wipe the old solar data without touching any hidden files.
Go to Developer Tools → Services and call the new service:
heating_analytics.reset_solar_learning
(Running it exactly like this, without specifying an entity, will flush the corrupted solar memory for ALL your units and set them back to the safe default).
For future reference: If you ever move furniture, add window blinds, or change the window coverage in just one specific room, you can use this service to reset the learning for that single unit only:
One last tip (Solar Correction): Before you let the system re-learn over the next few days, make sure your global solar slider (number.heating_analytics_solar_correction) is set correctly. This entity controls how much of the raw solar irradiance is allowed into the calculations:
100 = No blinds/screens, full solar gain through windows.
50 = Windows are typically partially covered during the day.
0 = Fully blocked, no solar impact.
If you don’t use blinds during the day, just leave it at 100.
Let the system run for a couple of sunny days now, and the midday forecasts should start showing a much more realistic solar impact! Let me know how it goes.
Sry for the confusion. I have updated the file location in the readme.md file and cleaned up in the tools folder.
I will in time post more ready made graphs here (with images in the readme.md)
You will find the dashboard and some plotly graphs in heating_analytics/tools at main · thuemah/heating_analytics · GitHub
I considder it.