Jordan Augé

New Aether Paper on Agentic AI Network Validation

2026-04-20T00:00:00+02:00

Notre article Aether: Network Validation Using Agentic AI and Digital Twin est désormais disponible sur arXiv : arXiv:2604.18233.

Aether permet aux opérateurs réseau d’exprimer des intentions de validation en langage naturel. Un système multi-agents décompose ces intentions en plans de vérification exécutables et les lance sur un jumeau numérique du réseau — vérification de configurations, simulation de changements de topologie et contrôle de conformité aux politiques opérationnelles.

Nous démontrons l’approche sur des scénarios réalistes issus de déploiements d’opérateurs en production, montrant qu’elle peut identifier des erreurs de configuration, prédire l’impact de changements planifiés et accélérer les processus de dépannage.

Travail conjoint avec Sam Betts, Giovanna Carofiglio, Giulio Grassi, Martin Gysi et John Kenneth d’Souza chez Cisco Outshift.

arXiv PDF

New Aether Paper on Agentic AI Network Validation

2026-04-20T00:00:00+02:00

Our paper Aether: Network Validation Using Agentic AI and Digital Twin is now available on arXiv as arXiv:2604.18233.

Aether is a framework that lets network operators express high-level validation intents in natural language. A multi-agent system autonomously decomposes those intents into executable verification plans and runs them against a digital twin of the network — checking configurations, simulating topology changes, and verifying compliance with operational policies.

We demonstrate the approach on realistic scenarios derived from production ISP deployments, showing that it can identify configuration errors, predict the impact of planned changes, and accelerate troubleshooting workflows.

Joint work with Sam Betts, Giovanna Carofiglio, Giulio Grassi, Martin Gysi, and John Kenneth d’Souza at Cisco Outshift.

Passer une TwoTrees TTC450 sous FluidNC — modes CNC et laser sans reflashage

2026-04-10T00:00:00+02:00

Le problème avec le firmware d’origine

La TwoTrees TTC450 est une machine sérieuse : 460×460 mm de zone de travail, moteurs NEMA 17 sur vis à bille en Z, broche 500 W, châssis aluminium solide. La mienne est livrée avec le module laser 20 W, ce qui la rend utilisable aussi bien en fraisage qu’en gravure. Le contrôleur est le MKS DLC32 v2.1, une carte ESP32 capable de piloter aussi bien une fraiseuse CNC qu’un laser. L’écran MKS TS35 installé par-dessus lui donne un aspect soigné.

La page TTC450 de Melvin Isken sur diode-laser-wiki est une excellente référence pour cette machine — elle couvre le montage, le firmware, les réglages et FluidNC en détail. Ce post s’appuie sur ce travail, étend la config FluidNC au laser 20 W et au mode CNC, et documente les adaptations nécessaires pour faire tourner l’écran et les plugins supplémentaires.

Le firmware stock, une version Makerbase de GRBL-ESP32, fonctionne bien à la livraison. Mais il a une limitation qui m’a rattrapé très vite : CNC et laser sont deux binaires distincts. Passer de la fraise au laser signifie brancher un câble USB, lancer le MKS Flash Tool, attendre le reflashage, et tout reconnecter. Sur une machine que j’utilise régulièrement dans les deux modes, c’est de la friction inutile.

J’ai aussi découvert que le binaire livré par TwoTrees et le firmware réellement installé sur la machine ne correspondaient pas — les partitions applicatives différaient octet par octet, ce qui m’a rendu prudent quant aux hypothèses sur l’état d’origine.

Pourquoi FluidNC

FluidNC est un firmware ESP32 moderne centré sur un fichier de configuration YAML. CNC ou laser n’est pas une question de firmware — c’est une question de fichier de config. On garde deux YAML sur la flash de la carte, et basculer entre les deux revient à taper :

$Config/Filename=config_laser.yaml
$Bye

C’est tout. Pas de câble, pas de reflashage, pas d’outil Windows.

FluidNC propose aussi une interface web servie via WiFi, une journalisation série détaillée, une configuration modifiable à chaud, et un système de plugins plus riche que GRBL. L’écosystème est actif et les releases sont prévisibles.

Le tableau suivant résume les compromis :

Critère	Stock (Makerbase)	FluidNC
CNC sans reflashage	✅	✅
Laser sans reflashage	❌ (binaire séparé)	✅
Basculement CNC↔Laser	Reflashage ~5 min	`$Config/Filename=…` + `$Bye`
Configuration	Paramètres GRBL `$$`	YAML + WebUI
Interface web	Basique	Complète (gestionnaire de fichiers, terminal, macros)
Debug / logs	Limité	Série détaillé + WebSocket
Rollback config	—	Toujours possible
Écran MKS TS35	✅	❌ (upstream)
Communauté TTC450	★★★★☆	★★★☆☆

Les deux dernières lignes posaient problème : le firmware stock pilote le TS35 nativement, et FluidNC en amont n’a pas ce support (et a explicitement refusé de l’ajouter). J’y reviens.

La procédure de sauvegarde

Avant de toucher au firmware, je voulais une sauvegarde complète de l’état d’origine. La flash ESP32 est accessible via serial avec esptool, et un dump complet capture tout : bootloader, table de partitions, les deux slots OTA, et le SPIFFS.

esptool.py --chip esp32 --port /dev/tty.usbserial-110 --baud 921600 \
  read_flash 0x00000 0x800000 flash_backup.bin

J’ai ensuite vérifié que le dump n’était pas vide et confirmé l’identité du firmware :

Chaîne $I : PRODUCER:MKS_DLC32 / VER:1.1h.2023070302
Affichage TS35 : MKS DLC32 CNC V2.1 — V2.3 (8M.H35.20230803)

Cette sauvegarde me donnait un point de retour complet. En cas de problème, un write_flash remet la machine dans son état d’origine.

Layout flash et analyse des partitions

J’ai aussi extrait la table de partitions pour comprendre l’organisation de la flash. Le firmware stock utilise un layout OTA standard ESP32 avec deux slots applicatifs et un SPIFFS. FluidNC utilise huge_app.csv, un layout sans OTA qui donne à l’application un slot de 3 Mo — pas de mise à jour en roulant, mais pas d’espace gaspillé non plus.

Une préoccupation passagère : est-ce que reflasher endommage l’ESP32 ? La spec datasheet pour la flash NOR est 100 000 cycles d’effacement par secteur. À raison d’un reflashage par jour, ça fait 273 ans. La question ne mérite pas qu’on s’y attarde.

Installation de FluidNC

L’installation se fait en trois binaires : bootloader, table de partitions, et le firmware.

esptool.py --chip esp32 --port /dev/tty.usbserial-110 --baud 921600 \
  write_flash \
    0x1000  bootloader.bin \
    0x8000  partitions.bin \
    0x10000 firmware.bin

Au premier démarrage, FluidNC crée un point d’accès WiFi (FluidNC, pas de mot de passe). On s’y connecte, on ouvre http://192.168.4.1, on envoie un fichier YAML, et la machine tourne.

Écrire la configuration YAML

Le fichier YAML est là où se fait le vrai travail. FluidNC attend une description complète de la machine : axes, steps/mm, vitesses max, accélération, limites, sortie broche ou laser, entrée palpeur.

Pour la config CNC de la TTC450, les valeurs viennent des specs des steppers :

NEMA 17 (17HS8401S) : 200 pas/tour (1,8°/pas)
Micro-stepping A4988 : 1/16 → 3200 pas/tour
Vis à bille T8 : 4 mm/tour
steps/mm = 3200 / 4 = 800

La config laser est la même description mécanique avec un bloc broche différent — une sortie laser PWM à la place du relais qui pilote la broche.

Mettre au point la config a demandé quelques vérifications croisées. Une config FluidNC communautaire pour la TTC450 existait comme point de départ, mais elle couvrait uniquement un module laser de moindre puissance et n’avait pas été validée en mode CNC ni pour le module 20W. Je l’ai confrontée aux réglages d’usine TwoTrees et au code source du firmware Makerbase, ce qui a permis de résoudre quelques divergences — certaines valeurs de la référence semblent être des marges de sécurité conservatrices plutôt que des limites physiques réelles. Le résultat est une config complète et sourcée pour les deux modes sur la TwoTrees TTC450 avec le module laser 20W. La liste complète des sources et des décisions se trouve dans docs/yaml-config-sources.fr.md.

Les configs TTC450, la procédure d’installation, et les variantes firmware pré-compilées — dont des builds avec les plugins couverts dans les posts qui suivent — sont dans github.com/jordanauge/fluidnc-ttc450. J’ai le laser 20W ; le dépôt recense aussi la config de diode-laser-wiki pour la variante 5,5W. Les PRs pour d’autres combinaisons matérielles sont les bienvenues.

Les deux configs coexistent sur la carte sous les noms config_cnc.yaml et config_laser.yaml. Le basculement est instantané et réversible.

Le problème de l’écran

Le TS35 est piloté en SPI et est spécifique au firmware Makerbase. FluidNC en amont ne le supporte pas, et après discussion publique dans le ticket #759, l’équipe principale a fermé la demande hors périmètre.

Cela signifiait faire tourner FluidNC sans affichage local — la machine fonctionnait parfaitement via WiFi, mais l’écran restait noir. Pour une machine dans un atelier, c’est un recul visible.

J’ai fini par écrire un plugin FluidNC standalone pour remettre l’affichage en service. C’est une autre histoire, couverte dans un post dédié.

Résultat

La machine démarre maintenant sous FluidNC v4.0.2, se connecte au WiFi local en mode STA, et est accessible depuis un navigateur à son adresse IP. Les premiers tests avec gSender confirment que la communication WiFi fonctionne, même si ce n’est pas la méthode recommandée pour un usage en production. Passer du mode CNC au mode laser prend une dizaine de secondes, sans aucun outil. La procédure de sauvegarde permet de restaurer le firmware Makerbase d’origine en moins de deux minutes si besoin.

L’approche YAML s’avère une vraie amélioration par rapport aux paramètres $$. La configuration de la machine est désormais un fichier texte versionnable, commenté, avec un historique et des diffs lisibles.

Ce post est le premier d’une série sur le projet CNC TTC450. Le dépôt avec les configs TTC450, les builds firmware et la procédure d’installation est sur github.com/jordanauge/fluidnc-ttc450.

Running CNC and Laser on TwoTrees TTC450 with FluidNC

2026-04-10T00:00:00+02:00

I bought the TTC450 to cover both milling and laser engraving on a single machine without two separate setups — the first post in the CNC & Laser Workshop build series. The decision to replace the firmware came within the first week, when I realized that switching modes meant reflashing.

The problem with the stock firmware

The TwoTrees TTC450 is a capable machine — 460×460 mm work area, NEMA 17 steppers on a ball screw Z axis, a 500 W spindle, and a reasonably solid frame. Mine came with the 20 W diode laser module, which makes it usable for both milling and engraving. The controller is the MKS DLC32 v2.1, an ESP32-based board that can run both CNC and laser modes. The MKS TS35 touchscreen sits on top and gives the whole thing a finished look.

Melvin Isken’s TTC450 page on diode-laser-wiki is an excellent reference for this machine — it covers setup, firmware, settings, and FluidNC in detail. This post builds on that work, extends the FluidNC config to the 20 W laser and CNC mode, and documents the changes needed when running the display and extra plugins.

The stock firmware, a Makerbase build of GRBL-ESP32, works well as shipped. But it has one limitation that I ran into immediately: CNC and laser are two separate firmware binaries. Switching from milling to engraving means connecting a USB cable, running the MKS Flash Tool, waiting for the reflash, and reconnecting everything. On a machine I use for both regularly, that becomes friction fast.

I also discovered that the local TwoTrees binary and the machine’s actual running firmware were not identical — the application partition differed byte-for-byte from the vendor file, which made me cautious about assuming the stock firmware was exactly what TwoTrees documented.

Why FluidNC

FluidNC is a modern ESP32 firmware with an architecture built around a YAML configuration file. CNC vs laser is not a firmware question — it is a config file question. You keep two YAML files on the board’s flash, and switching modes is:

$Config/Filename=config_laser.yaml
$Bye

That is the whole switching procedure. No cable, no reflash, no Windows tool.

FluidNC also has a proper web interface served over WiFi, detailed serial logging, runtime-editable configuration, and a richer plugin model than GRBL. The ecosystem is active and the release cadence is predictable.

The table below summarizes the tradeoffs:

