Manifeste
Pourquoi PNeX existe — et pourquoi nous avons tout recréé en Rust.
Pourquoi Rust, pourquoi partir de zéro
PNeX est écrit from scratch en Rust — pas un port d’une pile existante. Nous avons choisi de tout construire à neuf parce que l’état de l’art IoT industriel est une pile « colle » : une base SQL distribuée, un moteur de recherche, un bus de messages, une file de tâches, des workers, une UI séparée. Chaque brique apporte ses configs, ses mises à jour de sécurité, ses pièges d’exploitation. Résultat : des gigaoctets de RAM consommés pour déplacer des points de mesure, des déploiements fragiles, trois langages à maîtriser.
PNeX prend le chemin inverse : un seul langage, un seul workspace, un serveur qui ne fait que deux choses — les données et l’authoring — et des appareils conçus pour réguler tout seuls. Le contrat client-serveur est vérifié à la compilation, dans les deux sens.
Principes
Trois façons de coordonner les appareils. Aujourd’hui : la boucle médiée par le serveur — appareil vers serveur vers appareil — portée par le moteur de flows, pour les usages qui tolèrent une coupure. Le serveur n’écrit jamais un pin de sa propre initiative. Ensuite : les appareils autonomes, à qui PNeX caste leur configuration et qui régulent seuls, en flash, en gardant leurs métriques pendant une coupure serveur ou internet. Plus tard (en conception) : le mode M2M résilient — appareil vers appareil, sans centre — où chaque nœud actionneur embarque sa règle sur un mesh IPv6 auto-cicatrisant (OpenThread) avec du pub/sub pair-à-pair (zenoh-pico). Le hub ne fait que config et collecte : perdre le serveur n’interrompt pas le terrain, par construction.
Un seul langage. Serveur, app web, moteur de flows, build firmware, thermophysique : tout est Rust dans un seul workspace. Les mêmes types compilent nativement et en WebAssembly — le contrat client-serveur est vérifié à la compilation.
Moins de briques. Les piles IoT typiques font tourner cinq briques de stockage et de messaging — base SQL distribuée, Elasticsearch, NATS, Redis, une file de tâches. PNeX tourne sur trois : PostgreSQL, OpenObserve et Valkey. Le reste est couvert par des workers Postgres et le moteur de flows.
Sobriété. Une pile complète auto-hébergée tient dans quelques centaines de mégaoctets de RAM. C’est un produit de son temps : l’IA et le matériel moderne rendent la sobriété possible, et le matériel bon marché rend l’edge véritablement autonome.
L’IA comme aide à l’authoring. Un assistant intégré lit la télémétrie, rédige des brouillons de flows et de fonctions. Les appareils restent strictement en lecture pour l’assistant : l’IA aide les humains, elle ne touche pas au terrain.
Merci
PNeX croise des idées de ThingsBoard, ESPHome, Node-RED et de chaque plateforme IoT ouverte dont nous avons appris — reconstruites en Rust. Mais il est là parce que des gens ont contribué. Cette dette de reconnaissance ne sera jamais soldée.
Le modèle de programmation par flows que suit PNeX — des nœuds, des fils, et la conviction que les exploitants savent programmer.
La gestion d'appareils et les dashboards IoT, et la référence que nous visons.
L'expérience firmware que nous voulions : configurer, compiler, flasher, mettre à jour — sans toolchain.
L'observabilité en un seul binaire qui porte la télémétrie et les logs de PNeX.
Un fournisseur d'identité full-Rust — OIDC sans JVM.
Le Rust pour les UI : un seul code pour le web, Linux, Windows et Android.
Le framework serveur « Rails-on-Rust » qui porte toute l'API.
L'ORM async sous le serveur, de la migration à la requête.
Les propriétés thermophysiques, embarquées in-process plutôt qu'un service.
Le rendu cartographique ouvert qui porte la carte POI.
Le visualiseur 360 léger derrière les previews média.
La toolchain de build et de flash derrière les builds serveur et le flash navigateur.
Le runtime de flows vendored que PNeX supervise — merci à ses auteurs.
Les templates derrière les notifications, fidèles à Jinja.
Le runtime async sous tout le reste.
Chaque crate sur laquelle nous nous appuyons. PNeX existe parce que des gens ont contribué.
Et merci à vous, si vous utilisez, critiquez ou contribuez. C’est comme ça qu’un logiciel libre grandit.