Non, il vaut mieux conserver ton hub, mais utilise plutôt un hub usb2.
Ça dépendra du nombre de clés sur le RPI mais le SSD, prend pas mal d’énergie.
Celui-ci est très bien :
https://www.amazon.fr/dp/B0000B0DL7/ref=cm_sw_r_cp_apa_i_6GHN5BPPNSGVFCT77CWR?_encoding=UTF8&psc=1
Ok je vais deja retourner en 32bits voir si je retrouve la stabilité.
Je ne comprend pas trop l’histoire de l’Usb3, qui peut le plus peut le moins ? Non ? 
pas faux . 
Ca… c’est comme savoir conduire quand on a une grosse voiture, c’est pas obligatoire, mais c’est mieux de savoir 
Ceux qui font les OS, savent mieux ce qui est bien pour leurs systèmes que le bricolo du coins qui veux que tout se comporte comme il le veut lui, car, il parait que, sur youtube un pote à lui à vue une vidéo qui montre le contraire.
Le 64 bits n’a pas que cela comme avantage, c’est clairement un OS à privilégier, alors, dès que c’est compatible il faut y aller.
Là, le vrais problème, est directement visible avec dmesg sur les Raspberry Pi 3x sur SSD = ce n’est pas compatible !
Dans tous les cas : le proc des RPI3 et 4 est 64bits compliant après pour le SSD chacun voit midi à sa porte, moi j’ai fait une install sur un SSD en USB sur un RPI3B+ sachant que je l’ai configuré pour le boot en USB et ça marche bien … sauf si le SSD décide d’aller faire le boulet et là pour le coup s’il y a trop d’erreur en lecture … le système ne boot pas et paf le PI3 !
Mais à part ça … ça marche pas mal 
et au vue du fait que Jeedom aime bien écrire savie dans des journaux … avoiru n stockage déporté est mieux que d’utiliser les SD Card de part les temps d’accès et aussi le fait que si tu n’investit pas dans une classe 10 au moins tu risques de le regretter
Après faire un boot sur SD et avoir un point de montage supplémentaire pour /var/log/jeedom sur un SSD externe et expliquer à Jeedom que tous les journaux se mettent là … c’est aissi faisable
En gros tout est permis … du moment que comme le dit le onde de l’open source : « only when you know what you’re doing! »
Alors, je suis curieux de savoir ce que vous avez fait pour cela :
=> sur Raspberry Pi3B+ et sur Raspberry Pi4 (depuis 06/2020) il n’y a RIEN à faire pour qu’ils boot sur l’USB, c’est natif !
1 « J'aime »
J’imagine qu’il parle de cette vieille séquence :
$ vcgencmd otp_dump | grep 17:
17:3020000a
Il faut modifier le fichier boot.cfg pour lui dire qu’il boot sur l’USB et oui @mich0111 a raison c’est avec cette vieille commande
Bah non, ce n’est pas à faire, mettez à jour vos tutoriels
Les Pi3B+ boot en USB nativement, sans rien faire. Il suffit de graver l’image directement sur le SSD et hop, le SSD sur un port USB, on = boot !
Tiens … je n’ai pas vu ça … mais après tout la dernière fois que j’ai regardé ce qui se passait dans le monde du PI c’était au bas mot il y a 6 mois … et c’est long dans le monde de la geekerie
++
Chrisotphe
C’est, vous allez rire, depuis le DEBUT de l’existence du Raspberry Pi 3B+, que celui-ci boot nativement sur les ports USB, il n’y a JAMAIS eu besoin de faire cela sur cette machine.
Je détail une installation de Jeedom, pas à pas, ici :
1 « J'aime »
Merci pour le lien j’irai voir … mais cela va à l’encontre de toutes les docs que j’ai lu jusque là … et des différents tuto … mais je ne veux pas épiloguer … ça ne sert à rien et surtout ne changera rien au fait que PI3B+ et SSD ça fonctionne … du moment que l’on a une alimentation pour PI stable avec la bonne intensité et la bonne stabilité pour éviter les soucis 
++
Christophe
Bonjour,
De mon côté sur un pi4 avec l’image en 64bits et boot sur SSD, j’ai également des plantages aléatoires qui m’obligent à couper électriquement le pi4 pour le redémarrer.
Ma question, est ce que la solution en 64 bits est stable ou en bêta ?
Bonjour,
L’image 64 bits est bêta (je parle de l’image d’origine, celle de la fondation Raspberry Pi).
Mais sur Raspberry Pi4, en 64 bits, je n’avais pas encore lu de sujet dessus. Je suis moi même en train de finaliser un Raspberry Pi4 afin de migrer mon Jeedom sur ce nouveau matériel. Je serais rapidement fixé.
Dans votre cas, faites la commande SSH :
uname -a
Et coller le retour ici.
Étant à 500km de chez moi et ayant subit un nouveau plantage hier, donc plus de contrôle, je ne manquerai pas de poster le résultat de la commande unable -u dès mardi.
Bon WE
Plus précisément :
uname -a
Oui désolé. C’est de la faute au correcteur orthographique…
Bonsoir à tous,
Bon, retour d’expérience après le passage en 32bits : presque 24h que le RPI tourne sans déconnexion.
Cela semble donc bien fonctionner.
J’ai cependant des soucis avec Deconz (clé restaurée) mais certain équipements apparaissent NOK dans les noeuds du réseau décone et je ne parviens pas à les ramener OK…
Merci pour votre aide en tout cas concernant mes problèmes de connexion. 
Ça donne quoi quand tu passes par Phoscon ?
S’ils sont également « unreachable » dans Phoscon, tu peux les réapairer depuis Phoscon et lancer une synchro dans Jeedom.
En principe ça devrait repartir.
Ah je ne savais pas que lon pouvais egalement tester depuis phoscon… je vais tenter
Merci