Criterion	Stock (Makerbase)	FluidNC
CNC without reflash	✅	✅
Laser without reflash	❌ (separate binary)	✅
Switch CNC↔Laser	Reflash ~5 min	`$Config/Filename=…` + `$Bye`
Configuration	GRBL `$$` params	YAML + WebUI
Web interface	Basic	Rich (file manager, terminal, macros)
Debug / logs	Limited	Detailed serial + WebSocket
Config rollback	—	Always possible
MKS TS35 display	✅	❌ (upstream)
Community TTC450	★★★★☆	★★★☆☆

The last two rows were the catch: the stock firmware drives the TS35 display natively, and FluidNC upstream has no TS35 support (and has explicitly declined to add it). I will come back to that.

The backup procedure

Before touching the firmware I wanted a complete backup of the original state. The ESP32 flash is accessible over serial with esptool, and a full dump captures everything: bootloader, partition table, both OTA app slots, and SPIFFS.

esptool.py --chip esp32 --port /dev/tty.usbserial-110 --baud 921600 \
  read_flash 0x00000 0x800000 flash_backup.bin

Then I verified the dump was not just zeros and confirmed the firmware identity:

Board string from $I: PRODUCER:MKS_DLC32 / VER:1.1h.2023070302
TS35 display string: MKS DLC32 CNC V2.1 — V2.3 (8M.H35.20230803)

That gave me a complete recovery baseline. If anything goes wrong, one write_flash call puts the machine back exactly where it started.

Flash layout and partition analysis

I also extracted the partition table from the dump to understand how the flash was organized. The stock firmware uses a standard ESP32 OTA layout with two app slots and a SPIFFS partition. FluidNC uses huge_app.csv, a non-OTA layout that gives the application a 3 MB slot — no OTA rolling update, but no wasted space either.

A quick concern I had: does reflashing damage the ESP32? The datasheet spec for NOR flash is 100,000 erase cycles per sector. At one reflash per day that is 273 years before reaching the limit. The concern is not worth worrying about.

Installing FluidNC

The install is three binaries: bootloader, partition table, and the firmware itself.

esptool.py --chip esp32 --port /dev/tty.usbserial-110 --baud 921600 \
  write_flash \
    0x1000  bootloader.bin \
    0x8000  partitions.bin \
    0x10000 firmware.bin

On first boot, FluidNC creates a WiFi AP (FluidNC / no password). You connect to it, open http://192.168.4.1, upload a YAML config, and you are running.

Writing the YAML config

The YAML config is where the real work is. FluidNC expects a complete machine description: axis definitions, steps/mm, max rates, acceleration, limits, spindle or laser output, probe input.

For the TTC450 CNC config, the relevant values come from the stepper specs:

NEMA 17 (17HS8401S): 200 steps/rev (1.8°/step)
A4988 microstepping: 1/16 → 3200 steps/rev
Ball screw T8: 4 mm/rev
steps/mm = 3200 / 4 = 800

The laser config is the same mechanical definition with a different spindle block — a PWM laser output instead of the relay-controlled spindle.

Getting the config right required some cross-referencing. One community FluidNC config for the TTC450 existed as a starting point, but it covered only a lower-power laser variant and was not validated against CNC mode or the 20W module. I checked it against TwoTrees’ factory settings and the Makerbase firmware source, which resolved a few discrepancies — some values in the reference appear to be conservative safety margins rather than hard physical limits. The result is a complete, sourced config for both modes on the TwoTrees TTC450 with the 20W laser module. The full source list and decisions are in docs/yaml-config-sources.md.

The TTC450 configs, install procedure, and pre-built firmware variants — including builds with the plugins covered in the posts that follow — are in github.com/jordanauge/fluidnc-ttc450. I have the 20W laser; the repo also collects the config from diode-laser-wiki for the 5.5W variant. PRs for other hardware combinations are welcome.

Both configs live on the board as config_cnc.yaml and config_laser.yaml. Switching is instant and reversible.

The display problem

The MKS TS35 display is controlled over SPI and is specific to the Makerbase firmware. FluidNC upstream does not support it, and after public discussion in issue #759, the core team closed the request as out of scope.

This meant running FluidNC without a local display — the machine was fully operational via WiFi, but the screen went dark. For a machine in a shop that is a noticeable regression.

I ended up writing a standalone FluidNC plugin to restore the display, as well as a few useful plugins. But that will be the subject of future dedicated posts.

Result

The machine now boots FluidNC v4.0.2, connects to the local WiFi in STA mode, and is reachable via browser at its assigned IP. Initial tests with gSender seems to show it is able to communicate with the CNC over WiFi, although this is not a recommended way to use it for reliabiilty. Switching between CNC and laser takes about 10 seconds and requires no tools. The backup procedure means I can restore the original Makerbase firmware in under two minutes if needed.

The YAML config approach turned out to be a genuine upgrade over the $$ parameter system. Machine configuration is now a text file in version control, with readable comments, history, and the ability to diff changes.

This post is the first in a series on the TTC450 CNC project. The repository with the TTC450 configs, firmware builds, and install procedure is at github.com/jordanauge/fluidnc-ttc450.

Cisco Live EMEA 2026 — Agentic Observability and Evaluation

2026-03-25T00:00:00+01:00

En mars 2026, la vidéo de ma présentation Cisco Live EMEA 2026 sur l’observabilité et l’évaluation agentiques a été publiée.

Cette présentation touche à une intersection qui me semble importante : elle relie le travail concret sur la validation réseau que nous conduisons chez Cisco Outshift avec la question plus large de ce qu’il faut pour rendre les systèmes d’IA agentiques réellement observables et évaluables en pratique. L’observabilité, c’est une de ces choses qui paraît évidente jusqu’au moment où il faut vraiment la construire pour un système dont l’agent prend des décisions qu’on n’avait pas entièrement anticipées.

Vidéo

Agentic Observability and Evaluation | Cisco Live EMEA 2026

Cisco Live EMEA 2026 — Agentic Observability and Evaluation

2026-03-25T00:00:00+01:00

In March 2026, the video from my Cisco Live EMEA 2026 talk on agentic observability and evaluation was published.

This talk sits at an intersection I find important: it connects the concrete network-validation work we have been building at Cisco Outshift with the broader question of what it takes to make agentic AI systems genuinely observable and evaluable in practice. Observability is one of those things that sounds obvious until you actually try to build it for a system where the agent is making decisions you did not fully anticipate.

Video

Agentic Observability and Evaluation | Cisco Live EMEA 2026

Élu Chair du groupe Accuracy and Reliability de l'AAIF

2026-02-27T00:00:00+01:00

Je suis tres heureux et honore d’annoncer que, le 27 fevrier 2026, j’ai ete elu president du groupe de travail Accuracy and Reliability au sein de l’AAIF Agentic AI Foundation, qui fait partie de la Linux Foundation.

J’assurerai ce role aux cotes de Casper Nielsen de Diagrid, elu co-president.

C’est un moment important pour l’ecosysteme de l’agentic AI. Parmi les partenaires impliques dans la fondation, l’interet est deja tres fort, et le besoin l’est encore davantage: si l’agentic AI doit etre utilisee dans des systemes serieux, il faut des bases communes beaucoup plus solides sur la precision, la fiabilite, l’evaluation et la confiance operationnelle.

Je suis sincerement enthousiaste a l’idee de contribuer a structurer ce travail. Il y a ici une vraie opportunite de transformer une preoccupation largement partagee en lignes directrices concretes, en vocabulaire commun, et en orientations techniques utiles pour construire des systemes agentiques plus fiables.

Je me rejouis de travailler avec Casper, avec les autres contributeurs du groupe, et avec l’ensemble de la communaute AAIF pour faire de cette initiative un effort utile, ambitieux et ancre dans des besoins reels.

Pourquoi c’est important

La precision et la fiabilite sont centrales pour rendre l’agentic AI exploitable en production.
La demande est deja tres visible dans l’ecosysteme, avec un fort engagement des organisations participantes.
La coordination ouverte est essentielle: un cadre de fondation est le bon niveau pour aligner les termes, les attentes, les approches d’evaluation et les pratiques d’ingenierie.

La suite

Mon objectif est d’aider ce groupe de travail a devenir un espace ou l’experience pratique, les apports de la recherche et la rigueur d’ingenierie se rencontrent. Je suis tres motive a contribuer a cet effort et a construire quelque chose qui ait un impact reel pour la communaute.

Liens associes

Site web de l’AAIF

Elected Chair of the AAIF Accuracy and Reliability WG

2026-02-27T00:00:00+01:00

I am honored and excited to share that, on 27 February 2026, I was elected chair of the Accuracy and Reliability working group in the AAIF Agentic AI Foundation, part of the Linux Foundation.

I will be serving alongside Casper Nielsen from Diagrid, who was elected co-chair.

This is an important moment for the broader agentic AI community. Across the partners involved in the foundation, the level of interest is already very high, and the need is even clearer: if agentic AI is going to be used in serious systems, we need much stronger shared foundations for accuracy, reliability, evaluation, and operational trust.

I am genuinely enthusiastic about helping shape this work. There is a real opportunity here to turn a fast-growing set of concerns into practical guidance, common language, and concrete technical directions that can help teams build more reliable agentic systems.

I am looking forward to working with Casper, the other contributors in the working group, and the wider AAIF community to make this effort useful, ambitious, and grounded in real needs.

Swisscom : résultats en production du livre blanc publiés

2025-10-21T00:00:00+02:00

Apres plusieurs mois de collaboration entre Cisco Outshift, Swisscom et l’ETH Zurich, nous publions notre livre blanc technique complet documentant le deploiement en production de notre plateforme d’IA agentique pour la validation des changements reseau.

Le point de depart etait une question simple: des agents IA peuvent-ils vraiment valider des changements reseau dans des environnements de production reels ? Aujourd’hui, avec 2 deploiements actifs chez Swisscom et 5 cas d’usage valides, nous avons une reponse claire.

De 2 semaines a 2 heures

Les chiffres parlent d’eux-memes. Ce qui demandait traditionnellement aux ingenieurs reseau 2 semaines de validation manuelle — verification des politiques de routage, des regles de pare-feu, et des changements de topologie dans des environnements multi-fournisseurs — prend maintenant seulement 2 heures avec notre plateforme d’IA agentique. Cela represente une reduction de 99,4 % du temps de validation.

Mais la vitesse n’est pas le seul indicateur. La plateforme a montre une gestion robuste de scenarios complexes: changements de routage BGP et OSPF, modifications de regles de pare-feu, reconfigurations de load balancers et mises a jour de topologie. Chaque cas a ete valide avec le meme niveau de rigueur que les processus manuels, mais avec une constance et une tracabilite que seule l’IA peut fournir.

Quand l’architecture rencontre la realite

Le livre blanc detaille l’architecture technique qui a rendu cela possible: un systeme multi-agents coordonnant des jumeaux numeriques de reseau, des graphes de connaissances pour la comprehension de la topologie, et une observabilite basee sur OpenTelemetry. La plateforme s’integre a des outils de production comme Batfish, Suzieq et les API Meraki, soit 145 commits et plus de 12 000 lignes de code repartis sur plusieurs depots.

Il ne s’agit pas d’une demonstration de laboratoire. Ce sont de vrais reseaux Swisscom en production, transportant un vrai trafic, avec de vraies consequences en cas d’echec.

Ce que cela signifie

Cette collaboration montre que l’IA agentique peut faire evoluer les operations reseau d’une validation manuelle reactive vers une assurance automatisee proactive. L’approche ne se contente pas de reduire la charge operationnelle: elle transforme en profondeur la facon dont les changements reseau sont concus, valides et deploies.

Ressources associees

Le livre blanc technique complet ainsi que l’annonce officielle sont disponibles ci-dessous.

Acceder au livre blanc

Telechargement:

Associe:

Swisscom White Paper: Production Results Released

2025-10-21T00:00:00+02:00

After months of collaboration between Cisco Outshift, Swisscom, and ETH Zurich, we released our technical whitepaper documenting the production deployment of our agentic AI platform for network change validation.

The numbers: what traditionally took network engineers 2 weeks of manual validation now takes our platform just 2 hours — a 99.4% reduction. Across 2 live deployments at Swisscom and 5 validated use cases, the platform handles BGP and OSPF routing changes, firewall rule modifications, load balancer reconfigurations, and network topology updates. The system is built on a multi-agent architecture coordinating network digital twins, knowledge graphs, and OpenTelemetry-based observability, integrated with production tools like Batfish, Suzieq, and Meraki APIs.

AIEWF 2025 — IA multi-agents et graphes de connaissance

