[V4] Développement service Spotify

Une box générique est ce qu’il y a de mieux à mon avis :slight_smile:

Idéalement, il faudrait que le nom de la pièce ou du périphérique sur lequel la musique est jouée soit affichée quelque part : en haut de la pochette ou en dessous de l’artiste par exemple.

Pour le multi service, on peut utiliser des onglets pour chaque service :
player_multiservice

Ayant du temps à perdre en ce moment :grinning:
j’essaie d’optimiser le visuel - une autre proposition version mini et maxi

1 Like

c’est classe aussi en version miniature

Tu peux avoir autant de device que tu veux en DB qui gèrent de la musique :slight_smile:

Après effectivement à voir niveau UX comment on fait, soit on fait une box où l’on demande à l’utilisateur au moment ou il créé la box quel périphérique de musique il utilise. (et du coup l’utilisateur peut avoir plusieurs box sur le dashboard, un par device)

Soit on fait une box avec un switcher en haut pour contrôler tel ou tel device…

A noter que les devices spotify ne seront pas forcement « stables » comme les sonos ou enceintes connectées.

Spotify est installé sur un appareil, si cet appareil n’a pas spotify d’actif (un ordi, un tel, etc) car l’application est fermée, on ne le verra pas dans les devices disponibles (et on ne pourra pas le « réveiller » sans le lancer manuellement)

Quel sera le périmètre du service Sonos ?

  • Gérer le matériel et le multiroom ? auquel cas, le mieux serait peut être juste d’intégrer la partie sonos dans le bouton devices du player music
  • Gérer aussi les services de musiques proposés par Sonos ? dans ce cas la, il faudrait un bouton switch services dans la box music

Bref, ça dépendra du module Sonos, et des prévisions d’éventuels d’autres services de music (matériel ou logiciel)

Bref, pour l’instant, j’en suis la, je teste juste comment afficher les devices et les playlists proprement

gladys-spotify-5

3 Likes

A mon avis, il n’y a pas besoin que le service Sonos dans l’UI soit aussi puissant que l’app Sonos. Même remarque que sur l’autre topic, Gladys n’a pas vocation à construire et maintenir des UI plus complète que celles des constructeurs…

Pour la box sur le dashboard, une box très simple montrant l’état actuel de la musique + des contrôles simple fait l’affaire.

En revanche, le service Sonos va exposer dans les scènes des fonctionnalités avancées (multiroom par exemple) pour permettre des scénarios intéressants type « Quand le détecteur de mouvement du salon est triggered, alors étendre la musique au salon »), mais bon ça n’impact pas la box que tu es entrain de créer.

Je pense que c’est la bonne approche :slight_smile:

Donc si seulement le matériel est pris en charge, la seule évolution par rapport au service spotify serait la gestion de groupes de devices et la possibilité de jouer sur plusieurs devices en même temps (même sans “officiellement” les grouper) ?

Visuellement, cela se traduirait juste par un upgrade de la modale de sélection de devices, ou on verrait a la fois les devices spotify et les devices sonos (en supprimant les doublons) ?

Yes, il faudra juste faire évoluer le code pour permettre “d’étendre”, la ou spotify ne peut faire que “basculer”, mais sinon tout le reste devrait être identique.

Du coup, juste pour être sur de bien comprendre, le service sonos en lui même ne permettra pas de jouer de la musique, mais de sélectionner l’enceinte sur laquelle le son doit joué.
Autrement dit, il ne gère pas les sources de musiques, seulement les sorties ?

En fait le sonos c’est une API ou tu envoie des commandes genre « play », « pause », « next », c’est assez classique. Le multi-room avec le groupage est totalement séparé, c’est des commandes différentes. Dans l’API Sonos tu n’as pas a spécifier sur quel sonos tu joue quand tu envoie play. Le groupage est un mécanisme à part.

En fait pour expliquer comment ça marche:

  • L’utilisateur appuie sur le bouton « play » de l’UI, cela fait une requête sur une route d’API interne de Gladys, POST /api/v1/music/:device_selector/play
  • Gladys comprend que le device sélectionné est un device du service « Sonos » par exemple, et contact donc le service Sonos, fonction « play ».
  • Le service sonos fait sa tambouille et renvoie « ok » en retour si tout va bien

