Space
Rooms and architectural elements retain IFC identity and real placement.
USER ONBOARDING
Start with your home. End with a twin you can inhabit.
This guide is about the experience, not the development stack. It shows how Teldra is intended to move from an architectural model to a spatial view of rooms, devices, live context, and authored information.
THE JOURNEY
Six steps, one persistent model.
- 01
Bring in your home
Open an IFC building model or migrate a Sweet Home 3D project. Teldra keeps architectural meaning—rooms, walls, openings, fixtures, placement—rather than reducing the home to a picture or mesh.
- 02
Recognize the things that live there
Devices and capabilities receive stable Teldra identities. Home Assistant entity IDs or future platform IDs remain external bindings, so changing automation software does not redefine what the device is.
- 03
Enter the spatial twin
Open a portable .teldra project and navigate its bundled scene visually. Selecting a wall, fixture, or device resolves back to the same canonical identity used by the project instead of creating a renderer-only copy.
- 04
Inspect and change authored information
Studio can edit canonical device data, undo and redo changes, maintain recovery state, and safely save the portable project back from the browser.
- 05
Add live context
The read-only Home Assistant adapter brings normalized observations into Teldra without making Home Assistant the twin itself or implying that observation grants control.
- 06
Use the same home in different ways
Interactive 3D, analytical overlays, diagnostics, offline Blender/Cycles rendering, and future automation can all project from the same identity-preserving model.
WHAT YOU ARE LOOKING AT
The twin separates the home from the view.
This separation is what lets Teldra show the same home as a 3D scene, an analytical view, an editor, a diagnostic surface, or a rendered image without changing what the home means.
Things
Lights, sensors, media, openings, climate, and future device classes belong to the twin rather than a renderer.
State
Observed values, desired values, availability, and acknowledgements are modeled separately.
Context
Selection, camera position, filters, and visual emphasis help you navigate but do not rewrite the home.
WHAT EXISTS TODAY
Current, in progress, and intended are kept separate.
Available foundation
IFC identity, semantic SH3D import, stable schemas, portable .teldra open/edit/save, Babylon scene rendering and canonical selection, project recovery, deterministic fixtures, Blender/Cycles interchange, and read-only Home Assistant live state.
Being connected now
Authorization-gated Home Assistant control with explicit intent, acknowledgement, failure, and safety boundaries. The shipped adapter remains read-only.
Designed for later
Richer analytical overlays, broader automation adapters, deeper historical/maintenance context, and more complete end-user authoring.
EXAMPLE
You select a floor lamp.
The visible object resolves to a canonical device. That device can retain its room and building relationship, its external Home Assistant binding, its authored name and capabilities, and its latest read-only observation. Editing its name should not change its identity; changing the camera should not change its placement; changing automation platforms should not erase what it is.
Living room→Floor lamp→Teldra identity→HA binding→Live observation
NEXT
Explore the capabilities and project history.
The landing page shows the broader workflow, conventional and unconventional uses, the system graph, and the development timeline.