> ## Documentation Index > Fetch the complete documentation index at: https://documentation.kodelabs.com/llms.txt > Use this file to discover all available pages before exploring further. # SmartCore > Connect SmartCore (Vanti) to KODE OS for lighting, occupancy, and door status data > Connect SmartCore to KODE OS for lighting, other data integration ## Overview Use this integration to connect SmartCore to KODE OS. You can discover devices over gRPC, collect lighting, occupancy, and door-status data with hybrid snapshot collection, and surface shared-space and meeting-room conditions in Data Sources. | Property | Value | | ------------------- | -------------------- | | **System Type** | Lighting, Other | | **Communication** | gRPC (TCP/IP) | | **Collection** | Hybrid (Pull + Push) | | **Collection Mode** | SNAPSHOT | ## Supported Capabilities * Discover Devices & Points * Collect Sensor Data * Write to Points (lighting levels, transitions) ## Prerequisites * SmartCore (Vanti) gRPC server accessible from the KODE OS network * The IP address and port of the on-site SmartCore controller * KODE OS environment with access to Data Sources ## Configure Connector in KODE OS 1. Navigate to **Data Sources** in your building 2. Click **API Catalog** and search for **SmartCore** 3. Click **+ Add Datasource** 4. Fill in the fields below and complete the three-page setup flow | Field | Required | Type | Description | | ------------------ | -------- | ---- | ---------------------------------- | | **Connector Name** | Yes | text | Display name for this connector | | **Host** | Yes | text | gRPC server hostname or IP address | | **Port** | Yes | text | gRPC server port | ## Discover Devices and Points After configuring the connector, click **Discover** on the connector detail page. KODE OS will query the SmartCore system and return a list of available devices and their data points. SmartCore devices are discovered with trait-based point definitions. Each device exposes points based on the traits it supports (e.g., a lighting fixture exposes `LightApi` and `BrightnessSensorApi` traits). Review the discovered items and select the devices you want to register in KODE OS. For more details on the discovery process, see the [Discovery guide](/products/integrations/capabilities/discovery). ## Devices and Points SmartCore devices are organized by **traits** -- each trait defines a set of related data points with specific behaviors. All points are collected at **1-minute** intervals. ### BrightnessSensorApi Reports measured ambient brightness for a space. | # | Point | Description | Unit | Writable | Collection | | - | ---------------- | ----------------------------------------- | ---- | -------- | --------------- | | 1 | `brightness_lux` | Ambient brightness measured by the sensor | lux | No | Polling (1 min) | ### LightApi Controls light output. Brightness is normalized to 0-100%. See device specifications for supported step values. | # | Point | Description | Unit | Writable | Collection | | - | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | -------- | --------------- | | 1 | `level_percent` | Current device brightness level (0-100%). On write, only one of `level_percent` or preset should be set. Zero value is ignored if a preset is active | % | Yes | Polling (1 min) | | 2 | `brightness_tween.progress` | Read-only transition progress (0-100%) representing how far through the brightness transition the device is | % | No | Polling (1 min) | | 3 | `target_level_percent` | Target brightness level after the current transition completes. Zero values are ignored if a target preset is present | % | No | Polling (1 min) | | 4 | `brightness_tween.total_duration` | Duration of the brightness transition. On write, only the duration value should be provided | seconds | Yes | Polling (1 min) | ### OpenCloseApi For devices that can open and close, such as window contacts, blinds, and garage doors. | # | Point | Description | Unit | Writable | Collection | | - | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | -------- | --------------- | | 1 | `open_percent` | How open the device is (0 = fully closed, 100 = fully open) | % | No | Polling (1 min) | | 2 | `open_percent_tween_progress` | Transition progress for the open/close operation | % | No | Polling (1 min) | | 3 | `direction` | Movement direction for multi-direction devices. Values: `DIRECTION_UP`, `DIRECTION_DOWN`, `DIRECTION_OPEN`, `DIRECTION_CLOSE`, `DIRECTION_IN`, `DIRECTION_OUT`, and others | -- | No | Polling (1 min) | | 4 | `resistance` | Reports if physical resistance prevents the target position from being achieved (e.g., door held open, window jammed). Values: `RESISTANCE_NOT_OVERRIDDEN`, `RESISTANCE_OVERRIDDEN_EXTERNALLY`, `RESISTANCE_OVERRIDDEN_LOCALLY` | -- | No | Polling (1 min) | | 5 | `target_open_percent` | Target open percentage after the current transition | % | No | Polling (1 min) | | 6 | `open_percent_tween_duration` | Duration of the open/close transition | seconds | No | Polling (1 min) | ### LockUnlockApi For devices that can be locked or unlocked. Position may be in a steady state or transitioning. | # | Point | Description | Unit | Writable | Collection | | - | ---------- | -------------------------------------------------------------------------- | ---- | -------- | --------------- | | 1 | `position` | Current lock state. Values: `LOCKED`, `LOCKING`, `UNLOCKED`, `UNLOCKING` | -- | No | Polling (1 min) | | 2 | `jammed` | Reports whether the lock is jammed and unable to reach the target position | -- | No | Polling (1 min) | ### StatusApi Reports the working status of a device. Reflects the most severe level from any active problems. | # | Point | Description | Unit | Writable | Collection | | - | ------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ---- | -------- | --------------- | | 1 | `level` | Device health status, highest severity from current problems. Values: `NOMINAL`, `NOTICE`, `REDUCED_FUNCTION`, `NON_FUNCTIONAL`, `OFFLINE` | -- | No | Polling (1 min) | ## What Data You Get ### Point History Time-series readings including brightness levels, lighting output percentages, door/window open positions, lock states, device health status, and transition progress, collected every 1 minute from connected SmartCore devices. ### Polling Schedule * **Point History** -- Default polling: 1 minute (min: 1 minute, max: 1 hour) For more details on collection modes, see the [Data Collection guide](/products/integrations/capabilities/data-collection). ## Use Cases Once connected, this integration enables you to: * Control and monitor lighting levels across shared spaces and meeting rooms with personalized lux settings * Detect lighting fixture failures automatically and receive maintenance alerts before occupants are affected * Monitor door and window status (open/closed, locked/unlocked) from a central security dashboard * Receive fire door tampering notifications for building safety compliance * Track device health status to proactively schedule maintenance for degraded fixtures ## Troubleshooting Verify the host and port are correct. Ensure the SmartCore gRPC server is running and reachable from the KODE OS network. Check that firewalls allow TCP connections on the configured port. Verify the SmartCore system has devices registered and that the gRPC server is responding. Run a test connection first to confirm connectivity. Ensure the controller has completed its own device commissioning process. Check the connector status on the Data Sources page. If the status shows an error, review the error logs on the connector detail page. Common causes include network interruptions or the SmartCore controller being restarted.