IoT & Web : Créez un moniteur de feux tricolores avec Zephyr OS, Next.js et WebSocket

In a world where IoT and web are increasingly converging, the ability to create real-time monitoring interfaces is becoming crucial. Through this practical tutorial, we will explore creating a complete traffic light monitoring system, combining the power of Zephyr OS for IoT with modern web technologies. This project will serve as a concrete example to understand the challenges and solutions of real-time IoT monitoring.

Note: As a Zephyr OS expert, I am available to support you in your IoT development projects. Feel free to contact me by email or on LinkedIn or via GitHub for any questions about Zephyr OS or to discuss your embedded development needs.

The complete source code for this project is available on GitHub.

Article Outline

1. Project Overview

   • Global architecture
   • Technologies used
   • Learning objectives

2. IoT Part: Traffic Light Controller

   • Introduction to Zephyr OS
   • Controller implementation in C++
   • Server communication

3. Backend: Servers and Communication

   • HTTP API with Bun
   • WebSocket server for real-time
   • State management with Redis

4. Frontend: Monitoring Interface

   • Building with Next.js 15
   • Real-time React components
   • State and updates management

5. Infrastructure and Deployment

   • Docker configuration
   • Development scripts
   • Production deployment

6. Going Further

   • Tests and Quality
   • Monitoring and Observability
   • Functional Improvements

Introduction

Real-time monitoring of IoT devices presents unique challenges, from state management to bidirectional communication. Our connected traffic lights project perfectly illustrates these issues: how to ensure reliable synchronization between physical devices and a web interface while maintaining optimal performance?

Project Objectives

This educational project aims to:

• Demonstrate integration between IoT and modern web technologies
• Explore real-time communication patterns
• Put into practice full-stack development best practices
• Understand IoT supervision challenges

Global Architecture

Our system is built around four main components:

1. IoT Controller: Developed with Zephyr OS in C++, it simulates a traffic light controller
2. API Gateway: HTTP server for controller communication
3. WebSocket Server: Ensures real-time distribution of state changes
4. Web Interface: Next.js application for visualization and control

Important note about simulation: In this project, we simulate the IoT device in a Docker container for educational purposes. The controller simply logs state changes. In a real deployment, this controller would be installed on an actual IoT device (like a Raspberry Pi Pico) and would physically control traffic lights via its GPIO.

Example with Raspberry Pi Pico

The Raspberry Pi Pico is an excellent choice for implementing this project in real conditions because:

• It officially supports Zephyr OS
• It has GPIO to control the traffic light LEDs
• It can be connected to the network via various long-range communication modules (LoRaWAN, NB-IoT, LTE-M) suitable for outdoor deployments
• Its cost is very affordable (around €5)

To move from our simulation to a real deployment, you would need to:

1. Replace logs with GPIO commands
2. Adapt network configuration for WiFi or long-range communication modules (LoRaWAN, NB-IoT, LTE-M) depending on deployment context
3. Manage power supply and resilience
4. Add protective casing

1. Project Overview

Global Architecture

Our traffic light monitoring system relies on a modern distributed architecture, designed to ensure reliable real-time communication between IoT devices and the user interface.

Data Flow

1. IoT Level

   • Traffic light controllers, based on Zephyr OS, manage light states
   • In our implementation, state changes are transmitted via HTTP to the API Gateway, but other protocols could have been used:
     • MQTT for lighter and optimized IoT communication
     • CoAP for constrained networks
     • LoRaWAN for long-range communication
     • gRPC for increased performance
   • Controllers maintain a robust connection with the server

2. Backend Level

   • API Gateway receives updates and stores them in Redis
   • Redis acts as a centralized state store
   • WebSocket server subscribes to Redis events
   • Changes are broadcast in real-time to connected clients

3. Frontend Level

   • Next.js application establishes WebSocket connection
   • React components update automatically
   • Interface displays real-time light states

Technologies Used

IoT Side

cpp

Backend and Communication

typescript

