Si il n y pas de son avec l’action play également c’est forcément que le volume est muté…
Bon, alors on fera avec, ça encouragera à mettre la VR en veille, j’avoue que en test elle reste en écoute en permanente, sinon c’est vrai que je ne l’aurais pas forcément remarqué 
Je suis en écoute permanente 24/24 et je l’entend assez rarement, ça ne me gène pas plus que ça…
Bravo @dJuL, comme d’habitude ça fonctionne au quard de tour, la connection avec Emeet se fait dorénavant via le scénario par défaut de la VR, c’est nickel et maintenant je peux envoyer de la musique à un autre HP quand je ne me sert pas de la VR.
1 « J'aime »
Chez moi c’est toutes les 5 mn chrono sans jamais de décalage dans le temps …
Cela correspond au time out de retour en veille, je vais essayer de le pousser à 900 pour voir
A ce propos on ne peut mettre ni 0 pour le désactiver ni une valeur > à 999)
De quel timeout parles tu ?
Si tu parles de l’action sleepScreen c’est -1 pour désactiver et ça peut monter jusqu’a 86400s (24h) !
Ah ok.
En mode veille la reco est toujours continue, c’est juste qu’on sort du mode en cours et que JPI attend à nouveau le mot clef de déclenchement (champs défini juste au dessus du champ de ta capture)
oui, j’avais bien pigé, mais le timing du bip parasite est bien donné par cette valeur, avec 300 j’avais un bruit tt les 5 mn exactement, là je l’ai passé à 900 et apparemment je ne l’ai plus
Tout dépend ce que tu as dans le scénario de commande vocale « timeout des modes » puis dans le mode lancé ensuite dedans, si il y en a un.
C’est lui qui se déclenche une fois le timeout atteint.
edit: Ça sent le tts a un volume de 0 ou un truc du genre…
J’ai évité de toucher à tes scénarios, je me suis contenté de lancer mon scénar d’interaction en lieu et place de ton appel ‹ Interaction › et je viens d’ajouter le ManageBTDevice en tête du scénario par défaut.
Pour le TTS de JPI je n’utilise que pour répondre à la RV avec un appel unique, volume par defaut à ‹ -1 ›
Mais ce foutu bruit apparaît même au lancement de la tablette, avant même d’exploiter la VR.
La avec 900, il revient toutes les 15 mn, si j’interroge la RV, c’est 15 mn plus tard.
Bonjour @dJuL,
Je suis en pleine migration du plugin JPI vers le plugin script afin de ne plus dépendre du plugin (plus suivit depuis un moment).
J’ai recréé sans trop de difficulté les commandes.
J’ai une question, y a t’il un moyen de récupérer la qualité du signal GSM comme c’est la cas pour le wifi.
Je capte vraiment mal chez moi et je voudrais surveiller ce dernier.
J’ai rien trouvé dans la doc du framework.
Merci
D’où tiens tu l’information que le plugin n’est pas maintenu ? Je l’utilise régulièrement sans souci… Il faut créer les commandes si absentes.
Et pourtant ce n’est pas le cas 
Je ne vois pas ce que c’est du coup.
Le bruit dont moi je parle qui peut arriver de temps en temps c’est juste un petit clique, à peine audible, un peu comme celui qu’on peut distinguer juste avant le 1er tts d’une réponse vocale, oubien au lancement de la VR lorsque le micro BT s’initialise.
Non ce n’est pas possible.
La mesure est très complexe, selon le type d’appareil, la version d’android et le type de réseau (LTE, 3G…)
Du coup JPI analyse toutes ses mesures et tout les cas de figure afin de distinguer si le niveau de signal est suffisant, mais il est compliqué de réaliser un % de qualité de réception en temps réel comme dans la barre android.
Savoir si on capte suffisamment ou non pour exploiter la téléphonie et en fonction du résultat déclencher des scénarios m’a semblé suffisant.
bonjour @dJuL,
Je pense qu’il manque une fonction « getBTcurrentDevice » qui donnerait l’appareil BT actuellement connecté au BT.
Le but serais d’éviter de faire un manageBTdevice inutile quand il est déjà connecté.
L’intérét but serait de gagner du temps, l’a connexion d’un appareil, même si déjà connecté prenant 1-2 sec.
Autre solution, ne pas effectuer le manageBTdevice si le device demandé est déjà connecté.
Ce n’est pas facile à faire du tout, même si ça parait simple sur le papier…
La gestion du BT dans android est très complexe.
Déjà là, pour se connecter aux appareils appariés je suis obliger d’utiliser des hacks et des méthodes par « reflection » pour y parvenir car ce n’est pas possible officiellement via les api android (comme beaucoup de choses que fait JPI).
Je pourrai rajouté l’action, mais on n’aurait pas le résultat si la connexion BT a été faite à la main ou automatiquement par android, donc ça ne me plait pas.
Le plus simple serait de le gérer toi même, à l’aide d’une variable ou autre.
Sinon faire un manageBTdevice inutile n’a aucun impact si déjà connecté (malgré le temps d’attente)
Tu peux donc le faire de manière asynchrone dans JPI pour ne pas perdre de temps si cela est le problème (avec l’aide d’une action perso et sans attendre le résultat de l’action perso dans le scénario).
Bonjour,
Je pense que ce sujet a déjà été apporté mais j’ai du mal a retrouver les bonnes informations.
Tous les jours j’ai ce message d’erreur sur ma tablette qui affiche en pleine écran un design plein écran
{« state »:« error »,« result »:« Token d’accès invalide »,« code »:0}
J’ai mis en place un scénario pour que la tablette rentre en veille et que l’écran se rallume a la détection sur la caméra (j’ai repris le script fourni sur ce même forum.
Auriez vous une solution a me proposé pour éviter ce message et l’écran noir qui s’accompagne.
Merci d’avance.
Bonne soirée
Anthony
ok, en cas de soucis je passerais par une variable SD, effectivement si ils faut détourner les API ce serait dommage.
JPI fonctionne trop bien pour risquer de l’abimer !!!
Par contre je reviens sur le problème de l’arrêt de la détection de mouvement vu comme un problème de plantage de caméra par JPI (donc un problème matériel).
J’ai donc remonté FullyKiosk pour voir si il avait le même problème avec la nouvelle install (j’ai utilisé Fully Kiosk pendant plus d’un an avec la détection de mouvement sans soucis sur la précédente install).
apparemment cela ne pose toujours pas de soucis avec FullyKiosk, donc cela ne doit pas relever d’un problème matériel.
Par contre dans JPI, j’ai désactivé la sauvegarde des photos pour économiser du CPU :
Je vais la remettre et voir si ça impacte sur les plantages …
Tu as quoi dans le log quand ça plante ?