Bonjour,
Rpi 5 en Jeedom à jour 4.4.19 avec des plantages donc, aléatoires dans les heures et la charge. Je m’en aperçois parce que les interrupteurs en Zigbee ne répondent plus.
J’ai compris en lisant d’autres topics que les différences de configurations rendent la résolution du problème très compliquée.
Mon Rpi 5 4GB a un hat SSD avec un NVMe (loin d’être rempli), une seule clé en USB (Zigbee), il est en wifi (et pas de souci wifi dans le reste de l’utilisation domestique). L’alimentation est un bloc officiel.
Comment surveiller Jeedom pour comprendre ce qu’il se passe ? Mes logs sont vides. Le système a été stable 4 mois, depuis une vingtaine de jours j’ai ce plantage. Soit la nuit, soit en journée, avec des délais très variables de quelques heures à plus de 3 jours sans plantage.
Ce que je ne sais pas c’est si l’OS est encore ok, je redémarre le Rpi (électriquement) pour récupérer ma domotique sans essayer de ping ou un accès via Putty par exemple. Ça j’ai compris que je vais devoir essayer la prochaine fois.
D’ici là, est-ce qu’il y a quelque chose à configurer dans Jeedom pour surveiller ? Ou est-ce que je peux le faire dans Debian aussi ?
Je mets un screen de la santé au moment où je pose ma question, j’ai dû rebooter Jeedom hier soir vers 22h30.
woops j’avais crop la liste de plugins en effet :
(j’ai plusieurs plugins désactivés, faut que je m’en occupe mais depuis le passage sur le Rpi5 pas eut le temps)
La fuite mémoire Xiaomi m’est connue oui, et à l’installation j’avais déjà réglé le problème. Il me semble avec JPTY d’ailleurs. Ma mémoire vive dispo reste stable à 75% dans la durée, le swap à 100%.
Sur les plugins j’ai jamais fait gaffe, my bad, je pensais qu’ils étaient tous listés là mais en fait non je viens de le voir.
je re liste :
détection de téléphone bluetooth
Enedis
ESPeasy
JeeZigbee
Monitoring
MQTT Manager
Objets SmartLife/Tuya
Script
SSH Manager
Telegram
TTS Cast
Virtuel
Weather
wifilightV2
Xiaomi Home
Sur la taille des fichiers, j’ai un journal de 862M là tout de suite.
Si je réduis sa taille et sa persistance je ne me créée pas de difficultés pour veiller sur le système ? Ou j’applique la correction (taille et délai), si le problème persiste je ferais la manoeuvre inverse ?
corrections appliquées, systemd redémarré, et puis Jeedom aussi tant qu’à faire.
wait&see.
sur ma question de comment surveiller Jeedom, il y a des petites choses à faire éventuellement ? Pour avoir une trace du moment où il plante, le truc qui donne un indice en quelque sorte.
Pour surveiller Jeedom, j’ai un autre équipement avec Jeedom qui ne fait que les vérifications ainsi t’alerter en cas de problème. Un simple raspberry est suffisant par exemple, pas besoin d’un monstre de guerre.
Pour la simple surveillance OK/KO de ton jeedom, il existe des outils de monitoring qui le font pour toi.
J’ai fait un tuto qui explique comment mettre cela en place, c’est très simple.
Et si tu possède un NAS par exemple (sur lequel tu peux virtualiser des services), tu peux aussi utiliser Uptime Kuma. C’est grosso modo exactement la même chose que UptimeRobot (utilisé dans mon tuto), mais c’est toi qui l’héberge.
Je ne comprends pas, tu parles d’une erreur htaccess 403 dans le titre ? Et tu dois rebooter pour retrouver ton accès? Un simple rafraichissement de la page + login ne suffit pas ?
Bonsoir,
j’ai pas vu l’info au moment où j’ai fait mon installation, cela dit c’était plutôt très stable. Je tenterai des tests, mais faut que je trouve du temps pour le faire merci pour le détail.
j’ai raccourci parce qu’il y a pléthores de topics sur le sujet j’avoue.
Je détaille. Je m’aperçois que Jeedom a crash via la tablette qui fait l’affichage de la domotique (appli Fully Kiosk sous Android, juste la page du design sans interactions retour) : page blanche en « Server unable to read htaccess file ».
Mon accès Jeedom est en erreur 403 en local, et timeout en externe, pas de réponse ping ou de connexion possible via Putty en local. Rien de fonctionne, zigbee ou bot Telegram tout ça tout ça.
