[JPI-APK android] Tel Android dedié domotique

m.georgein · Mars 12, 2021, 9:23

Bonjour,

Encore un petit soucis, sur la tablette JPI les widgets ne se mettent plus à jour , les vidéos sont correctement actualisées mais les widgets non, cela fonctionne pourtant sur mon smartphone (p30 pro).
La version de webview de la tablette est 84.0.4147.111 , pas d’économiseur (…) , android 10 sur samsung tab s5e
J’ai tenté la mise à jour de webview via le plays store mais sans succès (boucle infini)

Si tu as une idée je suis preneur

dJuL · Mars 12, 2021, 10:01

Avec ça de coché c’est logique que l’écran ne s’éteigne jamais avec JPI au premier plan.
D’ailleurs faudra que je renomme la description de l’option pour être plus clair.

dJuL · Mars 12, 2021, 10:05

Comme ça non je vois pas trop.
Essaye de vider le cache de l’appli webview, de supprimer la session de la tablette dans les paramètres jeedom et de redémarrer la tablette.

dJuL · Mars 12, 2021, 10:13

Merci

La v1 oui et non, il me reste encore une grosse todo list dans ma tête…
Mais tout est relatif, car en raisonnant comme ça il n’y aura jamais de V1 car il y a toujours des choses à faire, à améliorer et à ajouter.
Mais bon il il y a tout de même quelques gros chantiers que j’aimerais finir avant ce cap symbolique.
Le plus fatiguant de tous, et qui ne me motive pas du tout sera le site et la doc
Par contre en therme d’aboutissement et de stabilité, je pense que oui, on y est quasi.

naboleo · Mars 13, 2021, 9:11

Hello

La dernière version de l’apk (fr.djul.JPI-0.9938-minAPI19.apk) ne fonctionne plus bien sur ma mibox 3.
ça coince sur l’étape (nouvelle ?) de l’optimisation de la batterie … et l’appli s’arrête
Retour à la 9937 pour ma part

dJuL · Mars 13, 2021, 10:03

C’est Android TV non ?
Je suis même étonné que JPI tourne sur Android TV sans crasher…
Ok je vais voir pour corriger ça.

Essaye avec cet APK pour voir :

http://rulistaff.free.fr/fr.djul.JPI-0.9938-minAPI19_TV.apk

naboleo · Mars 13, 2021, 10:08

Donc oui c’est de l’Android TV et ça doit faire 2 ans que jpi(+paw) fonctionn(ent) sur chez moi. Bon je l’exploite pas beaucoup c’est vrai mais jusqu’à maintenant pas de souci.

ça se lance parfaitement avec cette version !

dJuL · Mars 13, 2021, 10:15

Ok cool !
Je vais remplacer la version existante 9938 par celle là

edit:

domoggvad · Mars 16, 2021, 2:03

Bonjour @dJuL
Avant la dérnière mise à jour, lorsque je recevais de appels ou sms non désirés, je recevais un sms d’alerte, chose qui ne se produit plus, je ne sais pas si par mégarde j’ai modifié quelques chose, pourtant je n’ai rien touché aux paramètres existants
Merci d’avance

benj29 · Mars 16, 2021, 3:46

Bonjour @dJuL,

Après 6 ans de bons et loyaux services, mon Zenfone 2 a rendu l’âme. J’ai regardé l’alternative de mettre un chargeur 4.2v comme tu le proposais mais malheureusement le connecteur de batterie est impossible à souder. La SIM sautait très régulièrement, je pense que le tél a bien tourné mine de rien.

Du coup, je regarde pour investir à moindre frais.
J’étais parti sur l’occasion, mais entre le doute de la vie du téléphone, l’état de sa batterie ou l’état tout court… j’ai regardé du côté des alternatives : d’abord Xiaomi avec ces tél lowcosts.

Puis du côté d’Android One qui permet d’avoir des téléphones « nus » au niveau OS. Du coup, on sort à Nokia à 100€… neuf avec une configuration d’un tél d’il y a 3/4 ans type snap4x avec 4gb de ram.

Est-ce que tu as fait des tests sous Android One ? Vois-tu un quelconque souci à l’utilisation de PAW/JPI sous One ?

dJuL · Mars 16, 2021, 3:50

Aucune idée car je n’ai rien touché à ce niveau là.
Il faut regarder le log des événements, testé avec un numéro non autorisé pour voir ce qu’il se passe.
Et vérifier également les scénarios des numéros non autorisés des sms et des appels entrants…

