[JPI-APK android] Tel Android dedié domotique

dJuL · Mars 3, 2021, 6:34

Ouvert sur le routeur ?
Je ne vois pas trop le rapport, ni le pb, du moment que Paw n’est pas également sur le 8090…
Par défaut Paw est sur le 8080.
J’utilise également JeedomConnect et je n’ai pas de soucis (après je n’ai pas essayé JeedomConnect + JPI lancés en même temps sur le même appareil mais il n’y a pas de raisons que ça ne marche pas)

benj29 · Mars 3, 2021, 7:17

Non j’utilise depuis des années le 8090 pour jpi. Que ce soit sur jeedom ou sur les appareils Android en question. Et dernièrement j’ai testé jeedom connect… Avec ce fameux port 8090. Et depuis que je l’ai retiré… Magie.

dJuL · Mars 3, 2021, 7:48

J’imagine que le plugin Jeedom JeedomConnect devait sans doute saturer le perif JPI de requêtes websocket auxquelles JPI devait répondre… (Par contre ce n’est vraiment pas normal mais bon).
De toutes façons ce n’est jamais une bonne idée d’utiliser le même port d’une manière générale.
Enfin si tu as résolu ton pb c’est le principal

benj29 · Mars 3, 2021, 8:06

Bein c’est surtout que je ne savais pas que jeedom connect utilisait le 8090. J’ai découvert ça en lisant un post sur une bêta…

dJuL · Mars 3, 2021, 8:08

Ca peut se changer dans la configuration du plugin (ce que j’ai fait) :

dJuL · Mars 3, 2021, 9:55

Nouvelle version qui m’aura donné pas mal de fils à retordre pour fonctionner correctement sur les différents types d’appareils et versions d’android…

Update du code v0.9935 en ligne !

Au menu, ajout d’actions : empreintes digitales, boîte de dialogue, screenshot (root). Support du déverrouillage automatique de l’appareil via code pin (root), ajout d’un mode kiosque intégrale (root), amélioration du mode plein écran (déjà existant), possibilité de lancer une app en plein écran (root), améliorations visuelles de l’apk et de l’interface web, améliorations diverses et corrections de bugs.

–

Change log

****************** MOTS CLEFS: ******************

— Ajout Mots clefs état :

{SCREENBURNFIX} => État du nettoyeur d’écran (action screenBurnFix)
0 => stoppé / 1 => en cours

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

— Ajout d’actions :

Système / startFingerprint => Démarre la détection d’empreintes digitales avec un timeout définie. L’action retourne le résultat de l’authentification
.
Système / cancelFingerprint => Interrompt la détection d’empreintes digitales en cours
Fonctions / showDialog => Ouvre une boîte de dialogue sur l’appareil (peut importe si JPI est au premier plan ou non). Prend comme paramètre optionnels l’icône, le titre, le message, les boutons et le timeout d’affichage du dialogue. Retourne le résultat du dialogue (si le paramètre wait est à 1)
Fonctions / closeDialog => Ferme la boîte de dialogue en cours
Fonctions / screenShot => Effectue une capture d’écran de l’appareil et retourne le chemin du fichier (cette action nécessite le root)

— Modifications d’ actions:

Application (APK) / configureLayout => Ajout du paramètre androidKioskMode qui permet un mode kiosque intégral (nécessite le root)
Dans ce mode le paramètre androidFullScreen n’est pas nécessaire, tout l’appareil est en plein écran (même les applis lancés via launchApp), et les boutons home et tâches récentes ne sont pas actifs (même si l’appareil possède des boutons physiques). La barre de statut du haut et les boutons du bas sont complètement désactivés (même en cas de swap). L’appareil est donc totalement sécurisé et dédié à JPI.
Application (APK) / showApp => Fonctionne désormais sous Android 10 & 11
Système / launchApp => Ajout du paramètre androidFullScreen qui permet de lancer une appli en mode plein écran (nécessite le root). Ce paramètre est inutile si vous êtes déjà en mode kiosk intégral. il est similaire au paramètre androidFullScreen de l’action configureLayout mais pour une appli tiers.
Informations / getState => Ajout de la valeur ‹ SCREENBURNFIX › pour le paramètre keyword

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

