README.md

OwnLightSystem

Introduction

OwnLightSystem is a scalable and modular smart lighting control system designed to manage and monitor various lighting devices within a smart home environment. Leveraging a microservices architecture, OwnLightSystem ensures flexibility, ease of maintenance, and the ability to seamlessly integrate new devices and functionalities.

Table of Contents

1. Architecture Overview
2. Summary
3. Microservices Design
   • DeviceService
   • UserService
   • AutomationService
   • EnergyService
4. Integration Between Microservices
   • Communication
   • API Gateway (Ocelot)
5. Modularity and Scalability
   • Code Modularity
   • Database Modularity
6. Database Structure Examples
   • DeviceService Database
   • UserService Database
   • AutomationService Database
   • EnergyService Database (NoSQL)
7. Getting Started
   • Prerequisites
   • Installation
   • Running with Docker
8. Usage
   • Register a New User
   • Add a New Device
   • Monitor Energy Usage
9. Roadmap
10. Contributing
11. Acknowledgements
12. Changelog
13. FAQ
14. License
15. Contact
16. Security
17. Code of Conduct
18. References
19. Additional Resources
20. Documentation

Architecture Overview

OwnLightSystem employs a microservices architecture to ensure scalability, modularity, and ease of maintenance. Each microservice is responsible for a specific domain, allowing independent development and deployment. The system integrates both SQL and NoSQL databases to leverage the strengths of each for different service requirements.

Summary

• Microservices: Comprises DeviceService, UserService, AutomationService, and EnergyService.
• Databases: Each service uses its own database, leveraging SQL and NoSQL where appropriate.
• Modularity: Achieved through code and database design, facilitating the addition of new devices and features.
• API Gateway: Utilizes Ocelot for routing, aggregation, and security.
• Scalability: Designed to handle increasing loads and expand functionalities seamlessly.

Microservices Design

DeviceService

Responsibilities:

• Registering and controlling devices (e.g., turning on/off).

Database:

• Relational or NoSQL, based on scalability and data structure needs.

Example Tables:

• Devices
• DeviceActions
• DeviceTypes

Modularity:

• Supports adding new device types via device type tables or design patterns like the Strategy Pattern for actions.

UserService

Responsibilities:

• User registration, login, and authentication.

Database:

• Relational (SQL), such as PostgreSQL.

Example Tables:

• Users
• RefreshTokens

Modularity:

• Utilizes Identity and JWT patterns to facilitate new authentication methods and access control.

AutomationService

Responsibilities:

• Managing routines, rooms, and groups.

Database:

• Relational (SQL) or NoSQL, depending on query and scalability requirements.

Example Tables:

• Schedules
• Rooms
• Groups
• ScheduleActions (associates actions with routines)

Modularity:

• Employs event-driven patterns or flexible configuration approaches to allow dynamic creation and removal of rooms and groups.

EnergyService

Responsibilities:

• Monitoring energy usage of devices, rooms, and groups.

Database:

• NoSQL (e.g., MongoDB) for high scalability and flexible queries.

Example Collections:

• EnergyUsageDevices
• EnergyUsageRooms
• EnergyUsageGroups

Modularity:

• Designed with a flexible schema to accommodate new data types and metrics.

Integration Between Microservices

Communication

• Synchronous: Utilizes REST APIs or gRPC for real-time interactions.
• Asynchronous: Employs message brokers like RabbitMQ or Kafka for event-driven communication.

API Gateway (Ocelot)

Functions:

• Routing: Directs requests to the appropriate microservice.
• Aggregation: Combines responses from multiple microservices into a single response.
• Security: Implements centralized authentication and authorization.

Configuration Example:

