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.

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

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.