Frontend

typescript

Learning Objectives

This project has been designed to cover several essential aspects of modern IoT and web development:

1. Embedded Programming

• Using Zephyr OS for IoT development
• State and transition management in C++
• Network communication from an embedded device

2. Distributed Architecture

• Communication between heterogeneous systems
• Distributed state management with Redis
• Real-time messaging patterns

3. Modern Web Development

• Hexagonal architecture with Next.js
• Performant React components
• TypeScript and strong typing

4. DevOps and Infrastructure

• Containerization with Docker
• Automation scripts
• Monitoring and logging

In the following sections, we'll explore in detail each component of the system, starting with the IoT controller based on Zephyr OS.

2. IoT Part: Traffic Light Controller

Introduction to Zephyr OS

Zephyr OS is an open-source real-time operating system (RTOS), particularly suited for embedded and IoT systems. In our project, it offers several key advantages:

• Real-time management: Perfect for precise traffic light control
• Robust network stack: Native TCP/IP protocol support
• Reduced memory footprint: Ideal for constrained devices
• Modern C++ support: Enables object-oriented programming

Controller Implementation

Our traffic light controller is implemented in modern C++, using Zephyr OS features for efficient state management and communication.

Code Structure

cpp

State Management

cpp

Server Communication

Communication with the backend server is handled by a dedicated class using Zephyr's HTTP API.

HTTP Client

cpp

Logging and Monitoring

cpp

Traffic Light Management Algorithm

The algorithm implemented in main.cpp manages the traffic light cycle in a safe and coordinated manner. We opted for a simple and demonstrative implementation that could be enhanced for more complex use cases.

1. System Initialization

   cpp

2. Main Cycle

   • The system alternates between North-South and East-West axes
   • Each cycle includes three phases:
     1. Green (30 seconds)
     2. Yellow (5 seconds)
     3. Red with safety delay (2 seconds)

3. State Change Management

   cpp

4. Asynchronous Communication

   • A dedicated thread handles HTTP state change sending
   • Events are queued via k_msgq
   • HTTP thread processes them asynchronously

5. Safety and Robustness

   • Safety delay between axis changes
   • Communication error handling
   • Event logging for monitoring

Improvement Paths

This basic implementation could be enhanced with:

1. Customizable Scenarios

   • Time-based duration configuration
   • Special modes (night, emergency, events)
   • Real-time traffic adaptation

2. Advanced Traffic Management

   • Vehicle presence detection
   • Public transport priority
   • Intersection synchronization

3. Dynamic Configuration

   • Remote parameter interface
   • On-the-fly scenario changes
   • Traffic pattern machine learning

To implement these improvements, we would need to:

• Add an abstraction layer for scenarios
• Implement a dynamic configuration system
• Integrate sensors and complex business rules
• Develop a more complete control API

This simple version remains perfectly suited to demonstrate basic IoT and real-time communication concepts.

Project Configuration

The prj.conf file configures Zephyr OS features for our project. This configuration enables:

• C++ and C++17 standard support to use modern language features
• Network capabilities with IPv4 and TCP for server communication
• Sockets and HTTP client to send state updates
• Logging system for debugging and monitoring

These options are essential for our IoT controller to communicate over the network and send traffic light state changes to the central server.

conf

Optimized Compilation with Zephyr OS

Unlike traditional operating systems like Linux that include many default modules and drivers, Zephyr OS uses a minimalist and highly configurable approach. During compilation, only strictly necessary components are included in the final image:

1. Difference from Traditional OS

   • A classic embedded Linux is several hundred MB
   • It includes many unused drivers and services
   • Startup loads many superfluous components
   • Attack surface is larger

2. Zephyr Approach Advantages

   • Final image is only a few hundred KB
   • Only configured drivers and protocols are included
   • Startup is nearly instantaneous
   • Attack surface is minimal

3. Granular Configuration

   • Each feature is a Kconfig module
   • Dependencies are automatically resolved
   • Optimization is maximized
   • Resources are statically allocated

