[Sujet officiel] Plugin sonos

[labomatik]

Bonjour à tous,

je suis passé récemment à jeedom pour son marché de plugins, le plugin sonos a été mon premier à être installé mais la limitation 100 caracteres est embêtante pour lire son calendrier le matin, est ce que vous connaissez un moyen d'enlever la limitation?

Merci d'avance,
Christophe

[Masterfion]

Hello, la limitation n'est pas directement liée au plugin mais aux services TTS disponibles (Google, Voxygen, etc...). La seule solution pour s'adapter à cette limitation est de splitter le texte..........
Loic qui a décidé il y a quelques mois de proposer cet excellent plugin (réelle valeur ajoutée à Jeedom) a quelques surprises sous le coude. Attendons de voir

[xapi]

le TTS qui marche sur la playbar ?

[eudom]

Bonsoir à tous !

Petite question sur le plugin Sonos : j'ai une erreur "No devices found on the current network"...
En effet, j'ai une configuration un peu particulière : un jeedom mini en esclave à la maison (pour gestion zwave rfxcom et mysensors) et un jeedom qui tourne sur un serveur dédié kimsufi en maître.
Ainsi, je comprends que le jeedom maître me dise que le Sonos n'est pas sur le réseau.

Mais je pensais qu'en entrant directement l'adresse IP du Sonos (je la ping depuis le maître), cela marcherait, mais non, j'ai toujours cette erreur.

Y a-t-il une possibilité de "forcer" la connexion à l'IP sans que le plugin ne s'intéresse au "réseau local" ?

Merci !

[Masterfion]

Suis pas sûr de comprendre ton problème ?
Le plugin sonos est installé sur le maître et le maître est sur le réseau ? Si oui, il n'y a aucun raison pour que le plugin ne voit pas tes sonos.

[xapi]

@Masterfion : kimsufi est le nom d'un service de serveur dédié de chez OVH
Donc ici, le maitre Jeedom -installé sur ledit serveur- n'est pas pas sur le même LAN que le Sonos.

@eudom je pense qu'il te faudrait un VPN entre le kimsufi et le LAN sur lequel est le Sonos, car je doute qu'un développement spécifique soit effectué par l'équipe Jeedom pour un cas aussi spécifique.

D'ailleurs pour le coup ça m'intéresse de savoir pourquoi un tel choix, car en terme de perf -voire de sécurité- c'est pas super d'avoir un serveur Jeedom sur internet, non ?

[eudom]

Merci pour vos retours !

@Masterfion le serveur est déporté à travers Internet, le problème vient de là on dirait.

@xapi oui j'ai bien un VPN, et depuis mon Kimsufi je ping mon ip locale du Sonos (192.168.1.XX) sans aucun soucis.

Code : Tout sélectionner

root@nsXXXX:~# ping 192.168.1.30
PING 192.168.1.30 (192.168.1.30) 56(84) bytes of data.
64 bytes from 192.168.1.30: icmp_req=1 ttl=63 time=7.75 ms
64 bytes from 192.168.1.30: icmp_req=2 ttl=63 time=7.74 ms

J'ai l'impression que le plugin a besoin de "lire" le réseau local pour fonctionner, et que lui donner seulement l'IP ne suffit pas à le faire fonctionner ??

Sinon, j'ai choisi de déporter le maître sur un Kimsufi pour justement bénéficier de performances beaucoup plus importantes. J'avais auparavant un Banana Pi en maître, mais cette bestiole s'est avérée extrêmement peu fiable (carte SD corrompue à CHAQUE coupure de courant, notamment) et pas extrêmement véloce non plus. Avec un kimsufi i5 4 coeurs et 16 go de RAM, la différence est flagrante ! Du coup, les performances sont bien meilleures, d'autant qu'avec la fibre, j'ai un ping moyen d'environ 6 à 8 ms entre le kimsufi et ma mini (du coup tout est aussi instantané que si j'étais en local).
Je te rejoins toutefois sur le côté "sécurité" et sur le côté "dépendance à internet", mais je n'ai jamais eu de soucis jusqu'à présent et, surtout, je n'ai rien de sensible sur ma domotique (pas d'alarme, par exemple).