page CONFIGURATION / Réglages avancés :
– Section Application => Ajout du code pin de l’appareil pour le déverrouillage automatique de l’écran. Il est nécessaire d’utiliser un code PIN en cas de l’utilisation des empreintes digitales via l’action startFingerprint. En effet il est impossible sous Android de conserver les données des empreintes digitales si le verrouillage de l’écran n’est pas activé.
page ÉVÉNEMENTS / SCÉNARIOS :
– Les checkboxs permettant d’activer ou de désactiver une action ou un bloc condition pouvaient être toutes décalées sur certains appareils / navigateurs selon la valeur de zoom de la page => corrigé

****************** INTERFACE WEB - FENÊTRES: ******************

Fenêtre d’aide des mots clefs:
– Ajout du nouveau mot clef {SCREENBURNFIX}
Fenêtre générateur d’expressions CRON:
– Amélioration du design
Fenêtre OUTILS / Exécuter Action:
– Amélioration des textes par défaut dans les champs (placeholder)

****************** INTERFACE WEB - GÉNÉRAL: ******************

Maj des fichiers JS
Maj des fichiers CSS

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

Refonte du timing de certaines actions afin d’optimiser les performances
Optimisation de certaines variables du core
Support des nouvelles actions
Maj de la config d’usine
Diverses corrections et optimisations
Maj. des fichiers de langues

Patch du code v0.9936 en ligne !

Certains textes (liés à des checkbox) dans l’interface web était complètement décalés => corrigé
=>
Diverses petites modifications esthétiques dans l’interface web
Diverses petites corrections et optimisations

Patch du code v0.9937 en ligne !

Ajout du mot clef d’état {IS_CAM_DETECTING} => État de la détection de mouvement (motionDetector)
0 => stoppée / 1 => en cours
Action Informations / getState => Ajout de la valeur ‹ IS_CAM_DETECTING › pour le paramètre keyword
Diverses petites corrections et optimisations

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.9937 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.9935 en ligne !

Ajout du support du nouveau mode kiosk
Ajout du support des nouvelles actions et des modifications d’actions (fingerPrint, dialog, configureLayout, launchApp)
Ajout du support du déverrouillage automatique de l’écran via code pin lors de l’allumage de l’écran par JPI (allumages automatiques ou via actions JPI lancées par l’utilisateur)
Si l’appareil est protégé par un simple balayage, JPI le désactive (tant que le service JPI est lancé)
Corrections de la fonction de nettoyage d’écran (screenBurnFix) qui pouvait parfois bloquer certaines actions
Refonte du menu général avec introduction d’icônes
Modernisation du style des boutons de log
Si l’application est en mode plein écran, les boites de dialogues ou le menu faisait réapparaitre la barre de statut et les boutons android => corrigé
Lors de l’affichage du clavier en mode plein écran, la barre de statut android et les boutons android pouvait rester visibles par dessus JPI sur certains appareils lors du masquage du clavier => corrigé
Le mode plein ecran et le mode kiosk sont automatiquement reseté à chaque fois que JPI quitte ou démarre (idem avec les actions reboot et shutdown)
Refonte des routines de fermeture de l’application et du service
Ajout d’un black screen permettant à JPI de quitter tranquillement.
Correction de certaines fuites mémoires possibles sur certains appareil après avoir quitté JPI (Bluetooth et reconnaissance vocale notament)
Correction d’un bug lors de l’initialisation de JPI ou de la vérification des majs, certaines boîtes de dialogue pouvaient laisser l’appli figée sur le log lors d’un clique en dehors de la zone du dialogue => corrigé
Nombreuses corrections et optimisations
Corrections de certains crashs

Patch de l’APK v0.9937 en ligne !

Ajout du support du nouveau mot clef {IS_CAM_DETECTING}
Diverses petites 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

Change log versions précédentes:

Screenshots :

– Nouveau réglage avancé (Application) pour déverrouiller l’écran automatiquement:

– Correction affichage des checkbox (parfois décalés) dans les scénarios de l’interface web :
=>

– Nouveau paramètre androidKioskMode de l’action configureLayout :

– Nouvelles actions startFingerprint / screenshot / showDialog :

– Nouvelles icônes du menu et nouveau style des boutons log :

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.

benj29 · Mars 4, 2021, 5:14

Bonjour @djul,

