Expected environment setup
uv sync --reinstall --extra test
Observed in .github/workflows/code-quality.yml:L44
Native source materials / 48 indexed
This index links to repository-authored course records, examples, tutorials, and technical reading. The separate browser lab is an educational surrogate; its sliders and checkpoints do not execute this repository's native engine.
Current audited native source: 93c5579a3bb48ff7351ae8f8b46534df23feccab
Browser-lab provenance from the reconciled package: package source revision da01a0205289823ad4679c28c2f301bcf7e6da71. This is separate from the current native source revision above.
These exact one-line commands were observed in the audited repository workflow records and link to their source location. Expected setup, tool licensing, data, and environment vary by repository; the dashboard does not execute these commands or promise a completion time.
Expected environment setup
uv sync --reinstall --extra test
Observed in .github/workflows/code-quality.yml:L44
Source-defined validation command
uv run python -m unittest discover -s .github/tests -v
Observed in .github/workflows/code-quality.yml:L50
Source-defined example command
docker run --rm --entrypoint '/bin/cat' ${{ steps.build.outputs.imageid }} uv.lock >> ./OSV/${{ matrix.platform.target_arch }}.lock
Observed in .github/workflows/docker-build-test.yaml:L61
Source-defined example command
docker run --rm --entrypoint '/bin/cat' ${{ steps.cache.outputs.imageid }} uv.lock >> ./OSV/${{ matrix.platform.target_arch }}.lock
Observed in .github/workflows/publish_docker-test.yaml:L68
Expected environment setup
python3 -m pip install --break-system-packages .[test]
Observed in .github/workflows/updatePVLibDB.yaml:L23
48 materials
theme: gaia # default, gaia, uncover,
docs/EMHASS_presentation.md
Companion to docs/develop.md (humans, general) and AGENTS.md (vendor-neutral rules for AI agents). Read develop.md first if new to EMHASS.
docs/develop_ai_coders.md
docs/emhass.md
EMHASS can learn two of the battery constants the optimizer otherwise takes on trust, the usable capacity and the round-trip efficiency, from your own Home Assistant history. It follows the same learn-from-history pattern as the adjusted PV forecast (set_use_adjusted_pv).
docs/battery_identification.md
When contributing to this repository, please first discuss the change you wish to make via issue,
docs/develop.md
Let EMHASS decide when and how much to charge an EV, as one deferrable load in the whole-home
docs/cookbook/ev_evcc_executor.md
To automate EMHASS with Home Assistant, we will need to define some shell commands in the Home Assistant configuration.yaml file and some basic automations in the automations.yaml file.
docs/automations.md
html_theme.sidebar_secondary.remove: true
docs/index.md
In EMHASS we have 4 forecasts to deal with:
docs/passing_data.md
orphan: true
docs/cookbook/_template.md
EMHASS will need 4 forecasts to work properly:
docs/forecasts.md
By default, EMHASS uses the high-performance open-source solver HiGHS. It is bundled with the default Docker image and requires no configuration.
docs/advanced_solvers.md
docs/section_config.md
docs/section_reference.md
docs/section_getting_started.md
docs/section_core.md
In this section, we present the basics of the Linear Programming (LP) approach for a household Energy Management System (EMS).
docs/advanced_math_model.md
In this section, we will explain all parameters used by EMHASS.
docs/config.md
EMHASS supports defining a deferrable load as a thermal model.
docs/thermal_model.md
Make EMHASS shave your peak grid import (the kW demand / capacity charge many utilities bill on top of energy) in the same optimization that minimizes energy cost — no core changes, no second solver. You set one config key to your tariff's demand rate; EMHASS adds a peak-power term to the objective and spreads deferrable load to hold the single highest import point down. Optionally you f…
docs/cookbook/tariff_demand_charge.md
Users will pass parameters and secrets into EMHASS differently, based on what method your running emhass. (Add-on, Docker, Python)
docs/differences.md
EMHASS treats an EV charger as a windowed deferrable load: a fixed energy amount that must be delivered before some end time, with charging power up to the charger's rated nominal power. The optimizer then chooses when in the available window to charge.
docs/study_cases/ev.md
EMHASS (Energy Management for Home Assistant) is an optimization tool designed for residential households. The package uses a Linear Programming approach to optimize energy usage while considering factors such as electricity prices, power generation from solar panels, and energy storage from batteries. EMHASS provides a high degree of configurability, making it easy to integrate with Hom…
docs/intro.md
EMHASS is a Python module designed to optimize your home energy interfacing with Home Assistant.
README.md
EMHASS is the "brain" of your energy system. While Home Assistant sees what is happening now, EMHASS looks at the future (forecasts) to decide what should happen to save you the most money.
docs/main_core_concepts.md
Drive EMHASS naive-MPC optimization from a Node-RED flow on any cadence, recomputing runtime parameters per call. Transport-agnostic on the EMHASS side; you pick any sensor source (Modbus, MQTT, HA bridge, manufacturer API) for the inputs. After completing this recipe, your Node-RED instance posts a fresh MPC request every tick and your downstream consumers (smart-home controllers, dashb…
docs/cookbook/transport_nodered_mpc_orchestration.md
Starting with v0.4.0, a new forecast framework is proposed within EMHASS. It provides a more efficient way to forecast the power load consumption. It is based on the skforecast module that uses scikit-learn regression models considering auto-regression lags as features. The hyperparameter optimization is proposed using Bayesian optimization from the optuna module.
docs/mlforecaster.md
Starting with v0.9.0, a new framework is proposed within EMHASS. It provides a machine learning module to predict values from a CSV file using different regression models.
docs/mlregressor.md
EMHASS supports modeling thermal batteries for heat pump systems with thermal mass storage. This is useful when you have a heat pump with underfloor heating or a radiator system with a thermal storage medium like a concrete slab or water-based thermal mass.
docs/thermal_battery.md
docs/section_thermal.md
This scenario adds a 5 kWh battery to the previous tutorial. The optimizer now schedules battery charge/discharge alongside the deferrable loads.
docs/study_cases/basic_pv_battery.md
This scenario adds a 5 kWp PV installation to the previous tutorial. No battery yet. We run two optimization modes against this system: a 7-day historical perfect optimization (to see what the optimal schedule would have been with hindsight) and a day-ahead optimization (the real production case).
docs/study_cases/basic_pv.md
This is the simplest scenario: no PV installation, two deferrable loads (for example, a water heater and a pool pump). EMHASS schedules when to run each load to minimize cost against the day-ahead electricity price.
docs/study_cases/basic_no_pv.md
A DHW tank is a thermal store, but unlike an underfloor slab it has natural usage spikes (morning shower, evening dishes) that anchor when the water has to be hot, not a continuous comfort range. The naive approach is a fixed daily profile (e.g. "always at least 55 °C between 09:00 and 16:00"), which forces the heat pump to run at a fixed time of day regardless of price.
docs/study_cases/dhw_walkthrough.md
orphan: true
docs/study_case.md
This page collects insights that come from running EMHASS in production over months: what matters, what doesn't, and what surprises new users. Treat it as the why behind several recommendations scattered across the tutorials and how-to guides.
docs/study_cases/good_practices.md
This page walks through a complete real-house scenario: PV + electrochemical battery + heat-pump-driven thermal battery + (optionally) a regular EV charger. It is an orchestration page. For the parameter reference of the thermal battery model itself, see Reference: thermal_battery.
docs/study_cases/heat_pump_walkthrough.md
For Home Assistant OS and HA Supervised users, A EMHASS app repository has been developed to allow the EMHASS Docker container to run as a Home Assistant app. The app is more user-friendly as the Home Assistant secrets (URL and API key) are automatically placed inside of the EMHASS container, and web server port (default 5000) is already opened.
docs/installation_methods.md
The study-case tutorials and how-to guides primarily show REST API calls (curl, rest_command, or the Add-on action button), because the EMHASS Add-on and standalone Docker are the recommended deployment targets and these expose REST.
docs/study_cases/legacy_cli.md
The package is meant to be highly configurable with an object-oriented modular approach and a main configuration file defined by the user.
docs/quick_start.md
If using the add-on or the Docker installation, it exposes a simple webserver on port 5000. You can access it directly using your browser. (E.g.: http://localhost:5000)
docs/usage_guide.md
End-to-end walkthroughs for common EMHASS configurations using real data.
docs/study_cases/index.md
This page documents the columns of the optimization-result DataFrame returned by
docs/plan_output_schema.md
publish-data (which is either run manually or automatically via continual_publish or Home Assistant automation), will push the optimization results to Home Assistant for each deferrable load defined in the configuration. For example, if you have defined two deferrable loads, then the command will publish sensor.p_deferrable0 and sensor.p_deferrable1 to Home Assistant. When the dayahead-o…
docs/publish_data.md
These are anonymized, abstract templates. They are not real users' systems. Each block is a starting point — the parameter values reflect typical hardware in the archetype, but you must verify against your own equipment. See Configuration for the full parameter reference.
docs/study_cases/reference_configs.md
The dayahead-optim action computes a single 24 h schedule once per day. For systems where forecasts and state change throughout the day (especially battery SOC, EV state, dynamic prices), you want Model Predictive Control: re-run the optimization on a rolling window every N minutes, using the latest measurements as the new initial state.
docs/study_cases/mpc.md
Feed live battery state of charge (SOC) back into EMHASS naive-MPC on every call so the optimizer plans against the real current state, not a stale assumption. Avoid the most common consumer bug: SOC unit mismatch (fraction vs percent). After this recipe, every MPC POST your orchestrator sends carries the current soc_init, validated and clamped to your configured bounds.
docs/cookbook/battery_aware_runtime_params.md
Short, standalone, copy-pasteable recipes for common EMHASS patterns. Each recipe follows a fixed template: Goal / Prerequisites / Config / Snippet / Caveats / Credits.
docs/cookbook/index.md