C’est corrigé en 4.1.19.
A mon sens c’est une très mauvaise idée de forcer le refresh. Il vaut mieux trouver ton problème meme si il est long a identifier.
Pour la position de ta tablette, je ne vois pas pk elle peut merder par rapport à son emplacement sauf si tu as unr mauvaise connection locale. Wifi ou RJ45 ? Tres localement ? Si wifi est ce que la position de l’AP wifi est bon ? Qualité du signal. Test de debit depyus ta tablette ? Ping sur plusieurs minutes voir si le reseau ne decrohe pas ? As tu plusieurs AP wifi ? Si oui sont ils managés ou certains qu’ils sont sur des canaux differents ?
Mais ca ne justifie pas tes problèmes
Je serais toi j’essayerai deja de comprendre ce problème d’afficage. Il doit y avoir un truc.
Euh tu crois que cela fait combien de temps que je suis dessus ? Je peux comprendre ta réaction de lecteur à cet instant, mais si tu remontes dans les posts, j’ai remonté ces soucis depuis novembre. Bientôt 2 mois et demi.
1 tablette achetée en plus, 1 prêtée.
Pour récapituler :
tout fonctionnait depuis des années, des mois dans la configuration actuelle : routeurs, même SSID (2.4G/5G), canaux autos, DHCP routeur avec fix des adresses pour les équipements domotiques, etc
au même endroit j’ai un tél asus depuis 4 ans qui fait tout pareil sans souci,
j’ai une autre tablette (cuisine) qui est connectée sur le même routeur, celle du couloir est sur le routeur aimesh,
cela se passe sur une tablette à un endroit de la maison (à côté du routeur principal un Rog 5300, pardon !)
j’ai tenté de passer les routeurs en MerlinWRT au cas où, nada,
si je change la tablette par une autre tablette (de même marque, modèle (Lenovo mtab) ou configuration équivalente (Xiaomi mipad4plus), idem ;
pas d’adresse MAC aléatoire sur Android 10 et autre, au plus simple,
problème sur tablette avec ROM lenovo (assez propre) ou xiaomi avec une AOSP rootée ou…
j’ai tenté l’app jeedom avec le design ou jpi avec le design, ça part en pas de réponse au bout de quelques minutes,
j’ai tenté les allégèments graphiques des tablettes à chaque fois, mais quand bien même, je ne comprends pas pourquoi étant donné les configurations (snap > 660 ; 4 go de ram avec 2.5 Go de ram ; les tablettes n’ont rien de plus que JPI/PAW/Doorbird ; pas de détection de mouvement par caméra ; pas de flux vidéo enclenché par défaut).
si je mets un mode immersif avec un chrome ou firefox, aucun souci ! (ça prouve quand même que c’est côté webview sur JPI/Jeedom).
Le ping de surveillance jeedom ne voit rien de particulier (mac + port 8090 de paw).
J’ai testé les tablettes dans un autre endroit de la maison et je n’ai pas ce problème. J’ai pas non plus un château !
Je vais tester avec un routeur différent …
Sur routeur de l’étage Aimesh (ac68u), les tablettes sont connectées en Wifi 5GHz. L’aimesh propose un wifi 5G double avec un black hole.
Mais les canaux étant les mêmes sur les routeurs, je n’ai aucun intérêt à les changer car cela marche…
Pour ta remarque sur le refresh en 4.1.19, non, j’ai encore des cas où j’ai des capteurs xiaomi qui ne remontent pas dans mes tableaux. J’ai d’ailleurs fait au plus simple car j’ajoute les capteurs au lieu de passer par les résumés ou groupes. j’utilise un widget dédié pour changer la couleur, peut être que cela vient de là mais j’en doute après relecture. Je ferai un topic dans ce sens…
EDIT : configuration modifiée en fixant les canaux en manuel.
Par contre, j’ai perdu le sonoff et la raspberry extérieure car pas compliant avec les canaux en question…
EDIT2 : toujours pareil même en changeant les canaux…
Si, bien sur que si ça doit marcher, mais il faut inclure dedans également ta fonction addColspan.
Regarde avec F12 dans le navigateur pour voir quelle est l’erreur javascript dans la console. Si ça marche pas c’est que le code JS n’est pas bon.
Non. tu peux très bien rafraichir la page en JS toutes les x secondes mais c’est pas terrible car ça touchera tout les appareils qui affichent le design.
Le mieux c’est une tache cron JPI qui effectue juste l’action refreshLayout
Cette action ne remet pas JPI au premier plan et rafraichi tout ce que JPI est entrain d’afficher (page d’accueil ou design en cours, ou log…)
Du coup elle n’interférera avec rien, peu importe ce que fait la tablette, et si elle affiche un design il sera rafraichi à chaque exécution de la tâche cron JPI.
Merci @djul. Je te tiens au courant des essais routeur.
Le fait d’avoir couper un wifi 5GHz (blackhole), d’avoir changé de canaux etc … rien n’a changé. Toujours KO.
@dJuL, est-ce que le refreshLayout rallume l’écran si ce dernier est éteint ?
J’aimerai que non justement…
Ce que j’observe c’est que la tablette s’allume,
En dernier recours, il me faut prévoir un screenoff…
Je voudrai éviter un cron côté tablette…
Le plus simple reste d’essayer.
Il peut rallumer l’écran oui, mais si il était éteint il n’est rallumé que quelques secondes et s’éteint à nouveau après le rafraichissement comme pas mal d’actions JPI qui effectuent automatiquement le screenOff si l’écran était éteint au moment de la demande (du moins pour les actions qui ont besoin d’allumer l’écran pour fonctionner).
J’utilise beaucoup les taches Cron JPI et ça marche très bien (je m’en sert pour nettoyer les écrans la nuit, vérifier le niveau de ram, les connexions BT…)
Je trouve même totalement illogique de faire des taches cron Jeedom quand il s’agit uniquement d’interagir sur JPI… (cela prend des ressources Jeedom pour rien et nécessite que et Jeedom et JPI soit online pour pouvoir se lancer).
Je voulais savoir si c’était un comportement attendu ou non. Comme pour le wifi, je me doute que certaines ROM peuvent être limitantes par rapport à ton comportement.
Je fais des crons de screenon à cause de cela côté jeedom mais aussi car je me sers des capteurs de mouvement moins coûteux en batterie au regard de la caméra en détection de mouvement.
Quand je disais cron tablette à éviter c’était dans le sens, je veux éviter de faire un refresh du design pour parer à un problème d’affichage côté jeedom.
Je fais un refresh des designs chez moi, uniquement quand l’écran est éteint depuis 120mn, j’en déduit qu’il y a de fortes chance qu’il n’y ait personne dans la pièce.
Donc si il y a personne j’ai un refreshLayout toutes les 2 heures.
Tant qu’il y a une présence pas de refresh.
J’utilise également des capteurs côté Jeedom en plus du motiondetector pour être sur que les tablettes soient allumées quand on est dans la pièce.
Par contre pas de cron pour ça, Une action perso avec un sleep nommé suffit.
Je gère d’ailleurs mes screenOff en manuel de la même manière (sleep nommé).
Toutes mes tablettes sont synchronisées pour ne plus avoir à aller sur leurs interfaces web d’où l’utilisation des mots clefs locaux et de certains tests dans les scénarios ci-dessus
Approche intéressante. J’avais pensé à ce point en combinant la récupération du détecteur de mouvement, mais il faut bien donner l’ordre côté jeedom. Moi je lui donne l’ordre d’allumer. Toi tu lui donnes l’ordre de lancer une action perso. Effectivement en terme de charge, je comprends le jeu.
Après, moi c’est l’inverse je veux soulager au max les tablettes pour ne pas les décharger car ma VM est largement capable (j’ai un core i5 10e gén avec 32 go pour le serveur maison). Je me rappelle que tu avais expliqué que tes tablettes étaient sans batterie avec soudure du chargeur en direct.
Effectivement ça doit bien vernir de cela.
C’est facile à résoudre car JPI à déjà toutes les autorisations et permissions nécessaires pour lancer une app sous Android 10.
Il suffit juste que je modifie pour que ce soit le service de JPI qui lance l’appli et non Paw car actuellement l’action launchApp est entièrement effectuée par le code de JPI sous Paw (et je ne peux pas modifier l’apk de paw pour qu’elle ait les autorisations nécessaires).
C’est pour cela qu’actuellement une grande partie des actions de JPI sont effectuées par le service de JPI et que je suis obligé d’en déplacer au fur et à mesure de l’évolution des versions Android, en voici encore un exemple…
Ce qui revient au point qu’un jour il faudra oublier Paw qui devient vieillissant et que j’intègre le serveur web directement dans JPI, mais cela représente un boulot titanesque vu la complexité de JPI…
Certes, mais exécution du scénario mis à part (qui prend tout de même très très peu ressource vu la simplicité, et pendant seulement quelques ms) un sleep sous JPI prend 0% de ressource (tout comme un cron qui utilise le moteur cron du system Android).
Les 1er consommateurs de batteries, et de loin, sont l’écran, le wifi…
Ensuite le CPU si on utilise le streaming / détection de mouvement ou la reconnaissance vocale continue. Sinon à mois de faire tourner volontairement des milliards de boucles pour consommer du CPU, ou bien de saturer paw de requêtes http, JPI prend très peu de ressources.
Sur l’une de tes captures d’écran on voit 2 canaux wifi qui se superposent. Même si l’un est bcp plus faible, ce n’est jamais bon. Ton device met peu etre du temps à changer de canal.
Hypothèse mais je ne sais pas si ton problème peut venir du réseau ou non.
Attention aussi à bien les espacer afin qu’il n’y ait aucun chevauchement.
Par exemple en 2.4Ghz on ne devrait que utiliser les canaux 1, 6 et 11.
C’est le même principe en 5Ghz sahcant que les canaux sont plus larges. Il faut espacer d’autant.
Bon j’ai testé avec un autre routeur ou l’ancien et kif kif.
Par contre, je me rends compte que les tablettes sous Android 10 sont plus lentes pour charger le design. J’ai pris l’apk beta Android 10 que tu as donné et je n’ai plus de « pas de réponse » ou « arrêter ».
Du coup, je pense que je vais augmenter le délai avant de décider d’éteindre pour éviter d’avoir ces lenteurs de démarrage et refresh.
@dJuL tu me confirmes que tu laisses tes tablettes allumées tout le temps régulièrement ? C’est vrai que j’ai tendance à les éteindre assez rapidement (3 à 5 min) quand plus de mouvement.
Pour info, j’ai refait avec l’outil du routeur Asus en laissant la gestion automatique. J’ai fixé le canal 2 pour le 2.4 GHz car j’avais trop de déconnexion régulière de l’Harmony en 2.4 GHz.
En 2,4 GHz, je suis tout seul mais bon les autres réseaux des voisins font du hopping aussi (saut de fréquence). Moi je reste centré au 2 (couleur rouge).
En 5 GHz sur le réseau Aimesh visible, encore tout seul. Du moins les réseaux voisins ne sont pas visibles. Par contre, mon téléphone en voit plus car meilleure sensibilités.