2025-08-22T00:00:00+02:00

Ma collègue Ola Mabadeje a présenté nos travaux sur les systèmes multi-agents et les graphes de connaissance pour la validation des changements réseau à l’AI & Enterprise Workflow Forum (AIEWF) 2025.

AIEWF 2025: Multi-Agent AI and Network Knowledge Graphs

2025-08-22T00:00:00+02:00

My colleague Ola Mabadeje presented our work on multi-agent AI systems and knowledge graphs for network change validation at the AI & Enterprise Workflow Forum (AIEWF) 2025.

AIEWF 2025: Multi-Agent AI and Network Knowledge Graphs

2025-08-22T00:00:00+02:00

My colleague Ola Mabadeje presented our work on multi-agent AI systems and knowledge graphs for network change validation at the AI & Enterprise Workflow Forum (AIEWF) 2025.

AIEWF 2025 — IA multi-agents et graphes de connaissance

2025-08-22T00:00:00+02:00

"Video Galileo : architecturer une IA agentique fiable"

2025-07-09T00:00:00+02:00

Ceci ne concerne pas mon propre travail — c’est une présentation que je recommande car elle est directement pertinente pour la question plus large de la construction de systèmes agentiques fiables.

Giovanna Carofiglio a donné une présentation pour Galileo en juillet 2025 sur la fiabilité de l’IA agentique : ce qu’il faut pour construire des systèmes agents qui restent inspectables et dignes de confiance dans des conditions opérationnelles réelles.

La présentation aborde des enjeux d’ingénierie — observabilité, modes de défaillance, frontières de confiance — qui importent à quiconque déploie des agents en production, quel que soit le domaine spécifique.

Vidéo

Architecting Reliable Agentic AI | Cisco’s Giovanna Carofiglio on the AGNTCY Collective

Galileo Video: Architecting Reliable Agentic AI

2025-07-09T00:00:00+02:00

This is not about my own work — it is a talk I recommend because it is directly relevant to the broader question of building reliable agentic systems.

Giovanna Carofiglio gave a talk for Galileo in July 2025 on reliable agentic AI: what it takes to build agent systems that remain inspectable and trustworthy under real operational conditions.

The talk covers engineering concerns — observability, failure modes, trust boundaries — that matter to anyone deploying agents in production, regardless of the specific domain.

Video

Architecting Reliable Agentic AI | Cisco’s Giovanna Carofiglio on the AGNTCY Collective

Cisco Live US 2025: Agentic AI and NetDevOps Session

2025-06-03T00:00:00+02:00

My colleague Giovanna Carofiglio presented our work on agentic AI for network change validation at Cisco Live US 2025 in Las Vegas, session BRKNWT-2502.

The session covered how multi-agent AI systems can automate and validate network changes end-to-end using digital twin models of the network. The approach combines LLM-driven agents with network knowledge graphs to reason about the impact of changes before deployment, reducing the risk of outages while enabling faster NetDevOps iteration cycles.

The full session slides and session recording are available below.

Cisco Live US 2025 — Agentic AI and NetDevOps

2025-06-03T00:00:00+02:00

Ma collègue Giovanna Carofiglio a présenté nos travaux sur la validation agentique des changements réseau par IA à Cisco Live US 2025 à Las Vegas, session BRKNWT-2502.

La session a présenté comment des systèmes multi-agents peuvent automatiser et valider les changements réseau de bout en bout à l’aide de jumeaux numériques. L’approche combine des agents pilotés par LLM avec des graphes de connaissance réseau pour raisonner sur l’impact des changements avant déploiement.

Les slides et l’enregistrement sont disponibles.

Cisco Live US 2025 — Agentic AI and NetDevOps

2025-06-03T00:00:00+02:00

Ma collègue Giovanna Carofiglio a présenté nos travaux sur la validation agentique des changements réseau par IA à Cisco Live US 2025 à Las Vegas, session BRKNWT-2502.

Les slides et l’enregistrement sont disponibles.

Cisco Live US 2025: Agentic AI and NetDevOps Session

2025-06-03T00:00:00+02:00

My colleague Giovanna Carofiglio presented our work on agentic AI for network change validation at Cisco Live US 2025 in Las Vegas, session BRKNWT-2502.

The full session slides and session recording are available below.

Outshift and Swisscom: Building Agentic AI Networks

2025-04-24T00:00:00+02:00

We announced a collaboration between Cisco Outshift and Swisscom on building AI-driven network reliability through agentic AI and network digital twins.

Through the Aether project, we developed an agentic AI platform that creates network digital twins, orchestrates multi-agent validation workflows, and automates change validation — reducing validation time at Swisscom.

Outshift et Swisscom : déployer des réseaux d'IA agentique

2025-04-24T00:00:00+02:00

Nous avons annoncé une collaboration entre Cisco Outshift et Swisscom pour améliorer la fiabilité des réseaux grâce à l’IA agentique et aux jumeaux numériques de réseaux.

Dans le cadre du projet Aether, nous avons développé une plateforme d’IA agentique qui crée des jumeaux numériques des réseaux, orchestre des workflows de validation multi-agents et automatise la validation des changements — réduisant le temps de validation chez Swisscom.

Outshift et Swisscom : déployer des réseaux d'IA agentique

2025-04-24T00:00:00+02:00

Nous avons annoncé une collaboration entre Cisco Outshift et Swisscom pour améliorer la fiabilité des réseaux grâce à l’IA agentique et aux jumeaux numériques de réseaux.

Outshift and Swisscom: Building Agentic AI Networks

2025-04-24T00:00:00+02:00

We announced a collaboration between Cisco Outshift and Swisscom on building AI-driven network reliability through agentic AI and network digital twins.

Suivre la consommation d'un ballon d'eau chaude avec PowerCalc dans Home Assistant

2025-01-27T00:00:00+01:00

Introduction

Cet article explique comment utiliser l’intégration PowerCalc pour ajouter la consommation d’un ballon d’eau chaude au tableau de bord Énergie de Home Assistant sans installer de capteur de puissance dédié.

L’idée clé est qu’un ballon d’eau chaude suit un profil de consommation assez simple : c’est une charge résistive de forte puissance, souvent active sur des créneaux fixes, par exemple pendant les heures creuses la nuit. Lorsqu’aucun autre appareil comparable ne fonctionne au même moment, on peut exploiter les sauts de puissance, ou tout autre signal corrélé, pour détecter quand le ballon chauffe et estimer correctement sa consommation. PowerCalc est particulièrement adapté à ce type de capteur virtuel.

Motivation

J’ai volontairement choisi un appareil “simple”, le Sauter Cangar 200 L, annoncé à 2200 W, parce qu’un ballon d’eau chaude devrait rester un équipement basique. Le marketing semble pourtant avoir pris le dessus sur la durabilité, l’efficacité et le bon sens technique. Beaucoup de modèles plus récents exposent des interfaces propriétaires pour un faux sentiment de contrôle, exigent du Wi-Fi et une connexion cloud, et consomment en permanence une puissance de veille non négligeable. J’ai aussi constaté que certains ne peuvent pas être pilotés via le fil pilote, ce qui oblige à synchroniser manuellement leur programmation avec celle du fournisseur d’électricité. Les ballons plus classiques sont plus simples : ils sont pensés pour être pilotés via le fil pilote et, comme ils ne sont pas conçus pour rester alimentés en permanence, ils intègrent souvent une batterie plus robuste pour des fonctions comme l’anticorrosion active pendant les périodes hors tension.

Si vous utilisez Home Assistant sérieusement, vous avez sans doute déjà rencontré la “matière noire” de l’énergie domestique : des équipements lourds, comme les ballons d’eau chaude câblés en direct, sans mesure intégrée. On peut installer un relais dédié ou un sous-compteur dans le tableau électrique, mais dans certains cas un capteur virtuel piloté par logiciel est suffisamment précis et bien plus simple à maintenir.

Qu’est-ce que PowerCalc ?

PowerCalc est une intégration Home Assistant spécialisée dans l’estimation de la consommation des appareils qui ne la remontent pas eux-mêmes. Sa fonctionnalité la plus utile ici est le capteur de puissance virtuelle manuelle. Elle permet de prendre un simple état On/Off et de le transformer en entités de puissance (W) et d’énergie (kWh).

Le tableau de bord Énergie : n’a besoin que du capteur d’énergie (kWh) créé par PowerCalc.
Les utility meters : sont utiles si vous voulez des entités dédiées pour l’interface principale, ou des compteurs distincts selon les tarifs.

Calculer la résistance du ballon

On pourrait affecter une puissance fixe, par exemple 2200 W, ou prendre une moyenne récente, mais en pratique cette valeur varie dans le temps. Cela peut facilement introduire une erreur de 5 % ou plus.

La raison est la baisse de tension du réseau pendant les périodes de forte demande. J’ai observé une tension qui pouvait passer de 225 V à 215 V exactement au moment où les heures creuses commencent et où le ballon démarre. Si l’on modélise le ballon avec une puissance fixe, on surestime alors l’énergie réellement consommée.

On peut au contraire exploiter le fait qu’un ballon se comporte comme une charge presque purement résistive suivant la loi d’Ohm : $P = V^2 / R$. J’ai mesuré le delta de puissance avant et après le déclenchement.

	P	V
Avant déclenchement	212 W	220 V
Après déclenchement	2212 W	220 V

La formule donne alors $R = V^2 / P = 220^2 / 2000 = 24.2 \Omega$. Dans cette mesure, le résultat est proche de la valeur annoncée, mais ce n’est pas toujours le cas. J’ai répété l’opération sur plusieurs jours et retenu une résistance moyenne de 24 $\Omega$.

Une fois cette résistance estimée, on peut calculer la puissance instantanée directement à partir de la tension mesurée en utilisant la même formule.

Configurer PowerCalc

Installation

Installation via HACS : allez dans HACS -> Integrations -> Explore & Download Repositories. Cherchez “Powercalc” puis installez-le.
Redémarrage : redémarrez Home Assistant pour initialiser l’intégration.

Créer un binary sensor pour détecter l’activité du ballon

Pour suivre virtuellement un appareil, PowerCalc a besoin d’un capteur de référence indiquant quand l’équipement est actif. Ici j’utilise le compteur global de la maison, un Lixee ZLinky, pour détecter le saut de puissance.

Un binary sensor est créé dans templates.yaml :

- binary_sensor:
    - name: "Water Tank Heating"
      unique_id: water_tank_heating
      device_class: running
      delay_on: "00:00:15"
      delay_off: "00:00:15"
      state: >
        {% set power = states('sensor.lixee_zlinky_tic_puissance') | float(0) %}
        {% set is_time_window = 22 <= now().hour or now().hour < 6 %}
        {{ power > 1800 and is_time_window }}

Pour éviter les faux positifs dus à d’autres gros appareils comme un four, j’ajoute comme contrainte le créneau heures creuses, de 22 h à 6 h dans mon cas. Le delay_on de 15 secondes filtre les pics très courts, et le delay_off évite les clignotements lorsque le compteur remonte brièvement 0 W ou manque une mise à jour.

Ajouter un capteur depuis l’interface PowerCalc

Configuration de l’intégration : allez dans Settings > Devices & Services > Add Integration. Recherchez “Powercalc” puis sélectionnez-le.

Suivez ensuite les étapes suivantes :

Écran 1 : choix du type de capteur

Sélectionnez Virtual power (manual).

Écran 2 : création d’un capteur de puissance virtuelle

Source entity : binary_sensor.water_tank_heating.
Name : “Hot water tank Power”.
Calculation strategy : choisissez fixed.
Standby power : mettez 0.
Create energy sensor : laissez activé.

Écran 3 : configuration fixe

Utilisez le champ Power template pour le calcul dynamique.

Au lieu de saisir une puissance fixe, utilisez l’expression Jinja Home Assistant habituelle qui élève sensor.lixee_zlinky_tic_tension au carré, divise par 23.07, puis arrondit le résultat à deux décimales.

Écran 4 : options avancées

Energy integration method : choisissez left (Left Riemann Sum). Pour un appareil qui passe presque instantanément de 0 W à 2000 W, cette méthode est en général plus précise que la méthode trapézoïdale par défaut.
Energy sensor unit prefix : vérifiez que k (kilo) est sélectionné.

Pour aller plus loin + 2026-05-19

Précision : quantifier l’erreur liée aux fluctuations de tension

La formule $P = V^2/R$ implique qu’une variation de tension par rapport au nominal 230 V est amplifiée dans le calcul de puissance, car la relation est quadratique. Avec $R = 24\,\Omega$ :

