Base de données¶

Architecture de la base de données¶

L'architecture de la base de données de Diyae est conçue autour de deux tables centrales qui structurent l'ensemble du système : users et devices.

Concepteur base de données Diyae

Les tables principales¶

Users (Utilisateurs)¶

La table users représente les utilisateurs de l'application mobile. Chaque utilisateur possède :

Un compte personnel avec email et mot de passe hashé
Des paramètres de localisation (locale, timezone)
Plusieurs enceintes (relation many-to-many via device_members)
Un historique de connexion (last_login_at, email_verified_at)

Devices (Enceintes)¶

La table devices représente les enceintes connectées. Chaque enceinte contient :

Un identifiant unique (device_id) au format DY-XXXXXX
Des informations matérielles (modèle, version firmware, révision hardware)
Des informations réseau (IP locale, IP publique, WiFi)
Un statut (new, active, suspended, retired)
Méthode de provisioning (AP ou BLE)

DeviceMembers (Membres d'une enceinte)¶

La table device_members fait le lien entre les utilisateurs et les enceintes :

Relation many-to-many : un utilisateur peut avoir plusieurs enceintes, et une enceinte peut être partagée avec plusieurs utilisateurs
Propriétaire unique : chaque enceinte a un seul owner (flag owner = true)
Rôles : member (peut contrôler l'enceinte) ou viewer (lecture seule)

État et contrôle des enceintes¶

DeviceState (État actuel)¶

La table device_state stocke l'état en temps réel de chaque enceinte :

Statut de connexion (online)
Niveau de batterie (battery_pct)
Volume actuel (volume)
État de lecture (is_playing, playing_src, position_ms)
Force du signal WiFi (wifi_rssi)
Dernière mise à jour (updated_at)

DeviceCmd (Commandes)¶

La table device_cmd enregistre toutes les commandes envoyées aux enceintes :

Identifiant unique de requête (req_id)
Type d'opération (op) : play, pause, volume, ota, etc.
Paramètres en JSON (payload_json)
Statut d'exécution (sent, ok, error)
Code d'erreur éventuel (error_code)

DeviceStateLog (Historique)¶

La table device_state_log conserve l'historique complet des états :

Snapshots JSON de l'état du device
Horodatage de chaque état
Permet l'analyse et le debug

Système de contenu¶

Content (Contenu audio/vidéo)¶

La table contents stocke tous les contenus disponibles :

Type de média (audio, video, pdf, live)
Métadonnées (titre, description, auteur, langue)
Fichiers média (media_url, thumbnail_url, mime_type)
Durée (duration_ms)
Visibilité (public, private)
Appartient à une catégorie (category_id)
Peut faire partie d'une série (series_id, series_order)

Series (Séries de contenus)¶

La table series permet de regrouper des contenus en séries :

Titre et description de la série
Miniature (thumbnail_url)
Les contenus référencent leur série via series_id et leur position via series_order

Tags (Étiquettes)¶

La table tags contient les étiquettes pour classifier le contenu :

Nom unique du tag (ex: "Prophète Mohammed", "enfants", "ramadan")
Liaison avec les contenus via la table pivot content_tags

Categories (Catégories)¶

La table categories organise les contenus par grande catégorie :

Coran, Rappels, Invocations, Conférences, etc.
Chaque contenu appartient à une seule catégorie

Fonctionnement global¶

Le système repose sur une architecture flexible et évolutive :

Un utilisateur peut posséder plusieurs enceintes
Une enceinte peut être partagée avec plusieurs utilisateurs (avec rôles)
Chaque enceinte a un propriétaire unique (owner)
L'enceinte maintient un état en temps réel (connexion, lecture, batterie...)
Les commandes sont envoyées via MQTT et tracées dans device_cmd
L'historique complet est conservé dans device_state_log
Le contenu est organisé par catégories, séries et tags
Les séries permettent de structurer des contenus en épisodes ordonnés

Cette architecture permet :

Une gestion multi-utilisateurs des enceintes
Un partage familial des appareils
Un suivi précis de l'état et des commandes
Une bibliothèque de contenu riche et organisée
Une évolutivité pour de futures fonctionnalités