Tu ne peux pas couvrir les 4 Go d’un coup ? Il y a bien 4 Go sur l’Atlas non ?
Oui mais comme jeedom tourne en même temps je ne peux pas tester tout, il faut lui en laisser
Deuxième memtester ok, je continuerai une autre fois par acquis de conscience.
Par contre plus haut dans le fil @Aurelien mentionnait un potentiel problème avec le plugin phone-detection et/ou le bluetooth.Sur ces conseils j’avais supprimé il y a plusieurs semaines ce plugin, puis refait une fresh install deb 12/restore jeedom 4.6 après cette suppression pour obtenir un système sans trace de ce plugin. C’est ma situation actuelle.
Et donc en y repensant je me souviens que à l’époque où j’avais encore ce plugin après install/restore le contrôleur BT n’était pas reconnu et j’avais fait des manips (avec l’aide de Claude IA) pour le réactiver.
Actuellement, je n’utilise donc plus ce plugin phone-detection ni le BT et je n’ai donc pas cherché à corriger quoi que ce soit côté BT, mais j’ai tout de même qqch qui cloche je pense: la commande sudo systemctl status bluetooth me retourne ça
* bluetooth.service - Bluetooth service
Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; preset: enabled)
Active: active (running) since Sun 2026-07-19 09:05:36 CEST; 8h ago
Docs: man:bluetoothd(8)
Main PID: 345 (bluetoothd)
Status: "Running"
Tasks: 1 (limit: 4567)
Memory: 2.5M
CPU: 93ms
CGroup: /system.slice/bluetooth.service
`-345 /usr/libexec/bluetooth/bluetoothd
Jul 19 09:05:36 JeedomAtlas bluetoothd[345]: profiles/audio/mcp.c:mcp_init() D-Bus experimental not enabled
Jul 19 09:05:36 JeedomAtlas bluetoothd[345]: src/plugin.c:plugin_init() Failed to init mcp plugin
Jul 19 09:05:36 JeedomAtlas bluetoothd[345]: profiles/audio/bap.c:bap_init() D-Bus experimental not enabled
Jul 19 09:05:36 JeedomAtlas bluetoothd[345]: src/plugin.c:plugin_init() Failed to init bap plugin
Jul 19 09:05:36 JeedomAtlas bluetoothd[345]: profiles/network/bnep.c:bnep_init() kernel lacks bnep-protocol support
Jul 19 09:05:36 JeedomAtlas bluetoothd[345]: src/plugin.c:plugin_init() System does not support network plugin
Jul 19 09:05:36 JeedomAtlas bluetoothd[345]: Bluetooth management interface 1.23 initialized
Jul 19 09:05:36 JeedomAtlas systemd[1]: Started bluetooth.service - Bluetooth service.
Jul 19 09:05:37 JeedomAtlas bluetoothd[345]: profiles/sap/server.c:sap_server_register() Sap driver initialization failed.
Jul 19 09:05:37 JeedomAtlas bluetoothd[345]: sap-server: Operation not permitted (1)
Une piste à creuser ?
Bon j’ai toujours des crashs, la fréquence varie franchement et je n’arrive pas à corréler avec un quelconque évènement. Les memtester s’enchainent et sont tous ok.
Est-ce que la piste du bluetooth évoqué ci-dessus serait à creuser ?
Est-ce qu’un autre outil de diagnostic pourrait être utilisé ?
Est-ce qu’un outil comme mcpIA qui aurait accès à mon jeedom pourrait investiguer en profondeur ? J’ai survolé les discussions à ce sujet mais je ne sais pas trop me positionner sur la fiabilité/la confiance qu’on peut lui accorder.
@akenad je me permets de te solliciter pour savoir si tu as une idée sur des diagnostics supplémentaires à faire ? Et/ou si la piste du Bluetooht mentionné ci-dessus est à creuser ? J’ai vu sur un autre fil que tu parlais du package network-manager issu du plugin Atlas qui pouvait entrer en conflit, je n’ai plus ce plugin ni ce package (vérifié avec which) mais peut-être qu’il en existe d’autre dans la même veine ?
Possible.
Akenad a dit un jour que la désinstallation du plugin Atlas ne désinstalle pas network-manager.
Ce que je confirme aussi parce que j’utilise nm après avoir désinstallé le plugin Atlas. Je ne savais pas que c’était le plugin qui l’installait.
Bonjour @rom.jou
le plugin mcpIA pourra chercher dans les logs (et recouper plusieurs ou toutes les logs entre elles en fonction d’un horaire par exemple), et recouper des comportements, chercher dans l’historique des commandes, mais il n’a pas accès à autre chose que ton Jeedom (donc logs, commandes, historiques, etc…), il n’a donc pas accès au système, ni au logs systèmes, etc…
C’est un outil puissant, mais cela reste un outil / une aide, il ne fait pas à la place de (et c’est valable pour toute IA d’ailleurs).
Il peut t’aider à investiguer, recouper des infos, mais il faudra toujours rester attentif et critique par rapport à ses conclusions (c’est comme tout, quand tu n’as qu’une partie du contexte, les conclusions sont à l’image : incomplètes 
)
Bref, tu peux tester, cela peut t’aider à investiguer, recouper des infos, à chercher dans l’historique des commandes, à challenger, mais cela ne résoudra pas miraculeusement ton soucis actuel
TiTidom.
Ok merci pour ta réponse détaillée, effectivement je n’avais pas pensé au fait qu’il n’avait pas accès au système mais c’est logique (et préfèrable 
).
Pour le reste oui je prends toujours du recul avec ce que me raconte une IA,ça restera une aide à l’analyse pour me donner des pistes
Oui mais je suis certain de ne plus l’avoir : j’ai réinstallé from scratch après avoir supprimé le plugin Atlas, donc ça n’a jamais lancé ses dépendances, et la commande which network-mamager ne me retourne rien. Je demandais plutôt si il y avait d’autres pistes identiques à suivre
une suggestion de test : enlever la carte interne zigbee, ne rien mettre sur l’USB, remettre l’alim fournie avec l’Atlas.
akenad 
Merci chef, faut que je regarde comment enlever la carte zigbee
Hello,
Je suis toujours le sujet mais j’ai grillé toutes mes cartouches en me basant sur les éléments précédemment fournis par le partage des logs système.
En complément de la suggestion d’@akenad, tu peux aussi tester avec cette nouvelle image système qui gère le réseau différemment :
On sait jamais sur un malentendu ça peut marcher
Merci à toi de ne pas lâcher l’affaire. Je teste ça dès que les feux se sont éloignés de chez moi et que je pourrai rentrer
Hello,
Image installée avant-hier et j’ai toujours des crashs 
.
Il me reste à tester la suggestion d’akenad de retirer la carte zigbee gpio, la clé usb zwave et remttre l’alim d’origine.
Est-ce que le fait que le contrôleur bluetooth soit inaccessible peut entrer en jeu ? Ou être un symptôme d’une autre cause racine ?
Quand je lance sudo systemctl status bluetooth j’ai ce retour :
Unit bluetooth.service could not be found.
Je n’ai aucun plugin qui utilise le BT (j’avais désactivé phone-detection avant la réinstallation donc normalement même pas de dépendances installées)
Bonjour,
Sous Debian le paquet BT n’est pas installé par défaut. En théorie sur une box Jeedom cela devrait être le cas cependant mais …
Vérifier sudo dpkg -l bluetooth
dpkg-query: no packages found matching bluetooth
Bonjour,
Du coup tu sais pourquoi tu n’as pas de service BT démarré.
Mais aucun lien avec ton problème je pense.
Je pensais la même chose en effet, mais vu que c’est étonnant que ce ne soit pas installé par défaut sur une image « officielle » (ou en tous cas créée par l’équipe jeedom) je me disais qu’il y avait peut-être une piste à creuser avec d’autres étrangetés similaires…
Le paquet doit s’installer avec les dépendances.
Ils ont dû conserver la logique d’origine de Debian (paquet pas installé par défaut).