This "from scratch" approach allows obtaining a highly optimized and secure system, perfectly adapted to IoT constraints:

• Limited resources (RAM/Flash)
• Minimal energy consumption
• Fast startup
• Reduced attack surface

Compilation and Deployment

The project uses CMake for compilation:

cmake

This IoT implementation illustrates several advanced concepts:

1. Event-Driven Programming

   • Use of message queues for inter-thread communication
   • Timers for state transition management

2. Resource Management

   • Efficient memory usage
   • Network connection management

3. Robustness

   • Detailed event logging
   • Communication error handling
   • Automatic reconnection

In the next section, we'll see how the backend handles communication with these IoT controllers and distributes updates to web clients.

3. Backend: Servers and Communication

Our backend consists of several services working together to ensure smooth communication between IoT controllers and the web interface.

API Gateway with Bun

The API Gateway is the entry point for IoT controllers. Implemented with Bun for its exceptional performance, it handles HTTP requests and maintains state consistency.

Request Management

typescript

WebSocket Server

The WebSocket server ensures real-time distribution of updates to connected web clients.

Server Implementation

typescript

State Management with Redis

Redis plays a central role in our architecture, serving both as a message broker and state store.

Redis Configuration

yaml

Redis Subscriber

typescript

Communication Architecture

Our backend implements several essential communication patterns:

1. Pub/Sub Pattern

   • Redis as message broker
   • Decoupling of producers and consumers
   • Efficient update distribution

2. Gateway Pattern

   • Single entry point for IoT devices
   • Data validation and transformation
   • Centralized error handling

3. Observer Pattern

   • Real-time change notification
   • WebSocket connection maintenance
   • Update distribution to clients

Security and Performance

Several measures are in place to ensure security and performance:

1. Security

   • Input data validation
   • Configured CORS headers
   • Network isolation with Docker

2. Performance

   • Using Bun for optimal performance
   • Persistent Redis connections
   • Efficient WebSocket management

3. Reliability

   • Event logging
   • Robust error handling
   • Automatic service reconnection

In the next section, we'll explore the user interface developed with Next.js that allows visualization and interaction with our traffic light system.

4. Frontend: Monitoring Interface

Our system's user interface is built with Next.js 15, following modern development best practices and a hexagonal architecture.

Frontend Architecture

Our application follows a hexagonal architecture (ports and adapters) to maintain a clear separation of concerns:

typescript

Adapter Implementation

The adapter handles communication with the backend via WebSocket:

typescript

React Components

Main Page

typescript

Traffic Light Component

typescript

Styles and Configuration

Tailwind Configuration

typescript

Optimizations and Best Practices

1. Performance

   • Use of React Server Components
   • Render optimization
   • Lazy loading of non-critical components

2. Accessibility

   • Keyboard support
   • Appropriate ARIA attributes
   • Optimized color contrast

3. Maintainability

   • Hexagonal architecture
   • Strict typing with TypeScript
   • Automated testing

In the next section, we'll cover the infrastructure and deployment of our application.

5. Infrastructure and Deployment

Our system uses Docker to ensure consistent and reproducible deployment across all environments.

Docker Configuration

Service Composition

yaml

Development Scripts

Service Management Script

shell

Development Environment Configuration

Docker Image for Zephyr

dockerfile

Support Services

Docker Services Script

shell

Dependency Management

Next.js Configuration

json

Deployment Best Practices

1. Secret Management

   • Use of environment variables
   • Separation of configurations by environment
   • Secure secret storage

2. Monitoring

   • Centralized logging
   • Performance metrics
   • Automated alerts

3. Security

   • Network isolation
   • Regular dependency updates
   • Vulnerability scanning

In the final section, we'll discuss testing strategies and monitoring of our application.

6. Going Further

To make this project more robust and production-ready, several improvement areas can be explored:

1. Tests and Quality

To ensure system reliability, we should implement:

IoT Controller Tests

