Il y a un petit soucis, j’avais pas vu ça…
En attendant que je corrige :
https://www.jpi-domotique.com/?all
Edit: c’est corrigé :
bonjour à tous surtout toi @dJuL
Donc voici mon problème,
j’ai une tablette Samsung Galaxy Tab 4 10.1 avec installer dessus une ROM Custom qui est rooté « bien-sûr »
lightning-17.1-20200628-UNOFFICIAL-matissewifi-Unsweetened-XDA-BUILD
Et donc quand je lance JPI dessus j’ai une erreur rebuild config et sa dans le log
- 30/10/21 13:11:21 - Server started (http://192.168.1.56:8080)
- 30/10/21 13:12:02 - Error while rebuilding config file
- 30/10/21 13:12:10 - SERVICE Erreur ligne 36:
android.view.WindowManager$BadTokenException: Unable to add window android.view.ViewRootImpl$W@4647366 -- permission denied for window type 2038
- 30/10/21 13:12:10 - 0 cron task(s) loaded
- 30/10/21 13:12:10 - Service started
- 30/10/21 13:12:33 - Service stopped
- 30/10/21 13:12:33 - Server stopped
- 30/10/21 13:12:33 - Application will restart
- 30/10/21 13:13:08 - Activity start
- 30/10/21 13:13:08 - Voice recognition not available on this system !
- 30/10/21 13:13:09 - ACTIVITY Error ligne 136: java.lang.NullPointerException: Attempt to invoke virtual method 'boolean java.lang.String.equals(java.lang.Object)' on a null object reference
- 30/10/21 13:13:12 - Server started (http://192.168.1.56:17581)
- 30/10/21 13:13:53 - Error while rebuilding config file
- 30/10/21 13:14:02 - SERVICE Erreur ligne 36:
android.view.WindowManager$BadTokenException: Unable to add window android.view.ViewRootImpl$W@f90d5c3 -- permission denied for window type 2038
- 30/10/21 13:14:02 - 0 cron task(s) loaded
- 30/10/21 13:14:02 - Service started```
si ce n'était que cela mais aussi quand je fais une sauvegarde ou un recharger il me mets une erreur
Java et plante ! Obligé de faire un kill app sur la tablette.oups désolé pour le texte en rouge
Il est déjà très compliqué de rendre JPI stable sur tous les appareils et toutes les versions d’Android.
Alors avec des roms underground…
JPI fonctionne parfaitement sous LineageOS, c’est la seule que j’ai testée ces 2 dernières années.
Essayes déjà de regarder si un composant webview est installé.
je vais essayer ça
Merci
Petite question @djul, comment fonctionne l’action brightness en auto ?
Si je mets un level à 20 et auto, est-ce JPI va « caper » la valeur de la luminosité à 20 en autorisant une luminosité de 0 à 20 uniquement ?
Je pose cette question car j’ai une tablette (xiaomi) dont je trouve la luminosité bien trop importante au regard du nécessaire (notamment par rapport à mes lenovo à côté).
Merci !
En théorie oui mais je ne sais plus trop, je crois qu’en mode auto cela peut varier selon les appareils, il faut tester.
A priori, c’est ce que j’observe. Mais je voulais ton avis. Merci.
salut dJuL
Sur quel version Android JPI peut il fonctionner? car j’ai une tablette Asus avec version d’Android 4.2.1 mais impossible d’installer apk. j’ai autoriser l installation d application de sources inconnues mais rien a faire
JPI fonctionne avec Android 4.4 (api 19) ou supérieur.
Tu as une vielle version de JPI (datant de 2017 et fonctionnant avec Paw) qui marche avec Android à partir de 4.0.3 (api 15) :
https://www.jpi-domotique.com/?all
Tout en bas de la liste.
Bonjour,
Pour information,
Je n’arrive pas à faire tourner l’API19 sur un Motorola Razer HD sous android 4.4.2.
le démarrage reste bloqué sur Load config…
Le dossier contenant les logs reste vide.
Appareil complétement à l’état usine puis mise à jour Google avant installation de l’APK.
En théorie le code est fait pour fonctionner et tout est compatible, mais j’avoue ne pas avoir testé en dessous de Android 5.1 (j’ai rien pour le faire car même mes vieux trucs ont été flashés).
Merci pour la réponse la solution est peut être là ou l’API15 …
Bonjour @djul,
Sur mon Nokia, sous Android One, hier, arrêt total de l’application.
Comme je surveille JPI sur le port 8080 via Networks, j’ai pu m’en rendre compte et j’ai un scénario qui le relance par Macrodroid (vu que l’API est off côté JPI).
Mais surtout rien du tout dans les logs… alors que tout le reste du tél est OK.
Dans l’app log :
Dans l’error log, vide !
Dans l’app, rien de probant.
Bref, je ne sais pas trop quoi te dire/donner si ce n’est que JPI avait bien toutes les autorisations (notamment batterie optimisée etc). En dernière version bien sûr.
Autre souci remarqué.
Quand je faisais sur les précédentes versions un screenoff, aucun souci.
Sur ma tablette rooté (pas de souci sur les autres), maintenant l’écran reste poweron.
Quand j’analyse :
- si je passe par script (comme c’est depuis 2 ans facile),
- par :
https://i.imgur.com/YNlYDb9.png - cela fait un screenon dans la foulée et ça déclenche le scénario d’allumage.
https://i.imgur.com/l6GqoGY.png
Incompréhensible, le screenoff me fait un screenon… ?
Je précise que je n’ai pas le souci sur les autres tablettes non rootées et que je n’avais pas ce souci sur cette tablette rootée depuis l’upgrade logicielle.
Encore plus fou, si je passe directement par l’interface web et que je génère un screenoff, l’écran ne se rallume PAS !!!
Bref, je sèche complet.
J’ai tenté de redémarrer… pareil.
Je vois qu’il y a un sleepScreen dans les logs juste après le screenOff.
Essayes de le désactiver pour voir si c’est pas lui qui rallume l’écran.
Dans l’interface web l’action est exactement la même qui si déclenchée via l’api http, le code est identique donc ça ne vient pas de l’action screenOff elle-même mais d’un autre truc…
C’est effectivement bien ça.
Avant de faire le screenoff, je faisais un changement du temps de veille.
Sauf que je n’avais aucun souci sur les tablettes rootées ou non. Sur celle là maintenant j’ai ce souci.
Du coup, j’ai fait dans les actions AVANT de faire un screenoff un sleeptime puis un wait de 5 secondes.
Je remarque que j’ai la notification « JPI a demandé les droits etc » qui est un peu longue.
Bref, là ça marche.
Par sécurité, je vais corriger sur les autres.
@benj29, j’avais un problème similaire et j’ai désactivé les notifications de demande et d’accès aux droits root dans l’appli qui me permet de rooter.
Plus de problème de screenon depuis.
1 « J'aime »
Effectivement c’est peut être l’appli de gestion des droits root qui allume l’écran pour afficher le toast (« JPI a demandé l’accès aux droits ROOT… »).
Il suffit de désactiver les notifications de demande des droits root pour JPI (ce que perso je fais systématiquement pour ne pas être pollué par les toasts).
Après l’action sleeptime allume l’écran seulement si il est allumé (ça parait curieux mais c’est pour prendre en compte le nouveau temps de veille).
Avec l’ancien JPI il y avait une tempo forcée entre les actions, mais plus là, donc peut être que ça s’enchaine trop vite après le screenOff et que pour l’action sleeptime l’écran n’est pas éteint au moment de son exécution (ça reste une hypothèse).
Donc essaye de virer les notifications par toast de demande des droits root de JPI, et ensuite si ça continue un sleep de 0.2s devrait largement suffire entre les 2 actions.
Edit: Sinon faire le sleepTime juste avant le screenOff est aussi une bonne solution, et également pour les systèmes non rootés.
edit2: J’ai rajouté une petite tempo dans l’action sleepTime au cas où, ce sera dans la prochaine maj.
1 « J'aime »
J’ai cherché bêtement les toats sur JPI root côté admin web de JPI, avant de me dire que c’était tout simplement Magisk lors d’une mise à jour qui les avait réactivé.
Problème résolu. J’ai réduit à 0.2s ; ça tourne.