J’ai passé ma smart sous Debian 11 suite a l’impossibilité de continuer à mettre à jour les plugins z-wave js et JeeZigbee sous debian 10.
La première fois, je suis la procédure d’install et je restaure mon backup tout est ok jusqu’au premier démarrage ou ma carte z-wave n’est plus détecté en ttyAML1 mais ttyAML0 (et inopréante). Je refais la tentative une deuxième fois … même résultats
Finalement, je le refais une troisième fois … mais sans faire d’apt update / upgrade que je fais par habitude sur mes serveurs.
Du coup, je garde ma version 6.5.13-arm64 du kernel … Et la tout est stable et fonctionnel
Du coup, avez vous connaissance d’une manip à faire pour garder la compatibilité de la carte z-wave interne de la smart ( Carte d’extension (GPIO) RaZberry v2 Z-wave+ pour Raspberry Pi ZWAVE.ME ? ) avec un nouveau noyau ?
Pour info, lors d’un dmesg actuellement j’ai
Sur un sujet similaire en box DYI sous armbian, on parle d’activer du port série du GPIO qui n’est pas actif par défaut.
Pour l’activer il convient d’ajouter dans le fichier /boot/armbianEnv.txt la ligne : overlays=uartA
Y’a t il quelque chose de similaire à faire sur l’image Jeedom de debian 11 pour Smart ?
Dans les trucs à dire en REX smart sous debian 11 … Ne pas oubliez de relancer les dépendances de tous les plugins - comme celui par ex d’OpenVpn pour profitez des dns jeedom -
Je pense qu’on ne parle pas de la même chose. J’ai pris l’image Jeedom, mais les repos debian sont régulièrement mis à jour … pour la partie composant ( php, mysql, apache … ) et pour la partie système (noyau …)
La box est exposé sur internet … ne pas mettre à jour ne me parait pas être pertinent à plus d’un titre.
Dans tous les cas, ce n’est pas l’objet de mon POST.
c’est une box officielle gérée par jeedom et comme vous l’avez expérimenté, si vous le faites, ca casse… donc on vous confirme que la recommandation de l’équipe est de ne pas le faire et qu’ils gèrent.
Si vous avez un doute, contactez le support. On ne peut rien faire de plus que répéter l’info qu’on a.
Vous mettez à jour vos google home / alexa ou autre device connecté?
non car vous n’avez même pas accès au système. ca ne vous tracasse pas dans ce cas là?
Pour répondre rapidement, le kernel de l’image officielle a été modifié pour rendre le GPIO fonctionnel (entre autre). Une mise à jour manuelle du kernel implique que les personnalisations misent en place par l’équipe ne sont plus présentes. ttyAML0 est une console série interne au système pour info.
PS : un noyau en 6.5.X pour la Smart est bien plus que suffisant, voire même inespéré
Armbian permet l’activation du GPIO au niveau du /boot, d’avoir l’info des travaux coté équipe Jeedom permettrais de faire des test sur une version DIY de ma box.
J’irais farfouillez chez hardkernel, une doc doit trainer quelque part sur le sujet.
Bonjour Aurélien,
d’un point de vue purement sécurité, ne pas pouvoir avoir de mise à jour du kernel ce n’est pas top.
Mais admettons. Vous auriez (l’équipe Jeedom) au moins pu faire en sorte que les mises à jour du kernel soient bloquées sur l’image que vous avez mis à disposition. Si vous aviez passé ces deux commandes, je pense que vous auriez évité de faire perdre du temps à certaines personnes :
apt-mark hold linux-image-$(uname -r)
apt-mark hold linux-headers-$(uname -r)
En tout cas cela me pousse pour ma prochaine box à plutôt partir sur du raspberry PI classique et une clé USB Z-Wave pour remplacer ma Smart quand elle sera en fin de vie. J’ai perdu plus d’une journée sur ce sujet.
Si vous saviez le nombre de machines zombies utilisées par les organismes malveillants pour notamment effectuer des attaques DDoS. Et en général ces réseau de machines peuvent être créés grâce à des systèmes non mis à jour.
Un pirate ne va pas forcément casser votre machine et en général vous ignorez même qu’il est présent. Dans ce genre de cas, il préfère avoir des ressources machine à disposition pour ses vrais objectifs.
Quand au fait d’avoir tourné plusieurs mois avec un OS plus supporté, à qui la faute ? Cette date était connue depuis longtemps et a très mal été gérée par l’équipe Jeedom. Elle nous a évité de peu l’obsolescence programmée d’un produit qu’elle nous a vendu. C’est bien, mais ce qui serait mieux c’est que cela devienne la norme pour tout et que cela soit fait suffisamment tôt pour que les clients ne soient pas vulnérables alors qu’ils n’y peuvent rien. Après si les clients ne suivent pas les mises à jour, ils ne pourront s’en prendre qu’à eux-même.
Je préfère me dire qu’il y aura tjs des personnes pour dénigrer tout ce que l’équipe pourra faire, souvent ceux qui pensent être des experts de sujets qu’ils ne maitrisent pas et ce malgré que l’équipe ait fourni bien + d’informations que nécessaire dans le cas du présent sujet…
Je sais par expérience que ça ne sert strictement à rien d’essayer de réexpliquer quoi que ce soit étant donné que l’accusation n’est qu’à charge.
Je viens d’ailleurs de tout relire et nul part je ne vois d’avertissement sur les mises à jour du kernel avec apt. Et c’est bien ce que je trouve dommage, si l’équipe était consciente que tout autre kernel ne serait pas supporté. Où se trouve toute cette information supplémentaire que je n’ai pas su trouver ?
La partie logicielle de Jeedom est très bien et j’en suis très content. Je n’hésite pas d’ailleurs sur ce point à investir dans les nouveaux plugins que vous développez.
Finalement le point sur lequel vous devez progresser est la communication. Car un autre exemple est le plugin JeeZigbee sur lequel je viens de basculer. Pas un article sur le blog pour officialiser que c’est le futur, qu’il est conseillé de l’utiliser en remplacement de l’ancien module officiel Zigbee, et de juste dire que la migration consiste à arrêter l’ancien plugin et de ré-inclure à nouveau tous les équipements Zigbee un par un. C’est bête, mais pour ce genre de chose une communication officielle est indispensable. Cela ne devrait pas reposer sur une recherche dans la communauté. C’est aussi important que de mettre au point la partie technique.
En espérant ne pas trop vous frustrer avec ces commentaires.
