IBM Software / SaaS Japan

Smart Light

IT Operations Automation

Smart Light needed a practical way to combine voice interfaces, generative AI and heterogeneous facilities-control protocols, but existing smart-speaker dialogue flows and control integrations were too rigid for real environments.

50% improved efficiency

Reported impact

Business outcome

Smart Light created a repeatable way to test and deploy voice-driven building controls with generative AI, improving development efficiency and proving that flexible facilities automation can be built without hard-coded dialog trees for every device.

  • Productivity Improvement
  • Scalability

Solution

Smart Light built a facilities-control workflow around IBM watsonx.ai, IBM Cloud Code Engine, Node-RED and MQTT to make generative AI usable in IoT operations. The system begins with transcribed voice text, which watsonx.ai interprets in context so a user request can be mapped to a device action. Because control protocols vary across equipment, Code Engine provides a serverless layer for protocol conversion and runtime orchestration, while Node-RED standardizes interfaces and helps bridge device logic to the MQTT messaging model. That combination lets Smart Light connect air conditioning, lighting and curtain controls through a common AI-assisted command path instead of building separate rigid flows for every scenario. The architecture was designed for trial-and-error iteration through watsonx.ai's GUI and repeatedly tested prompt workflows, giving the team a practical way to validate new facility-control interactions before broader deployment.

Data flow

Voice text is interpreted by watsonx.ai, Code Engine and Node-RED convert the AI decision into a standardized MQTT command, and the command is sent to connected systems such as air conditioning, lighting and curtains for execution.

Solution architecture

4 components · 4 layers
  1. Ingest
    • Node-RED Standardizes interfaces and wiring between device protocols, messaging and cloud services.
  2. Compute
    • IBM watsonx.ai Interprets transcribed voice requests and determines the contextual action the facilities-control system should take.
  3. Serving
    • MQTT Provides the messaging protocol used to standardize control commands across facilities devices.
  4. Orchestration
    • IBM Cloud Code Engine Runs the protocol-conversion and bridging services that translate AI output into equipment-control actions.

Architecture clues

  • Code Engine was chosen as a serverless bridge between AI interpretation and device-control execution.
  • Prompt experiments were run repeatedly in the watsonx.ai playground before broader rollout.
  • The workflow standardizes device integration through MQTT rather than bespoke protocol handling for each endpoint.

Evidence from the source

50% improved efficiency
IBM Cloud Code Engine serverless platform was used for equipment control protocol conversion
IBM watsonx.ai
Its interface was standardized to the Message Queuing Telemetry Transport (MQTT) messaging protocol
Transparency Evidence & methodology 90/100 reference value · 89% confidence · 1 source

Review how this reference was scored and trace each normalized claim back to its documented source.

01

Scoring methodology

How scores are calculated

Customer Reference Value measures usefulness as a customer reference. Evidence Confidence measures the quality and traceability of available evidence, not independent verification.

Customer reference value90/100
  • Problem clarity20/20
    Measures whether the customer's operational problem is specific enough to compare.
  • Implementation depth25/25
    Rewards named components, data flow, integrations, and architecture detail.
  • Outcome specificity20/20
    Measures whether the reported benefit is concrete rather than a generic claim.
  • Quantified impact15/25
    1 metric describe measurable impact.
  • Deployment scale10/10
    Rewards evidence of a live or scaled deployment and meaningful integration scope.
Evidence confidence89%
  • Source authority20/25
    The main evidence is an official vendor-published customer story.
  • Claim traceability21/25
    10 of 12 key fields link to a named source.
  • Direct evidence20/20
    4 direct source quotes retained.
  • Date provenance10/10
    The publication date comes from the source page or publisher.
  • Source transparency8/10
    1 source reference document publisher, URL, authority, retrieval, and supported fields.
  • Implementation specificity10/10
    Rewards source-backed components, data flow, quantified impact, and a specific outcome.
02

Traceability

Sources & provenance

Field coverage shows which facts each source supports. Dates are shown only when documented by the source.

  1. IBM

    Smart Light customer story

    First-party
    https://www.ibm.com/case-studies/smartlight
    Source type
    Vendor-published customer story
    Published
    Jul 8, 2025
    Supports
    • Customer
    • Business problem
    • Solution
    • Products
    • Solution components
    • Data flow
    • Integrations
    • technical area
    • use case category
    • Business outcome
    • outcome category
    • Metrics
    • Architecture
    • evidence quotes
    • Publication date

Date evidence

Not separately sourced Industry, Region, Company size. Treat these normalized attributes as lower-confidence until a dedicated source is added.