• Unit tests for traffic light state machine
• Network integration tests
• Error condition simulation
• Light sequence validation

Frontend Tests

• React component tests with Jest and Testing Library
• End-to-end tests with Cypress or Playwright
• Performance tests with Lighthouse
• Accessibility validation

2. Monitoring and Observability

For effective production monitoring, we should add:

1. Performance

   • Integration with Prometheus/Grafana
   • Detailed WebSocket metrics
   • IoT resource monitoring

2. Reliability

   • Controller heartbeat system
   • Automatic anomaly detection
   • Automatic state backup

3. Security

   • Controller authentication
   • Communication encryption
   • Access auditing

3. Functional Improvements

The system could be enhanced with:

1. Advanced Interface

   • Maintenance mode
   • State change history
   • Customizable dashboards

2. Scenario Management

   • Time-based scheduling
   • Special modes (emergency, events)
   • External integration API

3. Scalability

   • Multi-intersection support
   • Intersection synchronization
   • Load balancing

4. Energy Optimization for Battery Deployment

For projects requiring energy autonomy (isolated sites, areas without mains power), several optimizations would be necessary:

1. Power Modes

   • Normal mode for standard operation
   • Eco mode for energy saving during quiet days
   • Night mode with reduced brightness
   • Emergency mode for low battery

cpp

2. Energy Saving Strategies

   • CPU sleep between state changes
   • Network transmission grouping
   • Dynamic LED brightness adjustment

cpp

3. Solar Power

   • Appropriate panel sizing
   • LiFePO4 batteries for longevity
   • Backup system

4. Battery Monitoring

cpp

For successful deployment, it is recommended to:

• Continuously monitor battery health
• Plan preventive replacements
• Regularly clean solar panels
• Implement degraded modes for low battery
• Provide backup signaling

Conclusion

This project demonstrates the successful integration of IoT and modern web technologies to create a real-time monitoring system. Key takeaways include:

1. Distributed Architecture

   • Clear separation of responsibilities
   • Efficient component communication
   • Scalability and maintainability

2. Modern Technologies

   • Zephyr OS for IoT
   • Next.js for frontend
   • WebSocket for real-time

3. Best Practices

   • Automated testing
   • Complete monitoring
   • Detailed documentation

This project can serve as a foundation for developing more complex IoT applications by adapting the architecture and patterns used according to your specific needs.

Putting into Practice

To get the most out of this tutorial and develop your own IoT projects, here are some practical exercise suggestions:

1. Start Small

1. Simplified Version

   • First create a single traffic light
   • Use a simple HTTP server without WebSocket
   • Display the state in a basic web page

2. IoT Simulation

   • Start without physical hardware
   • Simulate the controller with a Node.js script
   • Test communication logic

2. Progressive Evolution

1. Add WebSockets

   • Implement real-time updates
   • Handle automatic reconnection
   • Add logs to understand the flow

2. Integrate Redis

   • First store simple states
   • Add data persistence
   • Implement pub/sub patterns

3. Project Variations

Here are some ideas to create your own version:

1. Other Use Cases

   • Temperature/humidity monitor
   • Smart lighting system
   • Automatic watering control

2. Alternative Technologies

   • Replace Zephyr OS with ESP32/Arduino
   • Use MQTT instead of WebSockets
   • ...

4. Additional Resources

To deepen your understanding of each aspect:

1. Official Documentation

   • Zephyr OS Getting Started
   • Next.js Documentation
   • Redis Pub/Sub Guide

2. Example Repositories

   • Zephyr OS Samples
   • Next.js Examples
   • Redis WebSocket Examples

3. Communities

   • Discord Zephyr
   • Forum Next.js
   • Reddit r/IOT

1CONFIG_CPP=y
2CONFIG_STD_CPP17=y
3CONFIG_NETWORKING=y
4CONFIG_NET_IPV4=y
5CONFIG_NET_TCP=y
6CONFIG_NET_SOCKETS=y
7CONFIG_HTTP_CLIENT=y
8CONFIG_LOG=y

