Technical notes
DwellMetry
DwellMetry is a live and continuing application. These notes separate its implemented record-management foundation from restricted research implementations and from proposed future work. Research sections describe models, algorithms, and synthetic evaluation; they do not establish generally available features, field validation, calibrated home models, or diagnostic accuracy.
Implemented product foundation
IMPLEMENTED PRODUCT FOUNDATION
These notes describe the record model and workflows supported by the current product boundary. They do not imply customer validation or scientific diagnosis.
Relational data model
The implemented record foundation groups households and authorized members, home structure, equipment and systems, documents and reviewed candidate assertions, service and warranty history, maintenance records, and historical utilities. The important separation is between a physical record and an assertion about it: a wall or appliance can exist while a property attributed to it remains unknown, estimated, conflicting, or source-supported.
Physical-system graph
The implemented foundation connects homes, floors, rooms, zones, systems, and equipment through explicit relationships. Those links make records easier to navigate and correct. They do not by themselves establish a physical model, an equipment diagnosis, or how a system performs.
- 01
Home
Location, envelope, climate context.
- 02
Zones and spaces
What is thermally distinct from what.
- 03
Systems
Heating, cooling, ventilation, water, electrical.
- 04
Equipment
Identity, ratings, installation and service history.
- 05
Channels
What each piece of equipment is actually instrumented for.
Evidence and provenance
Three independent questions about any stored value, deliberately not compressed into one confidence field: where it came from (user entry, document, device, professional report), how it was obtained (measured, extracted, calculated, estimated), and its review state (unreviewed, accepted, conflicting, superseded).
Precision is separate again. A date extracted from an invoice may be known to the month, not the day, and the record says so rather than implying a precision it does not have.
A correction creates a new assertion and preserves the previous one. The system also distinguishes when something was observed from when DwellMetry learned of it — the distinction that stops a finding from an old inspection report being presented as newly observed.
Document intelligence
Implemented document workflows preserve private files and can produce candidate assertions with their source location for human review. Extraction does not turn text into verified fact: accepted, conflicting, corrected, and unknown states remain explicit, and no extracted value is treated as a physical measurement.
Utility analysis
The implemented product preserves historical billing periods, source values, units, optional costs, and visible overlaps or corrections. Comparisons account for period length where supported, but current product comparisons are not presented as weather-adjusted performance, efficiency analysis, forecasting, or diagnosis.
Maintenance and home health
The implemented foundation links maintenance knowledge, evidence-backed tasks, warranties, service events, and missing baselines to the relevant equipment. It does not claim predictive maintenance, exact failure dates, automated repair decisions, or a diagnosis of home condition.
Research / prototype implementations
RESEARCH IMPLEMENTATION · NOT FIELD VALIDATED
These models and algorithms are restricted research/prototype work evaluated with controlled or synthetic data. They are not generally available product functionality.
Digital twin representation
This is the physics-informed representation I explored for the research layer: a structural graph, evidence, estimated state, model parameters, uncertainty, and versioned inputs. It is a research architecture, not a claim that the current product is a calibrated digital twin of a real home.
T(t) = ( G(t), D(≤t), x̂(t), θ(t), U(t), V(t) )
- G(t)
- The home's structural, equipment and relationship graphs.
- D(≤t)
- Evidence and measurements available by time t.
- x̂(t)
- Estimated current physical state.
- θ(t)
- Parameters of the home-specific models.
- U(t)
- Uncertainty, missing information and applicability limits.
- V(t)
- Versions of the data, algorithms, rules and models used.
Scientific run records
The research architecture records model and code versions, input intervals, data-quality policy, parameter sets, uncertainty methods, and output references. This supports reproducible research runs; it does not establish that a model is released, calibrated for a real home, or field validated.
Telemetry semantics
The restricted research implementation distinguishes instantaneous samples, interval totals, cumulative counters, state observations, and categories. Missing telemetry remains missing; an absent state message is not proof that equipment turned off. This work is not presented as a generally available live-monitoring feature.
- Temperature, power. A value at a time, subject to sampling assumptions.
- Energy over 15 minutes. A quantity accumulated over a defined interval.
- Lifetime meter reading. Differences may produce interval quantities.
- HVAC on/off. Persists only under a documented validity policy.
- Heating / cooling / fan mode. A discrete operating classification.
Power, energy and time-weighted statistics
The research implementation treats energy as the time integral of power and weights irregular samples by the interval each represents. Coverage stays attached to an aggregate so a sparse series cannot masquerade as a complete observation. This has not been field validated as a released product capability.
Expected-behaviour models
The restricted research implementation explores per-home calendar baselines and weather-sensitive regression. A baseline can learn persistent inefficiency as normal, so its output can describe historical expectation without establishing health, efficiency, or a correct cause. It is not generally available or field validated.
P̂(t) = β₀ + β_h · max(0, T_bh − T_o(t)) + β_c · max(0, T_o(t) − T_bc)
- β₀
- Baseline consumption independent of outdoor temperature.
- T_bh, T_bc
- Balance-point temperatures below and above which heating and cooling begin.
- β_h, β_c
- Sensitivity to heating and cooling demand respectively.
- max(0, ·)
- The hinge: each term contributes only on its own side of the balance point.
Prediction uncertainty
Research evaluation pairs point estimates with intervals and considers coverage together with width. Time-series splits preserve ordering rather than leaking future observations into training. These methods describe prototype evaluation, not validated product performance.
Building heat transfer
Heat crosses a home's boundary by conduction through the envelope, by air exchange with outside through infiltration and ventilation, by solar gain through glazing, and by internal gains from occupants and equipment. Latent heat — moisture — is a separate accounting that matters for cooling.
A consumer application cannot instrument all of those. The modelling question is therefore not how to represent them fully, but which combinations the available measurements can actually constrain.
Reduced-order thermal model
The research implementation uses a deliberately simplified resistance–capacitance model to explore thermal response with sparse measurements. Its parameters and outputs remain subject to identifiability, calibration, data-quality, and applicability limits; it is not a calibrated model of a customer home.
Identifiability
The limit that shapes what the thermal model is allowed to claim. With only indoor temperature, outdoor temperature and equipment state, dividing the heat balance by the capacitance leaves a trajectory that depends on two ratios. Scaling conductance, capacitance and heat input together by any positive constant leaves the predicted temperature unchanged.
The measurements can identify the ratios. They cannot separate the three quantities. More optimisation cannot recover information the measurements never contained, so the software must report the identifiable combination, introduce independently supported information, state its assumptions explicitly, or decline to report the parameter.
Measured electrical power does not by itself resolve this, because electrical input is not the same quantity as heat delivered to the air.
dT/dt = (H/C) · (T_o − T) + (b/C) · u
- H/C
- Conductance over capacitance. Identifiable from the trajectory.
- b/C
- Equipment heat input over capacitance. Identifiable.
- H, C, b separately
- Not identifiable from these measurements alone.
- u
- Equipment operating state.
Calibration
Research fitting is constrained to physically plausible parameter ranges and evaluated only where the data-quality policy is satisfied. A curve fit is not evidence that each physical parameter has been identified, and no field-calibrated home model is claimed.
HVAC observability
This research table defines what different measurement sets could support. It is an observability boundary for prototype calculations, not an industry certification, equipment-health rating, or statement that those measurements are available in the current product.
| Available evidence | What it supports |
|---|---|
| Equipment records | Identity, maintenance, history |
| Operating state, indoor and outdoor temperature | Runtime, cycling, temperature response |
| Plus HVAC electrical measurement | Electrical power and energy per cycle |
| Plus supply and return temperatures | Temperature-split behaviour |
| Plus validated airflow | Supported air-side thermal-output estimates |
HVAC performance mathematics
The restricted research implementation explores cycle segmentation, temperature response, electrical energy, and—only where measured—air-side calculations. Unknown airflow or humidity remains unknown. No generally available, field-validated HVAC performance or efficiency result is claimed.
Measurement uncertainty
Uncertainty propagates through every derived quantity, and for a product of measured terms the relative uncertainties combine in quadrature. A sensible-output estimate built from a 10 percent airflow uncertainty and a temperature-difference uncertainty of similar size does not produce a number good to three figures.
Reporting the derived value without its uncertainty would imply a precision the inputs never had, which is the same failure as inventing a missing input, arriving by a slower route.
Anomaly detection
The restricted research implementation explores robust residuals, sustained-shift detection, persistence, and data-quality gates using controlled or synthetic evaluation. It is not a generally available production feature, has not been field validated, and does not establish equipment diagnosis.
Validation and release
Five levels of evidence, kept separate because each establishes something the others do not: software verification that the implementation matches the specified equations, synthetic evaluation under controlled known conditions, held-out evaluation on real observations not used for final tuning, field evaluation in supported homes and workflows, and release approval for a defined user group and stated purpose.
NIST's digital-twin credibility guidance identifies verification, validation and uncertainty quantification as lifecycle requirements rather than a one-time gate. Passing a synthetic test is not equivalent to demonstrating real-home diagnostic reliability.
Prediction quality is reported as mean absolute error and root-mean-square error, and interval quality as coverage assessed alongside interval width, operating conditions and sample size. Fault-related evaluation tracks false alerts, missed known events, detection delay and abstention rate — and diagnostic accuracy is not computed from cases lacking reliable outcome labels.
Availability of a feature is a conjunction, not a payment: authorized and entitled and released and data-ready and model-ready. Payment cannot supply a missing measurement or establish scientific validity.
Future / proposed directions
FUTURE / NOT YET ESTABLISHED
These sections preserve useful design work without presenting it as current product behavior.
Software architecture
A modular monolith with background workers: one coherent backend with separated responsibilities, rather than many independently deployed services from the start. A mobile client would be another consumer of the same service — it would not keep a competing household database or compute different scientific results.
The stack I planned around it: Next.js, React and TypeScript at the front; Python, FastAPI and Pydantic in the application layer; PostgreSQL with SQLAlchemy and Alembic, plus private object storage, for data; durable workers for background work; and NumPy, SciPy, pandas, scikit-learn and Pint for the scientific work.
That is the architecture I designed, not an inventory of what is deployed. I have not published the repository, so take it as the plan it was.
Web and mobile clients
Two front ends, one service. Neither computes its own science.
Authenticated API
Where authorization happens.
Application and domain services
Orchestration: what runs, for which household, in what order.
Approved scientific computation
Takes validated inputs, returns structured outputs. Knows nothing about components or payment providers.
PostgreSQL
Structured records: homes, equipment, evidence, runs.
Durable background processing
Ingestion, model runs and document work, off the request path.
Private object storage
Documents and images.
Weather and external data
Conditions the home did not measure itself.
Storage and background processing
This is a proposed architecture for separating raw ingestion from canonical records and for running long document or research jobs outside an interactive request. It is retained as design work, not presented as a verified inventory of the deployed system.
Multizone models and state estimation — explored
A single-zone model cannot represent a house where the upstairs runs five degrees warmer than the downstairs. The multizone form carries a temperature per zone and couples them through conductances, which turns the scalar heat balance into a small linear system.
State estimation over that system — a Kalman filter or a similar recursive estimator — would combine the model's prediction with each new measurement and carry a covariance, giving an uncertainty on the estimated state rather than a bare number.
This is a direction I investigated. It raises the identifiability problem rather than solving it: more states mean more parameters to separate from the same sparse measurements.
Ranked-cause reasoning
An interpretable hypothesis-ranking layer, designed to sit downstream of detection and kept separate from it. Each candidate explanation accumulates weighted supporting evidence and loses weight for contradicting evidence.
Grouping matters more than the weights. Increased runtime and increased daily energy largely reflect the same underlying behaviour; counting them as independent confirmations exaggerates support for whatever they both point at. Missing evidence contributes nothing in either direction — an unknown filter-maintenance date is not evidence that the filter is blocked.
A probabilistic formulation would need defensible likelihoods, priors, dependence handling and calibration. Applying a softmax to heuristic scores produces numbers that look like probabilities and are not, so the output stays a ranked explanation with its evidence attached rather than a probability of a fault.
Safety rules sit outside the ranking entirely and are independent of subscription state or any health score. A safety engine can only react to evidence it receives: no triggered warning is not proof that a home is safe.
Additional physical domains — explored
Directions the same evidence-aware framework could extend to, none of them part of the current product.
An airflow network combines mass conservation with pressure-driven connections between zones; the coefficients need evidence or calibration, and NIST's CONTAM is the established reference for multizone airflow and contaminant transport. Moisture adds latent transport and the conditions under which condensation becomes likely.
On the electrical side, solar generation, batteries and electric-vehicle charging change the shape of household demand enough that treating them as ordinary load would corrupt a baseline. Remaining useful life is a survival-analysis problem that needs failure data the application does not yet have.
Each is interesting and none is close to supportable on the measurements a typical home provides.
Intervention verification — explored
The most valuable loop to close and the one most easily done badly: deviation, possible explanation, actual intervention, measured behaviour afterwards.
Energy saved is the difference between what the pre-intervention model predicts would have happened under the conditions that actually occurred and what was observed. That reference is a counterfactual estimate, not last month's bill. A raw before-and-after comparison is insufficient whenever weather, schedules, occupancy or equipment use changed, which is nearly always.
Two disciplines follow. The pre-intervention model must be preserved and checked for whether it still applies, because immediately retraining on post-repair data obscures the very change being measured. And even a well-adjusted improvement is not proof of one causal mechanism: the report has to name the assumptions, the concurrent changes, the uncertainty and the professional findings actually available.