Hudratore Tomo AI Core: Building and Energy Automation Architecture

[Karel Horky]

Hudratore Tomo AI Core is our modular software project for coordinating building automation and energy management. Its development architecture connects measured operating conditions, analytical models, time-based planning and device-specific adapters in a single traceable decision flow.

Engineering work and verification behind Alpha039

The development process separates three scales: 11 lifecycle stages with 76 roadmap items, 17 concrete implementation steps and the 10-layer operating architecture illustrated below. The roadmap snapshot reviewed on 8 October 2026 marks 47 of its 76 items complete. These figures describe different parts of the same project.

Documented scope	What it covers
11 stages · 76 items	Requirements, architecture, inputs, models, planning, integration, verification, shadow validation, commissioning, extensions and ongoing maintenance.
17 implementation steps	A concrete sequence from installation inventory and public configuration through adapters, planning, feedback, historical simulation, shadow operation and channel-by-channel handover.
40 requirements	28 functional and 12 non-functional requirements, each traced to its implementation, test and evidence.
22 risks · 12 scenarios	A risk register and an initial set of operating and fault scenarios, alongside seven documented existing protection and control boundaries.
808 tests passed	The final instrumented local package run for Alpha039, recorded on 4 October 2026: 95.55% statement coverage and 92.24% branch coverage within that measured scope.
17 native HA scenarios passed	A separate run inside Home Assistant 2026.9.4 using explicitly synthetic registrations, including manual takeover, unverified capability manifests and loss of input sources.

Six checks after every implementation step

1. Correct deliverable: the change belongs to the intended project document or software component.
2. Correct layer: configuration, data, analysis, planning, arbitration, execution and feedback retain their assigned responsibilities.
3. Correct order: the necessary preceding steps and their evidence are complete.
4. Preserved approved baseline: the change keeps the agreed architecture and recorded decisions intact.
5. Interfaces and feedback: inputs, outputs, control authority, fresh measurement and the return path are explicit.
6. Roadmap traceability: the step has a corresponding lifecycle gate, test and recorded evidence.

Each completed roadmap item receives a retrievable closure package with its working files, purpose and verification evidence. Publication checks include a return copy, API readback and visual inspection. The review also traces 36 approved installation decisions across all 17 implementation steps.

The 808-test package run, the 17 native scenarios, API readback, visual inspection and physical-device qualification are separate evidence layers. The native Alpha039 scenario run recorded zero physical service calls. Device-specific execution proceeds through its own qualification, feedback, shadow-operation and handover gates.

Runtime and current development stage

The documented runtime is a local Home Assistant installation on an Intel N150 system. The latest project record describes Alpha039: registered inputs and planning cycles feed analytical outputs, neutral operating intentions and read-only arbitration. The next integration work qualifies the native execution path for each supported device. This technical note describes the software architecture and its current development stage.

Diagram 1 — Core decision and feedback path

1–3 · Definitions, runtime & registries
Versioned interfaces · Home Assistant / N150 · installation configuration

↓

4–6 · Input adapters & validated snapshot
Measured values · units · timestamps · source quality

↓

7 · Analysis & planning
Forecasts → time-limited, neutral operating intentions

↓

8 · Intent arbitration
Authority · priorities · manual takeover · one result per channel

↓

9 · Qualified native execution
Device adapter · command expiry · transport acknowledgement

↓

10 · Feedback & audit
Fresh measurement → observed result → next planning cycle

Reference architecture. Alpha039 currently provides read-only planning and arbitration; native execution is qualified per device.

Four energy domains and a consistent data model

The core model describes photovoltaic generation, building consumption, the grid connection and the battery. Every input carries its identity, unit, source, timestamp and validity. Grid power uses a common convention: positive for import and negative for export. Battery power is positive for charging and negative for discharging. Input adapters translate manufacturer-specific conventions before the data reaches analysis.

For multiple batteries, each channel preserves its own energy and state of charge. Shared grid and consumption measurements enter the common model once. The planning model can therefore represent shared flows alongside individual battery constraints.

Diagram 2 — Four energy domains, five canonical signals