1// WebSocket Server with Bun
2const wsServer = new WebSocketServer({ port: 8001 });
3
4// Redis event subscription
5subscriber.subscribe('traffic-lights', (message) => {
6  wsConnections.forEach((ws) => {
7    ws.send(JSON.stringify(JSON.parse(message)));
8  });
9});

1// Next.js component with WebSocket
2export function Intersection() {
3  const [lights, setLights] = useState<TrafficLightState[]>([]);
4
5  useEffect(() => {
6    const adapter = new TrafficLightAdapter();
7    return adapter.subscribeToUpdates((state) => {
8      setLights(prev => prev.map(light =>
9        light.id === state.id ? { ...light, state: state.state } : light
10      ));
11    });
12  }, []);
13
14  return (/* Traffic lights rendering */);
15}

1async fetch(req: Request) {
2  const url = new URL(req.url);
3
4  // CORS headers for all responses
5  const corsHeaders = {
6    "Access-Control-Allow-Origin": "*",
7    "Access-Control-Allow-Methods": "GET, POST, OPTIONS",
8    "Access-Control-Allow-Headers": "Content-Type",
9  };
10
11  // Route to receive traffic light updates
12  if (req.method === "POST" && url.pathname === "/traffic-light") {
13    try {
14      const data = await req.json();
15      const { id, state } = data;
16
17      // State validation
18      const validStates = ["red", "yellow", "green"];
19      if (!validStates.includes(state)) {
20        return new Response("Invalid state", {
21          status: 400,
22          headers: corsHeaders
23        });
24      }
25
26      // Publish state to Redis
27      await redis.publish("traffic-lights", JSON.stringify({ id, state }));
28      // Store current state
29      await redis.set(`traffic-light:${id}`, state);
30
31      return new Response(JSON.stringify({ success: true }), {
32        headers: {
33          ...corsHeaders,
34          "Content-Type": "application/json"
35        }
36      });
37    } catch (error) {
38      console.error("Error:", error);
39      return new Response(JSON.stringify({ error: error.message }), {
40        status: 500,
41        headers: corsHeaders
42      });
43    }
44  }
45}

1const subscriber = redis.duplicate();
2await subscriber.connect();
3
4await subscriber.subscribe("traffic-lights", (message) => {
5  try {
6    const data = JSON.parse(message);
7    console.log("New traffic light change:", data);
8
9    wsConnections.forEach((ws) => {
10      ws.send(JSON.stringify(data));
11    });
12  } catch (err) {
13    console.error("Error parsing message:", err);
14  }
15});

1services:
2  redis:
3    image: redis:latest
4    ports:
5      - "6379:6379"
6    volumes:
7      - redis-data:/data
8    command: redis-server --appendonly yes
9    networks:
10      zephyr-net:
11        ipv4_address: 10.5.0.3

1async function main() {
2    const redis = createClient({
3        url: "redis://localhost:6379"
4    });
5
6    redis.on("error", err => console.error("Redis Error:", err));
7    redis.on("connect", () => console.log("Connected to Redis"));
8
9    await redis.connect();
10
11    const subscriber = redis.duplicate();
12    await subscriber.connect();
13
14    await subscriber.subscribe("traffic-lights", (message) => {
15        try {
16            const data = JSON.parse(message);
17            console.log("New traffic light change:", data);
18        } catch (err) {
19            console.error("Error parsing message:", err);
20        }
21    });
22}

1export interface TrafficLightState {
2  id: string;
3  state: "red" | "yellow" | "green";
4}
5
6export interface TrafficLightPort {
7  getInitialStates(): Promise<TrafficLightState[]>;
8  subscribeToUpdates(callback: (state: TrafficLightState) => void): () => void;
9}