Tension	Puissance réelle	Erreur vs. 230 V fixe
215 V	1927 W	−277 W (−14 %)
220 V	2017 W	−187 W (−9 %)
225 V	2110 W	−94 W (−4 %)
230 V	2204 W	0
235 V	2301 W	+97 W (+4 %)

En heures creuses, le réseau est davantage chargé et la tension se situe typiquement vers le bas de cette plage. Sur un cycle de chauffe de 3h30 à 215 V, un modèle fixé à 230 V comptabiliserait 7,7 kWh au lieu des 6,7 kWh réels — soit un écart d’un kilowattheure par nuit, ou environ 30 kWh par mois.

Remarque sur les valeurs négatives. Si l’on cherchait à estimer la consommation du ballon en soustrayant une ligne de base à la puissance totale du foyer plutôt qu’en utilisant un déclencheur binaire, une chute de tension simultanée au démarrage du ballon pourrait produire un delta de puissance légèrement inférieur à l’attendu et, selon le timing, une lecture brièvement négative. L’approche par déclencheur binaire évite entièrement ce problème : la puissance vaut soit $V^2/R$, soit zéro, sans aucune soustraction.

Alternative : YAML natif sans PowerCalc

Si vous préférez éviter une dépendance HACS, le même résultat peut être obtenu avec trois composants standard de Home Assistant.

1. Capteur template — puissance instantanée, dans templates.yaml :

- sensor:
    - name: "Water Tank Power"
      unit_of_measurement: "W"
      device_class: power
      state_class: measurement
      state: >
        {% if is_state('binary_sensor.water_tank_heating', 'on') %}
          {{ (states('sensor.lixee_zlinky_tic_tension') | float(0) ** 2 / 24) | round(2) }}
        {% else %}
          0
        {% endif %}

2. Intégration de Riemann — accumulation d’énergie, dans configuration.yaml :

sensor:
  - platform: integration
    source: sensor.water_tank_power
    name: "Water Tank Energy"
    unit_prefix: k
    method: left
    round: 3

3. Compteur utilitaire — remises à zéro cycliques et persistance entre les redémarrages, dans configuration.yaml :

utility_meter:
  water_tank_energy_daily:
    source: sensor.water_tank_energy
    cycle: daily
  water_tank_energy_monthly:
    source: sensor.water_tank_energy
    cycle: monthly

Le capteur integration se remet à zéro à chaque redémarrage de Home Assistant. Le wrapper utility_meter ajoute des remises à zéro cycliques et des statistiques long terme, offrant le même comportement que le capteur d’énergie intégré de PowerCalc. Ajoutez sensor.water_tank_energy (ou une entité de compteur utilitaire) au tableau de bord Énergie de la manière habituelle.

Le compromis : trois blocs YAML contre une interface guidée en quelques clics. PowerCalc reste la solution la plus simple si HACS fait déjà partie de votre configuration.

Conclusion

Une fois les nouveaux capteurs créés, ils devraient apparaître dans le tableau de bord Énergie comme appareils individuels. Cela permet de sortir une part importante de la consommation de la catégorie générique “non suivie”, tout en gardant une estimation raisonnablement précise, même lorsque la tension secteur varie.

Tracking hot water tank power consumption with PowerCalc in Home Assistant

2025-01-27T00:00:00+01:00

Introduction

This article explains how to use the PowerCalc integration to add your hot water tank consumption to the Home Assistant Energy dashboard without installing a dedicated power monitor.

The idea is simple: a hot water tank is a high-power resistive load with a fairly predictable schedule. If no other similar appliance overlaps with it, a single whole-home power sensor is often enough to detect heater activity and estimate its energy usage with good precision. PowerCalc is a good fit for this kind of virtual sensing because it can turn a binary trigger into both instantaneous power and accumulated energy.

Motivation

I deliberately chose a “dumb” appliance, the widely available 200L Sauter Cangar, advertised at 2200W, because a hot water tank should remain a simple device. Marketing seems to have won the battle against durability, efficiency, and technical sanity. Many newer products expose proprietary interfaces for a superficial sense of control, require Wi-Fi and cloud connectivity, and draw a constant non-negligible standby load. I also found that some of them cannot be controlled through pilot wire, forcing you to manually synchronize their schedule with your electricity provider. Traditional tanks are simpler: they are designed to be driven by pilot wire and, because they are not intended to remain permanently powered, they often include a stronger battery for features such as active anti-corrosion during off-grid periods.

If you use Home Assistant seriously, you have probably run into the “dark matter” of home energy: hardwired appliances with no built-in metering. A hot water tank is a perfect example. You can install a relay with power monitoring or add a sub-meter in the electrical panel, but if the appliance has a clean enough signature, a software-only virtual sensor can be both simpler and accurate enough for the Energy dashboard.

What is Powercalc?

Powercalc is a specialized Home Assistant integration designed to estimate power consumption for devices that don’t report it themselves. Its key feature is the Manual Virtual Power sensor. It allows you to take a simple “On/Off” state and transform it into a high-fidelity Power (W) and Energy (kWh) entity.

The Energy Dashboard: only requires the Energy Sensor (kWh) created by PowerCalc. It manages its own long-term statistics internally.
Utility Meters: useful when you want dedicated entities for the main UI, or when you need separate tariff-specific counters outside the dashboard.

Computing the heater’s resistance

You could assign a fixed value such as 2200 W, or derive a simple average from recent history, but in practice this power varies over time. That can easily introduce errors of 5% or more.

The reason is that voltage is not constant. During heavy usage periods I observed mains voltage falling from roughly 225 V to 215 V, often exactly when off-peak hours begin and the heater turns on. A fixed-power model therefore counts energy that was never actually drawn.

The graph makes the problem visible: heater activation coincides with a lower grid voltage, so using a fixed advertised wattage would systematically overestimate consumption.

Instead, we can exploit the fact that a hot water tank behaves as a nearly pure resistive load following Ohm’s law: $P = V^2 / R$. I measured the power delta before and after the heater trigger.

	P	V
Before trigger	212 W	220 V
After trigger	2212 W	220 V

The formula gives $R = V^2 / P = 220^2 / 2000 = 24.2 \Omega$. In this measurement the result is close to the advertised value, but that is not always the case. I repeated the same check over several days and kept 24 $\Omega$ as the working resistance.

Once you have that resistance estimate, you can compute instantaneous power directly from the measured voltage using the same formula.

When this approach works well

This approach works well when three conditions hold:

the appliance behaves like a mostly resistive load
the appliance has a distinct power signature
its schedule or operating window helps reduce ambiguity

It works less well when several similar high-power loads overlap, or when the trigger sensor is too noisy to isolate the heater reliably.

Setting up powercalc

Installation

HACS Installation: Go to HACS -> Integrations -> Explore & Download Repositories. Search for “Powercalc” and download it.
Restart: Restart Home Assistant to initialize the new files.

Setting up a binary sensor to track active appliance

To track an appliance virtually, PowerCalc needs a reference sensor indicating when the device is active. Here I use the whole-home power meter, a Lixee ZLinky, to detect the power delta.

A binary sensor is created in templates.yaml:

- binary_sensor:  
    - name: "Water Tank Heating"  
      unique_id: water_tank_heating  
      device_class: running  
      delay_on: "00:00:15"   
      delay_off: "00:00:15"  
      state: >
        {% set power = states('sensor.lixee_zlinky_tic_puissance') | float(0) %}
        {% set is_time_window = 22 <= now().hour or now().hour < 6 %}
        {{ power > 1800 and is_time_window }}

To avoid false positives caused by other heavy appliances such as an oven, I use the off-peak schedule, 10 PM to 6 AM in my case, as an additional constraint. The delay_on of 15 seconds filters out short spikes, and delay_off prevents flicker when the meter briefly reports 0 W or misses an update.

Adding a sensor from PowerCalc UI

Integration Setup: Go to Settings > Devices & Services > Add Integration. Search for “Powercalc” and select it.

Follow these steps in the PowerCalc configuration flow:

Screen 1: Choose Sensor Type

Select Virtual power (manual).

Screen 2: Create a virtual power sensor

Source entity: binary_sensor.water_tank_heating.
Name: “Hot water tank Power”.
Calculation strategy: Select fixed from the dropdown.
Standby power: Set this to 0.
Create energy sensor: Ensure this is toggled ON.

Screen 3: Fixed config

Use the Power template field (the middle one) for your dynamic calculation.

Instead of writing a fixed wattage, use the usual Home Assistant Jinja expression that squares sensor.lixee_zlinky_tic_tension, divides by 23.07, and rounds the result to two decimals.

Screen 4: Advanced options

Energy integration method: change this to left (Left Riemann Sum). For appliances that switch almost instantly from 0 W to 2000 W, this is usually more accurate than the default trapezoidal method.
Energy sensor unit prefix: Ensure k (kilo) is selected.

Going further + 2026-05-19

Accuracy: quantifying the voltage error

The formula $P = V^2/R$ means that a voltage variation from the 230 V nominal is amplified when computing power, because the relationship is quadratic. With $R = 24\,\Omega$:

Voltage	Actual power	Error vs. fixed 230 V
215 V	1927 W	−277 W (−14%)
220 V	2017 W	−187 W (−9%)
225 V	2110 W	−94 W (−4%)
230 V	2204 W	0
235 V	2301 W	+97 W (+4%)

During off-peak hours the grid is typically more loaded and voltage tends to sit toward the lower end of that range. For a 3.5-hour heating cycle at 215 V, a fixed 230 V model would account for 7.7 kWh instead of the actual 6.7 kWh — a one kilowatt-hour overcount per night, or roughly 30 kWh per month.

A note on negative values. If you were to estimate heater energy by subtracting a baseline from the whole-home meter rather than using a binary trigger, a simultaneous voltage drop at heater turn-on could produce a power delta slightly lower than expected and, depending on timing, even a brief negative reading. The binary trigger approach avoids this entirely: power is either $V^2/R$ or zero, with no subtraction involved.

Alternative: native YAML without PowerCalc

If you prefer not to add a HACS dependency, the same result can be achieved with three standard Home Assistant components.

1. Template sensor — instantaneous power, in templates.yaml:

- sensor:
    - name: "Water Tank Power"
      unit_of_measurement: "W"
      device_class: power
      state_class: measurement
      state: >
        {% if is_state('binary_sensor.water_tank_heating', 'on') %}
          {{ (states('sensor.lixee_zlinky_tic_tension') | float(0) ** 2 / 24) | round(2) }}
        {% else %}
          0
        {% endif %}

2. Riemann sum integration — energy accumulation, in configuration.yaml:

sensor:
  - platform: integration
    source: sensor.water_tank_power
    name: "Water Tank Energy"
    unit_prefix: k
    method: left
    round: 3

3. Utility meter — cycle resets and persistence across restarts, in configuration.yaml:

utility_meter:
  water_tank_energy_daily:
    source: sensor.water_tank_energy
    cycle: daily
  water_tank_energy_monthly:
    source: sensor.water_tank_energy
    cycle: monthly

The integration sensor resets to zero on Home Assistant restart. The utility_meter wrapper adds cycle-based resets and long-term statistics, giving the same behaviour as PowerCalc’s built-in energy sensor. Add sensor.water_tank_energy (or a utility meter entity) to the Energy dashboard in the usual way.

The tradeoff is three YAML blocks versus a single guided UI flow. PowerCalc remains the simpler path if HACS is already part of your setup.

Conclusion

Once the new sensors are created, they should appear in the Energy dashboard as individual devices. This moves a large share of consumption out of the generic “untracked” bucket while keeping the estimate reasonably accurate, even during periods of lower mains voltage.

The practical advantage of this method is not just accuracy. It is maintainability. If you already have a reliable whole-home meter, a virtual model in Home Assistant is often easier to operate than adding another relay, another radio device, or another component in the electrical panel.

Exécuter Windows 11 sur Linux en VM QEmu imbriquée

2024-03-14T00:00:00+01:00

J’utilise exclusivement Linux chez moi et j’avais besoin d’une VM Windows pour compiler la suite de flipper virtuel et d’autres logiciels nécessitant l’utilisation du Windows Subsystem for Linux (WSL2).

Virtualbox vs QEmu

J’avais initialement choisi Virtualbox pour sa simplicité, mais je n’ai jamais réussi à y installer WSL2. Il semble que WSL2 soit implémenté sur la technologie HyperV de Windows, ce qui nécessite des fonctionnalités de virtualisation imbriquée pour être utilisé dans une VM.