Maintenant pour la sélection de la musique, la Sonos a une API qui permet de renvoyer les playlists disponible. Ce que l’on fait, c’est que pareil on a une route d’API générique: GET /api/v1/music/:device_selector/playlist qui appelle le service concerné et le service renvoie une liste de playlist dans un format standard (un tableau contenant le nom de la playlist + l’URI de la playlist)

Donc en gros, comme pour device, la musique on n’appelle jamais le service directement (sauf pour des spécificités du service), on appelle toujours l’API générique qui transmet au service.

N’hésite pas à lire le code du service Sonos côté back (c’est pas très long) pour mieux comprendre.

Si tu vois des choses qui ne marcheraient pas bien avec le service Spotify, n’hésite pas à commenter ici pour qu’on puisse s’accorder et faire une API générique qui marche pour tout le monde.

Autrement dit, il ne gère pas les sources de musiques, seulement les sorties ?

Si, il gère donc les deux, mais toujours en passant par l’API standard. D’ailleurs derrière tout ça l’API sonos mange des ID de musique Spotify (si tu as spotify), voilà le genre de requête qu’on envoie:

Ok je vois un peu mieux.

Pour l’instant, je n’avais pas fait de endpoints API par device, vu que les devices de spotify ne sont pas toujours up, je ne les avais même pas lié aux devices Gladys.
Mais va falloir le faire, faudra juste ajouter une vérification Spotify pour ne pas afficher des devices down.

Enfin, dans tous les cas, j’ai encore pas mal de boulot qualité / optimisations sur mon service, mais du coup ta solution me semble nickel, je vais partir la dessus pour reconstruire l’API proprement.

Ce que je te propose, c’est de faire une première PR une fois le code plus quali, en prenant compte de ces infos, et avec ta CR on pourra voir ensemble les adaptations a faire niveau modélisation, avant de passer aux étapes suivantes (scenarios et chat).

Ce serait possible d’avoir un peu sur les devices dans Gladys ?

A quoi correspondent exactement les features et params ?
Est des champs libres ?
Comment associer un device a une pièce ? peut on les associer a une maison a la place ? ou ne pas les associer et les utiliser tout de même ?
A quoi correspondent le poll ? c’est un push qui envoie automatiquement une info a un emitter en front a une intervalle spécifiée ? Ou ça push a chaque changement d’état ?

@pierre-gilles, l’onboarding dev est assez complique je trouve, si a la rentrée, tu pouvais faire un peu plus de doc, des exemples complets, voir des live/videos de dev, ça pourrait tous faire gagner un temps considérable je pense ^^

1 Like

Hello @Jacky!

Alors:

  • un device est un périphérique physique
  • une feature (« fonctionnalités ») est une fonctionnalité d’un device. Ex: capteur de température, capteur de mouvement, on/off, etc…
  • un param est un paramètres d’un device. Exemple, une caméra peut avoir un paramètre « CAMERA_URL » qui serait l’URL pour accéder à la caméra.

Il faut renseigner l’attribut « room_id » du device.

Non, car un device est forcément dans une pièce si il est dans une maison.

Certains device n’ont pas de mécanisme de push, il n’envoie pas les données eux mêmes. Si un device a l’attribut « should_poll » a true + une poll_frequency, Gladys viendra interroger le device toutes les X secondes pour aller chercher une nouvelle valeur.

Je suis d’accord, mais c’est pour l’instant « voulu », car pour l’instant beaucoup de mécanismes ne sont pas du tout définitif et change toutes les 5 minutes au gré des développement. Par exemple, la gestion de la musique dans Gladys 4, pour l’instant quasi rien n’est défini: même moi je ne sais pas encore comment on va faire, tout est à réfléchir, il faut poser les specs :slight_smile: J’ai pour l’instant juste communiqué ces infos lors des appels mensuels, ou dans des posts comme celui ci pour en discuter.

Après je suis 100% pour enrichir cette documentation dès qu’on est sur de nous et que les specs sont figés. Pour les device, c’est pas du tout le cas, pour l’instant aucuns services ne contrôle des devices. (on a des remontés d’informations, mais pas encore du contrôle)