tout d’abord un grand merci aux développeurs de ce plugin qui s’améliore continuellement… (info du volume, info interaction,…)
J’utilise ce plugin avec une freebox delta et intègre des commandes dans mes scenarios. En particulier dans le plugin alarme pour annoncer l’activation de l’alarme, le déclenchement, ou l’arrêt de celle-ci.
Pour ce faire, j’utilise la commande speak dans les actions du plugin alarme. Et je ne sais pas pourquoi, par moment, toutes les commandes de mon scenario s’exécute normalement sauf la commande speak.
Voilà, par exemple, mon scenario pour les actions immédiate d’enclenchement de l’alarme :
Est ce que le refresh en début de scenario à une action positive sur le reste des commandes ? ou faut-il ne pas faire de refresh ?
Je mets des pauses aussi entre chaque commande pour palier à la latence des interactions alexa/jeedom, mais je ne sais pas si c’est vraiment nécessaire ?
J’ai lu avec attention ton message.
J’ai une première question, quel est cet écran que tu nous mets en copie ? je ne le connais pas, ce n’est pas un écran scénario.
Cela étant dit, voici les réponses à tes questions :
Non, Refresh ne doit pas être lancé, il rafraichit les alarmes, alarmes musicales, les rappels, … et cela utilise des ressources et il faut éviter de le lancer juste avant des commandes, tu risques d’atteindre une limite de requete en peu de temps et des rejets du serveur Amazon, donc supprime tes Refresh, aucun interet. Le refresh se fait tout seul toutes les 15min de toutes façons.
Non, les pauses ne sont pas nécessaires, le plugin gère les commandes de manière synchrone et attend seul les réponses du serveur avec un timeout de 3s, donc supprime tes pauses (si tu constates des soucis dans les logs parle m’en plutôt que de mettre des pauses)
Pour le souci de Speak qui ne fonctionne pas toujours, je ne vois pas pourquoi, regarde les logs et donne les moi au moment d’un speak qui ne part pas.
Comme d’habitude : rapide et efficace. Rien à dire, sinon merci.
Effectivement c’est le plugin alarme de Jeedom (merci @sebfar), l’écran que je présente indique les actions à effectuer lors de l’activation immédiate de l’alarme, plus bas dans la page (ça ne se voit pas sur la capture) il y aussi des actions lors de l’enclenchement effective de l’alarme, dans mon cas 2min après l’activation, histoire de pouvoir sortir de la maison…
J’ai moi aussi lu avec attention ton message et pris bonne note de tes réponses
Pour le refresh, je le vire et je te remercie pour l’explication. J’avais cru voir dans les log l’authentification toutes les 15min, c’est donc confirmé.
Pour les pauses ok, je vire aussi. Sauf que, si je peux me permettre , si je fais un speak un peu long (plus de 3sec, je pense lié au timeout de 3secs?), l’action suivante se déclenche, dans mon cas le volume se remet à son volume initial avant la fin du speak. Le speak est annoncé avec un volume au debut et un autre volume à la fin.
Pour les logs, peux tu m’indiquer de quels logs tu as besoin et dans quel config (defaut, debug,…) ?
L’astuce de @Gorgluk me semble intéressante et montre peut-être aussi un problème de speak de ton coté ? Effectivement, j’ai remarqué que lorsque le premier speak ne passe pas le deuxième lui passe (donc faire un speak à 0 peut-être une solution palliative mais risque d’augmenter les requêtes au serveur et de se faire jeter…
Petite précision : j’utilise la dernière version stable du plugin, celle d’hier si je ne m’abuse… sur un jeedom 3.3.35 et un debian 9.11 sur rpi3b+.
Avec le plugin ALEXA API en dernière version stable de l’excellent @sigalou accompagné de @nebz (merci pour le plugin homebridge qui fonctionne parfaitement !)
Sur tout ce que tu ajoutes :
La question des 3s, je parlais du timeout, c’est à dire le temps laissé au serveur pour répondre à une requête, cela n’a rien à voir avec le temps du speak. Si tout se passe bien, le serveur répond immédiatement et ne prend pas 3s pour répondre. donc effectivement, si tu enchaines les commandes, il faut des tempos. Je me suis mal exprimé sur l’explication des commandes synchrones, elles ne sont pas liées entre elle, donc on n’attend pas la fin du speak pour faire la commande suivante (volume dans ton cas). On attend l’accusé de réception, pas la fin de la commande. Donc, je confirme, mets les pauses si tu changes le volume juste après avoir parlé.
Pour les logs, c’est évidemment en debug et c’est probablement alexaapi ou alexaapi_node. Regarde ce qu’il se passe à l’heure où t’as je souci, les logs sont maintenant horodatés.
Pour l’astuce de Gorgluk, non, il n’y a pas de problème sur speak, il « peut » (2% de chance) y avoir un souci d’autorisation du serveur Amazon, dans ce cas, si le plugin détecte un souci d’autorisation, il réinitialise le lien et cela prend 2s. Ce qui veut dire que la 1ere commande « peut » ne pas passer et la seconde passera. C’est juste une sécurité et l’idée est bonne. Ça n’augmente pas les requêtes au serveur, il est costaud. Pour tester la capacité du serveur, j’ai tenté l’ajout de 500 rappels et dans la foulée la suppression de tous les rappels 1 par 1, le serveur a bien suivi et je n’ai eu aucune erreur.
Donc c’est pas un speak de plus ou de moins qui change quelque chose. Au lieu de faire un speak à volume zéro, il suffit de faire deux fois une commande volume à 5s d’intervalle, et ça suffit.
Désolé pour la première question, je suis pas encore attentif aux tags
je posais la question pour le plugin pour Alexia, car pour la Google home, les plugins pour faire du TTS ne gèrent pas bien un envoi de plusieurs messages à suivre, je voulais savoir si c’était mieux géré par le plugin ou peut-être par la technologie de la boîte Amazon
Un exemple, j’ai un scénario avec 7 commandes ‹ parler › a suivre avec des phrases de différentes longueurs, avec le GH, je n’entends que la dernière phrases
Je pense qu’aucun serveur asynchrone ne gèrera bien cela, en effet, les commandes sont traitées quand elles arrivent et en toute logiques, elles ne sont pas liées entre elles donc, si à 2s d’intervale, on envoie un texte à lire de 5s,le premier sera forcement coupé.
L’idée de mettre une tempo du temps de la lecture du premier message me semble être une bonne solution.
Le principe c’est que le plugin te donne les outils, c’est à chacun à adapter l’utilisation dans les scénarios.
Pour palier ca, j’ai du faire un scénario qui vérifie que le GH est disponible, qui stock les messages si non dispo puis essaye de les renvoyer, ca marche pas mal mais avec le scénario la tentative de renvoi ne peut être faite moins de 1 minutes alors ca génère un blanc pas très agréable
@Mips2648 a fait un plugin ‹ notification queue › qui pourrait gérer ce besoin mais c’est pas encore pleinement fonctionnel avec mes tests en tous cas
Ha ? ben non, avec Alexa, le temps de latence est très court, 1s peut-être.
Si tu as un message de 10s puis un autre de 10s, tu fais :
Message 1
Pause 10s
Message 2
Après, faut vraiment avoir l’utilité de faire ça, je vois pas trop pourquoi, mais j’imagine que tu dois en avoir besoin.
La limite n’est pas celle de la GH mais du scénario Jeedom qui ne permet pas de faire un ‹ dans › de moins d’une minute
J’utilise beaucoup la GH pour faire communiquer ma domotique, un simple scénario qui donne quelques informations le matin et les phrases peuvent de télescoper et je veux pas gérer les pauses dans chaque scénario
Désolé, je suis un peu HS sur le post mais je voulais savoir si vous aviez cette même problématique, merci pour les réponses
merci pour toutes ces explications, je pense avoir compris maintenant
Je vais donc essayer de modifier mes scenarios en intégrant les informations que tu m’as communiqué.
Entres autres, douber la première commande (volume ou speak) quand j’enchaine plusieurs commandes avec Alexa, mettre des pauses après une commande seulement si elle est longue à s’exécuter (speak de plusieurs secondes) et ne plus mettre de refresh avec une série de commande Alexa.
Je vais tester tout ça et reviens vers toi rapidement pour te faire un retour.
Merci à tous pour votre aide et vos expériences partagées !
@+
je reviens vers toi après des essais réalisés ce soir avec le plugin alarme.
J’ai eu de nouveau le problème du speak qui ne s’est pas exécuté lors de l’activation et la désactivation de l’alarme. J’ai enlevé les refresh en début de scénario et les pauses entre chaque commande, sauf celle après le speak qui dure plusieurs secondes.
Ci après une copie d’écran, des actions effectuées lors de l’activation de l’alarme (sauf la première ligne qui est une action immédiate et la 5ème ligne qui est un speak en mode absent, j’étais en mode nuit…) :
Et ensuite le log alexa_node en mode info, car je n’étais pas en debug à ce moment là… mais j’ai l’impression qu’il s’est mis en debug tout seul lors du problème :
undefined[2019-10-30 20:49:00] Alexa-API: Lancement /Volume avec paramètres → device: 9a7fb38e624c4cd180b155bd437a3db1 & value: 19
undefined[2019-10-30 20:49:01] Alexa-Remote: Response(3): OK
undefined[2019-10-30 20:51:05] Alexa-API: Lancement /Volume avec paramètres → device: 9a7fb38e624c4cd180b155bd437a3db1 & value: 50
undefined[2019-10-30 20:51:06] Alexa-Remote: Response(3): OK
undefined[2019-10-30 20:51:06] Alexa-API: Lancement /Speak avec paramètres → device: 9a7fb38e624c4cd180b155bd437a3db1 & text: Alarme périmétrique activée.
2[2019-10-30 20:51:06] ******************************************************
2[2019-10-30 20:51:06] DEBUG*******
2[2019-10-30 20:51:06] ******************************************************
2[2019-10-30 20:51:06] DEBUGDEBUGAlexa-Remote: Response: No/Invalid JSON
undefined[2019-10-30 20:51:06] Rate exceeded: Too many requests.
undefined[2019-10-30 20:51:06] DEBUGDEBUG Message Exception :Unexpected token R in JSON at position 0
2[2019-10-30 20:51:06] ******************************************************
2[2019-10-30 20:51:06] ******************************************************
undefined[2019-10-30 20:51:06] Alexa-API: ******************************************************************
undefined[2019-10-30 20:51:06] Alexa-API: ERROR***
undefined[2019-10-30 20:51:06] Alexa-API: ******************************************************************
undefined[2019-10-30 20:51:06] no JSON
undefined[2019-10-30 20:51:06] Alexa-API: ******************************************************************
Error: no JSON
at IncomingMessage. (/var/www/html/plugins/alexaapi/resources/lib/alexa-remote.js:1027:52)
at IncomingMessage.emit (events.js:215:7)
at endReadableNT (_stream_readable.js:1183:12)
at processTicksAndRejections (internal/process/task_queues.js:80:21)
undefined[2019-10-30 20:51:06] Alexa-API: ******************************************************************
undefined[2019-10-30 20:51:06] Alexa-API: ******************************************************************
undefined[2019-10-30 20:51:11] Alexa-API: Lancement /Volume avec paramètres → device: 9a7fb38e624c4cd180b155bd437a3db1 & value: 19
undefined[2019-10-30 20:51:11] Alexa-Remote: Response(3): OK
2[2019-10-30 20:51:17] Alexa-API: *******************************************
2[2019-10-30 20:51:17] Alexa-API: Server is already listening on port 3456 *
2[2019-10-30 20:51:17] Alexa-API: *******************************************
undefined[2019-10-30 20:51:17] Alexa-Remote WS-MQTT: Close: 1005:
2[2019-10-30 20:51:18] Alexa-Remote WS-MQTT: Initialization completed
undefined[2019-10-30 20:53:20] Alexa-API: Lancement /Volume avec paramètres → device: 9a7fb38e624c4cd180b155bd437a3db1 & value: 50
undefined[2019-10-30 20:53:21] Alexa-Remote: Authentication check successfull
undefined[2019-10-30 20:53:21] Alexa-Remote: Response(3): OK
undefined[2019-10-30 20:53:21] Alexa-API: Lancement /Speak avec paramètres → device: 9a7fb38e624c4cd180b155bd437a3db1 & text: Alarme désactivée. Vous pouvez entrer. Bienvenue chez vous.
2[2019-10-30 20:53:21] ******************************************************
2[2019-10-30 20:53:21] DEBUG******
2[2019-10-30 20:53:21] ******************************************************
2[2019-10-30 20:53:21] DEBUGDEBUGAlexa-Remote: Response: No/Invalid JSON
undefined[2019-10-30 20:53:21] Rate exceeded: Too many requests.
undefined[2019-10-30 20:53:21] DEBUGDEBUG Message Exception :Unexpected token R in JSON at position 0
2[2019-10-30 20:53:21] ******************************************************
2[2019-10-30 20:53:21] ******************************************************
undefined[2019-10-30 20:53:21] Alexa-API: ******************************************************************
undefined[2019-10-30 20:53:21] Alexa-API: ERROR***
undefined[2019-10-30 20:53:21] Alexa-API: ******************************************************************
undefined[2019-10-30 20:53:21] no JSON
undefined[2019-10-30 20:53:21] Alexa-API: ******************************************************************
Error: no JSON
at IncomingMessage. (/var/www/html/plugins/alexaapi/resources/lib/alexa-remote.js:1027:52)
at IncomingMessage.emit (events.js:215:7)
at endReadableNT (_stream_readable.js:1183:12)
at processTicksAndRejections (internal/process/task_queues.js:80:21)
undefined[2019-10-30 20:53:21] Alexa-API: ******************************************************************
undefined[2019-10-30 20:53:21] Alexa-API: ******************************************************************
undefined[2019-10-30 20:53:29] Alexa-API: Lancement /Volume avec paramètres → device: 9a7fb38e624c4cd180b155bd437a3db1 & value: 19
undefined[2019-10-30 20:53:30] Alexa-Remote: Response(3): OK
undefined[2019-10-30 20:54:03] Alexa-API: Lancement /checkAuth
undefined[2019-10-30 21:00:05] Alexa-API: Devices
undefined[2019-10-30 21:00:06] Alexa-API: Lancement /checkAuth
undefined[2019-10-30 21:00:06] Alexa-API: routines
undefined[2019-10-30 21:00:09] Alexa-API: routines
2[2019-10-30 21:00:09] ******************************************************
2[2019-10-30 21:00:09] DEBUG*******
2[2019-10-30 21:00:09] ******************************************************
2[2019-10-30 21:00:09] DEBUGDEBUGAlexa-Remote: Response: No/Invalid JSON
undefined[2019-10-30 21:00:09] Rate exceeded: Too many requests.
undefined[2019-10-30 21:00:09] DEBUGDEBUG Message Exception :Unexpected token R in JSON at position 0
2[2019-10-30 21:00:09] ******************************************************
2[2019-10-30 21:00:09] ******************************************************
undefined[2019-10-30 21:00:09] Alexa-API: musicalalarmmusicentity
undefined[2019-10-30 21:00:10] Alexa-API: Alexa.whennextalarm: Retour vide
undefined[2019-10-30 21:00:10] Alexa-API: WhenNextMusicalAlarm
undefined[2019-10-30 21:00:10] Alexa-API: Alexa.whennextalarm: Retour vide
undefined[2019-10-30 21:00:10] Alexa-API: WhenNextAlarm
undefined[2019-10-30 21:00:11] Alexa-API: Alexa.whennextalarm: Retour vide
undefined[2019-10-30 21:00:11] Alexa-API: WhenNextReminder
undefined[2019-10-30 21:00:11] Alexa-API: Alexa.whennextreminder: Retour vide
undefined[2019-10-30 21:00:11] Alexa-API: WhenNextReminderLabel
undefined[2019-10-30 21:00:12] Alexa-API: Alexa.whennextreminder: Retour vide
undefined[2019-10-30 21:06:03] Alexa-API: Lancement /checkAuth
Qu’en penses-tu ? Est ce que cela te suffit pour analyser le problème ?
undefined[2019-10-30 20:53:21] Rate exceeded: Too many requests. Trop de demande au serveur ?