Contrairement à ce qui est annoncé dans la documentation officielle wsl-virtualbox, il semble que la prise en charge de la virtualisation imbriquée pour HyperV n’ait pas été incluse dans la dernière version 7.0 de Virtualbox (7.0.14-Debian à la date de rédaction), rendant impossible l’installation de WSL2 vbox-hyperv. Cela pourrait changer avec la sortie de la version 7.1.

WslRegisterDistribution failed with error: 0x80370102
Please enable the Virtual Machine Platform Windows feature and ensure virtualization is enabled in the BIOS.
For information please visit https://aka.ms/enablevirtualization

C’était l’occasion d’essayer QEmu, qui le prend en charge et promet d’être plus efficace grâce à l’utilisation de KVM et virtio.

Configuration de QEmu

J’ai suivi l’excellent tutoriel de raphtlw, dont les étapes sont équivalentes pour Windows 11 (à quelques occurrences IDE près qui devraient être remplacées par SATA). Les étapes les plus importantes sont résumées ici, et vous pouvez vous référer à la page originale pour une explication détaillée avec captures d’écran.

Dépendances

sudo apt-get install qemu-kvm bridge-utils virt-manager qemu-system virt-viewer spice-vdagent

Configuration classique

Avant de commencer le processus d’installation, vous devrez télécharger deux fichiers ISO :

Windows 11, disponible sur le site de Microsoft
L’ISO des pilotes VirtIO, nécessaire pour configurer les périphériques VirtIO pendant l’installation (le réseau est obligatoire) — montez-le comme un deuxième lecteur CDROM.

Créez une nouvelle VM qui sera installée à partir d’un fichier ISO :

CPU, mémoire : j’ai laissé les paramètres par défaut.
Taille du disque : au moins 60 Go sont recommandés — Windows lui-même occupe environ 30 Go, et les outils de compilation nécessitent 10 à 20 Go supplémentaires. Vous pouvez toujours étendre la partition après l’installation.
Créez un deuxième lecteur CDROM dans le menu Stockage (sélectionnez le type de support comme CDROM) et pointez vers l’ISO VirtIO.
Activez le démarrage depuis le CDROM SATA dans les options de démarrage. Vous pouvez également le sélectionner via le menu BIOS si la machine ne démarre pas.
Passez au pilote VirtIO pour le disque dur et la carte réseau pour de meilleures performances.

Ajustement de la prise en charge HyperV

La configuration a fonctionné jusqu’à ce que j’installe WSL2 et redémarre, moment où j’ai été accueilli par l’écran bleu avec le message SYSTEM_THREAD_EXCEPTION_NOT_HANDLED. La VM n’a jamais réussi à se rétablir.

J’ai trouvé des indications dans cet excellent article de Redpill Linpro, et après quelques essais avec l’éditeur XML dans la section “Processeur” de la configuration de la VM, j’ai réussi à redémarrer Windows avec ces paramètres :

  <features>
    <acpi/>
    <apic/>
    <pae/>
    <hyperv mode="custom">
      <vpindex state="on"/>
      <synic state="on"/>
    </hyperv>
    <smm state="on"/>
  </features>
  <cpu mode="custom" match="exact" check="partial">
    <model fallback="allow">Broadwell-noTSX-IBRS</model>
    <feature policy="disable" name="hypervisor"/>
    <feature policy="require" name="vmx"/>
  </cpu>
  <clock offset="utc">
    <timer name="rtc" tickpolicy="catchup"/>
    <timer name="pit" tickpolicy="delay"/>
    <timer name="hpet" present="no"/>
    <timer name="hypervclock" present="yes"/>
    <timer name="kvmclock" present="yes"/>
  </clock>

Je n’ai pas encore essayé d’optimiser ces paramètres au-delà de la confirmation que désactiver le passthrough CPU et sélectionner la bonne architecture CPU faisaient partie de la solution. La prochaine étape serait de consulter la documentation ou de continuer le processus d’essais-erreurs pour déterminer quelles propriétés sont réellement nécessaires ou offrent les meilleures performances. Comme le dit l’article, vos résultats peuvent varier.

À titre de référence, voici la configuration initiale proposée par QEmu :

  <features>
    <acpi/>
    <apic/>
    <hyperv>
      <relaxed state="on"/>
      <vapic state="on"/>
      <spinlocks state="on" retries="8191"/>
    </hyperv>
    <vmport state="off"/>
  </features>
  <cpu mode="host-passthrough"/>
  <clock offset="localtime">
    <timer name="rtc" tickpolicy="catchup"/>
    <timer name="pit" tickpolicy="delay"/>
    <timer name="hpet" present="no"/>
    <timer name="hypervclock" present="yes"/>
  </clock>

Installation de Windows 11

Laissez l’installateur vous guider jusqu’à l’étape où vous choisissez le disque sur lequel installer Windows. La liste devrait être vide.

Sélectionnez l’option “Charger les pilotes”, et parcourez le deuxième CDROM (E:) pour trouver les pilotes corrects pour votre système d’exploitation et votre plateforme (notez que parfois il n’y a pas de version win11, mais win10 fonctionne également) :

E:\viostor\w11\amd64 (disque)
E:\NetKVM\w11\amd64 (NIC)
E:\qxldod\w10\amd64 (graphique)

Cochez “Masquer les pilotes qui ne sont pas compatibles avec le matériel de cet ordinateur” pour vous assurer que les pilotes corrects sont trouvés. Si rien n’apparaît, vous avez peut-être oublié de passer un périphérique en VirtIO.

Plus tard dans le processus d’installation, vous n’aurez pas l’opportunité de charger de nouveaux pilotes via l’interface graphique. Vous pourriez atteindre une étape où l’installateur essaie de trouver une connexion réseau et reste bloqué faute d’interface réseau. Dans ce cas, appuyez sur Shift+F10 pour ouvrir un shell, naviguez vers les dossiers respectifs et exécutez :

pnputil /add-driver *.inf
pnputil /scan-devices

Il m’est arrivé que l’installateur trouve l’interface réseau mais refuse de se connecter faute de connectivité Internet. En exécutant un ping depuis le shell, j’ai confirmé le problème. Sur l’hôte, les paquets arrivaient au pont mais n’étaient pas transmis, probablement à cause de règles iptables manquantes. La solution la plus simple est de redémarrer libvirtd — cela n’affectera pas les VM en cours d’exécution :

sudo service libvirtd restart

Agent invité et pilotes supplémentaires

Une fois Windows installé, vous devriez également installer :

E:\virtio-win-guest-tools.exe depuis l’ISO VirtIO
Outils invités SPICE (dans la section Guest / Windows binaries) pour des fonctionnalités telles que le partage du presse-papiers et la résolution dynamique entre l’hôte et l’invité

Visual Studio et outils associés

Vous pouvez télécharger gratuitement l’installateur en ligne avec l’édition Community.

Voici les paramètres de charge de travail que j’ai utilisés pour mon cas d’utilisation actuel. Ils nécessitent environ 10 Go supplémentaires.

Web & Cloud
    [ ] ASP.NET and web development
    [ ] Azure development
    [X] Python development, could be useful
    [ ] Node.js developmen
Desktop & Mobile
    [ ] .NET Multi-platform App UI development
    [ ] .NET Desktop development
    [X] Desktop development with C++
    [ ] Universal Windows Platform development
    [ ] Mobile development with C++
Gaming
    [X] Game development with Unity
    [X] Game development with C++
Other toolsets
    [ ] Data storage and processing
    [ ] Data science and analytical applications
    [ ] Visual Studio extension development
    [ ] Office / SharePoint development
    [X] Linux and embedded development with C++

Git sera nécessaire, et vous pouvez trouver les binaires Windows sur le site officiel.

WSL2

Vous pouvez installer WSL2 directement depuis le Microsoft Store, ou via la ligne de commande comme indiqué ci-dessous.

Ouvrez cmd.exe depuis le menu démarrer et exécutez en tant qu’administrateur :

1	`wsl --install`

Si vous avez Windows 11, ou une version suffisamment récente de Windows 10, vous devriez déjà avoir WSL2. Confirmez avec :

$ wsl -v
WSL version: 2.1.4.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.2861

Plus d’informations peuvent être trouvées dans wslinfo, wsl1 et wsl2. Le système vous demandera de redémarrer.

Vous pouvez ensuite installer une distribution Linux (par exemple Debian) :

$ wsl --install --distribution Debian

Installing Windows optional component: VirtualMachinePlatform

Deployment Image Servicing and Management tool
Version: 10.0.22621.2792

Image Version: 10.0.22631.2861

Enabling feature(s)
[==========================100.0%==========================]
The operation completed successfully.
The requested operation is successful. Changes will not be effective until the system is rebooted.
Installing: Debian GNU/Linux
Debian GNU/Linux has been installed.
The requested operation is successful. Changes will not be effective until the system is rebooted.

Après avoir choisi un identifiant et un mot de passe, vous devriez avoir un shell Linux fonctionnel.

Maintenance

Si vous manquez d’espace disque, vous pouvez soit essayer de récupérer de l’espace, soit étendre le fichier image de Windows.

Récupérer de l’espace : Compact OS, mémoire virtuelle et fichiers d’hibernation

Vous pouvez d’abord essayer de désinstaller les applications inutilisées, bien que la configuration décrite ci-dessus n’ait pratiquement aucun logiciel supplémentaire installé.

Vous pouvez récupérer quelques Go en compressant les fichiers système à l’aide de la fonctionnalité “Compact OS” de Windows, en suivant ce tutoriel :

Ouvrez le menu Démarrer.
Recherchez Invite de commandes, faites un clic droit sur le résultat et sélectionnez Exécuter en tant qu’administrateur.
Vérifiez si Compact OS est déjà activé :

1	`Compact.exe /CompactOS:query`

Activez Compact OS :

1	`Compact.exe /CompactOS:always`

Le processus de compression peut prendre jusqu’à 20 minutes. Vous pouvez annuler la modification à tout moment avec Compact.exe /CompactOS:never.

Vous pouvez également économiser de l’espace en réduisant les fichiers de mémoire virtuelle et d’hibernation. Ouvrez une invite de commandes en tant qu’administrateur et exécutez :

1	`powercfg /h /type reduced`

Cela réduit le fichier d’hibernation d’environ 30 %. Pour le supprimer entièrement :

1	`powercfg /h /off`

Pour restaurer le fichier d’hibernation complet plus tard :

1	`powercfg /h /size 100`

Extension de la taille de l’image QEmu

Pendant que la VM est arrêtée, redimensionnez l’image :

sudo qemu-img resize /var/lib/libvirt/images/win11.qcow2 +10G

Vous pouvez ensuite utiliser le Gestionnaire de disques de Windows pour étendre le système de fichiers sur l’espace nouvellement disponible.

Je n’ai pas pu déplacer la partition de récupération située entre le lecteur C: et l’espace non alloué depuis Windows. Pour contourner cela, vous pouvez utiliser les outils côté hôte :

sudo modprobe nbd max_part=16
sudo qemu-nbd -c /dev/nbd0 /var/lib/libvirt/images/win11.qcow2

Le gestionnaire de partitions KDE n’a initialement pas vu les 10 Go supplémentaires. GParted les a vus, mais a affiché un avertissement :

Not all of the space available to /dev/nbd0 appears to be used, you can fix
the GPT to use all of the space (an extra 20971520 blocks) or continue with
the current setting?

Après avoir réparé la table GPT, les deux outils ont fonctionné correctement :

1	`sudo gparted /dev/nbd0`

Une fois terminé, déconnectez l’image :

sudo qemu-nbd -d /dev/nbd0

Références

Run Windows 11 on Linux with QEmu Nested Virtualization

2024-03-14T00:00:00+01:00

I exclusively run Linux at home, and needed a Windows VM for building the virtual pinball suite and other software that required me to use the Windows Subsystem for Linux (WSL2).

Virtualbox vs QEmu

I initially chose Virtualbox for simplicity but never managed to install WSL2 on it. It appears that WSL2 is implemented on top of Windows HyperV technology, and it thus requires nested virtualization features to be used inside a VM.

Unlike what is announced in official documentation wsl-virtualbox, it seems nested virtualization support for HyperV did not make it to the latest 7.0 Virtualbox release (7.0.14-Debian as of this writing), and thus it was not possible to install WSL2 vbox-hyperv. This might change with the release of 7.1.

