Pour ajouter une corde à sa gamme de produits domotiques, Apple semble miser sur le Thread de Google. En attendant la solution unifiée CHIP, elle introduit ce nouveau protocole dans son HomePod mini qui peut faire office de concentrateur HomeKit.
Hier soir, Apple dévoilait ses nouveautés de fin d'année. Parmi elles, une enceinte connectée plus compacte et moins chère : HomePod mini (Siri), vendue 99 euros. Elle prend la forme d'une sphère, à la manière du Nouvel Echo (Alexa). Bien que vendus au même prix (à 99 cts près), les deux produits ont des caractéristiques assez différentes.
HomePod mini mise sur le tout sans fil
Notamment en termes de connectivité et de connectique. Alors que l'enceinte d'Amazon propose une entrée/sortie audio (jack 3,5"), du Wi-Fi 5 (802.11ac), du Bluetooth (version non précisée) et du ZigBee lui permettant de faire office de hub domotique, le produit d'Apple opte pour une approche différente.
Outre son interface tactile plutôt que via des boutons, elle n'a aucune entrée/sortie physique. Elle se contente d'un Wi-Fi de génération précédente (802.11n sur 2,4 GHz) accompagné d'UWB et du Bluetooth 5. De quoi lui permettre de continuer à faire office de concentrateur HomeKit pour la domotique, avec toutefois une possibilité supplémentaire : il s'agit du premier produit Apple compatible Thread (version et fréquence non précisées).
Au sein de CHIP, Apple rejoint Google et son Thread
Pour rappel, il s'agit d'un protocole poussé par Google depuis quelques années, mais qui n'a pas connu un grand succès. Il se repose comme ZigBee sur le standard IEEE 802.15.4 et permet de créer un réseau maillé basse consommation, mais utilise des adresses IP pour chaque appareil à la manière de 6LoWPAN.
C'est d'ailleurs pour cela qu'il est un des éléments essentiels de l'initiative Connected Home over IP (CHIP) devant unifier les solutions autour des objets connectés. Il s'agirait donc d'un premier pas d'Apple dans cette direction. En ce sens, elle suit les pas de Google dont les Nest Wifi (AP/routeur) et Hub Max sont déjà certifiés.
Dans ses notes de bas de page, l'entreprise précise que la large compatibilité n'est pas au programme puisque seuls les « les appareils prenant en charge HomeKit Thread » seront gérés. Sans doute du fait de la méthode d'appairage particulière propre à cet écosystème. Pour le moment, aucun produit compatible n'a été annoncé.
Mais il y a fort à parier que cela évoluera rapidement. On peut aussi se demander si Apple ne pourra pas activer la compatibilité Thread de manière logicielle sur son HomePod actuel et sa dernière Apple TV.
ZigBee et HomeKit : un pont tiers reste nécessaire
Dans tous les cas, les partisans de ZigBee en seront pour leurs frais. C'est d'autant plus regrettable que ces deux technologies utilisant des bandes de fréquences similaires.
ZigBee est déjà présent dans un grand nombre d'objets connectés déjà dans les maisons, dont les Philips Hue. Proposer une fonctionnalité de hub pouvant les gérer directement, permettant ainsi de se passer de ponts tiers, comme le fait Echo depuis quelques générations, aurait sans doute été apprécié.
Apple n'a pour le moment pas explicité les raisons de son choix.
Commentaires (13)
#1
Zigbee ne permettait sans doute pas encore assez de verrouillage de l’écosystème pour Apple! En effet, quelques fabricants de contrôleurs s’aventurant à unifier le truc avec un peu de rétro-ingéniérie, avec les “fossoyeurs du garage” ça ne pouvait pas le faire même si côté utilisateur c’était déjà bien pénible (évolution constante des firmwares de contrôleurs pour supporter les nouveaux périphériques, avec les instabilités possibles…) à l’usage.
Et on voit venir un nouveau machin digne du RTS puis Somfy/Velux et leur IO-Home ayant amélioré le verrouillage jusque là trop imparfait à leur goût, en fait: La maison communicante… mais seulement avec nous mêmes!!!
On n’est donc pas le cul sorti des ronces, avec un secteur qui restera au final à quelques pouillèmes de % de son potentiel commercial…
#2
Franchement, c’est lourd. Si tu lis l’article que tu commentes et les articles précédents sur le sujet, tu lirais qu’il est fait mention de CHIP, qui est à peu près tout l’inverse de ce que tu dénonces. Rappelons aussi qu’Apple est tellement fermée sur la question de la domotique, qu’elle a opensourcé il y a de cela quelques mois son HomeKit Accessory Development Kit permettant de fait à n’importe quel fabriquant d’implémenter le support HomeKit sans avoir à demander la permission à Apple.
#3
C’est vrai, il n’y a déjà pas assez de trucs faisant le job dans la nature, il en fallait un de plus… Et venant d’Apple, les rois de l’emprisonnement dans leur écosystème ayant renié leurs origines de “garagistes”, désolé mais il en faut un peu plus pour me convaincre.
Ils prennent le train en retard ce qui les oblige à tenter un peu de souplesse initiale… avec déjà les bémols écrits noir sur blanc dans l’article. HomeShit en résumé.
#4
J’ai pas dit que ce qu’Apple faisait était bien ou mal. Ni qu’elle le faisait pas parce qu’elle est à la bourre. J’ai juste dit que votre premier commentaire n’avait aucun rapport les faits énoncés par l’article.
Apple s’est associé à Google pour lancer l’initiative CHIP. Apple a open sourcé l’ADK de HomeKit qui sera vraisemblablement la base technique de ce parternariat. Donc Apple et Google sont en train de créer un système domotique qui fonctionnera sur leurs deux plateformes et ce de manière ouverte.
C’est juste un fait et votre premier commentaire dépeint une situation opposée à cette réalité.
Le fait qu’Apple et Google font évidemment ça parce que c’est juste nettement moins galère que de nouer des partenariats dans tous les sens, qu’Apple agit contre sa propre nature historique de conception d’écosystèmes fermés … tout ça a beau être potentiellement véridique….
… ça ne change rien au fait que quand vous parlez d’une volonté de fermeture de l’écosystème et que vous comparez ça aux protocoles fermés existants, vous avez faux.
Quand vous dites que ce projet va contre a retro-ingénierie alors qu’à priori les spécifications seront publiques et les droits d’implémentations inexistants, c’est aussi faux.
Le fait qu’Apple et Google soient les entreprises les plus méprisables de notre époque (et encore, ne boudons pas Amazon) ne change rien au fait que CHIP sera probablement un bon coup de pied pour une domotique plus standardisée. Ou pas. Mais ce sera déjà mieux que la multitude d’écosystèmes fermés tous basés sur du ZigBee juste assez modifié pour que ça marche que sur la box de la même marque que tes ampoules.
#5
Pour l’aspect ouvert il faudra tout de même voir, parce que proposer un produit labellisé HomeKit, je doute que ça se fasse sans intervention d’Apple. Il faudra aussi voir ce que permettra l’écosystème CHIP/Thread à termes. Mais là on peut juste voir des concentrateurs avec rien derrière qui exploitent un simili zigbee sur IP sans support de l’existant. Il y a mieux pour montrer patte blanche niveau ouverture.
Espérons que CHIP quand il sera effectivement lancé sera plus convaincant que ça, et qu’on éclaircisse un peu la manière dont les différents protocoles vont cohabiter. Parce que pour le moment, on s’y perd un peu et on a du mal à voir l’intérêt des mouvements récents.
#6
Petite précision : Thread utilise 6LoWPAN, sur les mêmes couches radio (PHY et MAC) que Zigbee (et donc le même hardware que lui) .
La différence principale réside en l’endroit où est spécifiée l’interface protocolaire applicative, et donc une éventuelle compatibilité : dans zigbee c’est intégré : si une ampoule respecte le profile lightning zigbee (comme les Philips Hue par exemple) elle sera automatiquement compatible avec tous les appareils zigbee du même profile, quel que soit le fabricant.
Avec Thread par contre, la partie haute est simplement de l’UPD (via 6LoWPAN) et c’est l’application au dessus qui définit la façon dont elle l’utilise ( potentiellement avec CoAP ou autre, par exemple) ; le résultat est que deux produit thread n’ont aucun garantie d’être compatibles au niveau applicatif même s’il peuvent parler entre eux au niveau IP.
En gros, thread est plutôt comparable à du Wifi (du transport jusqu’à une couche IP) là ou Zigbee est un protocole métier tout en un (du transport jusqu’à l’application).
#7
C’est la que l’ouverture de la couche applicative HomeKit devient intéressante, car homekit comble justement ce manque de définition du protocole métier. (Bref, de la couche7)
https://github.com/apple/HomeKitADK
#8
“Apple n’a pour le moment pas explicité les raisons de son choix.”
La vision d’Apple est au contraire très claire et opposée aux solutions techniques nécessitant des “hubs” ou “ponts” qui sont autant de points névralgiques dans le réseau. Avec l’augmentation fulgurante de l’IoT, les technologies mesh avec gestion intelligente du flooding (Wi-Fi, BT5, Thread…) représentent l’avenir au contraire des technologies centralisées telles que le ZigBee ou le Z-Wave qui vont dans le mur (je ne dis pas ça méchamment, et je sais de quoi je parle car je suis équipé en Z-Wave chez moi depuis des années).
Par ailleurs il existe bien un “pont HomeKit” chez Apple, sous la forme d’une Apple TV ou d’un HomePod (voire d’un iPad déclaré en tant que tel) mais c’est en fait autre chose : 1) celui-ci n’est pas obligatoire et 2) sa vocation est purement sécuritaire, il permet de gérer la communication HomeKit en provenance de l’extérieur, lorsqu’on n’est pas à son domicile.
#9
Dans les détails techniques c’est vrai ; mais pour un utilisateur lambda la différence essentielle entre le ZigBee et Thread est que le premier nécessite un hub centralisé pour que les appareils à ce standard puissent fonctionner ; alors que le second non (Thread est par essence décentralisé).
#10
Comme tu le dis Apple n’est pas opposé aux ponts, ses produits en sont, il n’y a pas de différence sur ce point avec d’autres modèles à gestion centralisée, si ce n’est l’intégration
#11
Oui, et la deuxième différence pour l’utilisateur lambda, c’est que le logo thread ne garantit aucune interopérabilité entre les objets qui le portent, alors que le logo thread si ( sur le même profile, en tout cas…). ça fait quand même une grosse différence !
#12
Bof, le github en question spécifie qui sert a : “prototype non-commercial smart home accessories”
Bref, pour faire le moindre service ou objet vendu, ça ne fonctionne pas et il faudra passer par la case certif et le programme MFi.
Ce n’est pas vraiment de l’ouverture je trouve.
#13
La spécification est disponible, avec les exemples.
Donc, si, c’est ouvert.
Et les fabricants voudront plutôt avoir le “logo qui va bien” pour la vente, ce qui nécessite dans tous les cas de passer par la case certification (comme chez les concurrents).
Par contre, ça facilite l’implémentation DIY (home bridge et autres): l’utilisateur n’a qu’un écran supplémentaire indiquant que le produit n’est pas certifié.
Je fais une différence entre ouverture et certification/support. Les distributions Linux payantes sont toutes ouvertes, mais dès que tu intègres un driver de tierce-partie, tu n’es plus supporté.