DwellMetry
DwellMetry is a live home-information application I built to organize a home’s structure, equipment, documents, maintenance history, and utility records in one place. I also used it as a research environment for exploring thermal behavior, expected-performance models, telemetry, and anomaly reasoning, but those scientific features are not presented here as generally available or field-validated product capabilities.
Current scope
The record-management foundation is implemented. The physics, telemetry, expected-behavior, and anomaly work described later is research/prototype work and is not presented as generally available or field-validated functionality.
Summary
- Physics & Modeling
- Flagship
- Continuing
My contribution
I designed and built the DwellMetry application, its home/equipment/document data model, record workflows, and the software architecture around them. I also developed research implementations for thermal behavior, telemetry, expected-performance modeling, and anomaly reasoning. I keep those two layers separate here because a research implementation is not the same thing as a validated product capability.
Project overview
Why I built this
Information about a home is usually split across equipment labels, manuals, inspection reports, service records, warranties, and utility bills. I wanted to build a structured record that could keep those sources connected without turning missing or conflicting information into false certainty.
The same foundation also gave me a place to investigate a harder question: what additional measurements, models, and validation would software need before it could say anything responsible about how a home is behaving?
What I built
I built and deployed DwellMetry, and I am continuing to develop it. Its implemented foundation organizes household access, home structure, equipment, documents, service and warranty history, maintenance records, and historical utilities while preserving sources, corrections, conflicts, and unknowns.
Alongside that product foundation, I developed restricted research implementations for telemetry semantics, weather context, expected-performance models, thermal response, HVAC analysis, and anomaly reasoning. Those implementations are research/prototype work evaluated with controlled or synthetic data; they are not presented as generally available or field-validated product capabilities.
Design approach
The implemented application treats records and evidence as the foundation. Home structure, equipment, documents, maintenance, service, warranty, and utility history remain useful without requiring a physics model to be ready.
Research computation sits behind a separate boundary. A research result must identify its inputs, assumptions, data-quality limits, and model status; it does not become a released product feature merely because an implementation exists.
Testing and validation
The live application establishes that DwellMetry is deployed and continuing. It does not establish that the scientific research is accurate in real homes.
The record-management foundation is implemented. The scientific layers have been used for restricted research and synthetic testing, but systematic field validation across supported homes has not been established. I therefore do not claim calibrated home models, production diagnostic accuracy, or field-validated anomaly detection.
Failures and debugging
The research work exposed several ways software can produce a convincing but unsupported answer: treating missing telemetry as zero, learning a home’s past behavior and calling it healthy, or fitting a thermal curve and assuming the fit identifies each physical parameter.
Those are research and modeling failures, not field results. They led me to make unknowns, provenance, identifiability, and abstention explicit parts of the design.
What I learned
The strongest part of DwellMetry is the boundary between what the records establish and what a model is still trying to infer. A useful home-information product does not need to pretend that every stored value supports a physical conclusion.
Keeping product capability, research implementation, and future direction separate made the technical work more credible, not less ambitious.
Next iteration
The product work is to complete the remaining release gates around the record foundation and its workflows. The research work is to validate each scientific layer against appropriate real observations before considering any broader release.
A calibrated physics-informed twin, broader automated diagnosis, unattended integrations, and a mobile client remain future directions rather than current product claims.
Implemented product foundation
These capabilities are supported by the current product boundary. They describe implemented records and workflows, not customer validation or scientific diagnosis.
- Authenticated household workspaces with owner, member, and viewer authorization.
- Home, floor, room, and zone records with explicit relationships, sources, conflicts, and unknown states.
- Equipment and component records linked to the home, documents, warranties, service events, and maintenance history.
- Private document records and uploads, with reviewed extraction that creates candidate assertions for human review rather than verified facts.
- Historical electricity, gas, and water records with transparent comparisons. Current comparisons are historical, not weather-adjusted performance conclusions.
- Source-linked maintenance knowledge, evidence-backed tasks, warranty records, and service chronology without predictive failure or repair diagnosis claims.
Research / prototype implementations
RESEARCH IMPLEMENTATION · NOT FIELD VALIDATED
These implementations explore how a structured home record could support physical and statistical reasoning. They are restricted research/prototype work using controlled or synthetic testing, not generally available product functionality.
- Channel semantics, missing-data rules, time weighting, and coverage checks for research observations.
- Weather context and home-specific statistical baselines explored under restricted research conditions.
- Reduced-order heat-transfer calculations and identifiability limits explored as research models.
- Research calculations gated by which measurements actually exist; no field-validated performance or efficiency claim.
- Research implementations for detecting qualified deviations without turning an anomaly into a diagnosis.
- A research direction connecting records, observations, and models; not a calibrated twin of a real home.
Future / not yet established
These directions are not presented as current product capabilities.
- Requires supported measurements, parameter identifiability, validation, and explicit release gates.
- Not claimed as generally available integrations; a thermostat may currently exist as an equipment record.
- Not established. Research anomalies and hypotheses do not constitute equipment diagnosis.
- A future client direction, not a current public product claim.
Technical notes
Implemented product architecture, restricted research models, and proposed future directions—labeled separately throughout.
Read the technical notesEvidence
Log entries for this project
- More fitting cannot recover information the sensors never measuredThe thermal model reproduced the data well and had not learned what I thought it had. The limit is structural, not numerical.PhysicsIdentifiability
- An anomaly is not a diagnosisDetecting that behaviour changed and explaining why are different problems, and merging them produces confident causes the evidence does not support.Fault ReasoningUncertainty
Related work
Solar photovoltaic performance intelligence: a deployed application for comparing measured and expected production and investigating persistent underperformance. Public demonstrations use fictional/reference data while the analysis pipeline continues to be validated and expanded.