WslRegisterDistribution failed with error: 0x80370102
Please enable the Virtual Machine Platform Windows feature and ensure virtualization is enabled in the BIOS.
For information please visit https://aka.ms/enablevirtualization

This is the opportunity to give a try at QEmu which supports it and promises to be more efficient with the use of KVM and virtio.

QEmu setup

I followed the excellent writeup by raphtlw, for which the steps are equivalent for Windows 11 (beyond a couple of remaining IDE occurrences that should be SATA). The most important steps are summarized here and you can refer to the original page for a detailed explanation with screenshots.

Dependencies

sudo apt-get install qemu-kvm bridge-utils virt-manager qemu-system virt-viewer spice-vdagent

Regular setup

Before starting the installation process, you will need to download two ISOs:

Windows 11, available on the Microsoft website
The VirtIO drivers ISO, needed to set up both VirtIO devices during installation (network is mandatory) — mount it as a second CDROM drive.

Create a new VM that will be installed from an ISO file:

CPU, memory: I left the default settings.
Disk size: at least 60 GB is recommended — Windows itself takes around 30 GB, and build tools require an additional 10–20 GB. You can always extend the partition after installation.
Create a second CDROM drive in the Storage menu (select the medium type as CDROM) and point to the VirtIO ISO.
Enable boot from the SATA CDROM in Boot options. You can also select it via the BIOS menu if the machine does not boot.
Switch to VirtIO driver for both the HDD and the NIC for improved performance.

Fine-tuning HyperV support

The setup worked fine until I installed WSL2 and rebooted, at which point I was greeted by the infamous blue screen with the message SYSTEM_THREAD_EXCEPTION_NOT_HANDLED. The VM never managed to recover.

I found directions in this excellent writeup from Redpill Linpro, and after a couple of tries with the XML editor in the “Processor” section of the VM configuration, I managed to boot Windows again with these settings:

  <features>
    <acpi/>
    <apic/>
    <pae/>
    <hyperv mode="custom">
      <vpindex state="on"/>
      <synic state="on"/>
    </hyperv>
    <smm state="on"/>
  </features>
  <cpu mode="custom" match="exact" check="partial">
    <model fallback="allow">Broadwell-noTSX-IBRS</model>
    <feature policy="disable" name="hypervisor"/>
    <feature policy="require" name="vmx"/>
  </cpu>
  <clock offset="utc">
    <timer name="rtc" tickpolicy="catchup"/>
    <timer name="pit" tickpolicy="delay"/>
    <timer name="hpet" present="no"/>
    <timer name="hypervclock" present="yes"/>
    <timer name="kvmclock" present="yes"/>
  </clock>

I have not yet tried to optimize these settings beyond confirming that disabling CPU passthrough and selecting the correct CPU architecture were part of the solution. The next step would be to dig into the documentation or continue the trial-and-error process to find which properties are actually required, or lead to the best performance. As the article says, your results may vary.

As a reference, here is the original configuration proposed by QEmu:

  <features>
    <acpi/>
    <apic/>
    <hyperv>
      <relaxed state="on"/>
      <vapic state="on"/>
      <spinlocks state="on" retries="8191"/>
    </hyperv>
    <vmport state="off"/>
  </features>
  <cpu mode="host-passthrough"/>
  <clock offset="localtime">
    <timer name="rtc" tickpolicy="catchup"/>
    <timer name="pit" tickpolicy="delay"/>
    <timer name="hpet" present="no"/>
    <timer name="hypervclock" present="yes"/>
  </clock>

Windows 11 installation

Let the installer guide you until you reach the step where you choose on which disk to install Windows. The list should be empty.

Select the “Load drivers” option, and browse the second CDROM (E:) to find the correct drivers for your OS and platform (note that sometimes there is no win11 version but win10 also works):

E:\viostor\w11\amd64 (disk)
E:\NetKVM\w11\amd64 (NIC)
E:\qxldod\w10\amd64 (graphics)

Check “Hide drivers that are not compatible with this computer’s hardware” to ensure the correct drivers are found. If nothing shows up, you may have forgotten to switch a device to VirtIO.

Further down in the installation process, you will not have the opportunity to load new drivers through the GUI. You might reach a step where the installer tries to find a network connection and gets stuck because there is no network interface. In that case, hit Shift+F10 to open a shell, navigate to the respective folders, and run:

pnputil /add-driver *.inf
pnputil /scan-devices

It happened to me that the installer found the network interface but refused to connect because of no internet connectivity. Running a ping from the shell confirmed the issue. On the host, packets arrived at the bridge but were not forwarded, likely because of missing iptables rules. The simplest fix is to restart libvirtd — this will not affect running VMs:

sudo service libvirtd restart

Guest agent and additional drivers

Once Windows is installed, you should also install:

E:\virtio-win-guest-tools.exe from the VirtIO ISO
SPICE guest tools (under the Guest / Windows binaries section) for features such as clipboard sharing and dynamic resolution between the host and guest

You can freely download the installer online with the Community edition.

These are the workload settings I used for my current use case. They require approximately 10 additional GB.

Web & Cloud
    [ ] ASP.NET and web development
    [ ] Azure development
    [X] Python development, could be useful
    [ ] Node.js developmen
Desktop & Mobile
    [ ] .NET Multi-platform App UI development
    [ ] .NET Desktop development
    [X] Desktop development with C++
    [ ] Universal Windows Platform development
    [ ] Mobile development with C++
Gaming
    [X] Game development with Unity
    [X] Game development with C++
Other toolsets
    [ ] Data storage and processing
    [ ] Data science and analytical applications
    [ ] Visual Studio extension development
    [ ] Office / SharePoint development
    [X] Linux and embedded development with C++

Git will be required, and you can find Windows binaries from the official website.

WSL2

You can install WSL2 directly from the Microsoft store, or through the command line as shown below.

Open cmd.exe from the start menu and run as administrator:

1	`wsl --install`

If you have Windows 11, or a recent enough version of Windows 10, you should already have WSL2. Confirm with:

$ wsl -v
WSL version: 2.1.4.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.2861

More information can be found in wslinfo, wsl1 and wsl2. The system will ask you to reboot.

You can then install a Linux distribution (e.g. Debian):

$ wsl --install --distribution Debian

Installing Windows optional component: VirtualMachinePlatform

Deployment Image Servicing and Management tool
Version: 10.0.22621.2792

Image Version: 10.0.22631.2861

Enabling feature(s)
[==========================100.0%==========================]
The operation completed successfully.
The requested operation is successful. Changes will not be effective until the system is rebooted.
Installing: Debian GNU/Linux
Debian GNU/Linux has been installed.
The requested operation is successful. Changes will not be effective until the system is rebooted.

After choosing a login and password, you should have a working Linux shell.

Maintenance

If you run out of disk space, you can either try to reclaim some space or extend the Windows image file.

Reclaim space: Compact OS, virtual memory and hibernation files

You can first try to uninstall unused applications, although the setup described above has hardly any extra software installed.

You can reclaim a few GB by compressing system files using the “Compact OS” feature of Windows, following this tutorial:

Open Start.
Search for Command Prompt, right-click the result, and select Run as administrator.
Check whether Compact OS is already enabled:

1	`Compact.exe /CompactOS:query`

Enable Compact OS:

1	`Compact.exe /CompactOS:always`

The compression process may take up to 20 minutes. You can revert the change at any time with Compact.exe /CompactOS:never.

You can also save space by reducing the virtual memory and hibernation files. Open an administrator Command Prompt and run:

1	`powercfg /h /type reduced`

This reduces the hibernation file by about 30%. To remove it entirely:

1	`powercfg /h /off`

To restore the full hibernation file later:

1	`powercfg /h /size 100`

Extending the QEmu image size

While the VM is shut down, resize the image:

sudo qemu-img resize /var/lib/libvirt/images/win11.qcow2 +10G

You can then use Windows’ Disk Manager to extend the filesystem over the newly available space.

I could not move the recovery partition sitting between the C: drive and the unallocated space from within Windows. To work around this, you can use the host-side tools:

sudo modprobe nbd max_part=16
sudo qemu-nbd -c /dev/nbd0 /var/lib/libvirt/images/win11.qcow2

KDE Partition Manager did not initially see the additional 10 GB. GParted did, but raised a warning:

Not all of the space available to /dev/nbd0 appears to be used, you can fix
the GPT to use all of the space (an extra 20971520 blocks) or continue with
the current setting?

After repairing the GPT, both tools worked correctly:

1	`sudo gparted /dev/nbd0`

Once done, disconnect the image:

sudo qemu-nbd -d /dev/nbd0

References

Remplacer la bougie d'allumage d'un poêle Palazzetti Lara

2024-02-21T00:00:00+01:00

La bougie tournait depuis sept ans sans avoir jamais été remplacée. Quand elle a cessé de fonctionner en plein hiver, la solution la plus rapide était de la remplacer moi-même.

Après des échecs occasionnels au démarrage pendant quelques mois, le poêle à granulés a cessé de s’allumer complètement. Un test rapide avec du papier a confirmé que la bougie d’allumage était hors service sans avoir besoin d’ouvrir le poêle. Ce post couvre le diagnostic, le choix de la pièce de rechange correcte (le type de bride est la dimension critique) et la procédure de remplacement.

Symptômes et diagnostic

Pendant quelques mois, le poêle a présenté des échecs occasionnels au démarrage malgré son nettoyage annuel. Finalement, il a cessé de s’allumer complètement — la vis sans fin alimentait normalement les granulés, le ventilateur de combustion fonctionnait, mais aucune ignition ne se produisait.

Tout indiquait que la bougie d’allumage (également appelée bougie ou résistance chauffante) était en cause : le ventilateur d’admission fonctionnait (confirmé en plaçant une feuille de papier contre le tuyau d’admission — elle était aspirée fortement), et la vis sans fin alimentait les granulés, donc la panne se situait dans le circuit d’allumage.

Confirmation que la bougie d’allumage est hors service sans ouvrir le poêle : démarrez un cycle d’allumage normal, attendez les 5 minutes nécessaires à l’allumage, puis — tout en restant dans la phase d’allumage — ouvrez la porte, bloquez temporairement l’entrée des granulés, retirez le bac à granulés et glissez un petit morceau de papier dans le compartiment de la bougie d’allumage. L’absence de marques de chaleur sur le papier confirme que la bougie ne fonctionne pas.

Les bougies d’allumage durent généralement environ 3 ans en utilisation normale. La mienne n’avait jamais été remplacée en 7 ans, ce qui était largement dépassé.

Ouverture du poêle et confirmation avec un multimètre

Le poêle peut être ouvert sur place :

Coupez l’alimentation électrique au mur.
Retirez le panneau supérieur, les panneaux latéraux et la grille arrière.
La bougie d’allumage est vissée dans le tube d’admission d’air et fixée par une seule vis accessible depuis le côté droit.
Suivez le câble de la bougie jusqu’à la carte de contrôle située en bas à droite du poêle. Vous devrez couper quelques colliers de câbles et dévisser le couvercle de la boîte de contrôle pour libérer suffisamment de longueur de câble.

La bougie d’allumage est un élément résistif — la polarité n’a pas d’importance. Mesurer les bornes avec un multimètre en mode continuité devrait indiquer une faible résistance (typiquement 100–200 Ω pour un élément en bon état). La mienne n’indiquait aucune continuité, confirmant qu’elle était en circuit ouvert.

Choix de la pièce de rechange correcte

Le Palazzetti Ecofire Lara utilise une bougie d’allumage standard pour poêle à granulés avec les spécifications suivantes :

Paramètre	Valeur
Puissance	350 W
Longueur totale	170 mm
Longueur sous bride	160 mm
Résistance (neuve)	~138–150 Ω

Le type de bride est la dimension qui pose problème à beaucoup de gens. Il existe deux brides courantes : une bride plate en acier (correcte pour Palazzetti) et un raccord hexagonal en laiton (conçu pour une installation filetée dans d’autres marques). Elles ne sont pas interchangeables.

Amazon propose ces pièces à un prix environ moitié ou un tiers inférieur à celui des fournisseurs spécialisés en pièces de chauffage, et la pièce est un élément résistif standard sans électronique propriétaire. Le modèle que j’ai choisi¹ était disponible pour une livraison le lendemain — un critère important en plein hiver.

Vérification avant installation : le nouvel élément mesurait 150 Ω.

$$R_\text{expected} = \frac{U^2}{P} = \frac{230^2}{350} \approx 151\ \Omega \quad \checkmark$$

$$P_\text{actual} = \frac{U^2}{R} = \frac{230^2}{150} \approx 353\ \text{W} \quad \checkmark$$