{
  "ReRoutes": [
     {
        "DownstreamPathTemplate": "/api/devices/{everything}",
        "DownstreamScheme": "http",
        "DownstreamHostAndPorts": [
          {
             "Host": "device-service",
             "Port": 80
          }
        ],
        "UpstreamPathTemplate": "/devices/{everything}",
        "UpstreamHttpMethod": [ "Get", "Post" ]
     },
     {
        "DownstreamPathTemplate": "/api/users/{everything}",
        "DownstreamScheme": "http",
        "DownstreamHostAndPorts": [
          {
             "Host": "user-service",
             "Port": 80
          }
        ],
        "UpstreamPathTemplate": "/users/{everything}",
        "UpstreamHttpMethod": [ "Get", "Post" ]
     }
  ],
  "GlobalConfiguration": {
     "BaseUrl": "http://localhost:5000"
  }
}

Modularity and Scalability

Code Modularity

• Event-Driven Design: Allows the addition of new devices and actions without altering existing services.
• Design Patterns: Implements patterns like the Strategy Pattern for device actions and Factory Pattern for creating new device types.

Database Modularity

• Flexible Schemas: Utilizes database schemas that support extensibility, such as device type tables.
• NoSQL for Flexibility: Employs NoSQL databases like MongoDB to handle dynamic schemas and data structures.

Database Structure Examples

DeviceService Database

CREATE TABLE Devices (
    Id SERIAL PRIMARY KEY,
    Name VARCHAR(255) NOT NULL,
    TypeId INT NOT NULL,
    FOREIGN KEY (TypeId) REFERENCES DeviceTypes(Id)
);

CREATE TABLE DeviceTypes (
    Id SERIAL PRIMARY KEY,
    Name VARCHAR(255) NOT NULL
);

CREATE TABLE DeviceActions (
    Id SERIAL PRIMARY KEY,
    DeviceId INT NOT NULL,
    ActionType VARCHAR(255) NOT NULL,
    FOREIGN KEY (DeviceId) REFERENCES Devices(Id)
);

UserService Database

CREATE TABLE Users (
    Id SERIAL PRIMARY KEY,
    Username VARCHAR(255) NOT NULL UNIQUE,
    PasswordHash TEXT NOT NULL,
    Email VARCHAR(255) NOT NULL UNIQUE
);

CREATE TABLE RefreshTokens (
    TokenId SERIAL PRIMARY KEY,
    UserId INT NOT NULL,
    Token TEXT NOT NULL,
    ExpirationDate TIMESTAMPTZ NOT NULL,
    FOREIGN KEY (UserId) REFERENCES Users(Id)
);

AutomationService Database

CREATE TABLE Schedules (
    Id SERIAL PRIMARY KEY,
    Name VARCHAR(255) NOT NULL
);

CREATE TABLE Rooms (
    Id SERIAL PRIMARY KEY,
    Name VARCHAR(255) NOT NULL
);

CREATE TABLE Groups (
    Id SERIAL PRIMARY KEY,
    Name VARCHAR(255) NOT NULL
);

CREATE TABLE ScheduleActions (
    Id SERIAL PRIMARY KEY,
    ScheduleId INT NOT NULL,
    ActionId INT NOT NULL,
    FOREIGN KEY (ScheduleId) REFERENCES Schedules(Id),
    FOREIGN KEY (ActionId) REFERENCES DeviceActions(Id)
);

EnergyService Database (NoSQL)

{
  "EnergyUsageDevices": [
    {
      "DeviceId": "device1",
      "Usage": 150,
      "Timestamp": "2024-09-08T17:42:29Z"
    }
  ],
  "EnergyUsageRooms": [
    {
      "RoomId": "room1",
      "Usage": 500,
      "Timestamp": "2024-09-08T17:42:29Z"
    }
  ],
  "EnergyUsageGroups": [
    {
      "GroupId": "group1",
      "Usage": 1000,
      "Timestamp": "2024-09-08T17:42:29Z"
    }
  ]
}

Getting Started

Follow these instructions to set up the OwnLightSystem project locally.

Prerequisites

