# Migration intégration Netatmo : plantage de Gladys **URL:** \ **Category:** Configuration\ **Tags:** integration-externe\ **Created:** [Août 3, 2026, 8:30 UTC](https://community.gladysassistant.com/t/migration-integration-netatmo-plantage-de-gladys/10444 "2026-08-03T20:30:02Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![mutmut](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/mutmut/32/14064_2.png) [@mutmut](https://community.gladysassistant.com/u/mutmut)\ **Post date:** [Août 3, 2026, 8:30 UTC](https://community.gladysassistant.com/t/migration-integration-netatmo-plantage-de-gladys/10444/1 "2026-08-03T20:30:02Z")
Suite au démarrage de la migration d’un appareil Netatmo, après 49mn et seulement 5% d’effectué, Gladys à planté et redémarré semble-t-il ☹ ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/8/a/8a208cfe5e68a6975e995d03fa94471d16ca42c1.png) Logs dispo pour analyse. J’ai les 2 calculs de conso qui n’avançaient pas vite du tout et en regardant les courbes des CPU (4vCPU), ça ne dépassait pas les 10%. On est sur du mono-thread pour les calculs ou je lme trompe complètement ? ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/e/c/eccf35ff37dbf87dab2a526cd24600daa6ebd215.png) Le plantage est à 22h17 sur le graphique, le blanc correspond à des infos non récupérée, Gladys fonctionnait très bien. Côté disque, j’ai des montées/descentes et depuis le plantage je suis resté très haut ! ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/d/9/d995ded25697dce6d7895b3b292aa842d020703e.png) Comment fait-on pour nettoyer tout ça ? un reboot du docker ? EDIT : ajout de la charge moyenne : ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/2/a/2aad4a32589f881df95d2f20d3ee89c6202cc52f.png) ---
**Author:** ![mutmut](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/mutmut/32/14064_2.png) [@mutmut](https://community.gladysassistant.com/u/mutmut)\ **Post date:** [Août 3, 2026, 9:13 UTC](https://community.gladysassistant.com/t/migration-integration-netatmo-plantage-de-gladys/10444/2 "2026-08-03T21:13:32Z")
Après investigation, c’est mon script sur proxmox qui voit que la RAM est à fond (5.9GB/6GB) pendant la migration et redémarre alors le docker Gladys. Je vais désactiver ça. Par contre il faut combien de RAM pour migrer un appareil sans migrer son historique ? J’ai l’impression que ça bouffe beaucoup de mémoire. ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Août 4, 2026, 5:58 UTC](https://community.gladysassistant.com/t/migration-integration-netatmo-plantage-de-gladys/10444/3 "2026-08-04T05:58:25Z")
> [@mutmut](#): > > Par contre il faut combien de RAM pour migrer un appareil sans migrer son historique ? Tout dépend du volume de scène / tableaux de bord à migrer, mais c’est relativement léger je pense. Après, migrer l’historique ça doit passer largement sur ta machine je pense ---
**Author:** ![mutmut](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/mutmut/32/14064_2.png) [@mutmut](https://community.gladysassistant.com/u/mutmut)\ **Post date:** [Août 4, 2026, 1:51 UTC](https://community.gladysassistant.com/t/migration-integration-netatmo-plantage-de-gladys/10444/4 "2026-08-04T13:51:38Z")
Je n’en ai pas énormément (scène/dashboard) où j’utilise l’anémomètre par exemple (c’est lui que j’essayais de migrer. Ma duckDB fait presque 10Go, est-ce que ça joue ? En tout cas hier je migrais l’appareil sans aucun historique et ça faisait monter le RAM jusqu’à plantage (6Go) et ensuite redémarrage manuel car OOM. Aujourd’hui j’ai passé mon LXC de 6 à 8Go de RAM, lancer la migration sans historique : hyper rapide ! ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/1/d/1d62a8f5a8d7e09b8794ff4dad311f912a1d58c1.png) Mais alors ça me prend une RAM de fou et surtout la libération de la RAM ne se fait pas du tout après 🤨 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/9/0/90a7acc6e0dc23a97d3e816dac7cca58b11867f3.png) J’avoue ne pas comprendre ce qu’il se passe, si quelqu’un a une piste ? EDIT : config de mon LXC docker → 4vCPU, 8Go RAM, Disk 30Go. ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Août 4, 2026, 7:20 UTC](https://community.gladysassistant.com/t/migration-integration-netatmo-plantage-de-gladys/10444/5 "2026-08-04T19:20:32Z")
Aïe effectivement si ta base fait 10 Go et qu’il y a beaucoup d’états à migrer, alors oui ça peut prendre pas mal de temps et pas mal de RAM. Est-ce que tu as une possibilité d’allouer temporairement plus de RAM juste le temps de la migration ? Sur la mémoire qui « ne se libère pas » après : c’est normal et ce n’est pas une fuite. DuckDB garde ses pages en cache jusqu’à sa limite mémoire et le système ne la rend pas immédiatement. Elle est réutilisée par Gladys et libérée sous pression. Et je te conseille de désactiver le redémarrage automatique sur seuil RAM pendant ce genre d’opération : redémarrer Gladys au milieu d’une migration laisse le travail à moitié fait (c’est rejouable, mais autant l’éviter). ---
**Author:** ![mutmut](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/mutmut/32/14064_2.png) [@mutmut](https://community.gladysassistant.com/u/mutmut)\ **Post date:** [Août 4, 2026, 7:55 UTC](https://community.gladysassistant.com/t/migration-integration-netatmo-plantage-de-gladys/10444/6 "2026-08-04T19:55:18Z")
> [@pierre-gilles](#): > > Et je te conseille de désactiver le redémarrage automatique sur seuil RAM déjà fait > [@pierre-gilles](#): > > Est-ce que tu as une possibilité d’allouer temporairement plus de RAM juste le temps de la migration ? déjà fait mais il va falloir que je passe à 10 ou 12Go car j’ai une migration en cours depuis plus d’1h et les 8Go sont pleins et Gladys plante, le dashboard ne se rafraichit plus ☹ > [@pierre-gilles](#): > > DuckDB garde ses pages en cache jusqu’à sa limite mémoire et le système ne la rend pas immédiatement. Elle est réutilisée par Gladys et libérée sous pression. ok je vais surveiller alors histoire de voir ce qu’il se passe avec le temps. Bon je m’en vais redémarrer encore une fois Gladys ☹ Quelqu’un a eu le même soucis avec une migration ? ---
**Author:** ![spenceur](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/spenceur/32/1961_2.png) [@spenceur](https://community.gladysassistant.com/u/spenceur)\ **Post date:** [Août 4, 2026, 7:56 UTC](https://community.gladysassistant.com/t/migration-integration-netatmo-plantage-de-gladys/10444/7 "2026-08-04T19:56:41Z")
Jai le meme soucis quand je supprime un device. ---
**Author:** ![Will\_71](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/will_71/32/9582_2.png) [@Will\_71](https://community.gladysassistant.com/u/Will_71)\ **Post date:** [Août 4, 2026, 8:14 UTC](https://community.gladysassistant.com/t/migration-integration-netatmo-plantage-de-gladys/10444/8 "2026-08-04T20:14:17Z")
@mutmut, Pas de souci de mon côté avec une configuration presque identique à la tienne. J’ai migrer mon thermostat Netatmo sans problème, sans ralentissement et çà été très rapide. Ma base fait 6 Go ---
**Author:** ![mutmut](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/mutmut/32/14064_2.png) [@mutmut](https://community.gladysassistant.com/u/mutmut)\ **Post date:** [Août 4, 2026, 8:59 UTC](https://community.gladysassistant.com/t/migration-integration-netatmo-plantage-de-gladys/10444/9 "2026-08-04T20:59:39Z")
J’ai réussi à passer mon LXC à 12Go en live sans rebooter et la migration de ma station externe (avec tout à migrer) a pris 1h26 et gros ralentissement sur les calculs de conso le temps de la migration. ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/a/e/aeac8dcb35c7ae5864a71da8b383543bd68b9144.png) Je bascule sur la sonde interne avec la totale à migrer. En tout cas pour les 4 modules à migrer, un par un, j’en suis à plus de 24h ☹ Le soucis principal que je vois c’est que tant que la migration n’est pas finie, le calcul de conso est en standby, ainsi que tous ceux qui arrivent après. Il faudrait diminuer la priorité de la migration pour laisser les calculs de conso se faire et ça permettrait aussi d’avoir toujours la main sur les dashboards. Pour exemple, le calcul de conso vient de se lancer, donc 2 tâches avec la migration, et ça ralenti énormément ma Gladys. ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Août 5, 2026, 6:09 UTC](https://community.gladysassistant.com/t/migration-integration-netatmo-plantage-de-gladys/10444/10 "2026-08-05T06:09:24Z")
Merci, ces chiffres sont très utiles, et ton analyse est la bonne. Ce qui coûte cher n’est pas l’historique de l’appareil que tu migres, c’est la taille totale de ta base : chaque fonctionnalité est déplacée par une requête qui parcourt et réécrit des morceaux répartis dans tout le fichier de 10 Go. Une station externe = 4 à 6 fonctionnalités = autant de passes complètes, d’où ton 1h26. C’est aussi pour ça que @Will_71 n’a rien vu : un thermostat, c’est 3 fois moins de fonctionnalités sur une base plus petite. Et je te préviens tout de suite : la sonde interne sera la plus longue des quatre, c’est le module qui a le plus de fonctionnalités. Sur ta suggestion de baisser la priorité de la migration : tu as raison sur le principe, mais il n’y a pas de priorité à régler : le déplacement est aujourd’hui une seule grosse requête SQL, et tant qu’elle tourne rien ne peut s’intercaler. La bonne correction, c’est de la découper en tranches, comme le fait déjà la purge d’états : la mémoire reste bornée, et Gladys reprend la main entre chaque tranche pour les calculs de conso et les dashboards. C’est ce que je vais faire, avec au passage une vraie progression (aujourd’hui tu restes bloqué à 5 % pendant toute l’opération, ce qui n’aide personne). Le fait que tu aies dû monter à 12 Go n’est pas normal : ce n’est pas du cache, c’est de la mémoire de transaction non plafonnée. Après correctif, ça devrait passer sans rien ajouter. @spenceur ton cas à la suppression a probablement la même racine et sera regardé en même temps. Je vous tiens au courant ! ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Août 5, 2026, 6:54 UTC](https://community.gladysassistant.com/t/migration-integration-netatmo-plantage-de-gladys/10444/11 "2026-08-05T06:54:04Z")
Proposition : > > > Field report (community thread 10444): migrating a Netatmo weather station on a > …10 GB database took 1h26, pushed the RAM past 8 GB until the container was > restarted, and left the jobs page at 5% for the whole run. > > The history move ran one UPDATE per mapped feature over the whole table. Its > cost is therefore (number of features x size of the database), not the size of > the migrated device's history, and each statement held the single DuckDB write > connection from start to finish while allocating transaction memory that > memory\_limit does not bound. > > Move every mapped feature in the same statement, in created\_at slices: > > \- one UPDATE ... SET device\_feature\_id = CASE ... END per slice, followed by the > DELETE of whatever is left on the source features (overlap period and unmapped > features), instead of one pass per feature; > \- destination cutoffs read with one MIN(...) FILTER per pair in a single > statement, and the source range/volume in another one: the per-feature > metadata queries were themselves a full scan each, device\_feature\_id not > being indexed; > \- the first slice has no lower bound and the last one no upper bound, so states > written while the migration runs are never left behind; > \- the write connection is released between two slices, plus a duty-cycle pause > of one slice duration, so live inserts, dashboards and energy computations > keep running; > \- progress is reported per slice with a live moved-states counter, instead of > sitting at 5% until the move is over. > > Measured on a synthetic 2.9 GB / 176M-state database, moving a 6-feature device: > 347 s -\> 18.6 s, and the file grows by 6% instead of doubling (2.9 -\> 5.8 GB). > An INSERT + DELETE variant was also measured and rejected: twice the time of the > sliced UPDATE and a peak RSS above twice the memory limit. > > The per-feature purge had the same fixed-slice-count weakness (a single DELETE > below a million states, then ten slices whatever the volume): it now slices to > keep each statement around the same target size. > > Co-Authored-By: Claude Opus 5 \ > Claude-Session: https://claude.ai/code/session\_01BYPzK9ey1NXzvPaC3ArL6J > > > > \## Summary by CodeRabbit > > \* \*\*New Features\*\* > \* Device migration now transfers history in time-based slices with bounded resource usage. > \* Migration progress includes a live count of historical states moved. > \* Job details display the migrated-state count in English, German, and French. > \* Migration responses report the total number of transferred historical states. > > \* \*\*Bug Fixes\*\* > \* Improved handling of overlapping, unmapped, concurrent, and back-dated history during migration. > \* Large history purges now process data in dynamically sized batches for more reliable performance. **Merci pour tes mesures, elles ont permis de trouver le problème, et il est corrigé.** **La cause.** Le déplacement de l’historique lançait une requête par fonctionnalité, et chacune balayait toute ta base. Le coût réel n’est donc pas proportionnel à l’historique de l’appareil que tu migres, mais au produit (nombre de fonctionnalités × taille de la base). Une station météo a 5 ou 6 fonctionnalités, donc 5 ou 6 passes complètes sur tes 10 Go : voilà ton 1h26. C’est aussi pourquoi Will\_71 n’a rien vu avec son thermostat, moins de fonctionnalités sur une base plus petite. Et ta remarque sur la priorité était juste : la migration monopolisait la connexion d’écriture DuckDB du début à la fin, rien ne pouvait s’intercaler. **Ce qui a été fait.** L’historique est maintenant déplacé par tranches, toutes les fonctionnalités traitées dans la même requête. Gladys rend la main entre chaque tranche, avec une pause volontaire de la durée de la tranche, pour que les calculs de conso et les dashboards continuent de tourner. La progression est réelle, avec un compteur d’états déplacés en direct, fini le 5 % figé. La suppression d’appareil a été corrigée au passage, c’est le même mécanisme (ça devrait répondre à spenceur). **Les mesures** , sur une base de test de 2,9 Go et 176 millions d’états, pour un appareil de 6 fonctionnalités : **•** durée : 347 s avant, 18,6 s après **•** taille du fichier DuckDB : il **doublait** pendant l’opération (2,9 Go qui passaient à 5,8 Go), il grossit maintenant de 6 % Sur une base 5 fois plus petite le gain n’était que d’un facteur 4,5, contre 18 ici : plus la base est grosse, plus le gain est important, donc sur tes 10 Go ça devrait être au moins aussi bon. Compte plutôt un facteur 9 en pratique, la pause volontaire coûte environ la moitié du temps, c’est le prix pour que Gladys reste utilisable. **Mes réserves, pour être honnête avec toi :** Je n’ai pas réussi à reproduire ton explosion de RAM à 8 Go sur ma base de test, le gain mémoire mesuré est modeste. Ce que j’ai reproduit très clairement, c’est le doublement du fichier sur le disque, et je pense que c’est ça ta vraie cause : dans un LXC, le cache disque compte dans la RAM vue par ton script Proxmox, donc écrire 3 Go de plus remplit la mémoire telle qu’il la mesure. Ça colle exactement à tes courbes de disque. Mais tant que tu n’as pas retesté chez toi, ça reste une hypothèse. ---
**Author:** ![mutmut](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/mutmut/32/14064_2.png) [@mutmut](https://community.gladysassistant.com/u/mutmut)\ **Post date:** [Août 5, 2026, 11:39 UTC](https://community.gladysassistant.com/t/migration-integration-netatmo-plantage-de-gladys/10444/12 "2026-08-05T11:39:06Z")
> [@pierre-gilles](#): > > la sonde interne sera la plus longue des quatre, c’est le module qui a le plus de fonctionnalités. et bien non, « seulement » 44mn07s mais avec 12Go de RAM le temps que ça passe. > [@pierre-gilles](#): > > fini le 5 % figé Top ! car ça n’apportait rien comme info complémentaire. > [@pierre-gilles](#): > > Ce que j’ai reproduit très clairement, c’est le doublement du fichier sur le disque, et je pense que c’est ça ta vraie cause : dans un LXC, le cache disque compte dans la RAM vue par ton script Proxmox Je l’ai effectivement eu car mon LXC avait 20Go de disque et j’ai dû le passer rapidement à 30Go pour ne plus être bloqué par l’espace utilisé par la base. Concernant le cache, maintenant que tu en parles, il est de 1go sur mon LXC et à chaque fois que la RAM explosait, le cache était totalement plein. Je ne sais pas si c’était avant ou après par contre. Chose étrange lorsque je suis passé à 12Go temporairement, la RAM est montée presque à fond et une fois toutes les tâches finies elle est redescendue à 7-7,2Go sans jamais allez plus bas ou plus haut. Le cache était toujours plein donc je me suis permis un petit reboot et repassage à 8Go. Actuellement je tourne aux alentours 5Go de RAM sur les 8Go alloués, le swap est quasi vide. Je vais essayer de retester la migration avec ton prochain fix sur un backup que j’ai sur une instance de test, pour voir la différence et je te tiendrai au courant ici. En tout cas merci pour ton investigation et résolution ! ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Août 5, 2026, 4:50 UTC](https://community.gladysassistant.com/t/migration-integration-netatmo-plantage-de-gladys/10444/13 "2026-08-05T16:50:39Z")
C’est bon la PR est prête : [Slice the device migration history move and cut its passes over DuckDB by Pierre-Gilles · Pull Request #2778 · GladysAssistant/Gladys · GitHub](https://github.com/GladysAssistant/Gladys/pull/2778) Si tu veux tester @mutmut il y a un build Docker 🙂 ```auto ghcr.io/gladysassistant/gladys-preview:claude-netatmo-migration-user-response-8qbebx ``` ---
**Author:** ![mutmut](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/mutmut/32/14064_2.png) [@mutmut](https://community.gladysassistant.com/u/mutmut)\ **Post date:** [Août 12, 2026, 3:27 UTC](https://community.gladysassistant.com/t/migration-integration-netatmo-plantage-de-gladys/10444/14 "2026-08-12T15:27:02Z")
Corrigé avec [Gladys Assistant 4.85.0 : widget Photo, navigation dans les graphiques, chauffe-eau & HomeKit](https://community.gladysassistant.com/t/gladys-assistant-4-85-0-widget-photo-navigation-dans-les-graphiques-chauffe-eau-homekit/10483) Pour info, les tests concluants sur une zimaboard et docker avec 7Go de ram pour Gladys et peu d’espace disque de libre (1.5Go de libre pour une duckDB de 5.5Go) : ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/c/2/c2f3907ebfeb17bbe02ca20b6b0659fd88189dc0.png) La ram a un peu augmenté mais sans aller en limite. Superbe optimisation, bravo @pierre-gilles 🙌 Sur mon proxmox avec LXC (6go de ram et une DB de 5.5Go) : environ 500-700Mo de disque utilisé pendant la migration, et une `DUCKDB_MEMORY_LIMIT=2000MB` dans mon docker compose. ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/2/8/28185a7f2e6c61cedd2d6f96a191cf6b08606182.png) ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/d/e/de34dc9378e89aab5a86540dc98644df3754e69c.png) Ma DB est passée de 5.5Go à 6.3Go après la migration. ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Août 12, 2026, 5:24 UTC](https://community.gladysassistant.com/t/migration-integration-netatmo-plantage-de-gladys/10444/15 "2026-08-12T17:24:25Z")
Excellent !! Content d’apprendre que ça a résolu ton souci 😁