Suffisamment proche de la spécification. Le poêle n’a pas besoin d’un élément de précision ici — toute valeur dans une marge de ~10 % du nominal est acceptable.

Procédure de remplacement

Coupez les anciens colliers de câbles maintenant le câble de la bougie le long de son chemin d’acheminement. Notez le chemin d’origine avant de couper — le câble fait une large boucle à droite puis à gauche pour atteindre la carte de contrôle.
Dévissez la vis de fixation unique sur le côté droit du boîtier de la bougie.
Retirez la bougie du tube d’admission.
Faites glisser la gaine isolante en céramique de l’ancien câble sur le câble de la nouvelle bougie, en la coupant à la bonne longueur si nécessaire.
Acheminer le nouveau câble sur un chemin plus direct vers la carte de contrôle (le câble de remplacement était légèrement plus court que l’original ; un chemin plus droit a résolu ce problème).
Connectez à la borne de la carte de contrôle — l’orientation n’a pas d’importance.
Fixez le câble avec de nouveaux colliers de câbles.
Insérez la bougie dans le tube d’admission et serrez la vis de fixation.
Remontez les panneaux.

Au prochain démarrage, le poêle s’est allumé en 3–4 minutes, retrouvant son temps d’allumage normal.

La réparation a pris une demi-heure et coûté moins de 25 €. Le test au papier dans la section diagnostic est une petite astuce trouvée en ligne — elle permet de confirmer qu’une bougie est morte sans ouvrir quoi que ce soit, ce qui évite un démontage inutile quand on cherche encore la panne.

Bougie d’allumage pour poêle à granulés 350W 170mm — achetée en février 2024 pour 19,99 €. Une alternative moins chère était disponible (B01MRJ01FN à ~16 €) mais n’a pas été testée. ↩

Replacing the spark plug of a Palazzetti Lara pellet stove

2024-02-21T00:00:00+01:00

The igniter had been running for seven years without a replacement. When it stopped firing mid-winter, the fastest fix was to do it myself.

After occasional startup failures over a few months, the pellet stove stopped lighting entirely. A quick paper test confirmed the igniter was dead without needing to open the stove. This post covers the diagnosis, choosing the right replacement part (flange type is the critical dimension), and the replacement procedure.

Symptoms and diagnosis

Over a few months the stove developed occasional startup failures despite its annual cleaning. Eventually it stopped lighting at all — the auger fed pellets normally, the combustion fan ran, but no ignition.

Everything pointed to the igniter (also called the spark plug or glow plug): the intake fan was working (confirmed by holding a sheet of paper against the intake pipe — it was drawn in strongly), and the auger was delivering pellets, so the fault was in the ignition path.

Confirming the igniter is dead without opening the stove: start a normal ignition cycle, wait the full 5 minutes it would normally take to light, then — while still in the ignition phase — open the door, temporarily block the pellet inlet, remove the pellet tray, and slip a small piece of paper into the igniter compartment. No heat marks on the paper confirms the igniter is not firing.

Igniters typically last around 3 years under normal use. Mine had never been replaced in 7 years, so this was overdue.

Opening the stove and confirming with a multimeter

The stove can be opened in place:

Cut power at the wall.
Remove the top panel, side panels, and rear grille.
The igniter is threaded into the air intake tube and secured with one screw accessible from the right side.
Trace the igniter cable to the control board in the lower right of the stove. You will need to cut a few cable ties and unscrew the control box cover to free enough cable length.

The igniter is a resistive element — polarity does not matter. Measuring across the terminals with a multimeter in continuity mode should show a low resistance (typically 100–200 Ω on a healthy element). Mine showed no continuity at all, confirming it was open-circuit.

Choosing the correct replacement

The Palazzetti Ecofire Lara takes a standard pellet stove igniter with these specifications:

Parameter	Value
Power	350 W
Total length	170 mm
Length under flange	160 mm
Resistance (new)	~138–150 Ω

The flange type is the dimension that catches people out. There are two common flanges: a flat steel flange (correct for Palazzetti) and a hexagonal brass fitting (designed for threaded installation in other brands). They are not interchangeable.

Amazon offers these at roughly half to one-third the price of specialist heating parts suppliers, and the part is a commodity resistive element with no proprietary electronics. The model I chose¹ was available for next-day delivery — not a small consideration mid-winter.

Verification before installation: the new element measured 150 Ω.

$$R_\text{expected} = \frac{U^2}{P} = \frac{230^2}{350} \approx 151\ \Omega \quad \checkmark$$

$$P_\text{actual} = \frac{U^2}{R} = \frac{230^2}{150} \approx 353\ \text{W} \quad \checkmark$$

Close enough to spec. The stove does not need a precision element here — any value within ~10% of nominal is fine.

Replacement procedure

Cut the old cable ties holding the igniter cable along its routing path. Note the original path before cutting — the cable makes a wide loop right then left to reach the control board.
Unscrew the single retaining screw on the right side of the igniter housing.
Pull the igniter out of the intake tube.
Slide the ceramic insulating sleeve from the old cable onto the new igniter cable, trimming it to length if needed.
Route the new cable along a more direct path to the control board (the replacement cable was slightly shorter than the original; a straighter route solved this).
Connect to the control board terminal — either orientation is correct.
Secure the cable with new cable ties.
Insert the igniter into the intake tube and tighten the retaining screw.
Reassemble the panels.

On the next startup the stove lit within 3–4 minutes, back to its normal ignition time.

The repair took about half an hour and cost under €25. The paper test in the diagnosis section is a small trick I came across online — it lets you confirm a dead igniter before opening anything, which is worth knowing when you’re trying to identify the fault without disassembly.

Pellet stove igniter 350W 170mm — purchased February 2024 for €19.99. A cheaper alternative was available (B01MRJ01FN at ~€16) but was not tested. ↩

Installation d'un CR-Touch sur un CR-10S d'origine

2022-07-20T00:00:00+02:00

Le CR-Touch fonctionne très bien sur les cartes 8 bits — le signal PWM servo et la sortie numérique de déclenchement sont parfaitement dans les capacités d’un ATmega2560. Le problème avec le CR-10S stock n’est pas le processeur, c’est le connecteur : les guides Creality supposent tous un connecteur BLTouch 5 broches dédié que la carte V2 d’origine n’a pas. Cet article documente le câble adaptateur qui relie deux connecteurs existants, le patch Marlin en une ligne, et la procédure de réglage de l’offset sonde.

Le problème avec la carte d’origine

Les guides d’installation CR-Touch supposent presque tous un connecteur BLTouch 5 broches dédié sur la carte mère. Creality a ajouté ce connecteur sur ses nouvelles cartes 32 bits (CR-10S Pro, CR-6 SE, etc.), et la documentation officielle ne couvre que celles-là. La carte stock du CR-10S V2 — un ATmega2560 — est antérieure à ce connecteur. Le CR-Touch lui-même se fiche de l’architecture du processeur ; il a besoin de cinq signaux, et ces signaux sont disponibles sur deux connecteurs existants que la carte V2 expose déjà : un connecteur servo D11 libre (3 broches) et le connecteur fin de course Z (2 broches). Pas de carte adaptateur, pas de découpe de câble.

Fabrication du câble adaptateur

L’adaptateur divise le connecteur 5 broches JST du CR-Touch en deux branches :

une fiche Dupont femelle 3 broches pour le connecteur servo D11
une fiche JST 2 broches remplaçant le connecteur de fin de course Z

Le risque principal est d’inverser le connecteur : une erreur de câblage peut endommager le CR-Touch. Utilisez un multimètre en mode continuité pour vérifier avant la mise sous tension. Les deux broches de masse (G) du CR-Touch sont court-circuitées en interne, ce qui permet de les confirmer facilement en les sondant simultanément.

Le câblage correct pour le CR-10S d’origine est indiqué ci-dessous. Notez que les fils GND (blanc) et VIN (noir) se croisent entre le connecteur CR-Touch et le connecteur D11 — la broche 1 du D11 est VIN, mais VIN est le second fil du CR-Touch.

Broche CR-Touch	Couleur fil	Destination	Signal
G	Blanc	D11 broche 2	GND
V	Noir	D11 broche 1	VIN (+5V)
IN	Jaune	D11 broche 3	Signal
G	Rouge	Fin de course Z broche 2	GND
OUT	Bleu	Fin de course Z broche 1	OUT

Le connecteur D11 se lit de gauche à droite : noir (VIN) — blanc (GND) — jaune (SIG) vu côté fiche. Le connecteur fin de course Z a le bleu (OUT) sur la broche 1 et le rouge (GND) sur la broche 2.

Conseil de vérification : sondez les deux broches G (blanc et rouge) en continuité — elles doivent biper. Vérifiez aussi le VIN par rapport à un point +5 V connu sur la carte avant la mise sous tension pour confirmer la polarité.

Patch Marlin 2

Les définitions de broches RAMPS/Creality par défaut dans Marlin ne définissent pas SERVO0_PIN, ce qui laisse le signal servo du BLTouch flottant. Modifiez Marlin/src/pins/ramps/pins_RAMPS_CREALITY.h en ajoutant à l’intérieur du bloc #ifdef NUM_SERVOS existant :

#ifdef NUM_SERVOS
  #define SERVO0_PIN 11
#endif

Ce mapping assigne le servo 0 à la broche 11, correspondant au connecteur D11 utilisé ci-dessus.

Paramètres Configuration.h

Activez les defines suivants dans Configuration.h :

#define BLTOUCH                          // traite le CR-Touch comme un BL-Touch
#define USE_PROBE_FOR_Z_HOMING           // homing Z via la sonde, pas le fin de course
#define Z_SAFE_HOMING                    // évite de crasher la sonde hors du plateau

// Grille de sondage
#define GRID_MAX_POINTS_X 7              // maillage de niveau 7×7

// Assistants de calibration (optionnels mais recommandés)
#define PROBE_OFFSET_WIZARD
#define PROBE_OFFSET_WIZARD_START_Z -4.0

// Babystepping (peut déjà être activé dans les versions récentes de Marlin)
#define BABYSTEPPING
#define BABYSTEP_DISPLAY_TOTAL
#define BABYSTEP_ZPROBE_OFFSET

Comprendre l’état des LEDs

Après le flash et la mise sous tension, le CR-Touch effectue un auto-test. Les LEDs rendent compte du résultat :

État LED	Signification
🔴 Rouge seule, fixe	Alimentation OK ; signal PWM pas encore reçu
🔴🔵 Rouge + Bleu (violet)	Auto-test réussi — sonde prête
🔴 Rouge clignotante	Auto-test échoué — broche bloquée ou obstruée

Si l’auto-test passe mais que seule la LED rouge s’allume (pas de bleu), le câble de signal PWM est probablement mal connecté ou lâche. Fixez le connecteur Dupont maison avec du scotch ; vérifiez le fil signal sur la broche 3 du D11.

Une fois la LED bleue allumée, testez le déploiement et l’escamotage depuis le menu Marlin Mouvement → BLTouch avant de lancer une impression.

Réglage de l’offset sonde

NOZZLE_TO_PROBE_OFFSET { X, Y, Z } définit la position de la pointe de sonde par rapport à la buse. X et Y dépendent du montage du support ; Z est la hauteur de déclenchement.

N’essayez pas de régler Z à la compilation. Laissez-le à 0 dans le build et utilisez l’Assistant d’offset sonde (Mouvement → Offset sonde dans le menu Marlin) pour le régler en live. L’assistant utilise un test papier pour trouver la hauteur exacte de déclenchement et écrit le résultat en EEPROM.

Pour X/Y, des valeurs typiques avec le support métal Creality standard :

Axe	Valeur typique	Notes
X	−44 à −46	Mesurez sur votre support ; −44 est un bon point de départ
Y	−9	Généralement stable quelle que soit la position du support
Z	0 (compilation)	Régler en live via l’Assistant d’offset, sauvegardé en EEPROM

1	`#define NOZZLE_TO_PROBE_OFFSET { -44, -9, 0 }`

Si les résultats de première couche dérivent latéralement, mesurez la distance réelle buse-sonde avec un pied à coulisse et ajustez X/Y en conséquence.

Babystepping et ajustement Z en direct

Le babystepping permet de régler l’offset Z en cours d’impression sans arrêter l’impression. Avec BABYSTEP_ZPROBE_OFFSET activé, l’ajustement est persistant : il met à jour l’offset sonde stocké en EEPROM, pas seulement un décalage temporaire. Workflow recommandé :

