Journal Logitech, domotique et libre

Posté par  . Licence CC By‑SA.
Étiquettes :
18
12
oct.
2025

« Logitech coupe ses interrupteurs connectés Pop, qui seront inutilisables dès le 15 octobre. » Extrait de l'article : « Comme souvent avec les produits propriétaires qui reposent sur des serveurs, la fin de la prise en charge implique la fin des produits eux-mêmes, qui sont bons pour la poubelle. »
Ça m'a rappelé une discussion sur la récente dépêche Stallman : de quoi nous prive le logiciel privateur/propriétaire ? Ou plutôt, qu'est-ce qu'il a « d'injuste » ? Dans le cas de la domotique (et globalement des objets connectés) c'est assez évident : si la boîte coupe l'accès au service, on se retrouve avec de jolis morceaux de plastique totalement inutiles. Alors qu'avec du logiciel libre quelqu'un quelque part trouvera certainement le moyen de faire tourner un serveur et le partagera avec la communauté (le moyen, pas le serveur). D'ailleurs l'histoire n'est peut-être pas finie, on a eu divers exemples de reprise par "la communauté" avec les montres Pebbleou la Squeezebox (de Logitech encore).

  • # pas forcément

    Posté par  . Évalué à 4 (+2/-0). Dernière modification le 12 octobre 2025 à 18:09.

    C'est un vrai problème auquel les gens ne sont pas vraiment sensibilisés. Matter devrait en principe apporter des solutions mais je n'ai pas de retour d'expérience personnel là-dessus.

    Ceci dit, "produit propriétaire" ne signifie pas forcément produit qui finit à la benne si son fabricant arrête de le supporter. En fait, c'est comme pour les formats de données, ce qui importe avant tout, c'est qu'il supporte un protocole standard (MQTT, HTTP, Matter, …) et permette un accès sans passer par l'appli ou le cloud du fabricant. Dans ce cas, il n'est pas juste de parler d'injustice.

    Ce n'est pas si rare : les relais Shelly, la serrure Nuki, des devices zigbee (zigbee2mqtt supporte énormément de produits zigbee) sont des exemples que j'utilise chez moi.

    • [^] # Re: pas forcément

      Posté par  (site web personnel) . Évalué à 5 (+3/-0).

      « Ceci dit, "produit propriétaire" ne signifie pas forcément produit qui finit à la benne si son fabricant arrête de le supporter […] ce qui importe avant tout, c'est qu'il supporte un protocole standard (MQTT, HTTP, Matter, …) et permette un accès sans passer par l'appli ou le cloud du fabricant. »

      Pourquoi parlerait-on de « produit propriétaire » dès lors ? Il me semble que l'expression signifie que le vrai propriétaire 1) n'est pas l'acheteur, 2) garde les droits sur le produit, 3) ne les délègues au mieux que partiellement à son client. Non ?

      « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

      • [^] # Re: pas forcément

        Posté par  . Évalué à 3 (+1/-0).

        Il me semble que l'expression signifie que le vrai propriétaire 1) n'est pas l'acheteur, 2) garde les droits sur le produit, 3) ne les délègues au mieux que partiellement à son client. Non ?

        C'est vrai aussi pour du logiciel libre.

        • [^] # Re: pas forcément

          Posté par  (site web personnel) . Évalué à 2 (+0/-0).

          Absolument. Sinon, à moins d'être Homère ou l'un de ces sectateurs, inutile d'accoler un épithète. Privateur ou libre sont ajouter pour préciser quelque chose qui n'est pas dans l'ordre des chose le plus classique.

          « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

  • # pas forcément (bis)

    Posté par  . Évalué à 5 (+4/-0). Dernière modification le 12 octobre 2025 à 18:51.

    Il existe beaucoup de matériels qui reposent sur des microcontroleurs esp (esp8266, esp32, …) et qui sont très facilement flashables avec un firmware alternatif comme tasmota ou esphome.
    chez moi la totalité de la domotique fonctionne quand ma box internet est coupée, j'ai pris soin de remplacer l'ensemble des firmwares qui dépendent d'un cloud externe pour ne dépendre que de mon serveur Home Assitant.
    C'est assez simple à faire, je pense que c'est une bonne pratique pour ne pas dépendre d'un serveur externe, pour ne pas dépendre de la liaison internet non plus, …
    Du coup, je veux bien acheter du matériel de divers fournisseurs, mais je commence par vérifier que le device est flashable avec esphome !

    d'autant que je viens de regarder : 2 interrupteurs POP qui nécessitent un pont et au cout de 130€ !!! il vaut mieux acheter un shelly ou bien un sonoff pour quelques € …

    • [^] # Re: pas forcément (bis)

      Posté par  (site web personnel) . Évalué à 8 (+6/-0).

      Ça fait rêver. Mais il faut probablement commencer par s'y connaître un peu plus que la moyenne en électronique et disposer de pas mal de temps libre pour se lancer dans ce genre de chose. Non ?

      « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

      • [^] # Re: pas forcément (bis)

        Posté par  . Évalué à 5 (+4/-1).

        Flasher son matériel quand c'est possible, c'est bien. Mais c'est loin d'être le passage obligé pour "libérer" du matériel. J'ai personnellement flashé un relai Sonoff mais si j'avais utilisé un Shelley (que je ne connaissais pas à l'époque), je n'en aurais pas eu besoin. Idem pour tous les devices zigbee (By the way, je n'ai aucune compétence en électronique, c'est quand même assez facile).

        Ceci dit, il est vrai que ça implique le plus souvent un serveur domotique (Home Assistant, par exemple). Mais soyons réaliste : si tu veux pouvoir accéder à distance (via internet) à un device, la solution "grand public qui n'y connaît rien", c'est une application ou une interface web qui se connecte à un cloud. Même si le code du serveur est libre, la reprise par une communauté ne va pas se faire en un jour (si tant est qu'elle se fasse s'il s'agit d'un device peu répandu).

        On en conclut quoi : en tout premier, que la domotique n'est pas impérative (sinon je vais me faire démolir par tkr), ensuite que si on en utilise, il faut choisir des matériels qui permettent un accès local via un protocole documenté (ou, mieux, standard). Que les logiciels fournis par le fabricant (dans le matériel ou coté serveur quand il y en a un) soient libres ou non est moins important en pratique pour Mr ou Mme Lambda.

    • [^] # Re: pas forcément (bis)

      Posté par  . Évalué à 2 (+1/-0).

      Bonjour,

      Est-ce que des éléments d'un système d'alarme dont l'abonnement a été résilié peuvent ainsi être réutilisé ? Pas forcément avec le même usage: par exemple un détecteur de présence pour allumer des lumières ?

      Comment procéder pour déterminer si c'est possible ?

      • [^] # Re: pas forcément (bis)

        Posté par  . Évalué à 4 (+2/-0).

        Tout dépend du système d'alarme, impossible de donner une réponse générique. Un moyen de le savoir est d'identifier ses composants et de voir s'ils font partie des intégrations disponibles dans Home Assistant (https://www.home-assistant.io/integrations/?brands=featured) ; même si on ne compte pas utiliser ce logiciel, ça donne une indication sur l'ouverture du composant. Pour les composants fonctionnant en zigbee, on peut regarder https://www.zigbee2mqtt.io/supported-devices/#. Idem même si on ne compte pas utiliser zigbee2mqtt.

        A noter : Home Assistant a des intégrations qui prennent en compte certains systèmes d'alarme comme un tout : il faut donc d'abord chercher avec la marque du système d'alarme. Si ce n'est pas pris en charge, il faut alors identifier les composants individuels du système d'alarme, les capteurs notamment. Cela peut se révéler plus difficile si le fabricant du système d'alarme a masqué cette information.

  • # Dépêche en cours

    Posté par  (site web personnel, Mastodon) . Évalué à 8 (+6/-0).

    Dans l'Espace de rédaction, il y a une dépêche qui a été commencée : "Ouvrir le code source quand une application est abandonnée ?"

  • # Pourquoi pas le serveur?

    Posté par  . Évalué à 10 (+10/-0).

    avec du logiciel libre quelqu'un quelque part trouvera certainement le moyen de faire tourner un serveur et le partagera avec la communauté (le moyen, pas le serveur)

    Pourquoi pas le serveur ?

    Depuis plus de trois ans, je mets le serveur de vidéoconférence https://galene.org:8443 à disposition du public. Ça me coûte 6€ par mois environ. Il n'y a aucun business model derrière, le seul but est d'aider les gens à éviter le spyware de Zoom.

    Ce n'est pas un cas isolé. Le service https://beacondb.net est fourni gratuitement, sans aucun business model derrière. Et maintenant que j'y pense, c'est aussi le cas de https://linuxfr.org.

    Les serveurs sont vraiment bon marché en ce moment, et ils risquent de devenir moins chers encore lorsque OpenAI aura déposé le bilan et vendu ses datacenters au rabais. Il n'y a aucune raison de se priver de la joie de fournir des services gratuits au public.

    • [^] # Re: Pourquoi pas le serveur?

      Posté par  . Évalué à 7 (+5/-0).

      Une visioconf, tu sais quand tu y entres, et quand tu es sors. Dans le cas de la domotique, c'est assez différent - c'est tout le temps connecté. Il faut avoir confiance dans le fait que le serveur ne va pas te trahir (volontairement ou involontairement), et que des personnes tierces ne vont changer ton thermostat pendant tes vacances, mater tes images de caméras ou ouvrir ta serrure connectée.

      La colocation de serveur qui contrôle des objets qui sont dans un logement, il faut vraiment prendre le temps d'y réfléchir avant de s'y mettre.

      À noter qu'une visite rapide sur Shodan permet de voir que l'auto-hébergement ouvert sur Internet n'est pas forcément toujours mieux maîtrisé :-/.

      • [^] # Re: Pourquoi pas le serveur?

        Posté par  (site web personnel) . Évalué à 5 (+3/-0).

        Ça pourrait être faisable avec du chiffrement end2end, comme pour un serveur de messagerie. Mais c'est moins le cas si on veut une interface web: à un certain moment on doit faire confiance à ce que le serveur nous envoie. Je dis pas que c'est simple…

        Un LUG en Lorraine : https://enunclic-cappel.fr

        • [^] # Re: Pourquoi pas le serveur?

          Posté par  . Évalué à 4 (+3/-0). Dernière modification le 12 octobre 2025 à 23:34.

          à un certain moment on doit faire confiance à ce que le serveur nous envoie

          Entièrement d'accord (avec tous les deux). Si vous utilisez galene.org, vous me faites confiance (ainsi qu'à mon fournisseur de service) pour ne pas vous espionner. Je n'ai aucune envie de vous espionner, mais si jamais je reçois un ordre d'un juge, je n'irai pas en prison pour vous protéger.

          De ce fait, j'encourage les gens à installer leur propre instance de Galène sur un serveur qu'ils contrôlent (éventuellement à travers https://yunohost.org), c'est ce qui donne les meilleures garanties de vie privée, et en même temps je maintiens de manière bénévole le service public sur galene.org pour ceux qui n'ont pas les moyens techniques ou tout simplement pas l'envie de maintenir leur propre serveur. Ce n'est peut-être pas idéal, mais c'est sans doute mieux que Zoom ou Google.

          • [^] # Re: Pourquoi pas le serveur?

            Posté par  . Évalué à 4 (+2/-0).

            Je ne disais pas que ce n'était pas possible de fournir le serveur à la communauté, juste que ça sera plus rare parce qu'il y a un prix corrélé à la quantité de gens qui vont l'utiliser. Un serveur pour un truc qui avait des milliers ou millions d'utilisateur ça pourrait tout simplement ne pas être à la portée d'un seul individu donc on fourni le moyen et chacun monte le sien (ou pour lui et ses copains, sa famille).

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.