1export class TrafficLightAdapter implements TrafficLightPort {
2  async getInitialStates(): Promise<TrafficLightState[]> {
3    try {
4      const responses = await Promise.all(
5        ["North", "South", "East", "West"].map((id) =>
6          fetch(`${API_URL}/traffic-light/${id}`).then((res) => res.json())
7        )
8      );
9
10      return responses.map((response) => ({
11        id: response.id,
12        state: response.state,
13      }));
14    } catch (error) {
15      console.error("Error retrieving states:", error);
16      return [
17        { id: "North", state: "red" },
18        { id: "South", state: "red" },
19        { id: "East", state: "red" },
20        { id: "West", state: "red" },
21      ];
22    }
23  }
24
25  subscribeToUpdates(callback: (state: TrafficLightState) => void): () => void {
26    const ws = new WebSocket(WS_URL);
27
28    ws.onmessage = (event) => {
29      try {
30        const data = JSON.parse(event.data);
31        callback(data);
32      } catch (error) {
33        console.error("Error processing WebSocket message:", error);
34      }
35    };
36
37    return () => ws.close();
38  }
39}

1import { Intersection } from "@/interfaces/components/traffic-lights/intersection";
2
3export default function Home() {
4  return (
5    <div className="min-h-screen flex flex-col items-center justify-center p-8">
6      <h1 className="text-2xl font-bold mb-8">Traffic Light Monitor</h1>
7      <Intersection />
8    </div>
9  );
10}

1"use client";
2
3interface TrafficLightProps extends TrafficLightState {
4  orientation?: "vertical" | "horizontal";
5}
6
7export function TrafficLight({
8  id,
9  state,
10  orientation = "vertical",
11}: TrafficLightProps) {
12  const lights = ["red", "yellow", "green"];
13
14  return (
15    <div className="flex flex-col gap-2 items-center">
16      <h3 className="text-sm font-semibold">{id}</h3>
17      <div
18        className={`bg-gray-800 p-2 rounded-lg flex ${
19          orientation === "horizontal" ? "flex-row" : "flex-col"
20        } gap-2`}
21      >
22        {lights.map((light) => (
23          <div
24            key={light}
25            className={`w-8 h-8 rounded-full ${
26              state === light
27                ? {
28                    red: "bg-red-500",
29                    yellow: "bg-yellow-500",
30                    green: "bg-green-500",
31                  }[light]
32                : "bg-gray-700"
33            }`}
34          />
35        ))}
36      </div>
37    </div>
38  );
39}

1export default {
2  content: [
3    "./src/pages/**/*.{js,ts,jsx,tsx,mdx}",
4    "./src/components/**/*.{js,ts,jsx,tsx,mdx}",
5    "./src/app/**/*.{js,ts,jsx,tsx,mdx}",
6    "./src/interfaces/**/*.{js,ts,jsx,tsx,mdx}",
7  ],
8  theme: {
9    extend: {
10      colors: {
11        background: "var(--background)",
12        foreground: "var(--foreground)",
13      },
14      borderSpacing: {
15        'road': '16px'
16      },
17      backgroundImage: {
18        'dashed-white': 'repeating-linear-gradient(90deg, white 0 12px, transparent 12px 32px)',
19        'dashed-white-vertical': 'repeating-linear-gradient(0deg, white 0 12px, transparent 12px 32px)',
20      }
21    },
22  },
23  plugins: [],
24}

1services:
2  traffic-lights-monitor:
3    image: oven/bun:latest
4    working_dir: /traffic-lights-monitor
5    volumes:
6      - ./traffic-lights-monitor/:/traffic-lights-monitor
7    command: sh -c "bun install && bun run build && bun run start"
8    ports:
9      - "3000:3000"
10    environment:
11      - NEXT_PUBLIC_API_URL=http://zephyr-dev:8000
12      - NEXT_PUBLIC_WS_URL=ws://localhost:8001
13    networks:
14      zephyr-net:
15        ipv4_address: 10.5.0.5
16
17  redis:
18    image: redis:latest
19    ports:
20      - "6379:6379"
21    volumes:
22      - redis-data:/data
23    command: redis-server --appendonly yes
24    networks:
25      zephyr-net:
26        ipv4_address: 10.5.0.3
27
28volumes:
29  redis-data:
30
31networks:
32  zephyr-net:
33    driver: bridge
34    ipam:
35      config:
36        - subnet: 10.5.0.0/24

