The application should allow remote management of smart home devices, i.e., a smart home equipped with various devices, such as gas sensors, remotely controlled refrigerators, ovens, security cameras with PTZ option, bubblers, etc. Each device may come in several variants that differ slightly, and each of them can appear in a certain (limited) number of instances. The home does not currently support building complex systems, but allows the user only to control individual devices and read their status.
- Each smart home device is represented as an object/service on the server side. The way it integrates and communicates with the real device is not the subject of this project. Devices may run on multiple server instances (demonstration: on at least two servers).
- When designing the device interface, use more complex types than just string/int/long where applicable. Remember to declare and signal exceptions (or errors) wherever relevant.
- It is sufficient to support two or three types of devices, each of which may have two or three subtypes.
- Recreate the listed features of the chosen technology in a way that best leverages its support for building such an application, aiming for the simplest solution possible (if a feature cannot be achieved simply, you must justify design decisions).
- The set of devices must remain unchanged during the server's lifetime (adding new devices may require server code modification and process restart). The application may be compiled with different supported device types.
- The initial set of device instances should be specified in the server-side configuration file.
- The client application should allow switching between different devices without restarting to control another device.
- The server must provide functionality to retrieve the list (of identifiers) of currently available device instances.
- Any technology is allowed. If using ICE, each smart home device should be implemented as a separate middleware object, accessible by its unique identity (e.g., "Joe").
- If using Thrift or gRPC, minimize the number of exported service instances (but avoid extremes – e.g., fridge and bubbler must not share the same interface!).
- Use two different languages (one for the client, one for the server).