SmartHaus

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.

Quick Start

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 --build

The 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.
• REST Client requests include synthetic Ubiquiti webhook examples.

The Compose definition owns dependency endpoints and the optional
hardware-specific speech profile; review its header before starting that profile.

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.

Projects

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.

Compatibility

Version 2.0 classifies missing application or event-sink configuration as ConfigurationException
and duplicate KNX export metadata as InvalidDataException, rather than GenericException.
Consumers catching the old concrete exception must update their handlers and rebuild. Device
packages retain .NET 8 and .NET 10 support; application hosts remain .NET 10.

When migrating from versions before 1.1, also update 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.

Use a Standalone Library

For a host application with configuration and logging, install a device client:

dotnet add package CasCap.Api.Fronius

Register 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.

Configuration

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.

Configuration Examples

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.

System Context

SmartHaus integrates devices and cloud APIs, exposes HTTP/SignalR/MCP surfaces, and delegates model
execution and Signal account ownership to separate services. The
architecture drilldown covers event flow and package dependencies;
artifact publication separates CI releases from registry publication.

flowchart LR
    classDef system fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
    classDef person fill:#ede9fe,stroke:#6d28d9,color:#2e1065
    classDef external fill:#fef3c7,stroke:#d97706,color:#78350f
    users([Operators and client applications]):::person -->|"HTTP and SignalR"| haus[SmartHaus]:::system
    devices["Devices and cloud APIs"]:::external <-->|"readings, events and commands"| haus
    haus -.->|"agent runs"| runtime[Agent Runtime]:::external
    runtime -->|"MCP tools"| haus
    haus <-->|"messages and attachments"| signal[Signal gateway]:::external
    haus -.->|"optional persistence"| azure[Azure Storage]:::external

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.

Development

Use a stable .NET 10 SDK. For the current source tree, the Debug solution uses sibling source
dependencies:

dotnet build SmartHaus.Debug.slnx --configuration Debug

These 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.

Device integration fixtures select the shared Test configuration environment, including optional
appsettings.Test.json, local test overrides, User Secrets and environment
variables. The tracked test defaults use local dependencies; they do not supply real device access.
Put test-only private overrides in appsettings.Local.Test.json, not the Development tier.

License

MIT License.