La config de Jeedom me parait correcte
Je viens de copié sur le Nuc dont la config est bonne tout « /var/www/html/plugins/alexaapi » avec les sous répertoires et j’ai tout remplacé sur l’autre NUC (en t’en que root)
Mais ça ne change rien, même si je relance les dépendances et la génération du cookie
Moi, j’aimerais bien comprendre où est le BUG car je suis dans les starting-block depuis une semaine (je commence à avoir des crampes) et je voudrais corriger pour continuer à améliorer le plugin.
Cette nuit le démon de mon 2ème NUC est tombé il n’a pas redémarré automatiquement, il a fallu que j’intervienne. le cookie d’alexa posait problème => accès refusé au port 3456.
J’ai donc recréé le cookie d’identification puis j’ai pu relancer le démon ! donc ça refonctionne. (mais pas cool)
Sur l’autre NUC je n’arrive pas à désinstaller Alexa-API il reste toujours des traces.
Quand je supprime dans /var/www/html/plugins alexaapi et alexaamazonmusic
et que je fais une ré-installation du plugin alexaapi je m’aperçois que la date de la dernière installation des dépendances est mémorisée ! alors qu’elle ne devrait pas faire référence à une date car elles n’ont pas été encore installée !
Donc ma question : où sont stockée les dépendances ?
c’est en lisant le sujet « Alexa Api - création cookie Amazon pas en local » que je me suis rappelé que j’avais ouvert le port 3456 et 3457 dans apache2 suite au plantage et au log " AmazonMusic ne peut plus accéder au port 3456" après avoir fais des essais non concluants j’ai oublier de supprimer ces deux ports que j’avais ouvert
Chose corrigée ! Tout refonctionne maintenant à merveille.
Merci pour ton aide @sigalou , elle a été fabuleuse ! et très constructive !
Mais avec un peu d’imagination il y a peut être des choses à corriger :
regarder quel est l’origine du cookie qui revient vide et qui conduit a un message de log " connection refused AmazonMusic ne peut plus accéder au port 3456
Il serait peut mieux de compléter ce message avec cookie non présent.
Le comportement de l’interface qui peut être parfois blizzard …
Je te remercie, j’adore ce type de remarques d’utilisateurs qui commencent à accuser le plugin alors que le bug se situe finalement entre le clavier et la chaise.
OK, Je vais essayer d’imaginer que le cookie qui revient vide est la cause d’un message de log " connection refused AmazonMusic. Et je vais chercher le lien avec l’impossibilité d’accéder au port 3456… tu as as raison sur un truc, on est dans le blizzard…
Merci pour ton retour d’expérience, pense STP à cocher résolu pour qu’on n’en parle pas encore pendant des semaines. 61 messages me semblent suffisants.
Je te remercie, j’adore ce type de remarques d’utilisateurs qui commencent à accuser le plugin alors que le bug se situe finalement entre le clavier et la chaise.
Ah bon !
Il me semble que tu te moques facilement et tu utilises abondamment les smileys, pas toujours de façon agréable, comme tu lis uniquement ce que tu as envie, je suis désolé de te contredire mais le problème qui m’a fait ouvrir ce sujet est bien à l’origine d’un comportement déficient du plugin Alexia-API car il était tombé et ne voulait plus redémarrer.
Donc ce n’est pas moi à l’origine du problème, mais bien toi ! Moi j’ai juste essayé de solutionner ce problème qui m’a conduit dans une impasse. Impasse que je me suis sorti tout seul.
Je remercie quand même les personnes qui ont essayé de m’aider.
Je vois que tu interprètes mal ce que je dis « un cookie vide » c’est un cookie qui ne contient pas d’information valide. Le cookie contient une information cryptée qui comporte entre autres la période de validité, le nom du compte utilisateur…
Mais si tu veux faire progresser les choses essai d’intégrer les commandes :
Ne pas dérange
Activer/désactiver le micro (la commande est manuelle, mais elle doit être aussi programmable)
Aujourd’hui après 2 mises à jour le plugin Alexa-API parait plus stable donc je ferme le sujet.
non je ne t’ignores pas.
Résolu !
hallucinant 
59 échanges pour en arriver là !