Mise à jour faite sans souci.

J’ai rapidement testé RAS que ce soit sous Android 10 rooté (Xiaomi) ou non (Lenovo).
Merci pour l’ajout de l’état du screenburnfix car pour ma part, je les lance quand nous ne sommes pas là en journée sur l’alarme et si je reviens alors qu’ils ne sont pas finis, je veux pouvoir les reprogrammer au lendemain. Très pratique.

Une question, y a t’il possibilité dans les options de demander l’affichage des boutons en page principale de JPI. Pas la page du design mais bien la page de base celle où on voit gateway, jeedom et les appareils à surveiller. Je les aies au démarrage mais une fois que j’ai configuré le layout avec button=0 (car sinon ils sont présents sur la page du design affiché), je les perds sur la page de base.

Je t’ai fait un don car depuis le temps que j’ai basé ma domotique au niveau des interfaces sur JPI, je ne sais pas si ma vision de la domotique aurait été la même sans ton outil.

dJuL · Mars 4, 2021, 2:28

Merci pour le retour.
Je ne comprend pas trop, si tu veux afficher les boutons sur la page principale il suffit d’utiliser configureLayout à nouveau. Et Pour le faire en une fois il suffit d’utiliser une action personnalisée tout comme par exemple _designFS qui est inclue en exemple qui fait déjà ça en envoyant ‹ 0 › comme id :

Après même si les 3 boutons du bas sont maqués, leurs fonctions sont accessibles via le menu principal sur l’écran d’accueil en cliquant sur l’icone JPI en haut en gauche :

Ps: Merci pour le don

dJuL · Mars 4, 2021, 5:44

La v0.9935 du code génère des nouveaux petits bugs d’affichage.
C’est corrigé avec ce patch du code :

benj29 · Mars 4, 2021, 7:50

Effectivement l’astuce de cliquer sur la maison suffit.
Modifier le layout n’est pas pratique. Ce que je veux c’est pouvoir faire une mise à jour sans devoir appuyer sur check update côté jeedom et sans à avoir à la mano à modifier le layout. Donc l’astuce convient !

dJuL · Mars 5, 2021, 5:55

Nouveaux patch en ligne de l’apk et du code :

Les rapports de crashs se font de plus en plus rares malgré l’évolution de JPI, c’est bon signe

m.georgein · Mars 7, 2021, 6:30

Bonsoir @dJuL,

J’ai un petit problème, j’utilise JPI pour écouter une radio sur une enceinte bluetooth, tout fonctionne nickel sauf que … si une autre routine fait un appel à JPI (style portier qui veut changer le design), cela semble couper le « play » .
Je cherche donc le moyen ou d’inhiber ce fonctionnement, ou de connaitre le statut courant du « play » pour le relancer si nécessaire.
par asquis de conscience, le code de lancement :

vince84 · Mars 8, 2021, 9:12

Bonjour,
j’ai un petit soucis depuis plusieurs jours que je n’arrive pas à résoudre : l’écran ne se met plus en veille.
Quand je fait un essai direct sur JPI par le bouton tester, celui ci me dit que c’est OK, mais sur la tablette, cela change rien → toujours allumé.
La fonction screenOff ne fonctionne toujours pas chez moi.

merci

dJuL · Mars 8, 2021, 6:38

Ce n’est pas normal, il faudrait voir le scénario.
Au pire le play peut être coupé lors d’un tts mais il est rétabli à la fin.
Ou alors tu as un VRstatus = 1 qui le coupe définitivement.

Pour ça il y a le mot clef d’état {IS_PLAYING} utilisable directement dans les champs, ou sinon récupérable également via l’action getState.

Mais il faudrait que tu testes le scénario qui coupe le play pour trouver quelle action coupe la lecture car ce n’est pas normal du tout.

Je n’ai rien touché au mécanisme du screenOff depuis longtemps.
Après, si tu n’est pas root, tu as un réglage pour allonger la durée avant extinction :

Essayes de l’augmenter progressivement. Au pire, normalement à 5s ça devrait suffire, cela dépend des appareils… (la majorité passe avec le réglage par défaut de 0)

benj29 · Mars 8, 2021, 8:30

