# Leveraging Retrieval-Augmented Generation for Automated Smart Home Orchestration
## 3 System Overview
### Architectural Design and Components
#### 3.3.4 Generative AI Integration Layer
Once the new orchestration bundle is started, its services (if any are provided) or at least its component existence is also registered. In most cases, though, the generated bundle is primarily a consumer of device services. As soon as it activates, the orchestrator's job for this request is completed. Figure 5 shows an example from the runtime: after deployment, device bundles (and by extension any orchestration bundles) appear in the Apache Felix console's service registry listing, confirming that they have been successfully registered and are ready to use. Figure 4: Interaction between service consumers, service providers, and the service registry within an OSGi framework, based on the model proposed in [21]. The service provider registers/publishes services, the consumer discovers them, and binding is handled dynamically by the registry. 3. Automated Code Generation and Deployment: A central innovation of this system is the dynamic creation of OSGi-compatible code via an AI model. After determining which devices and services are involved in a user request and gathering their interface details, the orchestrator formulates a structured prompt for the LLM (OpenAI's model) [27]. This prompt typically includes a summary of the user's request, a description of each relevant device service, and what the final code should accomplish. When the LLM returns the Java code, the code consists of a class implementing the desired logic in an _@Activate_ method, with fields for each required device service (annotated with _@Reference_ and setter methods for dependency injection). It also includes any helper methods corresponding to device action, i.e., an execute method or directly the _@Activate_ method calls _lightService.setBrightness(58)_, _speakerService.turnOn()_, and _speakerService.setVolume(30)_. An important aspect is that the LLM has been guided to follow a template that matches the system's requirements, so the output code is likely to be correct without manual editing. Once the code is ready, the system programmatically compiles it. It uses the Java compiler with a runtime classpath that includes all required dependencies: notably, the JARs of the device bundles (to resolve _LightService_, _SpeakerService_, etc. ), plus the OSGi core and DS libraries. The orchestrator generates the compilation command and executes it, producing a.class file for the new component [28; 29]. Next, the orchestrator assembles the OSGi bundle: it creates a JAR file that contains this compiled class, and it adds the MANIFEST.MF file. The manifest contains entries such as Bundle-SymbolicName, Bundle-Version, and Import. It also includes the Service-Component entry, which points to the automatically generated component XML file in OSGI-INF (this XML lists the component and its implemented interfaces and references, as derived from the annotations in code). With these pieces in place, the orchestrator has a complete OSGi bundle JAR ready to go. Deployment is then handed off to the Control Layer: the orchestrator calls the controller to install this new bundle into Apache Felix. The controller installs and immediately starts the bundle, which triggers the OSGi SCR to activate the component. The generated code's _@Activate_ method runs, executing the automation logic. If all goes well, the user's requested actions are performed on the target devices. The entire deployment happens, typically within the span of a few seconds after the user's input. After execution, the new bundle can remain in the system to listen for any events or simply be idle. In a more advanced implementation, one might uninstall the bundle after use to save resources, but that is a design choice; in this thesis implementation, bundles remain deployed, and their presence is harmless as they only act when triggered by their activation and then effectively go dormant. 4. Contextual Reasoning and Decision-Making: Beyond simply executing commands, the orchestrator exhibits a degree of intelligence in decision-making to handle edge cases and optimise performance.