ok, donc pas besoin de remettre un user jeedom? Par contre, si pb avec le root, ça ne complique pas l’affaire de ne pas avoir un autre user?
Vous pouvez créer les comptes que vous voulez, là, c’est juste un accès par défaut pour utiliser le SSH.
Et encore, par défaut root ne devrait pas avoir le droit d’ouvrir une session en SSH.
La règle est : utilisateur / pass puis sudo commande ou su - ect… en fonction des besoins.
D’origine, une installation de Raspberry Pi OS n’autorise plus une connexion root en SSH.
Bonjour @Alexandre
L’identifiant n’est pas plutôt : jeedom
à la place de root ?
C’est ce qui est indiqué dans la documentation et surtout, cela me semble plus sur.
Salut,
le user jeedom n’existe plus après passage en buster, je n’ai pu me conencter qu’en root sur ssh.
Mais même avis, pas extra safe de n’avoir que root et qu’il puisse se connecter en direct.
Quelqu’un connait une procédure pour ajouter un user jeedom avec les mêmes droits qu’avant?
Hello,
Si tu veux recréer un utilisateur jeedom :
sudo useradd jeedom -m
sudo passwd jeedom
sudo adduser jeedom sudo
2 « J'aime »
Bonjour,
Passage de la 4.0.61 à la 4.1.19 en 70s chrono (sans compter le temps du backup).
A part quelques soucis de transparence sur les design rapidement corrigé, tout semble rouler (et plus vite).
Merci à toute l’équipe pour le travail effectué 
Vivement la 4.2 
bonjour,
petit souci pour ma part: je suis en 4.1.17 et impossible de passer en 4.1.19
temps très long et message suivant dans les informations
2021-02-11 17:18:17 (12.1 KB/s) - Read error at byte 8325298/70808786 (Error decoding the received TLS packet.). Retrying.
--2021-02-11 17:18:18-- (try: 2) https://codeload.github.com/jeedom/core/zip/V4-stable
Connecting to codeload.github.com (codeload.github.com)|140.82.121.9|:443 connected.
HTTP request sent, awaiting response
200 | OK
Length: 70808786 (68M) [application/zip]
Saving to: '/tmp/jeedom/install/jeedom_update.zip'
une idée d’où cela peut-il venir?
j’ai essayé en mode forcé ce qui ne change rien en l’occurrence
Merci d’avance
Bonjour,
Ici, c’est (en principe) un fil qui est là pour annoncer une nouveauté (la v4.1 en l’occurrence).
Pour votre problème, il est souhaitable de créer un fil rien que pour cela (1 fil = 1 problème = 1 aide personnalisée).
=> Ici, vous noyez toute la pertinence de l’information d’origine.
Dans votre cas, il semble que votre connexion Internet pose un problème lors du téléchargement du package de mise à jour.
Hello
Ne souhaitant pas créer un énième sujet de migration Smart et même si je sais que ce fil était à la base pour une comm de nouveauté, je partage mon retour d’expérience positif de migration de ma smart il y a 2 jours.
Ayant vu pas mal de sujet de prb et autres difficultés, je trouvais intéressant aussi de partager ce qui fonctionne 
Le 22.02 je me décide à basculer ma Smart de stretch 4.0.62 vers buster 4.1.20 (en deux étapes) :
- 22.02 : passage de stretch à buster en utilisant l’assistant de migration via le bouton de maj proposé dans le centre de maj : migration réussie du premier coup sans problème (je mettrai le détail ci-dessous)
- petite pause pour déjà m’assurer que ca tourne comme avant, puis passage à la 4.1 le 24.02 : idem tout a l’air ok et les nouveautés de la 4.1 sont enfin sur ma smart et non plus que sur mon rpi3b de test !
Quelques informations donc :
- migration buster : réalisée en 1h15 environ, yc restauration de la sauvegarde
- étape 0 ( ) : je sauvegarde au cas ou la smart, je détruit dans mon compte market ma box de test pour libérer une place et ne plus avoir que 4 instances actives et non 5
- étape 1, étape 2 (13h40) : 5mn environ
- étape 3 : environ 30 à 40mn (je n’ai pas vu le moment de bascule exact)
- étape 4 : environ 30mn
- étape 5 (14h52) : 2mn à peu près / accès local ou externe ok
- étape 0 (
- migration 4.0 vers 4.1 : en gros 2mn !
ma config est une smart reliée en direct à la box de mon FAI sur ligne Fibre. J’ai 31 plugins sur la Smart. Assez peu au final nécessitaient de revoir les dépendances (peut-être maxi 6 ou 8 : openzwave, openvpn, networks, surveillance station, squeezebox, monitoring, onduleur…)
Dans les deux ou trucs rapides à régler :
- à la première connexion post restauration de sauvegarde je vois INVALID API KEY dans openzwave, résolu après un redémarrage sans rien faire d’autre (déjà eu ca sur mon rpi3b quand je l’ai lui aussi passé de stretch 4.0 à buster 4.1)
- mot de passe à rechanger pour le ssh afin de ne pas conserver Mjeedom96
- une rafale d’erreur plugin network qui n’aime pas une date unique de rafraichissement dans le passé ou le futur (j’ai du remettre une date à fréquence annuelle). J’ai des équipements dont le refresh ne m’intéresse qu’occasionnellement donc j’avais mis des dates uniques pour ne pas surcharger le cron networks pour rien
- suppression du plugin weather que je n’utilise pas et qui a été réinstallé (en inactif). Idem pour Jeeasy
- pour le passage de 4.0 à 4.1 : rien de spécial, rapide et pas d’erreur. J’ai toutefois du retoucher mes design car le choix de transparence que je n’avais pas coché je crois jusque là est devenu requis pour ce que je veux comme rendu.
Je n’ai vu quasi aucune hausse significative d’espace pris sur le disque, j’étais même en deçà d’avant migration tant que je n’avais pas fait 2 ou 3 sauvegardes.
A titre d’info les captures avant (13h31) et après (14h52) migration du monitoring : avant :
et après :
Actuellement je suis à 3.6Go utilisé stable depuis 24h
Bref une double montée en version plutôt très efficace et très bien guidée avec l’assistant natif de la smart. Merci à tous ceux qui ont œuvré pour cela et pour la 4.1 qui renforce toutes les déjà excellentes qualités je trouve de la 4.0.
Edit 02.03.2021 :
- toujours ok en comportement. L’espace disque tourne autour de 3.7 à 3.8Go utilisé (je pense que cela ne varie qu’avec les sauvegardes quotidiennes car dès fois j’en fait des manuelles et j’en détruit d’autres, depuis que je ne touche plus aux sauvegardes c’est stable en disque utilisé)
- à noter que j’ai aussi basculé mon dernier rpi3b de prod (celui du chauffage, oui j’ai osé avec la météo du moment qui repartait au froid) : idem comme mes deux autres rpi3, passage ok buster puis après 24/48h ok sur 4.1. La aussi stabilité de l’espace disque pris et pas vraiment plus élevé qu’avant en stretch 4.0.62
2 « J'aime »
Petit feedback: migration 4.0 stretch vers 4.1 buster en VM
Tout s’est bien passé 
Passage fait de 4.0.62 à 4.1.22.
Bien passé. Cependant beaucoup de temps pour refaire tous les designs. Autant que le passage de 3 à 4.
Souhaitant que nous ne devions pas faire cela à chaque MAJ majeure.
Par ailleurs, j’ai tenté après un rédémarrage (pour être certain que tout se passe bien) et toutes les valeurs des virtuels ont disparues. J’espère que cela ne sera pas le cas à chaque redémarrage. A priori le cache disparait. Pourquoi ce changement ? MAJ, redémarrage suivant plus le problème. Mais delais de mise à jour de l’heure Jeedom jusqu’à la synchronisation de l’heure.
Pour le reste tout va bien pour le moment.(charge 1 min supérieure semble t-il)
Cela ne semble pas être « voulu » comme action (ce n’est pas indiqué) mais effectivement, on vois plusieurs utilisateurs ayant eu ce problème (je l’ai eu aussi plusieurs fois de suite).
J’ai lu ici (une réponse du support) qu’il faut attendre au moins 10 minutes par exemple, entre 2 redémarrage. C’est le temps que le fichier de cache puisse exister.
Salut
Pour ma part j’ai jamais vu le cache revenir de lui même (avec les valeurs) dans ce genre de cas.
De plus attendre 10 minutes, c’est parfois simplement impossible puisque pendant ce temps, l’ensemble des scénarios continuent de fonctionner et se basent sur des valeurs qui n’existent pas.
Bonjour,
C’est 10 minutes, ce n’est pas pour que les valeurs reviennent, c’est le délais d’attente à prendre en compte entre 2 redémarrages.
Afin de s’assurer que le fichier de cache soit créé.
Merci pour ce complément d’info.
Sauf que de mon côté le raspberry redémarre immédiatement après avoir redémarré (dès que le système s’affiche. Puis plus de problème au 2ème redémarrage. Donc le cache n’a pas le temps de se regénérer semble t-il. Et au 2ème démarrage le cache est perdu.
C’est exactement ce que j’ai constaté.
Chez moi, ce problème venait d’un appareil branché sur un hub usb2. Une alimentation d’enceinte.
J’ai déplacé cela et plus de problème.
Détaillez votre installation pour tenter de comprendre.