SmartHaus is an open-source .NET 10 smart-home and IoT application for edge hosts. It connects heating, solar, KNX building automation, cameras, lighting and appliance APIs to event sinks, versioned HTTP endpoints and Model Context Protocol (MCP) tools for AI agents.
The application is an early proof of concept: interfaces may change and it is unsupported. The standalone device libraries can also be used without running SmartHaus.
With Docker and Compose installed:
The source-built demo uses the Release graph, resolving shared libraries, Agent Runtime contracts and communications packages from NuGet. Debug source builds instead use the adjacent checkouts listed in Development. This README does not report an executed demo.
git clone https://github.com/f2calv/SmartHaus.git
cd SmartHaus
docker compose --profile demo up --buildThe demo builds the server and starts Redis, Azurite and OpenTelemetry infrastructure with
EdgeHardware,Ubiquiti,Comms enabled. Device/API exploration does not require a physical device or
Azure subscription; available CPU/GPU readings depend on the host and container access.
The communications feature additionally requires separately configured Agent Runtime and Signalizr
services. It is not a self-contained AI or messaging demo.
- Swagger UI lists available HTTP endpoints.
- System metadata identifies the running application.
- Redis UI lets you inspect local event state.
- REST Client requests include synthetic Ubiquiti webhook examples.
For example, with the demo running, submit one synthetic camera event:
curl -X POST "http://localhost:8080/api/v1.0/ubiquiti/event/smart?type=person&camera_name=ExampleCamera&score=0.95"The callback returns ok and dispatches the event to configured sinks. It does not imply that an
agent or Signal recipient is configured.
The eight package listings below are published on NuGet; their source targets .NET 8 and .NET 10. Other application libraries are source-only and target .NET 10. Each integration README describes its own device, cloud authentication and configuration requirements.
| Integration | Client and usage | Optional storage sinks | Published packages |
|---|---|---|---|
| Buderus KM200 heating | Client | Redis, Azure Tables | Client, sinks |
| DoorBird door stations | Client | Redis, Azure Tables, Blob | Client, sinks |
| Fronius solar inverters | Client | Redis, Azure Tables | Client, sinks |
| KNX building automation | Client | Redis, Azure Tables, raw CEMI | Client, sinks |
| Edge CPU/GPU and GPIO | Library | Redis, Azure Tables | Source only |
| Miele appliances | Library | Redis, Azure Tables | Source only |
| Shelly smart plugs | Library | Redis, Azure Tables | Source only |
| Sicce water pumps | Library | Redis, Azure Tables | Source only |
| UniFi Protect webhooks | Library | Redis, Azure Tables | Source only |
| WiZ lighting | Library | Redis, Azure Tables | Source only |
| Azure Dynamic DNS | Library | Not an event-sink integration | Source only |
| Application hosts | HTTP server, agent console | Shared bootstrap | Container image |
| Application orchestration | Backend, SignalR, communications, media and MCP | Redis streams and media cache | Source only |
| Helm charts | Application, Grafana dashboards | Configurable workload aliases and dashboard provisioning | oci://ghcr.io/f2calv/charts/smarthaus |
| Tests | Buderus, DoorBird, Fronius, KNX, Miele, host, backend | Source-declared inventories and prerequisites | Not published |
The 1.1 release intentionally includes incompatible contracts despite its minor version. Rebuild package consumers and migrate the Buderus query-service write result. HTTP callers must also check the current typed device responses, string-enum JSON and validated Miele command bodies; unrecognized Miele fields are rejected rather than forwarded.
For a host application with configuration and logging, install a device client:
dotnet add package CasCap.Api.FroniusRegister the client and query its Solar API without starting continuous monitoring:
using CasCap.Extensions;
using CasCap.Services;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
var builder = Host.CreateApplicationBuilder(args);
builder.Services.AddFronius(builder.Configuration, lite: true);
using var host = builder.Build();
var reading = await host.Services.GetRequiredService<FroniusClientService>()
.GetPowerFlowRealtimeData();Supply CasCap:FroniusConfig using the Fronius configuration examples,
replacing synthetic values with the inverter's LAN endpoint. Other libraries expose their own
registration methods and contracts; full background monitoring needs the feature-worker runner,
not just a call to AddHostedService.
CasCap:FeatureConfig:EnabledFeatures selects a comma-separated set of features:
Buderus,Comms,DDns,DoorBird,EdgeHardware,Fronius,Knx,Miele,Shelly,Sicce,SignalRHub,Ubiquiti,Wiz.
Select only integrations you have configured; enabled device features may read or control real hardware.
The hosts load base and environment appsettings, local overrides, user secrets, environment variables
and optional Azure Key Vault through the shared bootstrap. See
configuration initialization for the provider contract.
Use gitignored local configuration or user secrets for credentials. Environment keys use double
underscores, for example CasCap__FeatureConfig__EnabledFeatures=Ubiquiti.
This fragment selects webhook processing and disables Key Vault; merge it with the tracked application configuration and Ubiquiti settings:
{
"AppConfig": { "KeyVaultName": "skip" },
"CasCap": {
"FeatureConfig": { "EnabledFeatures": "Ubiquiti" }
}
}Redis is a server prerequisite even for a single-process profile. Azure storage sinks and Key Vault are optional capabilities; corresponding options may still require syntactically valid endpoints. The local demo uses Azurite rather than an Azure subscription.
Feature services collect device readings or receive webhooks and dispatch events to selected sinks. SignalR broadcasts events; Redis streams connect domain events and media to communications. SmartHaus exposes its own MCP tools but does not construct or select language-model agents.
flowchart LR
classDef owned fill:#e0f2fe,stroke:#0369a1,color:#082f49
classDef external fill:#dcfce7,stroke:#15803d,color:#052e16
classDef state fill:#fef3c7,stroke:#b45309,color:#451a03
DEVICES["Devices and cloud APIs"]:::external
FEATURES["SmartHaus feature services"]:::owned
SINKS["Event sinks"]:::owned
REDIS[("Redis state, streams<br/>and media cache")]:::state
STORAGE[("Optional Azure Storage")]:::external
HUB["SignalR hub"]:::owned
COMMS["Communications and media"]:::owned
MCP["Domain MCP tools"]:::owned
RUNTIME["External Agent Runtime"]:::external
SIGNAL["External Signal gateway"]:::external
DEVICES --> FEATURES --> SINKS
SINKS --> REDIS & STORAGE & HUB
REDIS --> COMMS
COMMS --> RUNTIME
RUNTIME --> MCP --> FEATURES
SIGNAL <-->|"messages and attachments"| COMMS
The backend README documents Signal groups, speech-to-text providers, media limits and tool registration. Agent instruction examples illustrate behavior only; active definitions, sessions, inference providers and credentials belong to the external runtime.
Use a stable .NET 10 SDK. For the current source tree, the Debug solution uses sibling source dependencies:
dotnet build SmartHaus.Debug.slnx --configuration DebugThese include the public
CasCap.Common and
CasCap.Api.Azure libraries,
Signalizr communications and
Agent Runtime projects, plus their transitive source references,
checked out alongside this repository.
docker compose up starts only local infrastructure; the demo profile also builds the server.
See the project test READMEs before choosing tests: some access live devices, cloud services or
change device state, and must not be treated as credential-free checks.