Photovoltaic generation pv_total_w · W	Building consumption house_load_w · W
Grid connection grid_power_w · W + import / − export	Battery battery_soc_pct · % battery_power_w · W + charge / − discharge

↓

Validated operating snapshot
Source · timestamp · availability · quality

Logical data model. Each registered battery retains its own state; common grid and building flows are counted once.

From measurements to a qualified action

1. Definitions and runtime: establish common meanings, interfaces and the local execution environment.
2. User registries: identify actual sensors, devices, calendars, profiles and enabled modules.
3. Input adapters: acquire and normalise data from registered sources.
4. Operating values and source validation: check units, ranges, availability and permitted data age.
5. Analysis and planning: produce time-limited intentions with a reason and priority.
6. Arbitration: resolve competing intentions, manual takeover and the authority assigned to each physical channel.
7. Native execution and feedback: translate a qualified intention through a verified output adapter, then compare fresh telemetry with the intended result.

A successful transport response is one part of the evidence. Confirmation of the achieved state comes from subsequent measurement. Technical reports retain the relationship between the input snapshot, plan revision, intention and observed outcome.

Versioned contracts at module boundaries

The current public contract version is 1. The shared message envelope carries contract_version, kind, message_id, source_id, interface_id and received_at. These identifiers preserve the source and relationship of each value as it passes between modules.

Boundary	Technical qualification
Observation	Unit, sign convention, measured time, receipt time, validity and availability.
Neutral intention	Module, logical channel, operation, reason and a timezone-aware validity interval.
Command envelope	Qualified native operation, parameters, issue and expiry times, authority and idempotency key.
Feedback	A new measured state linked to the originating plan, intention and command.

Illustrative neutral intention: the following shows the interface shape using fictional identifiers and a fictional operating window.

{
  "module_id": "example_planner",
  "channel": "example_thermal_channel",
  "operation": "example_operation",
  "reason": "configured operating window",
  "valid_from": "2026-10-08T12:00:00+02:00",
  "valid_until": "2026-10-08T12:15:00+02:00"
}

The planner uses a logical channel. Translation into a Home Assistant service, device address or manufacturer register belongs to the qualified output adapter. At arbitration, several intentions for one channel become an explicit conflict while independently qualified channels can continue.

For a 15-minute planning interval, the elementary energy conversion is E [kWh] = P [W] × 0.25 [h] / 1000. Variable power requires integration over the interval. The model keeps stored energy, instantaneous power and state of charge as separate quantities; price evaluation uses the energy transferred and the configured tariff.

Energy, weather and seasonal profiles

The planning inputs can combine quarter-hour electricity prices, production and consumption forecasts, battery reserves, temperature and configured operating windows. A seasonal profile describes user-defined timing and comfort requirements; weather and measured production provide the changing operating context.

For a controllable thermal load, an intention can specify a useful heating interval, a priority and an energy budget. Qualification then considers fresh measurements, configured thresholds, minimum running time and the registered operating conditions. Device-native protection and the selected manual-control policy remain part of the execution boundary.

Economic comparison uses the complete configured purchase or sale price, conversion losses, battery reserve and the energy expected to be needed later. The project therefore separates a planning objective from the instantaneous response of the local device controller.

Modularity across homes and business buildings

Core registrations describe the installation through public interfaces rather than a fixed house profile. Device adapters encapsulate protocol-specific translation; analytical and reporting modules consume the same normalised operating model. A technical view and a simpler user view can present the same plan with different levels of detail.

This separation gives an integrator a concrete acceptance process: validate source meanings and timestamps, compare plans with measured operation, qualify one execution channel, demonstrate its feedback and verify the return to the existing operating mode.

Software architecture and AI hardware

Hudratore Tomo AI Core is the software project described here. Our Tomo AI Core NVIDIA platform provides a related edge-computing hardware direction for AI workloads. Hardware selection and porting are evaluated against the intended application; the documented development runtime for this controller is N150.

Related hardware: 524WiFi™ Tomo AI Core NVIDIA. The Hudratore Tomo AI Core software runtime documented in this post is Home Assistant on N150.

Discussion: Which inputs and operating constraints matter most in your installation: battery reserve, heating comfort, weather-dependent loads or coordination of several energy channels?

[Author]

Posts