C’est toujours possible de souder.
Si ce n’est pas sur le connecteur lui même, c’est possible directement sur le pcb, mais faut savoir souder sur des tout petits éléments…
Il peut être possible également de dessouder le connecteur pour souder à la place… Bref difficile a dire sans voir mais il y a toujours une solution…

Aucune idée, jamais testé.
j’avais jamais entendu parlé de Android One…

Edit: je viens de voir c’est juste un label, de ce que j’ai compris l’os reste le même, il est juste allégé un peu comme Android Go sauf qu’il n’y a aucune surcouche. donc ça ne devrait pas poser de soucis sur le papier

benj29 · Mars 16, 2021, 4:03

J’ai tenté, j’avoue que le PCB du tel ne me laissait que peu de place. J’ai trouvé par continuité un plot pour l’alimentation, mais le fait qu’il soit trop proche d’un via métallisé de masse a faussé tous mes espoirs.
A cela ajoute probablement le fin de vie de la partie RF avec la SIM qui sautait… (merci l’alerte SMS de GSM perdue/récupérée)…

Du coup, je vais investir dans un nokia à 100€ neuf… 4go et snap400.

dJuL · Mars 17, 2021, 5:02

Update du code v0.9939 en ligne !

Je n’avais pas prévu de publier cette version, mais aux vues de certaines modifs profondes, surtout au niveau de l’apk, je préfère finalement la publier tout de suite sans tout ce qui était prévu.

–

Change log

****************** ACTIONS: ******************

— Modifications d’ actions:

Système / shell => Modification de l’action afin d’éviter un crash ou un lag de JPI :
Si le script crashait, l’action pouvait rester bloquée malgré le dépasssement du timeout spécifié => corrigé
Téléphonie / answercall => Ajout du paramètre keyIndex

Explication un peu plus bas ci-dessous du rôle de ce nouveau paramètre (qui correspond à la mise à jour de la méthode Key).

****************** INTERFACE WEB - PAGES: ******************

page CONFIGURATION / Réglages avancés :
– Section Téléphonie => Refonte de la méthode key pour le décrochage des appels :

Cette méthode fonctionne dorénavant également avec un système rooté et devient la méthode par défaut.

J’ai remarqué que sur certaine ROM (Linéage OS notamment) et certains appareils, la méthode Service peut entrainer un crash de l’appli Téléphone, voir de l’OS complet et de JPI.
Si tel est le cas la méthode service ne fera plus crasher JPI, mais peut continuer à mettre l’OS dans un état instable, ce qui n’est pas le cas avec cette nouvelle méthode Key.
C’est pour cela qu’elle devient la nouvelle méthode par défaut.

Le nouveau réglage du choix du type de touche par défaut (Headset Hook) devrait fonctionner pour tout le monde. Mais au cas où, une deuxième touche est disponible (Call).

Note: pour les systèmes non rootés, la méthode Key peut tout de même fonctionner, mais il y a tout de même relativement peu de chance que ce soit le cas avec les versions récentes d’Android.

Note²: Si vous utilisez les fonctions de décrochage des appels et que cela semble perturber votre appareil, penser à passer de la méthode Service à la méthode key (seuls les nouveaux utilisateurs de JPI avec une config vierge ont la méthode key définie par défaut).

****************** MOTEUR (CORE DE JPI): ******************

Refonte de l’action shell
Support des nouvelles modifications d’actions
Maj. de la configuration d’usine.
Diverses corrections et optimisations
Maj. des fichiers de langues

ps: Si vous avez défini un user/password (autre que ceux par défaut), vous devez les redéfinir à nouveau dans la page CONFIGURATION / Connexion pour qu’ils soient pris en compte pour l’authentification du streaming, des actions rapides et du lien du gestionnaire de fichiers.

NOTE: Vous devez d’abord mettre à jour l’APK de JPI en v0.9939 pour pouvoir avoir accès à cette mise à jour du code.

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.

Update de l’APK v0.9939 en ligne !

Grosse refonte de la gestion des threads de l’application:
J’ai passé en revu tout le code pour éviter que certaines tâches ou actions utilisateur ralentissent les threads principaux du service de JPI (par exemple concrètement cela pouvait donner des ralentissements voir même des actions ratées quand JPI recevait plusieurs actions lourdes à traiter en simultanées provenant de différents clients, surtout si l’appareil est sollicité en même temps sur autre chose).
Réécriture de nombreuses actions pour optimiser la performance (concerne notamment toutes les opérations effectuées en tant que root)
Nouvelles sécurités dans le code du moteur du service pour éviter tout crash du service.
Diverses corrections et optimisations

