Forum Domoticz en français

J'ai réinstallé mon fichier image de sauvegarde domoticz de 120Go sur mon SSD INTEL 256Go 1.13A qui a tendance à couper après quelques minutes sur le rpi. Je pense trop consommateur d'énérgie par rappart à mon alimentation.

J'ai ensuite utilisé un autre rpi3b+ surlequel j'ai branché mon SSD INTEL 256Go. Il a booté dessus et démarré.
J'ai sans attendre installé un lecteur de carte microSD avec une carte de 32Go et lancé un rpiclone pour réduire l'image de sauvegarde à 32Go.

J'ai juste eu le temps de le faire et après le rpi a planté.

J'ai réinjecté cette nouvelle image de sauvegarde de 32Go sur mon SSD Sandisk 2242 32Go 0.14A.
Et j'ai installé ce SSD sur mon rpi principal.

Tout fonctionne depuis hier soir sans problème. Ouf !

Entre temps, j'ai reçu un nouveau boitier externe pour mes SSD SATA III et il se connecte sans problème à l'ordinateur.
Je pense donc que l'origine de mes problèmes vient bien d'un problème de boitier SSD et c'est donc le deuxième qui claque.
Celui que j'ai reçu d'AMAZON semble avoir des composants différents, on verra bien dans le temps mais je vais privilégier désormais les petits SSD 2242 moins consommateurs d'énergie et j'en profiterai pour revoir aussi mon alimentation.
@fcBourgogne : Comment as tu relié ton alimentation sur ton rpi ? avec un cable microusb ou directement par les pin 5V/Gnd ?

Bonjour,
Mon RPI est alimenté par le câble microusb (nécessaire aux ports USB) , tous les accessoires relais capteurs et autres direct sur transfo.
A+

Matthias a écrit : 12 janv. 2025, 09:55 Je pense donc que l'origine de mes problèmes vient bien d'un problème de boitier SSD et c'est donc le deuxième qui claque.

Ces boîtiers sont sans doute rarement conçus pour des usages en continu 24/7, mais plutôt pour du recyclage de HDD/SSD en disque externe de sauvegarde.

Il en fut d'ailleurs de même, il y a une petite dizaine d'années, de la couche logicielle usb-storage (qui était séparée du SCSI/SATA d'un stockage directement relié à ce type d'interface internes nativement) du noyau Linux d'ailleurs: J'ai vu qq bugs bien tordus au boulot sur des cartes embarquées utilisant ce type de stockage (sortes de clef usb cartelette: eUSB), parfois selon les contrôleurs en face, avant que les eMMC les remplacent.

Clairement, le cas d'usage était la clef branchée pour une sauvegarde qq minutes par ci par là. Pour en faire un media de boot fiabilisé il avait fallu corriger les problèmes corrigibles et évincer certaines références quand ça ne l'était pas (ou débugger le truc 3 mois avec le fabricant, qui en fait ne maîtrisait guère les FW des stockages fournis avec juste qq options de compilation optimisant qq cas d'usage cibles, puis le fondeur du contrôleur).

Idem pour booter là dessus: Que ce soit des uboot ou des bios, le cas d'usage était le média d'installation que l'utilisateur relancera d'un off/on au besoin. Pour du fiable il avait fallu un bon déverminage. Toujours considérer le cas d'usage majoritaire d'une solution au moment d'envisager de l'utiliser: Quand on en sort, on passe souvent de pilote de ligne à pilote d'essai.

Mon DD tourne depuis janvier 2018, j'ai retrouvé la trace de mon achat.
Une merveille
Celui ci: A+

Ma uSD date de 2019, j'ai cru avoir un signe avant coureur de pb de fiabilité en juin dernier mais au final c'est encore elle qui fait le job! Maintenant chacun fait comme il veut et des exceptions confirment les règles, mais quand on sort de cas d'usages majoritaires des problèmes sont à attendre.