L’éclairage RGB de la 7e baie du ZimaCube dispose désormais d’un protocole de contrôle officiel : vous n’avez donc pas besoin de flasher CubeFX pour modifier les couleurs ou les effets. Le firmware officiel expose un point de terminaison Wi-Fi ESP32 à l’adresse 172.16.1.1 et accepte des commandes JSON pour les modes respiration, constant et personnalisé par LED.
CubeFX reste un firmware communautaire facultatif pour les utilisateurs qui souhaitent une interface différente ou une personnalisation plus poussée. Si vous préférez le firmware d’origine, utilisez la méthode HTTP/JSON officielle et évitez de reflasher l’ESP32.
Fonctionnement de l’éclairage de la 7e baie
Le protocole LED de la 7e baie actuel indique que le contrôleur d’éclairage est un ESP32 connecté à une bande de 13 LED WS2812B.
Se connecter au contrôleur d’éclairage
Le firmware officiel crée un réseau Wi-Fi nommé ZimaCube, avec le mot de passe documenté homecloud. Le contrôleur est accessible à l’adresse 172.16.1.1.
ping 172.16.1.1Définir une couleur constante
{
"id": 2,
"data": [
{"h": 21, "s": 255, "v": 255}
]
}Envoyez le JSON au contrôleur :
curl -X POST -H "Content-Type: application/json" -d @light.json http://172.16.1.1/postModes respiration et personnalisés
Le mode 1 est un mode respiration à vitesse réglable. Le mode 5 permet de contrôler la couleur et la luminosité de chacune des 13 LED. La documentation officielle indique actuellement que les modes 3 et 4 sont en cours de développement.
Vous pouvez conserver le firmware d’origine
Il s’agit du principal changement par rapport au fil de discussion du forum de 2024 : une documentation officielle du contrôle est désormais disponible. Vous pouvez automatiser le firmware d’origine sans flasher une image tierce.
CubeFX reste une alternative facultative
Le fil de discussion du projet CubeFX fournit une solution de firmware personnalisé aux utilisateurs avancés qui le souhaitent délibérément.
Mises à jour du firmware par OTA
L’ESP32 expose également une interface web OTA. Ne téléversez pas de binaires de firmware inconnus ; conservez une copie de récupération et gardez à l’esprit qu’un firmware personnalisé peut modifier le protocole attendu par ZimaOS.
Utiliser le RGB pour automatiser les états
Comme le point de terminaison de contrôle accepte le JSON, vous pouvez associer l’état des sauvegardes, les alertes de disque, les téléchargements ou l’activité d’une IA locale à des couleurs à partir de scripts, sans toucher au sous-système de stockage.
La présentation du contrôle RGB fournit davantage de contexte sur le projet.
Convertir les valeurs HSV avant d’envoyer le JSON
Le protocole officiel attend la teinte, la saturation et la valeur sur une échelle de 0 à 255. Si votre sélecteur de couleurs utilise des degrés et des pourcentages, convertissez ces valeurs avant de les envoyer à l’ESP32.
Tester un mode simple avant d’automatiser
Commencez par le mode couleur constante et vérifiez que le contrôleur répond. Ajoutez seulement ensuite des scripts pour l’état des sauvegardes, les alertes de disque ou les effets musicaux. Cela permet de distinguer les problèmes de réseau ou de protocole des problèmes liés à la logique d’automatisation.
Garder l’automatisation non critique
Utilisez les LED comme indication visuelle pratique, et non comme unique moyen d’alerte en cas de panne de disque ou de problème de sauvegarde. Les notifications matérielles doivent également apparaître dans les journaux, les e-mails, la supervision ou un autre canal persistant.
FAQ
Ai-je besoin de CubeFX pour contrôler les LED ?
Non. Le firmware officiel actuel dispose d’un protocole JSON/HTTP documenté.
Combien de LED la bande contient-elle ?
La documentation matérielle officielle indique 13 LED WS2812B.
Puis-je contrôler chaque LED séparément ?
Oui, le mode personnalisé officiel prend en charge les valeurs HSV pour chaque LED.
Puis-je restaurer le firmware d’origine après CubeFX ?
Utilisez les ressources officielles OTA/du firmware et vérifiez la révision matérielle correcte avant de reflasher.