Merci pour vos rapports de crashs.
Par contre svp évitez de les envoyer si vous n’utilisez pas la dernière version de JPI
Je n’en reçois quasi plus, ou alors provenant de vieilles versions c’est donc un bon signe

Change log versions précédentes:

NOTE : Cette version est en beta, merci de signaler les éventuels bugs rencontrés (testé sous Android v5 à v9 et Android GO).

Page permettant de télécharger toutes les versions de l’apk (avec changeLog) :

Get JPI

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.

domoggvad · Mars 17, 2021, 5:31

Hello @dJuL
Merci j’ai retrouvé mon fonctionnement normal pour les numéros non désirés avec cette mise à jour tout refonctionne correctement.

benj29 · Mars 18, 2021, 9:14

Bonjour @djul,

Mise à jour effectuée. Par contre, je me sers des states pour avoir l’état du startburningfix et vérifier qu’il a bien eu lieu.

Par contre, j’ai un problème de manière aléatoire. Mon principe est le suivant, je récupère l’état du state par script. Cela est fonctionnel, rien à dire. Je vérifie par scénario si j’ai déjà fait un nettoyage dans la semaine. Si ce n’est pas le cas, je lance le nettoyage.

La tablette reçoit bien l’ordre du lancement :

Je récupère bien 1 mais au bout de 5 min, ça retombe à 0.

Du coup, quand j’ai mon scénario de clôture, le nettoyage n’a pas fait plus de 2h et est reprogrammé le lendemain.

Dans les logs, on dirait que c’est le refresh toutes les 10min qui me réaffiche le design…

Est-ce qu’il faut que dans mon cron je rajoute un test sur l’état du burning ?

Ce que je ne comprends pas c’est que j’ai la même configuration sur 4 tablettes au total, et que de manière aléatoire, le comportement n’est pas le même. Sous-entendu, le burningfix se fait sans problème.

Pour info, côté jeedom, j’empêche l’exécution des actions screenon/screenoff si le burningfix est en place.

Pour le screenoff, scénario répété toutes les 5min :

(idem pour le screenon).

dJuL · Mars 18, 2021, 10:07

Regarde les logs de l’apk pour voir l’horodatage exact de l’arrêt (et la raison).

Oui c’est mieux de toutes façons car aucun intérêt de refresh le design pendant un screenburnfix.

m.georgein · Mars 19, 2021, 1:08

Bonjour @dJuL ,

Je reviens t’embêter avec mes problème de perte de connexion, je m’explique. Une fois un design chargé les widget ne sont pas mis à jour, ce qui est gênant ;). J’en été arrivé à penser que c’était un problème matériel chez moi (tablette ou réseau). J’ai aussi des coupures intempestive de liaison Jeedom=>Tablette (la tablette n’ayant elle, AUCUNE perte de liaison avec ou vers jeedom). Un « reset » du wifi périodique résout le problème.

Mais voilà ce matin, pour me simplifier la maintenance de la tablette j’ai installé « AnyDesk » , une sorte de VNC, et là surprise, les mise à jour des widgets des design se font sans problème, MEME après avoir fermé anydesk …

Cela donne l’impression que cet Install à « débloqué » quelque chose sur la tablette, à voir maintenant sur la durée …

Je te communique l’info, cela t’éveillera peut être quelque chose !!!

dJuL · Mars 19, 2021, 1:20

Comme ça ça ne m’évoque rien.
Mais à voir effectivement…
De mon côté je n’ai jamais eu ces pb de refresh ou de perte de connexion d’un côté ou de l’autre.
Et JPI fait déjà un wakelock du Wifi et du CPU pour justement éviter les pertes de connexion, je ne vois pas trop quoi faire d’autre…
Peut être une histoire de route ajoutée qui règlerait le pb, là comme ça je ne sais vraiment pas…

m.georgein · Mars 19, 2021, 5:37

C’était juste pour info, j’ajouterais que apparemment il faut que le « daemon » d’anydesk soit actif pour retrouver la maj des widget, si je le tu, les design redeviennent inactif.
C’est franchement étrange.
Est ce que tu connais le nom des process android qui « pilote » la comm wifi ? Histoire de voir si il ne serait pas aussi atteint d’un syndrome Harpagon d’économie d’énergie

benj29 · Mars 20, 2021, 9:18

Salut @djul,

Petit bug trouvé.
L’ancien téléphone avait besoin d’une rotation à 270° pour la caméra.
J’ai beau remettre la rotation à 0 (j’ai testé en lancant, stoppant etc) et j’enregistre ça revient à 270°…

Je clique sur sauvegarder :

En soit, cela n’est pas gênant car j’active le streaming par script en forçant la rotation.