Hello
C’est la bonne image
1 « J'aime »
Je viens de refaire une installation avec l’image officielle en 64. Je n’ai rencontré aucune difficulté. Attention, lors de la migration d’une 32 vers une 64 il est nécessaire de bien relancer toutes les dépendances des plugins. J’ai mis un boîtier argon sur un pi4 avec un SSD. Température de 40 degré, excellente stabilité. Par contre niveau réaction c’est pas hyper flagrant. Disons que la 64 c’est l’avenir, donc autant anticiper. Amitiés. Phil
Merci.
J’ai toujours le Pi3B+ (iso au mien de production) qui tourne depuis le 23 décembre 2020, en 64bits avec une restauration de mon Jeedom de production.
Constat depuis les historiques de Jeedom :
Les (+)
+ La charge 1/5/15 est plus faible sur le 64 bits (mais attention, les deamons des plugins Z-Wave et RFXCom ne sont pas démarrés)
+ Le benchmark de Jeedom donne un avantage au 64 bits (entre 1 et 2 points)
Les (-)
- La consommation de la RAM est supérieure en 64 bits (toujours avec 2 deamons à l’arrêt) (17% de consommation de mémoire en plus)
Par contre, je ne constate pas d’amélioration à l’usage (comme la vitesse d’affichage sur le navigateur). J’ai les deux installations en // sur le même matériel, cela me permet de tout tester.
Les annonces sonores (qui sont des MP3 enregistrées à l’avance) sont même jouées plus tôt (1 seconde au moins) sur l’installation en 32 bits (ce qui donnerais un avantage au 32 bits, mais ne n’en tiens pas compte ici).
Je ferais un retour de ce type dès que ma production passera en 64bits (je prend le temps de tester et je prépare la migration en v4 en même temps).
/!\ Attention, tu parles de migration vers 64bits depuis une 32bits, ce n’est pas une bonne idée du tout (cela n’est même pas possible depuis Windows par exemple).
3 « J'aime »
Bonjour @Fabrice
Non, je me suis mal exprimé…
Je suis bien parti d’une 64 directement via l’image officielle. Je voulais juste préciser que suite à la restauration du Backup, j’avais du relancer l’installation des dépendances à la main pour certain plugin qui ne démarraient pas même après plusieurs heures.
Je ne fais pas une généralité de mon cas car j’en ai profité pour changer de contrôleur zwave (razberry vers aeotec 5 et bluetooth vers clé sedna), donc je pense que les changements de port ont pu entraîner cela.
Pour la charge sur ma jeedom de prod, c’est nettement mieux, environ à.70 au lieu de 1,20. J’ai un PI4 avec 4GO.
Tout cela me conforte dans mon choix de rester sur un PI, univers que je connais particulièrement bien.
Amitiés
Ha ok,
J’avais mal compris.
C’est aussi le cas chez moi, pour le plugin PlayTTS par exemple (l’installation des dépendances ne se fait pas automatiquement). Sur ce plugin, j’ai une autre curiosité, la date d’installation des dépendances reste désespérément à la date d’installation initiale de ce plugin chez moi.
- Comme pour MailListener et Monitoring entre autre.
Tout pareil pour les Pi, j’aime bien.
Merci pour ces informations
1 « J'aime »
Bonjour à tous,
Je fais le retour de mon passage éclair en 64 bits sur Raspberry Pi 3B+
Installation de l’image officielle de Raspberry Pi OS 64 bits (08/2020) + update / upgrade du 30/12/2020 et Jeedom 4.0.61.
Constat au bout de 2 jours (visible dans les historiques de Jeedom) :
Augmentation de la charge CPU (1/5/15), consommation de la mémoire RAM supérieur à l’édition 32 bits (15% en plus en moyenne).
Mais le fonctionnement de Jeedom était toujours correct.
Plantage 1 : (j+4)
- Plus rien ne répondait
- Module de chauffage bloqué en ON (n’a jamais reçu l’ordre d’arrêt)
=> reboot : ok
Après analyse des logs/var/log: la machine a cessée de vivre à 06h du matin, comme si on lui avait retiré le disque.
Plantage 2 :
- réponse aux pings : ok
- connexion SSH : nok
- accès web Jeedom : nok
- état Jeedom : non fonctionnel
=> reboot : ok
Plantage 3 :
- réponse aux pings : nok
- (donc pas de WEB/SSH)
- Etat de Jeedom : fonctionnel (le thermostat était ok, les annonces sonores aussi, ainsi que tout ce qui fonctionne avec RFXcom en automatique).
- La sauvegarde automatique de la nuit, a générée une erreur et la sauvegarde sur le NAS (la taille du fichier n’était que de 20mo / 83mo normalement)
=> reboot : ok
Raspberry Pi 3B+ de test (sur MicroSD) : n’est pas lié au Z-Wave et RFXCom
1 plantage : plus rien ne répondait (cela est arrivé en cours d’utilisation, à distance)
=> reboot : ok
Visite du forum de raspberry.org :
Bon, bah je me sens moins seul, beaucoup d’utilisateur rencontrent des problèmes liés à l’USB et aux pertes de la carte réseau. Les mises à jour successives du Kernel n’ont pas corrigées ces problèmes.
Au final, je suis repassé ce lundi en 32 bits (sur les 2 RPi)
Je note au passage, l’inverse que j’ai pu constater après l’installation en 64 bits, l’historique : température / charge CPU est moins élevé en 32 bits et il reste plus de mémoire RAM de disponible.
dmesg : absence des erreurs OTG visibles en 64 bits
Pour information, ma précédente installation de Jeedom avait un uptime qui correspondait toujours aux derniers redémarrage que j’effectuais (suite aux mises à jour OS), en 64 bits mon plus gros uptime : 4 jours.
Conclusion : J’en conclus une très large dégradation du uniquement au passage en Raspberry Pi OS 64 bits. Pour le moment en tout cas, je ne recommande pas du tout le passage en 64 bits sur ce type de Raspberry (testé uniquement avec Raspberry Pi OS 64bits (qui est en bêta)).
Nous sommes plusieurs utilisateurs à avoir fait ce constat (sur ce forum).
3 « J'aime »
- 1 tout a fait d’accord avec toi
J’ai moi meme remis en 32 b sur 2 rpi
Bonjour, je vais être l’exception alors.
Depuis un peu plus de 2 mois que j’ai fais ma fresh installe image officielle buster 64bits en installation automatique suivant la doc jeedom, je suis bien plus stable qu’avant. J’ai eux vraiment aucun plantage sur mon pi3b+.
Avant j’avais quelques plantages, plus d’accès à jeedom.
Alors depuis cette fresh installe j’ai le même matériel j’ai juste mis une sd car suspicion du câble du msata défectueux.
J’ai constaté une baisse de la charge par rapport à avant sous stretch toujours jeedom v4.
J’ai pas poussé plus l’investigation et les comparaisons.
Bonjour,
Moi, ce qui parle, c’est pas le ressentie, c’est les historiques (pas de facteur humain faussé).
Ce que je ne sais pas, c’est si l’image de Jeedom est réalisée depuis une Debian ARM 64 bits ou si elle est effectuée depuis une Raspberry Pi OS 64 bits. La différence (si c’est le cas) peut être à l’origine de la stabilité que vous avez.
Je l’ai tenté sur 2 machines et dans les 2 cas, je suis déçu.
Alors, par rapport à la vue du plugin Monitoring, soit votre OS n’est pas à jours (45 jours de uptime le prouve) et donc, nous (ceux qui plantent) on à eu une version plus récente qui plante.
Car par exemple, ce plugin n’est plus capable de remonter la température du CPU sur les nouveaux Kernel (5.10.5) de Raspberry Pi OS.
Ou alors elle est figée chez vous.
C’est une piste…
Mon uptime est un peu faussé, il faut rajouté 20 jours environ car j’avais redémarré mon jeedom mais pas de plantage.
Depuis cette installe je n’ai pas fais de « sudo apt upgrade » faut -il le faire ? je suppose que oui mais si j’ai bien compris j’aurais plus la température et peut etre aussi des risques de plantage si c’est la piste.
La baisse de charge CPU je l’explique par le passage du msata a une carte sd (à confirmer quand même). Le jour ou elle lache je repasse sur mon msata avec nouveau câble car on avait discuté ensemble des problèmes de câbles des disques msata.
Hello,
Si la 64bits est en bêta ce n’est pas pour rien 
Perso j’attends la stable pour ma domotique.
Salut,
Ca veut dire que tu n’as pas les dernières mises à jour de sécurité par exemple et comme c’est un jeedom il est ouvert sur l’extérieur j’imagine.
Tu joue avec le feu là
Alors la, j’ai la solution !
C’est une petite modification à faire sur le fichier /boot/config.txt pour ceux qui on un SSD.
- la charge monte / la température aussi, pour justement rechercher une carte MicroSD : et cela le fait tout le temps. Il suffit alors de modifier le fichier config.txt en ajoutant simplement cette ligne (en bas) :
dtparam=sd_poll_once
Et hop, un reboot plus tard, la charge / température diminue drastiquement.
Je note ta modif dans un coin
Donc je la mise à jour je la fais avec la commande cité plus haut?
Et comme le dit @lone je joue avec le feu mais comme je savais pas je m’inquiétais pas, maintenant si lol
D’abord
sudo apt update
pour mettre à jour tes dépots
sudo apt upgrade
pour la mise à jour elle même
Je ferai la mise à jour tout a l’heure ou demain.
Un reboot après ?
Si ca plante dans quelques jours, je vous en tiens tout les 2 comme responsables 
Alors, ne le fait pas.
=> c’est mon conseil (alors que je suis le 1er à pousser tout le monde à le faire !)
Peut-être que ta version est justement pas concerné par les problèmes que j’ai décris.
Et encore, je ne rentre pas trop dans les détailles (log dmesg / plus de remonté des températures avec Monitoring / compilation de mplayer impossible (testé ok avec Lone en 32 bits : nous avons suivit la même procédure)
1 « J'aime »
Non coupable, linux me paye pas 
Sinon oui, un reboot de temps en temps fait pas de mal.
1 « J'aime »
je choisis quoi ?
Hello,
J’ai plus de pi avec jeedom, mais j’avais clairement pas ce genre de souci de stabilité avec la version 64b en mars/juillet de l’année dernière…