• .NET 8.0 SDK or later
• PostgreSQL for relational databases
• MongoDB for NoSQL databases
• Docker (optional, for containerization)

Installation

1. Clone the repository:

   git clone https://github.com/Pocador999/OwnLightSystem.git
   cd OwnLightSystem

2. Set up the databases:

   • PostgreSQL: Create databases for each microservice.
   • MongoDB: Ensure MongoDB is running for the EnergyService.

3. Configure environment variables: Create a .env file in the root directory with necessary configurations.

   DEVICE_SERVICE_DB_CONNECTION=your_postgresql_connection_string
   USER_SERVICE_DB_CONNECTION=your_postgresql_connection_string
   AUTOMATION_SERVICE_DB_CONNECTION=your_postgresql_connection_string
   ENERGY_SERVICE_DB_CONNECTION=your_mongodb_connection_string

4. Run the microservices:

   cd DeviceService
   dotnet run
   cd ../UserService
   dotnet run
   # Repeat for other services

5. Start the API Gateway:

   cd ApiGateway
   dotnet run

Running with Docker

Alternatively, you can use Docker Compose to run all services:

docker-compose up --build

Usage

After setting up the project, you can interact with the APIs through the API Gateway.

Register a New User

• Endpoint:

  POST /users/register

• Request Body:

  {
    "username": "johndoe",
    "password": "SecurePassword123",
    "email": "[email protected]"
  }

• Response:

  {
    "id": 1,
    "username": "johndoe",
    "email": "[email protected]",
    "roles": ["User"]
  }

Add a New Device

• Endpoint:

  POST /devices

• Request Body:

  {
    "name": "Living Room Light",
    "typeId": 2
  }

• Response:

  {
    "id": 1,
    "name": "Living Room Light",
    "typeId": 2
  }

Monitor Energy Usage

• Endpoint:

  GET /energy/usage/devices

• Response:

  {
    "EnergyUsageDevices": [
      {
        "DeviceId": "device1",
        "Usage": 150,
        "Timestamp": "2024-09-08T17:42:29Z"
      }
    ]
  }

Roadmap

For detailed plans and future enhancements, please refer to our Roadmap.

Contributing

We welcome contributions from the community! To contribute, please follow these steps:

1. Fork the repository

2. Create a new branch:

   git checkout -b feature/YourFeature

3. Make your changes

4. Commit your changes:

   git commit -m "Add some feature"

5. Push to the branch:

   git push origin feature/YourFeature

6. Open a Pull Request

Please read our CONTRIBUTING.md for more details.

Acknowledgements

• Microservices.io for architectural guidance
• Ocelot for the API Gateway solution
• Domain-Driven Design principles by Eric Evans
• Open Source Contributors and the Developer Community

Changelog

All notable changes to this project will be documented in our CHANGELOG.md

• [1.0.0] - 2024-10-04
  • Initial release with DeviceService, UserService, AutomationService, and EnergyService in progress.
  • Implemented API Gateway using Ocelot.
  • Set up PostgreSQL and MongoDB databases.

FAQ

For answers to frequently asked questions, please see our FAQ.

License

This project is licensed under the MIT License.

Contact

For any questions or support, please reach out via:

• Email: [email protected]
• GitHub Issues: OwnLightSystem Issues

Security

If you discover any security vulnerabilities, please report them via email. We will address all issues promptly. For more details, refer to our Security Policy.

Code of Conduct

Please read our Code of Conduct to understand the standards we expect from contributors.

References

• Microsoft .NET Documentation
• Microservices Architecture
• Ocelot API Gateway
• Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans
• Design Patterns
• PostgreSQL Documentation
• MongoDB Documentation

Additional Resources

• Design Patterns (DDD)
• PostgreSQL Documentation
• MongoDB Documentation

Documentation

Comprehensive documentation is available in the docs directory, including:

• API Reference
• Deployment Guide
• Architecture Details