Comme le dit @djul, j’ai eu ce souci de screenoff qui ne marchait plus. Mais en vrai c’était le sleepScreen.
Une mise à jour de ROM avait fait que les sleeptime pour le screenoff/on ne collait plus.
Le fameux l’écran se met en veille au bout de …
Pour cela, il faut que la valeur envoyée soit bien dans la liste Android des propositions.

dJuL · Mars 8, 2021, 9:31

Je pense intégrer dans le prochain patch l’utilisation possible d’expressions complètes dans les conditions JPI des scénarios.
Je l’utilise personnellement car les tests simples ne me suffisaient plus (et pourtant j’étais sur que pour JPI cela serait largement suffisant !).
Je l’ai rajouté sous forme d’opérateur de condition.

Exemple :

Un peu similaire dans l’utilisation au moteur d’expression Jeedom, la syntaxe est en java et supporte toutes les fonctions classiques java ainsi que tous les mots clefs JPI.
L’avantage est par exemple de ne plus devoir rajouter des blocs conditions dans des blocs conditions pour faire du &&…

m.georgein · Mars 9, 2021, 9:28

Bonjour,

Je reviens vers toi pour ce problème de coupure du ‹ play ›, je viens de pister plusieurs de ces coupures dans tes logs :

- 09/03/21 10:20:16 - motiondetected_event - lance: SINON
 - 09/03/21 10:20:16 - motiondetected_event - action: sendMail => -1 [ACTION DÉSACTIVÉE]
 - 09/03/21 10:20:16 - motiondetected_event - FIN du bloc CONDITION
 - 09/03/21 10:20:16 - motiondetected_event - action: screenOn => 1 [OK]
 - 09/03/21 10:20:26 - motiondetected_event - action: sleep => 1 [OK]
 - 09/03/21 10:20:26 - motiondetected_event - action: resumeMotionDetector => 1 [OK]
 - 09/03/21 10:20:26 - MOTIONDETECTED_EVENT terminé
 - 09/03/21 10:21:26 - CUSTOM3OFFLINE_EVENT désactivé
 - 09/03/21 10:21:43 - CUSTOM3ONLINE_EVENT désactivé

La coupure à eu lieu à 10:23 …

Le journal de l’application :

 - 09/03/21 10:20:26 - START MotionDetector (Front camera)
 - 09/03/21 10:24:23 - START MotionDetector (Front camera)
 - 09/03/21 10:25:04 - START MotionDetector (Front camera)
 - 09/03/21 10:25:20 - START MotionDetector (Front camera)
 - 09/03/21 10:26:09 - START MotionDetector (Front camera)

Peux tu me dire à quoi correspond CUSTOM3OFFLINE_EVENT et CUSTOM3ONLINE_EVENT ???

EDIT :
Est ce qu’il existe un mécanisme dans JPI pour déclencher un événement sur un changement de valeur d’une variable (IS_PLAYING) ???

dJuL · Mars 9, 2021, 10:57

Le log s’arrête à 10:21:43

Appareil personnalisé n°3 hors ligne et en ligne

Le plus simple je pense c’est de lancer le play manuellement et de lancer le scénario qui coupe le play manuellement pour essayer de comprendre ce qu’il se passe.
Avec le bouton tester dans les scénarios de l’interface web.

Ce sont les événements, mais je ne pense pas créer un événement pour la lecture ou l’arrêt de la leture alors que normalement le play ou pause sont des actions forcément volontaire et lancées par l’utilisateur lui même.

m.georgein · Mars 9, 2021, 11:11

Parmis tout mes tests j’ai coupé la comm avec Jeedom pour éviter une interférence, dans ce cas je lance manuellement le play et … au bout d’un temps variable cela coupe le ‹ play › sans aucune trace dans les logs comme tu l’as vu plus haut.
Cela m’énerve car je ne comprends rien
Le plus étonnant est que l’icone du play en haut de l’écran de l’interface web disparait bien quand cela coupe (donc bien vu par JPI) et que rien n’apparaisse dans les logs.

dJuL · Mars 9, 2021, 11:21

Je pense que le play s’arrête à cause d’un pb de stream ou de connexion ou de buffer, et que ce n’est pas directement lié aux autres scénarios ou requêtes.

edit: il faudrait que tu testes avec un ou des fichiers mp3 locaux dans l’appareil. Là je pense que tu n’auras aucun stop involontaire.