Problème réglé, j’ai du utiliser un vieux backup, merci @dJuL pour ton efficacité 
Pas de soucis.
Par contre les erreurs que tu avaient ne sont pas un bug mais une action exécutée quelque part avec un paramètre nombre qui contient NULL au lieu d’un nombre.
Dans ton cas ça pourrait ressembler par exemple à une variable pour spécifier le volume dans l’action tts du scénario de commande vocale qui serait vide.
Je ne pense pas que réinstaller JPI avec la même configuration va corriger le problème …
OK, bien compris, je vais vérifier mes modifs de volume.
Par contre j’ai encore 2 questions
1 - J’ai mis en oeuvre la détection de mouvement, c’est ok, j’ai bien les pop up mais par contre l’écran se réeteint 1 sec après son rallumage (la tablette à un timing de 5 mn sur la veille … et j’ai rajouté un ‹ screenOn › dans la macro). Problème matériel ou j’ai loupé un épisode ?
2 - J’ai une surveillance d’appareil personnalisé avec ces 2 réglages :
Le problème est que lors des microcoupures de moins de moins de 1 mn il envoi quand même un message malgré une clef de scénario à 120
Faut il renommer la variable DEVICE2off60 ???
- Je ne sais pas sans voir le détail du scénario et de la configuration mais ça ne me semble pas normal
- Il faudrait voir dans le journal des événements quand le scénario 120 se déclenche (si c’est bien 2 minutes après la 1ère détection de offline)
Non le nom de la variable n’a aucune incidence.
Par contre le message du sms est « hors ligne depuis 1 minute » au lieu de « 2 minutes » qui correspond à 120s.
En théorie le scénario devrait bien se déclencher au bout de 120s de offline, si ce n’est pas le cas c’est pas normal
Bah je ne vois pas de screenOn
C’est donc normal que l’écran se ré-éteins direct après le toast si il était déjà éteint…
Le screenon avait sauté avec la réinstall 
mais même avec le problème subsiste.
Après vérif il s’avère que le paramétrage de l’écran de veille repasse à 30 sec même si je le force à 10 mn. J’ai l’impression qu’il revient à 30 sec (valeur défaut) lors d’une détection de mouvement.
Est il possible de le ‹ forcer › ? (galaxy tab4 android v 5.01) ? @dJuL
Problème résolue.
Si cela peut resservir à quelqu’un, FullyKiosk avait modifier un paramètre empêchant la prise en compte le timing de l’écran de veille. Le seul remède est de réinitialiser les paramètres de la tablette, après il faut tous réinstaller !
Au final tout est OK, et JPI n’y était absolument pour rien !!!
Au passage, en remplaçant FullyKiosk par JPI pour piloter les design et faire la détection de mouvements j’ai gagné 30% de CPU !!! Merci @dJuL !!!
1 « J'aime »
J’essaye d’installer l’apk JPI sur un vieu XT894 rooté, tournant sur un LineageOS-14.1 (Android 7.1.2).
Tout se passe bien, jusqu’au « Search PAW data folder », qui fail. Pourtant lors du premier lancement, PAW a bien décompressé ses data.
Le chemin des data est bien renseigné dans le « PAW home ».
Je suis reparti sur un OS vierge, viré toute conf de PAW, idem …
Pourtant dans /storage/xxx-xxxx/paw j’ai bien les données de PAW … Si je supprime ce rep, PAW le recréé bien…
PAW Server est fonctionnel…
Toutes les permissions sont OK pour PAW et pour JPI.
Il n’y a pas un moyen de donner le path directement à l’apk JPI ?
J’ai raté une étape ?
Any help ?
EDIT : j’ai testé en downgradant sur une vieille version 0.958 problème idem …
Je vais regarder ça, la partie qui check le chemin est la même depuis le début de JPI et personne n’avait jamais soulevé ce problème avant.
Les xxx-xxxx c’est le nom qui est masqué volontairement ou c’est le vrai nom du dossier ?
Masqué volontairement (je ne l’avais plus en tete), c’est bien l’ID de la partoche.
Testé aussi avec l’api15 (v0.94) au cas où, problème idem.
Je peux tester avec à peu près tous les symlink et points de montage, ça ne change rien (ex : /mnt/sdcard/paw).
ça devrait marcher avec storage/0/emulated qui et le truc de base de 99% des devices.
Je suis au taff je peux pas checker de suite…
Edit: par contre bizarre que l’os n’a pas ce point de montage, j’ai lineage OS7 également sur un S4 mini et c’est bien là qu’il y a tout les fichiers.
C’est une espèce de sdcard virtuelle pour stocker tous les fichiers utilisateurs qui est retournée par la fonction environment.getExternalStorageDirectory()
Alors que toi il semble que les donnée se trouvent sur la partition interne de l’appareil…
Edit 2: du coup pas sur que le symlink fonctionne vu que je pense que j’utilise la fonction native Android pour avoir le répertoire des données, fonction qui retourne surement null chez toi.
Faut que je check le code de l’APK pour voir comment c’est fait…
Je te confirme que /storage/0 n’existe pas sur ma ROM lineage.
Ma « sd virtuelle » est bien montée dans /sdcard (et ailleurs d’ailleurs).
EDIT : je me suis fait un petit mount bind vers /storage/0/emulated … et là ça passe.
Tu as hardcodé le chemin quelque part ?
Désolé d’être dans le 1% des cas différents
En principe non, ça m’étonnerai beaucoup que j’ai fais ça.
De mémoire je scan la mémoire interne des données utilisateur et les potentielles sdcard si je trouve rien, le tout via les fonctions internes android mais faut que je check le code car c’est très vieux.
Vraiment pas de quoi être désolé, le but est que tout fonctionne sur 100% cas de figures (et c’est pas les cas de figure qui manquent avec les différentes versions Andoid, les surcouches et les ROMS…) 
Ca a l’air plus compliqué que ça …
J’avais donc un premier lancement OK de JPI avec la GUI.
Je viens de re-tester la procédure (ba oui je suis sysadmin, mais pas de connaissance en dev android) : désinstallation paw + jpi, suppression du dossier paw, réinstall avec le chemin dans paw /storage/0/emulated … Et ba … le check ne marche plus !
EDIT : je n’arrive pas à reproduire à chaque fois le même comportement … Je continue de tester …
EDIT2 : je sens bien la race condition …
EDIT3 : si tu as une version qui balancerait un peu de débug dans le log de boot de JPI ça pourrait être intéressant (genre le retour de ta fonction environment.getExternalStorageDirectory())
En résumé la seule procédure où ça fonctionne chez moi :
- On repart de zéro : suppression/désinstallation, suppression du dossier paw sur SD forcekill PAW+JPI.
- mount bind de la SD vers /storage/0/emulated
- Installation de JPI qui installe automatiquement PAW
- Lancer PAW à la main pour extraire le content (le wait de la procédure est trop court pour mon tel, et sans le lancer à la main ça ne fonctionne pas forcément). Le Home de PAW n’est pas forcément /storage/0/emulated, il peut etre /storage/xxx-blabla/paw
- Relancer JPI, le check du content passe dans la majorité des cas mais pas tout le temps.
Si ça ne fonctionne pas, il faut que je relance la procédure de 0 car ça ne fonctionnera jamais.
Je n’ai pas réussis à reproduire à coup sur le fonctionnement ou le non fonctionnement…
→ Si /storage/0/emulated n’est pas monté, je n’ai jamais réussis à avoir le check de JPI fonctionnel.
Ok c’est curieux tout ça.
Je viens de rentrer et comme prévu JPI ( si il ne trouve pas les chemins par défaut basés sur la racine retournée par Environment.getExternalStorageDirectory() + les répertoires possibles de Paw ) scanne ensuite le dossier complet retourné également par la fonction Environment.getExternalStorageDirectory()
Il y a donc un potentiel bug dans ta ROM car cette fonction devrait retourner null et non pas sorage/0/emulated vu que le dossier n’existe pas par défaut dans la ROM !
Sachant que ce dossier est également un point de montage virtuel dans toutes les ROMs, custom ou stock, c’est surement un oublie des devs de la ROM.
Après pourquoi parfois ça passe, et parfois non, ça je sais pas… Peut être que l’OS peut mettre un certain temps avant de détecter la liaison symbolique et de faire en sorte que la fonction retourne le chemin au lieu de null…
Cela expliquerait également la réaction de paw sur la destination de l’extraction
Bon alors 1% j’étais gentil, ça doit être plutôt 0.1 % 
En fait il semble, après recherches, que ce pb survient sur les très vieux modèles qui avaient besoin d’une carte SD physique pour fonctionner…
Bref j’ai ajouté un truc qui devrait marcher sans avoir besoin de faire un symlink.
Ce sera dans la prochaine version qui est prête et qui sera en ligne d’ici ce WE je pense.
Tu me diras si ça marche.
1 « J'aime »
Update du code v0.98 en ligne ! 
Ajout du support du bluetooth pour la reconnaissance vocale, ajout d’actions Jeedom et d’action pour la gestion de l’écran, diverses corrections.
Change log :
Interface web : CONFIGURATION / Réglages de bases / Jeedom
- Ajout d’un bouton pour tester la configuration de Jeedom
Test effectué avec les paramètres des champs protocole, IP, port, chemin, clef API et timeout afin de valider la configuration à la volée avant même d’avoir à sauvegarder la configuration.
Interface web : CONFIGURATION / Réglages avancés
- / Commande Vocale : Ajout d’une option pour utiliser un micro en bluetooth (si disponible) pour la reconnaissance vocale.
- / Gestionnaire de fichiers : Refonte du bouton pour tester si le chemin racine est valide
Interface web :
- Correction de bug de scrollbars inutiles qui pouvait apparaître sur certains appareils.
- Maj du CSS
Interface web : Asssistant d’édition / exécution d’actions
- Action Jeedom / setCmd : Ajout d’un menu magique pour récupérer directement les ID des commandes, classés par OBJETS / EQUIPEMENTS
- Action Jeedom / getCmd : Ajout d’un menu magique idem a setCmd
- Action Jeedom / scenario : Ajout d’un menu magique pour récupérer directement les ID des scénario, classés par OBJETS / GROUPES
NOTE: pour récupérer les ID de l’action Jeedom / scenario il faudra attendre une prochaine maj de Jeedom (le temps que la modif arrive dans la branche release), ou bien effectuer vous même cette ajout dans le fichier core/api/jeeApi.php : Update jeeApi.php by rulistaff · Pull Request #1578 · jeedom/core · GitHub
Ajout d’actions :
- Jeedom / setVariable : Permet de définir ou modifier une variable Jeedom
- Jeedom / getVariable : Permet de récupérer le contenu d’une variable Jeedom
- Jeedom / message : Permet de publier un message dans le centre des messages Jeedom
- Système / sleepScreen : Permet de définir la durée (en seconde) de mise en veille de l’écran, -1 pour jamais éteindre (Peut ne pas fonctionner sur certains appareils)
- Informations / getScreenTime : Retourne la durée (en seconde) de mise en veille de l’écran
Core :
- Corrections dans le moteur des journaux afin de supprimer certains caractères qui pouvait parfois compromettre l’intégrité du log (à la sauvegarde et à la lecture)
- Maj de l’initialisation
- Maj des fichiers de langues
- Diverses corrections et optimisations
NOTE: Vous devez d’abord mettre à jour l’APK de JPI en v0.98 pour pouvoir avoir accès à cette mise à jour du code.
Update de l’APK v0.98 en ligne !
- Ajout du support du bluetooth pour la reconnaissance vocale
Il est possible de connecter / déconnecter à chaud un handset BT pendant la reconnaissance vocale continue, la bascule est automatique.
- Ajout du support du bouton BT de lancement de l’assistant Google pour pouvoir lancer à la place la reconnaissance vocale de JPI (lors du premier clique il faut l’associer à JPI sur l’écran de l’appareil)
- Lors de l’utilisation de la croix Rouge pour vider le log des erreurs, maintenant les notifications android des erreurs de JPI sont également vidées.
- Il y avait un bug sur la vérification des permissions d’accès aux notifications si plusieurs applications avaient la permission accordée => corrigé
- Nouvelle méthode pour trouver les dossiers de Paw, qui peuvent être n’importe où, en interne ou sur une carte SD externe, et même si le dossier racine ‹ paw › est renommé (Il est déconseiller de changer le chemin du répertoire créer par défaut au 1er lancement de Paw pour éviter à JPI de scanner partout et de rallonger le démarrage de JPI)
- Rallongement du délais d’attente de l’extraction des données de paw lors de l’installation de JPI sur les plus vieux appareils.
- Support des nouvelles actions
- Divers corrections et optimisations
Change log versions précédentes:
v0.974: jpi-apk-android-tel-dedie-domotique/10014/22
v0.973: jpi-apk-android-tel-dedie-domotique/10014/22
v0.97 à 0.972: viewtopic.php?f=27&t=18283&start=3020#p627896
NOTE : Cette version est probablement à prendre comme une “V1” et devrait être relativement stable. (testé sous Android v5 à v9)
NOTE² : pour les vieilles version d’android (< V6) les designs de Jeedom V4 nécessitent la mise à jour de l’appli système WebView. Il faut parfois bidouiller et avoir l’accès root pour pouvoir la faire.
Symptômes : Mauvaises couleurs des fonds et des textes dans les designs qui sont dues aux variables CSS présentes dans Jeedom V4 et qui ne sont pas supportées par les vieux moteurs WebView
Ex pour résoudre le pb (nécessite un accès root) :
Testé avec succès sur des tablettes android V5.1 où il n’était pas possible de mettre à jour ou de choisir la version de webview.
L’application restera gratuite. un bouton donation se trouve dans la fenêtre DIVERS / A propos de l’interface web si vous souhaitez soutenir le projet. 
Screen shots :
Nouveau bouton de Test de la configuration de Jeedom :
Nouveaux menus magique pour récupérer directement les id Jeedom :
Nouvelles actions :
Vidéo de démo du bluetooth pour les interactions :
L’application restera gratuite. un bouton donation se trouve dans la fenêtre DIVERS / A propos de l’interface web si vous souhaitez soutenir le projet.
1 « J'aime »
Bravo @dJuL !
Le réglage du temps de veille est géniale (testé, nickel), mais la prochaine version essaye de la publier au moins une semaine avant de l’avoir faite Ca me fera gagner du temps !!! 
.
Par contre la fonction getScreenTime est introuvable . Je compte l’utiliser pour le sleep du contrôle de mouvement pour gagner en lisibilité dans les logs en diminuant les appels ResumeMotionDetector
PS : comme elle a l’air sympa, tu peux nous donner la référence de ton boitier musical magique ?