1#!/bin/bash
2
3# Colors for messages
4RED='\033[0;31m'
5GREEN='\033[0;32m'
6YELLOW='\033[1;33m'
7NC='\033[0m'
8
9# Function to check if containers are running
10check_containers() {
11    if ! docker compose ps --quiet &>/dev/null; then
12        echo -e "${RED}Containers are not running.${NC}"
13        echo -e "${YELLOW}Starting containers...${NC}"
14        docker compose up -d
15    fi
16}
17
18# Function to start containers
19up() {
20    echo -e "${YELLOW}Building Docker image if needed...${NC}"
21    docker compose build
22    echo -e "${YELLOW}Starting containers...${NC}"
23    docker compose up -d
24    echo -e "${GREEN}Containers started successfully${NC}"
25}
26
27# Function to stop containers
28down() {
29    echo -e "${YELLOW}Stopping containers...${NC}"
30    docker compose down
31    echo -e "${GREEN}Containers stopped successfully${NC}"
32}

1FROM ghcr.io/zephyrproject-rtos/zephyr-build:latest
2
3USER root
4
5RUN apt-get update
6RUN apt-get install -y \
7    net-tools \
8    uml-utilities \
9    bridge-utils \
10    nftables
11
12RUN apt-get install -y qemu-system-x86
13RUN apt-get install -y iputils-ping curl
14RUN apt-get install -y --no-install-recommends git cmake ninja-build gperf \
15    ccache dfu-util device-tree-compiler wget \
16    python3-dev python3-pip python3-setuptools python3-tk python3-wheel xz-utils file \
17    make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1
18
19RUN west init -m https://github.com/zephyrproject-rtos/zephyr --mr main .
20RUN west update
21RUN west zephyr-export
22
23RUN cd /workdir/tools/net-tools && make
24
25RUN curl -fsSL https://bun.sh/install | bash
26ENV PATH="/root/.bun/bin:${PATH}"
27
28COPY gateway-http-server-redis /gateway-http-server-redis
29RUN cd /gateway-http-server-redis && bun install
30
31EXPOSE 8000
32
33USER root

1#!/bin/bash
2
3/workdir/tools/net-tools/loop-socat.sh & > /dev/null 2>&1
4/workdir/tools/net-tools/loop-slip-tap.sh & > /dev/null 2>&1
5cd /gateway-http-server-redis && bun run main.ts
6/bin/bash

1{
2  "name": "traffic-lights-monitor",
3  "version": "0.1.0",
4  "private": true,
5  "scripts": {
6    "dev": "next dev --turbopack",
7    "build": "next build",
8    "start": "next start",
9    "lint": "next lint"
10  },
11  "dependencies": {
12    "react": "^19.0.0",
13    "react-dom": "^19.0.0",
14    "next": "15.1.3"
15  },
16  "devDependencies": {
17    "typescript": "^5.7.2",
18    "@types/node": "^22.10.2",
19    "@types/react": "^19.0.2",
20    "@types/react-dom": "^19.0.2",
21    "postcss": "^8.4.49",
22    "tailwindcss": "^3.4.17",
23    "eslint": "^9.17.0"
24  }
25}

1cmake_minimum_required(VERSION 3.20.0)
2
3set(CONF_FILE "prj.conf")
4set(BOARD qemu_x86)
5
6enable_language(C CXX)
7set(CMAKE_CXX_STANDARD 17)
8
9find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
10project(traffic-lights-orcherstrator)
11
12target_sources(app PRIVATE
13    src/main.cpp
14    src/logger.cpp
15    src/http_client.cpp
16)