Lancer une impression.
Observer la première couche ; utiliser le menu babystepping pour corriger si nécessaire.
La valeur corrigée est sauvegardée automatiquement.

Pour un guide visuel combinant l’Assistant d’offset sonde et le babystepping, voir ce guide de calibration Z.

Visualisation du nivellement de plateau

Si vous utilisez OctoPrint, le plugin Bed Level Visualizer affiche le maillage sous forme de carte de chaleur 3D. Il est utile pour repérer les problèmes physiques de plateau qu’aucune correction Z ne peut résoudre, comme un châssis voilé ou non de niveau.

Quatre ans après (2026)

Une fois calibré, le CR-Touch devient invisible — la première couche fonctionne, point. Le câble adaptateur est la seule étape non standard ; une fois ce problème de connecteur réglé, c’est de la configuration Marlin classique. Quatre ans plus tard, je n’ai pas eu à recalibrer une seule fois.

Installing a CR-Touch on a stock CR-10S

2022-07-20T00:00:00+02:00

The CR-Touch works on 8-bit boards just fine — the PWM servo signal and digital trigger output are well within ATmega2560 capabilities. The catch with the stock CR-10S is not the processor, it is the connector: Creality’s guides all assume a dedicated 5-pin BLTouch header that the stock V2 board does not have. This article documents the adapter cable that bridges two existing headers, the one-line Marlin patch, and the probe offset workflow.

This guide assumes you are already running custom Marlin 2 on your printer. If you are still on stock firmware, see Building and flashing Marlin 2 on a CR-10S V2 first.

The stock board problem

CR-Touch installation guides almost universally assume a dedicated 5-pin BLTouch header on the mainboard. Creality added that header on newer 32-bit boards (CR-10S Pro, CR-6 SE, etc.), and the official documentation only covers those. The stock CR-10S V2 board — an ATmega2560 — predates that header. The CR-Touch itself does not care about the processor architecture; it needs five signals, and those signals are available on two existing headers the V2 board already exposes: a free D11 servo header (3 pins) and the Z endstop header (2 pins). No adapter board, no cut wires.

Building the adapter cable

The adapter splits the CR-Touch’s 5-pin JST connector into two branches:

a 3-pin female Dupont plug for the D11 servo header
a 2-pin JST plug replacing the Z endstop connector

The main risk is reversing the connector: getting the pinout wrong can damage the CR-Touch. Use a multimeter in continuity mode to verify before powering on. The two ground pins (G) on the CR-Touch are shorted internally, which makes them easy to confirm by probing both simultaneously.

The correct wiring for the stock CR-10S is shown below. Note that the GND (white) and VIN (black) wires cross between the CR-Touch connector and the D11 header — pin 1 of the D11 header is VIN, but VIN is the second wire out of the CR-Touch.

CR-Touch pin	Wire colour	Destination	Signal
G	White	D11 pin 2	GND
V	Black	D11 pin 1	VIN (+5V)
IN	Yellow	D11 pin 3	Signal
G	Red	Z endstop pin 2	GND
OUT	Blue	Z endstop pin 1	OUT

The D11 header reads left to right: black (VIN) — white (GND) — yellow (SIG) when viewed from the plug side. The Z endstop header has blue (OUT) on pin 1 and red (GND) on pin 2.

Verification tip: probe both G pins (white and red) with continuity — they should beep. Also verify VIN against a known +5 V point on the board before powering on, to confirm polarity.

Patching Marlin 2

Marlin’s default RAMPS/Creality pin assignments do not define SERVO0_PIN, so the BLTouch servo signal floats. Edit Marlin/src/pins/ramps/pins_RAMPS_CREALITY.h and add inside the existing #ifdef NUM_SERVOS block:

#ifdef NUM_SERVOS
  #define SERVO0_PIN 11
#endif

This maps servo 0 to pin 11, which corresponds to the D11 header used above.

Configuration.h settings

Enable the following defines in Configuration.h:

#define BLTOUCH                          // treats CR-Touch like BL-Touch
#define USE_PROBE_FOR_Z_HOMING           // home Z using the probe, not the endstop
#define Z_SAFE_HOMING                    // prevents crashing the probe off the bed edge

// Probe grid
#define GRID_MAX_POINTS_X 7              // 7×7 bed level mesh

// Calibration helpers (optional but recommended)
#define PROBE_OFFSET_WIZARD
#define PROBE_OFFSET_WIZARD_START_Z -4.0

// Babystepping (may already be enabled in recent Marlin versions)
#define BABYSTEPPING
#define BABYSTEP_DISPLAY_TOTAL
#define BABYSTEP_ZPROBE_OFFSET

Understanding the LED status

After flashing and powering up, the CR-Touch runs a self-test sequence. The LEDs report the result:

LED state	Meaning
🔴 Red only, solid	Power OK; PWM signal not yet received from the board
🔴🔵 Red + Blue (purple)	Self-test passed — probe is ready
🔴 Red blinking	Self-test failed — pin stuck or obstructed

If the self-test passes but only the red LED lights (no blue), the PWM signal cable is likely loose or miswired. Secure the Dupont connector with a piece of tape; double-check the signal wire on D11 pin 3.

Once the blue LED is on, test deploy and stow from the Marlin Motion › BLTouch menu before starting any print.

Setting the probe offset

NOZZLE_TO_PROBE_OFFSET { X, Y, Z } defines the probe tip position relative to the nozzle. X and Y depend on your bracket mounting; Z is the trigger height.

Do not try to get Z right at compile time. Leave it at 0 in the build and use the Probe Offset Wizard (Motion › Probe Offset in the Marlin menu) to dial it in live using the paper test. The wizard writes the result to EEPROM.

For X/Y, typical values with the standard Creality metal bracket are:

Axis	Typical value	Notes
X	−44 to −46	Measure from your own bracket; −44 is a common starting point
Y	−9	Generally consistent across mounting positions
Z	0 (compile)	Set live via Probe Offset Wizard, saved to EEPROM

1	`#define NOZZLE_TO_PROBE_OFFSET { -44, -9, 0 }`

If first-layer results drift laterally, measure the actual nozzle-to-probe distance with calipers and adjust X/Y accordingly.

Babystepping and live Z adjustment

Babystepping lets you nudge the Z offset mid-print without stopping. With BABYSTEP_ZPROBE_OFFSET enabled, the adjustment is persistent: it updates the stored probe offset in EEPROM, not just a temporary shift. Recommended workflow:

Start a print.
Watch the first layer; use the babystepping menu to correct if needed.
The corrected value is saved automatically.

For a visual walkthrough combining the Probe Offset Wizard and babystepping, see this Z-offset calibration guide.

Bed levelling visualisation

If you use OctoPrint, the Bed Level Visualizer plugin renders the mesh as a 3D heatmap. It is useful for spotting physical bed problems that no Z offset correction can fix, such as a warped or unlevel frame.

Four years later (2026)

Once calibrated, the CR-Touch is one of those upgrades that becomes invisible — the first layer just works. The adapter cable is the only non-standard step; once you’re past the connector problem, it’s standard Marlin configuration. Four years in, I have not had to recalibrate it once.

Accueil de LANMAN 2019 — Démo sur la gestion par politiques

2019-07-01T00:00:00+02:00

Nous accueillons IEEE LANMAN 2019 à Paris du 1er au 3 juillet 2019.

Je présenterai une démonstration de nos derniers travaux sur la gestion des réseaux par politiques lors de l’atelier.

Hosting LANMAN 2019 — Demo on Policy-Based Networking

2019-07-01T00:00:00+02:00

We are hosting IEEE LANMAN 2019 in Paris from 1–3 July 2019.

I will be presenting a demo on our latest work on policy-based networking at the workshop.

IETF-102 Montréal — Session DMM sur la mobilité hICN

2018-07-14T00:00:00+02:00

Je participerai à IETF-102 à Montréal du dimanche 14 juillet au vendredi 20 juillet.

Nous présenterons deux drafts IETF dans la session du groupe de travail Distributed Mobility Management (DMM) décrivant la gestion de la mobilité dans les réseaux 5G par des mécanismes hICN :

IETF-102 Montréal — DMM Session on hICN Mobility

2018-07-14T00:00:00+02:00

I will be attending IETF-102 in Montréal from Sun 14 July to Fri 20 July.

We will be presenting two IETF drafts in the Distributed Mobility Management (DMM) Working Group session describing mobility management in 5G networks using hICN mechanisms:

Publication du draft IRTF MAP-ME

2018-07-02T00:00:00+02:00

La première version de notre draft MAP-Me: Managing Anchorless Mobility in Content Centric Networking est en ligne.

Tout retour est le bienvenu.

MAP-ME IRTF Draft Published

2018-07-02T00:00:00+02:00

The first version of our draft MAP-Me: Managing Anchorless Mobility in Content Centric Networking is online.

Any feedback is welcome.

IETF-101 Londres — Présentation à l'ICNRG sur MAP-ME

2018-03-17T00:00:00+01:00

Je serai à IETF-101 à Londres du samedi 17 mars au jeudi 22 mars.

Le dimanche, je donne une présentation à la réunion intérimaire de l’ICNRG sur notre article MAP-ME: Managing Anchor-less Producer Mobility in Content-Centric Networks.

IETF-101 London — ICNRG Interim Talk on MAP-ME

2018-03-17T00:00:00+01:00

I will be at IETF-101 in London from Sat 17 March to Thu 22 March.

On Sunday I am giving a talk at the ICNRG interim meeting related to our paper MAP-ME: Managing Anchor-less Producer Mobility in Content-Centric Networks.

ITU 5G Demo Video — ICN for Delivery, Mobility and Security

2016-12-15T00:00:00+01:00

L’ITU a publie le 15 decembre 2016 une video publique de demo 5G montrant comment l’ICN pouvait etre utilise pour la diffusion de donnees, la gestion de mobilite et le transport securise.

Cet artefact est l’une des traces publiques datees les plus nettes de la famille hICN / Hybrid ICN dans un format de demonstration, et pas seulement au travers d’articles ou de code.

Artefact public

Artefact video public : Using ICN to simplify data delivery, mobility management and secure transmission

ITU 5G Demo Video — ICN for Delivery, Mobility and Security

2016-12-15T00:00:00+01:00

The ITU published a public 5G demo video on 15 December 2016 showing how ICN could be used for data delivery, mobility management, and secure transmission.

This artifact is one of the clearest dated public traces of the hICN / Hybrid ICN family in a demonstration format rather than only through papers or code.

Public artifact

Public video artifact: Using ICN to simplify data delivery, mobility management and secure transmission

"Video CiscoFrance : publication d'une demo de mobilite ICN"

2016-04-15T00:00:00+02:00

CiscoFrance a publie le 15 avril 2016 une video de demonstration publique autour de la mobilite avec l’Information-Centric Networking.

Cet artefact public est utile parce qu’il conserve une demonstration datee de la narration mobilite autour de l’ICN, au-dela des articles scientifiques et des descriptions de projet.

Artefact public

Artefact video public : ICN Demo - Rethinking mobility with information centric networking

CiscoFrance Video: ICN Mobility Demo Published

2016-04-15T00:00:00+02:00

CiscoFrance published a public demo video on 15 April 2016 around mobility with Information-Centric Networking.

This matters as a public artifact because it preserves a dated demonstration of the mobility narrative around ICN, beyond papers and project descriptions.

Public artifact

Public video artifact: ICN Demo - Rethinking mobility with information centric networking

"Video TelecomTV : l'ICN dans la recherche 5G de Cisco"

2016-03-16T00:00:00+01:00

TelecomTV a publie le 16 mars 2016 une video publique consacree a l’Information-Centric Networking (ICN) dans la trajectoire plus large de recherche 5G de Cisco.

Cet artefact public est utile parce qu’il fournit une trace externe datee de la maniere dont ce travail ICN etait presente publiquement a l’epoque, dans un format plus simple a citer que des slides internes ou des demos non archivees.

Artefact public

Artefact video public : Information Centric Networking driving Cisco’s 5G research

TelecomTV Video: ICN Driving Cisco's 5G Research

2016-03-16T00:00:00+01:00

TelecomTV published a public video segment on 16 March 2016 covering Information-Centric Networking (ICN) as part of Cisco’s broader 5G research direction.

This public artifact matters because it gives a dated external trace of how the ICN work was presented publicly at the time, in a format that is easier to cite than internal slides or undocumented demos.

Public artifact

Public video artifact: Information Centric Networking driving Cisco’s 5G research