Voilà voilà, ben si jamais vous avez une idée pour mon soucis... il a l'air top ce plugin !

[Masterfion]

Ok, je ne connaissais pas le petit nom "kimsufi".
Pour que tu puisse diffuser les trames uPnP des Sonos en dehors de ton réseau local, tu dois l'autoriser sur ton routeur car par défaut ce n'est pas le cas pour des raisons évidentes de sécurité. Ton routeur doit gérer l'UPnP IGD me semble-t-il.

Mais sinon.... puisque tu as le RFXcom sur ton satellite, ça implique que Jeedom est installé sur ton satellite (le zwave l'implique aussi si tu utilise OpenZwave) donc dans ton cas très particulier il suffirait que le plugin Sonos gère le mode déporté.

Par curiosité, tu paies combien ta VM "kitesufi" ?!

[eudom]

@Masterfion oui mais en fait, comme j'ai installé un VPN, mon kimsufi se comporte comme s'il était sur le réseau local, de la même façon que mon banana pi l'était!

oui effectivement, si le plugin gérait le mode déporté, je pense que ça squizerait les problèmes!

la kimsufi me coûte 18€ par mois ; on est deux avec un ami à le partager et on s'en sert pour pas mal de choses (serveur Plex connecté aux films de nos deux NAS, serveur backup, Jeedom, etc.)

[Masterfion]

@Masterfion oui mais en fait, comme j'ai installé un VPN, mon kimsufi se comporte comme s'il était sur le réseau local, de la même façon que mon banana pi l'était!

Oui mais il ne l'est pas, les flux sont routés hors l'uPnP ne l'est pas.

[eudom]

ah oui !! mais là par contre, je sèche.

en fait, j'ai un serveur VPN sur mon NAS Synology, et mon Kimsufi se connecte en tant que client au NAS.
le réseau VPN est en 10.0.0.X et pour rendre visible mon réseau local en 192.168.1.X depuis le Kimsufi, j'ai créé une route statique (/sbin/route add -net 192.168.1.0 netmask 255.255.255.0 dev ppp0).

[Masterfion]

Courage...
http://bda.ath.cx/blog/2009/01/24/multi ... ith-linux/

[bert]

Bonjour,

J'ai un problème dans la continuité du/des message(s) précédent(s)...

J'utilise Jeedom version béta sur Synology avec Docker. La subtilité vient du fait que docker créé un réseau séparé pour les containers Docker. Mon réseau perso (où il y a les sonos) est en 192.168.0.0/24 et mon container Jeedom en 172.16.x.x (le synology faisant la passerelle entre les deux)

Si je définis les Sonos par leur IP, je n'arrive pas à exécuter des commandes dessus (sur l'objet, je fais "tester" la "pause" par exemple, sans succès).
Si je fais depuis le container un telnet sur l'IP du sonos sur le port 1443 (un des ports ouverts des sonos), ça fonctionne.
(pour info, je controle parfaitement les sonos via l'API avec un autre système qui est sur le réseau 192.168.0.0/24).

Donc il y a deux choses:
- le discovery ne fonctionne pas: j'ai un peu regardé, cela semble utiliser des adresses multicast avec SSDP, j'ai essayé de faire qqch avec smcroute sauf que le multicast n'est pas activé dans le noyau du synology (et ça ne se compile pas en module, pas trop envie de recompiler le noyau complet du synology).
- la définition en dur des sonos ne fonctionne pas, et ça c'est plus étrange. Ce n'est pas très grave de se débrouiller avec ça au lieu du SSDP, on n'en ajoute/enlève pas tous les jours. La connectivité est ok (cf telnet ci-dessus) mais les commandes ne veulent rien savoir. Je vois pas trop ce qui coince.

Une idée/piste?

Merci
Bert

[Popix]

Même problème que précédemment, le plugin Sonos est inutilisable sur une install docker synology, hors comme il est affiché compatible docker, je suppose que quelqu'un l'a testé ?
Je débute avec docker, y a t il une manip à faire sur le syno pour gérer le routage réseau ?
Je prévois de mettre le docker en master et un rasp en slave, le rasp étant sur le Lan du sonos, est ce qu'en installant le plugin sonos sur le slave je vais régler ce problème ?

Merci pour vos réponses

[bert]

Après une analyse réseau, bien qu'en définissant l'IP, on a un discovery sur le multicast en UDP 1900. Donc dans le cas du docker, ça bloque.

Une solution (sale) au problème docker/sonos ci-dessus mais qui a le mérite de rendre les sonos utilisables:

Remplacer le contenu de la fonction getDevices dans /usr/share/nginx/www/jeedom/plugins/sonos3/vendor/duncan3dc/sonos/src/Network.php par
{
return array("192.168.0.a","192.168.0.b","192.168.0.c");
}

pour 3 sonos qui ont les IPs évidemment à adapter (on peut facilement récupérer les IPs depuis le Sonos Controller : Help > About my Sonos System).

Faire un discovery, save et le plugin est ensuite utilisable normalement. Attention aux mises à jour qui vont écraser ceci à priori.

Si ça peut en défrustrer quelques uns comme moi en attendant d'avoir mieux...

Bert.

[eudom]

@bert ta solution me semble très intéressante, c'est exactement ce genre de combine que je cherchais, mais je n'avais pas trouvé quoi modifier et où.

j'ai mis
return array("192.168.0.x");

à la place de tout ce qu'il y a dans getDevices, mais j'ai un vilain 500 : Internal Server Error qui apparaît quand je fais une recherche d'équipement !

[bert]

@eudom Regarde dans les logs nginx.error ?

[eudom]

@bert oui j'avais fait des bêtises ; pas bien remplacé tout ce qu'il fallait dans le fichier Network.php ! en tout cas ton astuce marche parfaitement, un grand merci !

j'en profite comme tu as l'air de t'y connaître un peu en réseau... ! j'ai créé une route statique pour accéder à mon réseau local depuis mon serveur distant (ce dernier étant relié à mon nas par un vpn), via /sbin/route add -net 192.168.1.0 netmask 255.255.255.0 dev ppp0

ça marche très bien, mais à chaque fois que mon interface ppp0 saute (1 à 2 fois par semaine), la route statique est perdue. sais-tu s'il y a un moyen de créer une route statique ""permanente"" ?

merci

[bert]

@eudom oui, mais ça dépend de l'OS de ton serveur distant. Google "<ton_OS> permanent static route" . Par exemple avec Debian: http://unix.stackexchange.com/questions ... -on-debian

[eudom]

@bert merci, j'ai continué à chercher, et j'ai enfin trouvé la solution.

je la publie ici, si ça peut servir à d'autres :

• Tout d'abord, je précise que je suis sous Debian, et que j'ai un vpn (protocole PPTP) qui relie mon serveur distant à mon NAS. Le serveur distant est client, et se connecte à mon NAS automatiquement (j'ai configuré pour cela /etc/network/interfaces et /etc/ppp/peers/).
• L'astuce consiste à ajouter la route statique dans /etc/ppp/ip-up, un fichier qui liste toutes les commandes à lancer dès que le lien ppp est activé
• Ce qu'il faut rajouter dans ce fichier ressemble à cela :
  

  Code : Tout sélectionner

  case "$1" in
          ppp0)
                  /sbin/route add -net 192.168.1.0 netmask 255.255.255.0 dev ppp0
          ;;
  esac

et ainsi, à chaque reconnexion de l'interface ppp0, cette commande est automatiquement lancée (pour info mon interface ppp0 se relance une à deux fois par semaine car l'adresse IP de mon serveur VPN change... et oui, la fibre Orange...)

voilà !