1// Zephyr OS code example
2void change_traffic_light_state(const char* id, const char* state) {
3    // Send state via HTTP
4    http_client.send_traffic_light_state(id, state);
5    // Event logging
6    LOG_INF("Traffic light %s: %s", id, state);
7}

1enum class LightState
2{
3    RED,
4    YELLOW,
5    GREEN
6};
7
8struct TrafficLight
9{
10    const char *name;
11    LightState state;
12    k_timer timer;
13};
14
15struct StateChangeEvent
16{
17    int light_index;
18    LightState new_state;
19};

1void change_axis_state(int light1_index, int light2_index, LightState new_state, uint32_t duration_ms)
2{
3    StateChangeEvent evt1 = {light1_index, new_state};
4    StateChangeEvent evt2 = {light2_index, new_state};
5
6    k_msgq_put(&state_change_queue, &evt1, K_NO_WAIT);
7    k_msgq_put(&state_change_queue, &evt2, K_NO_WAIT);
8
9    if (duration_ms > 0)
10    {
11        k_timer_start(&lights[light1_index].timer, K_MSEC(duration_ms), K_NO_WAIT);
12        k_timer_start(&lights[light2_index].timer, K_MSEC(duration_ms), K_NO_WAIT);
13    }
14}

1void HttpClient::send_traffic_light_state(const char *id, const char *state)
2{
3    // HTTP request preparation
4    struct http_request req;
5    memset(&req, 0, sizeof(req));
6
7    const char *headers[] = {
8        "Content-Type: application/json\r\n",
9        content_len,
10        NULL
11    };
12
13    req.method = HTTP_POST;
14    req.url = "/traffic-light";
15    req.host = SERVER_ADDR;
16    req.protocol = "HTTP/1.1";
17    req.header_fields = headers;
18    req.payload = payload;
19    req.payload_len = strlen(payload);
20}

1#include <zephyr/logging/log.h>
2
3LOG_MODULE_REGISTER(traffic_lights, LOG_LEVEL_INF);
4
5void log_light_state(const char *name, const char *state)
6{
7    LOG_INF("Traffic light %s: %s", name, state);
8}

1void init_traffic_system() {
2    // Timer initialization for each light
3    for (auto &light : lights) {
4        k_timer_init(&light.timer, timer_expiry_callback, nullptr);
5    }
6    // HTTP thread creation for communication
7    http_thread_id = k_thread_create(&http_thread_data, ...);
8}

1void change_axis_state(int light1_index, int light2_index,
2                      LightState new_state, uint32_t duration_ms) {
3    // Send state change events
4    StateChangeEvent evt1 = {light1_index, new_state};
5    StateChangeEvent evt2 = {light2_index, new_state};
6
7    // Timer programming if duration is specified
8    if (duration_ms > 0) {
9        k_timer_start(&lights[light1_index].timer, ...);
10        k_timer_start(&lights[light2_index].timer, ...);
11    }
12}

1enum class PowerMode {
2    NORMAL,     // Standard operation
3    ECO,        // Energy saving mode
4    NIGHT,      // Night mode
5    EMERGENCY   // Emergency mode (low battery)
6};

1void enter_low_power_mode() {
2    // CPU frequency reduction
3    pm_device_action_run(cpu_dev, PM_DEVICE_ACTION_RESUME);
4
5    // Timer wake-up configuration
6    k_timer_start(&wakeup_timer, K_SECONDS(state_duration), K_NO_WAIT);
7
8    // Enter sleep mode
9    k_sleep(K_FOREVER);
10}

1struct PowerMetrics {
2    float battery_voltage;
3    float current_draw;
4    float temperature;
5    uint32_t uptime;
6};
7
8PowerMetrics getCurrentMetrics() {
9    PowerMetrics metrics;
10    metrics.battery_voltage = adc_read_battery();
11    metrics.current_draw = adc_read_current();
12    metrics.temperature = read_temperature();
13    metrics.uptime = k_uptime_get();
14    return metrics;
15}