Qu'avons-nous pour une période de temps donnée dans le monde de l'
AG ? Fait connu: chacune des grandes entreprises informatiques a son propre outil pour travailler avec les maisons intelligentes. Et chaque fournisseur fournit sa propre API pour ceux qui s'intéressent à l'intégration. Et au stade initial, il paie même les développeurs pour de nouvelles compétences (actions, compétences, etc. - conformément à la terminologie du fournisseur).
Le service le plus pratique et le plus pratique à ce jour, selon nos experts, est Amazon Alexa. Elle a plus de possibilités de formation détaillée que Google Assistant, Yandex "Alice", Mail.Ru "Maroussia", Tinkoff "Oleg" et autres. Pour Alexa, un appareil est une entité virtuelle paramétrique, ce qui permet de personnaliser les compétences pour chaque appareil individuellement. Par exemple, en plus de la température de l'eau, vous pouvez spécifier les consommables que l'assistant proposera d'acheter sur Amazon. Mais, malheureusement, Alexa ne prend actuellement pas en charge la langue russe et ne fonctionne pas sur le territoire de la Fédération de Russie, donc cette AG est inutile pour un utilisateur russe. Chez Google et Yandex, l'assistant est plus «naturel» - il reçoit et répond aux commandes dans un langage «humain», peut dialoguer avec l'utilisateur, ce qui rend cette AG plus agréable à utiliser. Le seul inconvénient sérieux de Google était que ses actions ne prenaient pas en charge la langue russe. Cependant, à partir du 24 juillet 2019, Google Actions fonctionnait sur les «téléphones» en russe, donc les collègues ont éliminé cet inconvénient.
C'est bien. Et si nous voulons intégrer un appareil avec plusieurs GA?
C'est possible. Utilisation de l'appareil.
Un périphérique est une entité avec son comportement dans le système. Il s'agit d'un principe commun à tous les fournisseurs. Et ici, cela vaut la peine de s'arrêter, ici tout le plaisir commence. Les différences résident dans les approches. Par exemple, Google et Yandex tentent de normaliser la gestion de la technologie. Autrement dit, il est maintenant nécessaire d'écrire du code non pas pour chaque appareil individuel, mais un programme pour toute la série suffit. Et même si le firmware change, vous devrez changer le code une fois, ce qui est très pratique. Notre entreprise a déjà une intégration avec Google, Yandex, Amazon. La technique
écoute Alice , Alex et l'assistant de Google. Plus tôt, nous l'avons montré à l'
intérieur des assistants vocaux .
D'où venaient les assistants vocaux?
L'un des systèmes de reconnaissance vocale les plus avancés au monde appartient à Google, son histoire a commencé en 2002. La société a publié Voice Search, sur la base de laquelle l'Assistant Google a été développé. En 2016, il a été présenté lors de la présentation de Google I / O. Google Home est l'une des «surfaces» de Google Assistant. Maintenant, la précision de la reconnaissance vocale de leur GA est estimée à 95% et presque inférieure aux personnes.
L'assistant vocal d'Alexa a été introduit par Amazon en 2014. La colonne intelligente Amazon Echo, qui peut contrôler un grand nombre d'appareils dans une maison intelligente, y a également été présentée.
Yandex SpeechKit - Système de reconnaissance vocale Yandex. Il est utilisé dans plus de 400 applications. La société intègre également son GA - Alice - dans les navigateurs et les appareils électroniques. La société russe a présenté son AG en 2017, et déjà à l'automne 2018, Yandex a lancé sa colonne intelligente Yandex.Station.
Nos experts disent que d'ici la cent cinquante-sixième année ...
Nous plaisantons, jusqu'à présent seulement d'ici 2020. Un peu de statistiques:
- En 2017, environ 33 millions d'appareils à commande vocale ont été enregistrés dans le monde;
- Les experts occidentaux ont qualifié la recherche vocale de l'une des 3 principales tendances SEO en 2017 ;
- Pour 2018, Google Assistant fonctionne sur 400 millions d'appareils dans le monde. Et ce chiffre ne fait que croître;
- Selon le Global Web Index , 25% des personnes âgées de 16 à 24 ans utilisent la recherche vocale à partir d'appareils mobiles;
- Selon les prévisions de Comscore , d'ici 2020, 50% des demandes seront faites par la voix;
- Selon les recherches de WalkerSands en 2018 , un utilisateur sur cinq d'un haut-parleur intelligent d'Amazon a acheté avec lui et un tiers prévoyait de le faire l'année prochaine;
- Selon une étude de PWC , 71% des utilisateurs qui recherchent sur le Web préféreraient taper des voix plutôt que manuellement.
Comme vous pouvez le comprendre, la tendance à utiliser GA augmente, ce qui suggère qu'il est temps de prendre un fournisseur et de lancer votre propre assistant. Pour nous, la clé est la capacité de contrôler les appareils intelligents, qui distinguera SkyFriend des autres assistants.
Et intégrons!
MAIS notre tâche est également de travailler avec l'approche du fournisseur existant et de l'adapter davantage à notre protocole de contrôle technologique spécifique. Nous suivons le chemin de la normalisation, de l'application pratique, percevant l'appareil comme un ensemble de compétences: chaque bouilloire sait comment faire bouillir l'eau (compétence), elle sait aussi la chauffer à la température souhaitée (compétence), maintenir cette température pendant un temps donné, etc. Par exemple, La commande «On / Off» est standard pour tout appareil. La tâche consiste à transférer cette commande du service vers notre protocole. Quelle est la particularité de notre protocole? Il connecte différents assistants vocaux (maintenant trois, à l'avenir - tous de grande taille) et leur permet à tous de travailler avec des appareils, y compris en même temps. La communication est une à plusieurs. La seule question est de savoir comment adapterons-nous exactement notre protocole à toutes les approches?
Voyons voir. Les projets distincts pour chaque AG sont:
- Augmentation du personnel
- Beaucoup de code et d'héritage à l'avenir;
- Incapacité à évoluer.
Lorsque de nouveaux assistants apparaissent sur le marché, il sera nécessaire d'augmenter proportionnellement le personnel et le volume de travail. Il est logique que nous ayons refusé cette option. Cependant, malgré les différentes approches pour chaque assistant vocal, ils peuvent trouver quelque chose en commun - ce avec quoi ils travaillent essentiellement est la compétence, le trait, la compétence. Les noms sont différents, mais l'essence est la même. Ainsi, la tâche est de développer votre «compétence», qui sera perçue par les assistants. À l'avenir, vous n'aurez qu'à ajouter de nouveaux fournisseurs, ce qui résout le problème de la mise à l'échelle. Nous garderons également à l'esprit qu'une grande partie de notre équipement utilise des véhicules BLE, ce qui dicte les caractéristiques architecturales.
Nous avons développé deux microservices qui fonctionnent par paires.
Le premier est la couche de commande. Sa tâche: effectuer la conversion (mapping) entre l'API du vendeur et notre protocole. Cela fonctionne comme ceci: une demande spécifique pour un assistant cartographie nos compétences - cartographie pour un protocole de périphérique. Avec cette approche, il est facile d'ajouter de nouvelles compétences: la cartographie est effectuée pour le protocole R4S final - le code est transféré au deuxième service. Le dernier élément peut être exclu lors de la transmission d'une commande via Wi-Fi.
La deuxième couche de service ou de transport est utilisée pour:
- Établir une session avec une passerelle client;
- Augmenter et maintenir une connexion Bluetooth;
- Réception / transmission des commandes du premier service.
Ce service fait partie d'une entité de niveau supérieur: appareil BT plus passerelle-intermédiaire, fonctionnant sur le principe: réception de commandes via Internet - envoi via BT. Les connexions sans fil peuvent ne pas être fiables. Pourquoi? Le canal radio peut être limité par des paramètres environnementaux - murs de béton épais, etc. ... En conséquence, les appareils peuvent «tomber» de manière élémentaire, donc maintenir une connexion stable devient une tâche importante pour la couche de transport.
La politique de connexion peut être différente:
1. Support de communication continu.
Avantages : retard minimum dans l'exécution des commandes GA.
Inconvénients : cher pour le trafic et la consommation d'énergie; il y a une limite sur le nombre d'appareils connectés simultanément (dans cette génération Bluetooth 4.0 / 4.2 - six, dans Bluetooth 5.0 jusqu'à vingt). Cela nécessitera également des ressources de serveur supplémentaires.
2. Connexion sur demande.
Avantages : la connexion ne nécessite presque pas de trafic ni de frais.
Inconvénients : un retard important dans l'exécution des commandes plus l'exécution elle-même n'est pas garanti (la connexion peut "tomber" ou échouer). Avec cette approche, nous ne cadrons pas en attendant que l'AG réponde. La session s'est terminée et la fin.
La question demeure également - la commande a été reçue et élaborée, MAIS quoi faire de la connexion: déconnecter ou continuer. Notez que c'est exactement de la même manière qu'Apple HomeKit fonctionne lorsque vous travaillez avec des terminaux BLE (via Apple TV ou iPad comme passerelle). Cela ressemble à ceci - la première fois que vous essayez d'envoyer une commande, le processus prend un temps assez long (ou mieux pour être perceptible par l'utilisateur), mais les commandes suivantes sont exécutées presque instantanément. Une fois le travail de l'utilisateur avec l'appareil terminé, le système d'exploitation «configure» la session après un certain temps, puis le processus est répété comme nouveau.
Mais ce n'est pas tout.
Difficulté 1 . Routage de passerelle.
S'il y a plusieurs passerelles dans la pièce, la question se pose - à laquelle se connecter et à quelle passerelle à quel appareil est connecté. Maintenant, tout fonctionne selon le principe - celui qui réussit est connecté. L'implémentation n'est pas toujours réussie, car la passerelle la plus proche (et donc capable de se connecter de manière plus fiable) peut être occupée dans l'intervalle de temps utilisé. Ensuite, celui qui est libre et capable est connecté. Cela se produit sans égard à la qualité de la communication. Par conséquent, il est important de construire une hiérarchie et un schéma de travail afin que l'utilisateur soit le plus à l'aise possible.
Difficulté 2 . Beaucoup d'utilisateurs.
Il s'agit d'une situation où plusieurs utilisateurs peuvent utiliser une passerelle ou un appareil en même temps. Bien sûr avec un haut niveau de sécurité. Par exemple, depuis différentes AG ou depuis des AG et des téléphones d'utilisateurs. Un essaim de questions: quel appareil allumer en premier, si les commandes GA se contredisent, quelle commande est une priorité et doit être exécutée plus tôt, etc. En partie, notre problème est résolu par le service Redis - une base de données dans laquelle sont stockées les sessions utilisateur, les statuts de l'appareil et l'émetteur-récepteur commandes et bus de données de desserte entre les premier et second services. Mais c'est là que la solution au problème s'arrête.
Qu'avons-nous fait? Nous avons créé SkyFriend. Il s'agit de notre propre développement, un assistant vocal pour la gestion de la technologie, qui prendra également en charge la langue russe. Une caractéristique clé de notre GA est qu'il est affiné pour une interaction directe avec la technologie Smart Ready for Sky sans instruments supplémentaires. L'appareil est deux en un - l'assistant est combiné avec une passerelle qui recevra les informations soit via des commandes que l'utilisateur envoie depuis son smartphone, soit directement par la voix. De plus, SkyFriend possède des fonctionnalités supplémentaires qui lui permettront de rivaliser avec celles qui existent déjà. Il peut activer des rappels sur demande, il peut déterminer la géolocalisation de l'utilisateur, rechercher des informations sur Wikipédia, recommander des films, faire des toasts, lire des nouvelles, répondre à des questions, dire l'heure et la météo dans n'importe quelle ville du monde, jouer à Mystères et villes avec l'utilisateur faire des blagues. L'achat de billets et la commande d'un taxi sont encore au stade du test alpha. Et ce n'est qu'une partie de la fonctionnalité.
Plus récemment, Google a annoncé le travail de sa colonne sur une architecture similaire - le script d'exécution est chargé directement dans la colonne Google Home. Gagner du côté de l'utilisateur est de réduire le temps nécessaire à l'exécution des commandes. Vous n'avez pas besoin de l'envoyer au serveur du fabricant de l'équipement; il vole directement vers la colonne du serveur Google via le même canal de communication et y est exécuté.
Cependant, Google ne prend toujours pas en charge d'autres transports - Bluetooth, ZigBe, Z-Wave, RF, etc. directement sur la colonne, et SkyFriend prend en charge Bluetooth 5.0.
Que nous reste-t-il? Travaillez avec les ressources système - ajoutez de la mémoire, de la puissance processeur, etc. Et nous sommes prêts à offrir aux utilisateurs une nouvelle qualité GA.
Que dire en conclusion?
GA est une tendance, c'est pratique, c'est pratique. Le sujet est nouveau, complet, il comporte de nombreuses questions encore difficiles à résoudre. Surtout seul. Par conséquent, nous vous invitons à une discussion.
Que se passera-t-il ensuite? Et puis il y aura notre nouvel article sur l'architecture SkyFriend. Nous raconterons et montrerons tout. Mais alors.
PS Des suggestions et des critiques peuvent être laissées dans les commentaires.