Bonjour @Nostromo42
J’ai le même message
Mais je pense que cela vient du plugin-jpi et non de jpi-apk
Bonjour, @dJul
Sur JPI-APK j’obtient l’erreur suivante
j’ai cette erreur en essayant d’envoyer une capture caméra à l’aide du plugin-JPI (action sendMms)
je reçoit le mms avec uniquement la partie texte
Merci pour ton aide
Jean-luc
Hello,
Vous savez si le plugin va etre compatible avec la V4 ? sur la proposition de jeedom il me dit que je dois le désinstaller avant de faire le passage en V4. Et sans pouvoir garder la main sur la domotique par SMS il est hors de question de migrer sans.
merci
Il faut passer par script et récupérer tes URL. Un peu long à faire mais ça se fait très bien…
Je dis ça j’ai quatre devices jpi.
1 « J'aime »
le lien est mort 
1 « J'aime »
merci c’est noté
1 « J'aime »
Salut @djul,
En prévision de la V4, j’ai supprimé le plugin JPI plugin que j’utilisais depuis le début de ton application et ce plugin car non dispo en V4.
Je suis passé par le plugin script.
Pour l’envoi de SMS je rencontre un souci mais je n’arrive pas à le reproduire, c’est bizarre…
Mes scénarios d’envoi de SMS pour l’alarme ou la présence qui sont les mêmes depuis des années envoie plusieurs SMS à la même personne alors qu’avant, un seul était parfaitement envoyé.
Ici dans le scénario, j’ai bien l’envoi de 2 SMS (un à moi, un à madame).
Côté log de l’application, elle voit plusieurs commandes du coup, ça semble venir côté jeedom. Mais je ne vois pas ce que j’ai mal fait côté Jeedom par script.
Au même instant 3 fois le SMS envoyé à moi pour 1 à madame (soit 4). Comme si script l’avait envoyé 3 fois d’affilée ! Sauf que le scénario le demande qu’une fois …
Ou alors piloter ça autrement mais bonjour le changement à faire côté scénario et je n’aime pas car tout tourne depuis des années…
Par contre quand j’utilise la commande SCRIPT « seule » ça marche bien ; pas d’envoi en double, triple. Je viens de tester.
J’utilise script en HTTP.
Je passe le numéro de téléphone en 06XXXXXX.
Je n’utilise que le champ #message# et non le title.
La commande côté scénario est comme ça du coup :
Autre sujet, j’ai rooté et changé la ROM d’une de mes mipads suite à un lag pas possible (d’un coup).
Je te ferai un post quand j’y verrai plus clair.
Il me semble que tu demandais dans le passé, si Root + Android 9 pour avoir ça non ?
Par contre, je suis un peu très étonné. Tablette de 4 Go, il n’y a que PAW et JPI dessus et Mokee Android 9 une ROM avec Google en nano (pour TTS).
Seulement 1,8 à 2 Go de RAM dispo aie !
Le SSID est vide, kesako le Nice ?
L’action sms attend que le sms soit bien envoyé pour confirmé une erreur ou non.
Cela peut prendre un certain temps.
Je pense que dans ta commande script Jeedom le timeout est trop court et qu’il répète l’action x fois (4 fois par défaut) ce qui donne x sms. Essaye à nouveau en spécifiant un timeout de 5s ou plus pour la commande Sms (c’est 2s par défaut et on le voit bien dans ton log que la répétition est toute les 2s)
.
Pour la RAM c’est normal, c’est utilisé par l’os car Android ne purge la ram que quand il pense que cela est nécessaire.
Quand au SSID je ne sais pas.
Je vais modifier et voir.
Tu penses que d’une manière générale ce timeout est à mettre aux autres commandes ?
Bon, les « petits » tests de SMS semblent bons, on verra demain sur l’envoi de plusieurs SMS en parallèle.
Du coup j’ai modifié mes commandes HTTP. J’ai mis un timeout partout à 5 avec 3 essais maxi.
J’ai décoché « pas d’erreur » et « retour vide ».
Tu n’as pas donné de config recommandée type sauf erreur non ?
Par contre, je n’ai plus l’énorme souci de lag avec cette configuration, peut être que…
Bon au final 3 devices rootés sous Android 8 et 9.
Reste la lenovo non rootée sinon je perds les droits pour canal et netflix…
Merci @djul, comme d’hab.
PS : c’est normal que l’on perde le mot de passe de la configuration en cas de restore, c’est voulu ?
Il faut le réenregistrer de nouveau après un restore.
EDIT : par contre, sur mes tablettes, je me rends compte que l’OS Android indique souvent que JPI n’a pas de réponse. Sauf que tout est OK, on clique sur Wait et tout marche. Juste ce foutu popup. Il n’y a pas moyen de contourner cela ? Car cela conduit à un bloquage de jpi qui attend que l’on clique sur wait. Et là tout reprend.
Je précise que la tablette est parfaitement fluide et fonctionnelle en même temps que ça ou en dehors.
J’ai forcé une réinstallation pour voir si différence.
A noter que la tablette est rootée et jpi a les droits roots (aussi activé dans l’interface web). Mais pour autant ce fichage ne déclenche rien. Il me faut à la main, stopper JPI le relancer et tout revient.
Du coup, j’ai forcé une réinstallation et j’ai aussi changé quelque chose dans ma configuration, j’ai activé la passerelle avec screenon si perte (à 0). Sur la seconde je n’ai pas activé pour voir si différence.
Penses tu que le fait d’utiliser un port différent d’origine 8090 pour paw/jpi change quelque chose (cela fait plus de 2 ans que j’ai cette configuration sans souci).
Non. D’une manière générale les actions répondent en quelques millisecondes, mais chaque action, selon son type, peut avoir un temps de réponse différent, surtout si on utilise le paramètre wait sur certaines (là le temps de réponse va en découler directement).
Non une restauration de config, si c’est de ça que tu parles, ne modifie pas le mot de passe d’accès. Par contre, vu qu’il n’est pas stocké dans la config, en cas d’effacement de l’appareil oui il est perdu, tout comme les valeurs des variables de type SD et les dates des événements.
Tout cela est stocké dans le répertoire \data de JPI.
Sur toutes tes tablettes ? Je n’ai jamais vu ça. Peut être un truc dans le design qui provoque ça ? Car même quand je force JPI a 100% de CPU, ça rame mais ça n’affiche jamais ce popup…
En théorie non.
@djul,
merci pour tes retours.
Bon concernant le problème avec l’une de mes tablettes ; je n’arrive pas à trouver ce qu’il se passe.
Comme je te l’indique, c’est la même configuration depuis des années, j’oserai dire.
JPI se met en erreur (la fenêtre tuer l’application ou attendre) alors que derrière il est parfaitement fonctionnel et j’ai accès à l’interace web sans souci. Sauf que le design lui est figé.
La tablette elle est parfaitement fonctionnelle, menu android, navigation, ressources de cpu à < 10% et encore, ram à 1,8 GO sur 4.
J’ai remarqué dans mes logs qu’il est vrai que je fais beaucoup d’appels de poweroff pour forcer l’écran éteint ou le power on (toutes les minutes) ; du coup, s’enchaine des commandes de sleepduration, etc.
Mais même, je ne comprends pas pourquoi ça tournait depuis 2 ou 3 ans et maintenant 1 tablette parmi 3 posent des soucis.
Pour le téléphone, les premiers envois semblaient bons mais ce soir en rentrant, 3 fois le même SMS.
- 04/01/21 19:02:29 - HTTP_EVENT déclenché - http action: sendSms - CLIENT: 192.168.2.90
- 04/01/21 19:02:29 - http_event - scénario: __DEFAULT__
- 04/01/21 19:02:35 - HTTP_EVENT déclenché - http action: sendSms - CLIENT: 192.168.2.90
- 04/01/21 19:02:35 - http_event - scénario: __DEFAULT__
- 04/01/21 19:02:36 - Erreur d’envoi du SMS à +33XXXXXXXXX, nouvelle tentative dans 20 seconde(s)
- 04/01/21 19:02:40 - HTTP_EVENT déclenché - http action: sendSms - CLIENT: 192.168.2.90
- 04/01/21 19:02:40 - http_event - scénario: __DEFAULT__
- 04/01/21 19:02:58 - http_event - action: sendSms => 1 [OK]
- 04/01/21 19:02:58 - http_event - action: httpReturn => 1 [OK]
- 04/01/21 19:02:58 - HTTP_EVENT terminé
- 04/01/21 19:02:59 - http_event - action: sendSms => 1 [OK]
- 04/01/21 19:02:59 - http_event - action: httpReturn => 1 [OK]
- 04/01/21 19:02:59 - HTTP_EVENT terminé
- 04/01/21 19:03:00 - http_event - action: sendSms => 1 [OK]
- 04/01/21 19:03:00 - http_event - action: httpReturn => 1 [OK]
- 04/01/21 19:03:00 - HTTP_EVENT terminé
Ce matin tout avait bien tourné. J’augmente le timeout à 30 secondes pour être à l’aise selon toi ?
Oui il faut l’augmenter car on voit bien l’envoi répété 5s plus tard dans le log, c’est donc que l’action sendSms a pris plus de 5s pour répondre et confirmer le statut du sms (ce qui est tout de même relativement long mais bon, peut être un petit « trou de réseau »).
Avec 30s, oui, tu devrais être tranquille.
Quand à ta tablette qui pose soucis je n’ai aucune idée. Peut être le webview qui plante. Tu devrais essayer sans afficher de design pour voir si le message continu.
Salut @djul,
Plus de soucis de SMS, le timeout à 30s a reglé le souci, merci.
Pour la tablette, j’ai déjà réduit les appels de scénario et d’API qui tournait toutes les minutes et cela semble moins la stresser. Mais le résultat est le même à plus long terme.
La page web de JPI reste accessible depuis un client distant. Le design reste figé (je le vois à l’horloge et les secondes qui ne comptent pas).
J’attends quelques secondes, au mieux ça se remet à compter et tout retourne correctement au bout de quelques secondes (max 30 secondes).
Au pire, la page se fige alors que toute la tablette reste parfaitement fonctionnelle.
Je viens de désactiver l’appel de design par scénario ou au démarrage pour voir si changement.
Les logs indiquent un core obsolète et arrêté :
J’insiste sur le fait, que j’ai une seconde tablette identique qui tourne avec la même configuration et je n’ai aucun souci avec elle (même avec des appels à la minute ou moins pour les screenon/off etc).
Y a t’il un moyen de contourner webview par exemple ?
C’est effectivement webview qui plante. Une idée de comment contourner cela ? J’ai installé chrome aussi. Mais que je mette l’un ou l’autre pareil ça plante.
Ça le faisait sur la rom officielle xiaomi très nettoyée de Google et maintenant j’ai une custom root pareil…
Il ne te reste qu’à épurer ton design élément par élément pour trouver ce qui fait tout planter, je ne vois que ça…
Un truc en JS (javascript) doit faire une boucle infinie, ou provoquer un gros lag qui doit être la cause de ton problème, très probablement un widget ou un bout de code JS.
Salut Djul,
Je viens de flasher cyanogen 13 sur ma Nexus 10, Android marshmallow 6.0.1, et après avoir installé PAW et JPI, ça plante au démarrage de JPI…
PAW est bien en marche et j’ai le message check if paw IS running erreur
Comment ça se fait ?
Paw a craché au bout de quelques secondes (vu que d’après ton log tu as lancé PAW avant JPI).
Essaye de lancer JPI en premier et de le laisser démarrer Paw (même si je ne pense pas que ça change grand chose…)
Dans ce cas je ne comprends pas pourquoi les 2 autres tablettes n’ont pas ce problème…