AVAROS

The problem

Manufacturing information is distributed across energy, production, material, carbon, and supplier systems. Operators need an understandable way to ask for that information without navigating a different dashboard for every question.

AVAROS is an OpenVoiceOS-based digital assistant for manufacturing teams. The engineering challenge is connecting conversational interfaces to real platform data while keeping integration details, canonical metrics, and optional analytics cleanly separated.

My contribution

As lead developer and system architect, my work spans the voice interface, application architecture, platform integration, configuration experience, and containerized delivery.

• Structured the system around a canonical manufacturing metric model and platform adapter boundaries.
• Built the FastAPI and React configuration surface for connecting a platform, registering assets, linking resources, mapping metrics, and enabling intents.
• Worked across the OVOS skill, browser voice bridge, HiveMind gateway, and wake-word service.
• Designed the integration boundary for optional PREVENTION anomaly and drift analytics.
• Supported Docker Compose delivery for standalone and WASABI OVOS environments.

Integration before intelligence

The v0.1.1 overview documents 19 canonical manufacturing KPIs; newer main-branch integration work adds native energy-channel handling and profile-specific capability boundaries. A platform-specific adapter translates external JSON/REST resources into those concepts, so voice and application behavior can operate against a consistent model.

The configuration wizard makes those boundaries visible to an operator:

1. Enter the platform endpoint and authentication.
2. Test connectivity.
3. Register assets and link platform resources.
4. Map external fields to canonical metrics.
5. Activate supported intents.
6. Configure PREVENTION if the deployment uses it.

That separation is more useful than assuming every deployment exposes the same API or names its measurements the same way.

One assistant, separate platform profiles

The latest main-branch implementation extends the integration story beyond a single manufacturing backend. It includes profile work for Reneryo, ThingsBoard CE, and OpenEMS: each profile carries its own endpoint, authentication, assets, and metric mappings.

Reneryo covers manufacturing KPIs and mapped energy resources. ThingsBoard provides device telemetry through configured REST mappings. OpenEMS adds native energy channels for generation, consumption, grid import/export, and storage state. These capabilities depend on the active profile's actual bindings; a platform name does not imply that every canonical manufacturing metric is available.

Profile switching is an application-state problem as well as an adapter problem. The implementation refreshes frontend state, reloads the backend adapter, notifies the voice skill, and isolates mapping lookups for background work. That prevents the previous platform's assets or endpoints from leaking into the next conversation.

The repository includes a three-profile manual query checklist. Its expected answers are useful validation guidance, not independently measured pilot results or evidence that every checklist item has passed.

Deterministic dialogue, explicit limits

The query layer now supports factory summaries, asset rankings, KPI definitions, comparisons, contextual follow-ups, and bounded direct-KPI scenarios. It resolves configured asset names and time periods rather than relying on a fixed demonstration vocabulary.

• “Rank all lines by OEE last month.” Preserve the values, assets, and calendar period behind the ranking.
• “What about Line-2?” Reuse the previous metric and period within the same session.
• “Is OEE good on Line-1?” Judge against a configured objective, or explain that none is configured.
• “What if scrap rate drops by 10 percent?” Calculate a bounded KPI scenario; do not infer a temperature-to-output causal model.

AVAROS is advisory and read-only. Equipment-control requests are refused, analytics depend on available configured capabilities, and missing data or objectives should produce an explicit limitation instead of an invented answer. Calendar periods and rolling windows are treated separately.

Voice and operational reliability

The recent implementation work also addresses the lifecycle around a query: browser and embedded voice clients can cancel an in-flight request; profile-aware analytics readiness keeps optional services from appearing universally available; and OVOS registration replay avoids attaching duplicate response handlers after a core restart.

These changes make the engineering contribution more specific than “voice over a dashboard”: coherent state across clients and services, bounded answers, and failure behavior that an operator can understand.

October development: bilingual, context-aware dialogue

The active October development branch extends this foundation into the Reneryo/FutureGen experience. It adds English and Turkish voice support, more natural Turkish metric questions, and structured clarification handling that preserves the subject, operation, and period through follow-up questions.

Historical answers also need a precise time model. Organization-local calendar requests use an administrator-verified timezone binding and become explicit UTC query bounds. Observation timestamps can be narrated in the verified local zone while retaining the original evidence. Missing bindings, empty windows, or incompatible source aggregation produce a clarification or limitation; the assistant does not guess a timezone, substitute another period, or prorate upstream monthly buckets.

The widget work includes short-lived signed session renewal, more conversational Turkish narration, and clause-aware pauses for long spoken answers. Those are important delivery details for an assistant embedded in another platform, where identity, conversation continuity, and audible output must agree.

This work is present on the active fix/turkish-understanding-continuity branch reviewed on 23 October 2026. It is described separately from main and the v0.1.1 overview. The repository's controlled FutureGen acceptance plan still requires real signed-session text checks and human English/Turkish audio review; source changes and automated tests do not establish that acceptance has passed.

Interface and configuration

The available screenshots document an earlier interface iteration. They show the dashboard, KPI views, voice interaction, and configuration surface; they are not a claim that every visible module ships in the current release.

A CLOSER LOOK

←→×

Project gallery

0 / 4 · ESC TO CLOSE

Architecture

OVOS skill / Browser voice / React configuration UI
                         ↓
FastAPI application and query orchestration
                         ↓
Active profile + canonical metrics + capability checks
                         ↓
Profile-isolated JSON/REST adapter and native bindings
                         ↓
Reneryo / ThingsBoard CE / OpenEMS

Optional: PREVENTION anomaly and drift analytics
Evaluation: deterministic demo manufacturing API

The demo API provides a deterministic data source for configuration and training. It remains distinct from a real manufacturing deployment.

PREVENTION is optional. The assistant remains usable without it, and anomaly/drift commands are disabled when no endpoint is configured. The current release does not bundle a production PREVENTION installation or provision its identity infrastructure.

Delivery decisions

• Explicit deployment modes: standalone Compose includes its own OVOS core; the WASABI integration connects to the existing OVOS environment.
• Configuration over hardcoding: platform endpoints, authentication, metric bindings, and optional analytics belong to deployment configuration.
• Operational boundaries: production deployments need HTTPS and credential rotation. A container starting is not sufficient evidence of a correctly connected manufacturing system.
• Clear release scope: DocuBoT is not part of the current v0.1.1 release. Earlier broader integration plans are not presented as shipped functionality.

What the work demonstrates

AVAROS brings together conversational UX, canonical domain modeling, heterogeneous platform integration, and deployment engineering. The important architectural decision is keeping platform data access separate from the intelligence and interfaces that use it.

Sustainability reductions are project goals for pilot evaluation, not measured savings claimed by this portfolio.