[JPI-APK android] Tel Android dedié domotique

[rodfred]

Salut rodfred, c'est pour moi ? Car je ne comprends pas du tout l'intérêt. Je parle de récupérer la détection de mouvement via le capteur photo d'une tablette frontale par exemple.

Par contre, ton idée m'intéresse car je posais la question plus haut de comment envoyer des MMS de manière assez générique en utilisant un instantanée sur une caméra...

Je cherche comment envoyer des capture photo de mes camera par mms, et je n'y arrive pas
le nom du fichier n'est jamais le meme,
je me demandais si il y avait moyen via une url de capture directe des cam
mais pour le moment je n'ai pas réussi à envoyer un mms ni de jeedom ni des cams
si tu as réussi à faire quelque chose je suis intérréssé par ton code pour comparer

[Theduck38]

Quelle est la bonne config pour éviter qu'à la commande 'screenOn' la tablette bascule sur un écran d'accueil verrouillé avec JPI et PAW et 'toucher pour ouvrir' ?

Il faut désactiver le verrouillage de l'écran dans les paramètres Android

Je constate que si j'envoie un screenOn ou un screenOff, le délai de veille passe systématiquement sur 30s !
Si je règle à 'Jamais', et que je mets en veille et réactive via le bouton physique de mise en route => aucun problème : mon délai de veille reste à 'Jamais'.
Si je règle à 'Jamais', que je mets en veille avec le bouton et réactive avec un screenOn => le délai est passé à 30s.
Si je règle à 'Jamais', que je mets en veille avec un screenOff et réactive avec le bouton => le délai est passé à 30s.

Je ne suis pas sûr que ce problème existait il y a 2 ou 3 versions... ou alors je ne l'ai pas constaté. Je jouais avec Fully Kiosk et JPI en parallèle et il me semble bien que j'arrivais à activer / désactiver sans que ça se ré-éteigne tout seul au bout de 30s.

[Edit et précision] : Ce problème ne se pose que pour le réglage 'Jamais'... j'ai essayé avec le maxi, soit 30 minutes et le réglage reste...

Merci.
Ce problème existe depuis toujours.
Mais il est corrigé avec la dernière maj de l'APK

Merci pour tes réponses...
J'ai pourtant eu les màj auto en redémarrant la tablette hier ; je devrais être dans la dernière version. Je regarderai ce soir... en tout cas le problème est connu, c'est une bonne chose !

[Jeandhom]

J'ai de temps en temps ces messages dans le log erreur.

Code : Tout sélectionner

  - 13/02/18 18:11:35 - Main ERREUR!: Impossible de lancer l’événement: 
Attempt to invoke method getHostAddress on null value

Merci c'est corrigé dans le dernier patch du code

Quelle rapidité
Un grand merci à toi

[dJuL]

Hello,

Y a t'il possibilité de récupérer l'état de la détection de mouvement de la caméra par exemple de manière à savoir si quelqu'un est passé devant la tablette ? L'intérêt serait de pouvoir déclencher des actions de présence ou autre plutôt que de passer par un capteur tiers (xiaomi ou autre) (de JPI vers Jeedom donc). J'ai posé la question sur le fil plugin aussi. Je vois que dans les actions URL on peut démarrer arrêter la détection mais pas récupérer son état.

J'ai bien pensé à faire un scénario qui passe un virtuel à 1 côté Jeedom qui retomberait à 0 passé une minute, mais je me dis que c'est "violent" .
Y a mieux ?

Il a déjà un événement dans JPI se déclenchant sur détection de mouvement. (Caméra / Mouvement détecté)
Il suffit de lancer un scénario Jeedom dedans.
Il y a aussi l'action getLastDetection qui retourne la date de la dernière détection.

Je cherche comment envoyer des capture photo de mes camera par mms, et je n'y arrive pas
le nom du fichier n'est jamais le meme,

Dans la prochaine version du framework SC il y a aura une fonction pour retourner le fichier le plus récent d'un répertoire, tu pourras bientôt faire ce que tu souhaites.

Merci pour tes réponses...
J'ai pourtant eu les màj auto en redémarrant la tablette hier ; je devrais être dans la dernière version. Je regarderai ce soir... en tout cas le problème est connu, c'est une bonne chose !

C'est la maj de l'APK qui corrige le pb, il faut donc forcément être devant l'appareil car c'est une maj manuelle (il faut cliquer sur 'oui' )

[benj29]

Bah, tu dois avoir l'habitude... parfait !

[rodfred]

[

Je cherche comment envoyer des capture photo de mes camera par mms, et je n'y arrive pas
le nom du fichier n'est jamais le meme,

Dans la prochaine version du framework SC il y a aura une fonction pour retourner le fichier le plus récent d'un répertoire, tu pourras bientôt faire ce que tu souhaites.

Le problème, c'est que je n'arrive pas à télécharger une image, (je ne parle pas d'aller chercher la dernière automatiquement, meme si cela sera le top)

//charge la librairie JPI
$jpi = $sc->load('jpi', 'http://192.168.0.193:8081');

//charge la librairie files
$files = $sc->load('files');

//Récupère le chemin du fichier image dans une commande de type info
$imagePath = '/var/www/html/core/php/../../plugins/camera/data/records/375/Arri%C3%A8re-9903_2018-02-15_07-39-38.jpg';

//génere le lien, avec une validité de 30 secondes
$url = $files->makeDownloadUrl($imagePath, '192.168.0.108', 30);

//Envoie le MMS
$jpi->sendMms('069999999', $url, 'Message de test');

[dJuL]

Quel est l'erreur dans le log du scénario ?

$imagePath = '/var/www/html/core/php/../../plugins/camera/data/records/375/Arri%C3%A8re-9903_2018-02-15_07-39-38.jpg';

Déjà nom de fichier me semble bizarre.
le 'è' est encodé comme pour un paramètre d'une url
Et le chemin peut être raccourci.

Essayes avec ça :
$imagePath = '/var/www/html/plugins/camera/data/records/375/Arrière-9903_2018-02-15_07-39-38.jpg';

[rodfred]

Quel est l'erreur dans le log du scénario ?

$imagePath = '/var/www/html/core/php/../../plugins/camera/data/records/375/Arri%C3%A8re-9903_2018-02-15_07-39-38.jpg';

Déjà nom de fichier me semble bizarre.
le 'è' est encodé comme pour un paramètre d'une url
Et le chemin peut être raccourci.

Essayes avec ça :
$imagePath = '/var/www/html/plugins/camera/data/records/375/Arrière-9903_2018-02-15_07-39-38.jpg';

Ok super là ça fonctionne avec
$imagePath = '/var/www/html/plugins/camera/data/records/375/Arrière-9903_2018-02-15_07-39-38.jpg';
Merci, maintenant j'attends la prochaine version pour qu'il envoi la dernière photo.

[benj29]

Bonsoir,
J'aimerai un retour car je ne sais pas si je le fais bien...

J'aimerai mettre en place une mode screen ON et screen OFF sur les tablettes domotiques.
J'avais pensé à faire des screenoff quand la présence était nulle à la maison et des screenOn quand on était là... mais après mûre réflexion, je pense plus partir vers quand nous sommes là sur "si détection, laisse la tablette allumée X min par screenon et screenoff" (ensuite je ferai pour lancer le design, gérer son rafraichissement, j'avoue que je ne sais pas encore faire cela).

Du coup, j'ai interfacé une virtuel et sa commande (retour à 0 après 1 min) depuis JPI et un HTTP (qui me sert pour d'autre chose par exemple pour désactiver l'alarme le matin automatiquement au réveil et ensuite pour faire d'autres notifications).

Mais je me suis dit, tiens autant le faire direct avec JPI sans passer par Jeedom et JPI Plugin.

Par exemple...


Le truc c'est que le 60 secondes est là pour le test, mais je pense mettre 5 ou 10 min par défaut.
Et du coup, ça veut dire si je comprends bien que derrière je perds le rafraichissement du capteur de mouvement...



Dans ce cas, je réactive la détection de mouvement dans 300 secondes et pas avant, ce qui veut dire que si mon virtuel est repassé à 0 côté détection Jeedom, je vais devoir attendre si j'ai loupé un event...

J'avais pensé segmenter façon sleep 60, resume motion detector, sleep 240, screenoff ... mais ça va pas faire des scénarios récursifs ?

Pensez-vous que c'est une bonne idée de le faire via un sleep (je n'ai pas trouvé un genre "Dans X min fais".
Ou vaut-il mieux le faire via Jeedom.

A ceux qui utilisent JPI comment gérez-vous l'affichage et le rafraichissement de la page ?

Je viens de tester par contre que le screenoff ne se fait pas via JPI si Canal Plus ou Plex est lancé (ouf, madame aurait râlé !).

[benj29]

Du coup, je complète, je ne comprends pas comment ouvrir un numéro de design donné (par exemple le 9) dans mon scénario détection de mouvement.



Je ne vois pas où est le champ ID (j'ai cherché dans les mots clés et autres).

J'ai bien tenté de le créer mais visiblement il demande quand même le paramètre ID.



EDIT : boulet, je vais me coucher, c'est id et non ID...

Bon par contre, je ne comprends plus rien, je me retrouve avec un design calé sur une résolution via chrome et là dans le navigateur JPI, visiblement j'ai un rapport 1/3 de partout, va falloir que je revois toutes mes tailles

Dernière question, et alors du coup, la fameuse question, comment gérez-vous le rafraichissement ?

Et ! Dans ce cas, visiblement, le fait de relâcher la motiondetection, la tablette s'éteint plus rapidement que ce qui est prévu (à 60 secondes - car la veille est réglée à 15 secondes)
Et si je fais ça ... pour avoir les 5 min ... la tablette ne s'allume plus pendant 1 certain temps... (environ 5 min) car justement le capteur n'est pas relâché...



Donc, je suis resté sur ça, mais aucun rafrachissement, mais au moins le design pendant 5 min...



Merci !

[dJuL]

En fait il faut donner un nom à ton dernier sleep dans JPI, et ce afin de pouvoir l'annuler si une détection se reproduit dans l'intervalle avant que le screenOff ne se déclenche.
Sinon tu va avoir l'écran qui va s’éteindre quand tu ne le désires pas.
Sinon il y a l'action setCmd, pas besoin d'utiliser l'adresse de l'API Jeedom à la main

voila le code du scénario (importable directement) :

Code : Tout sélectionner

{
	"event": "MOTIONDETECTED_EVENT",
	"key": "__DEFAULT__",
	"data": [
		{
			"//": "type=info&text=%C3%89v%C3%A9nement+se+d%C3%A9clenchant+lorsque+la+fonction+modtionDetector+d%C3%A9tecte+un+mouvement."
		},
		{
			"//": "type=comment&text=Annule+le+sleep+en+cours+si+il+existe"
		},
		{
			"sleep": "name=Sleep+OFF"
		},
		{
			"screenOn": ""
		},
		{
			"_designFS;1": "id=20"
		},
		{
			"setCmd": "id=6676"
		},
		{
			"//": "type=comment&text=Fait+une+pause+de+60+secondes%2C+puis+re-d%C3%A9marre+la+d%C3%A9tection"
		},
		{
			"sleep": "time=60"
		},
		{
			"resumeMotionDetector": ""
		},
		{
			"//": "type=comment&text=Sleep+annulable"
		},
		{
			"sleep": "name=Sleep+OFF&time=240"
		},
		{
			"__IF__": "paramL=%7BSTATUS%7D&operator=__EQUAL__&paramR=1"
		},
		{
			"screenOff": ""
		},
		{
			"__END__": ""
		}
	]
}

Pour la taille du design il y a le paramètre webTextSize que tu peux éventuellement modifier dans l'action configureLayout du scenario _designFS

[dJuL]

Merci, maintenant j'attends la prochaine version pour qu'il envoi la dernière photo.

C'est en ligne, il faut mettre à jour le Famework SC
viewtopic.php?f=27&t=17645&start=320#p586683

Puis :
$imagePath = $files->getLastFile('/var/www/html/plugins/camera/data/records', 'jpg|png|gif|bmp', true);

[Sartog]

Bonjour Djul,

Je souhaiterais ton avis / expérience quant au paramétrage de la détection du mouvement.

Je suis sur une tablette Chuwi HI12 avec caméra frontale que j'utilise pour allumer l'écran quand il y a un mouvement.
Pour cela, je suis sur Fully Kiosk en affichage et gestion de la caméra et JPI en arrière plan pour la communication Jeedom et scénarii.
Lorsque je passe devant la tablette (+- 1m), l'écran s'allume instantanément et se coupe automatiquement au bout de 30 sec d'inactivité (c'est Fully Kiosk qui s'en occupe).
Hélas, par moment la tablette plante et je me dis que la cohabitation des 2 applications peut en être à l'origine (supposition).
J'aimerais don basculer à 100% sur JPI qui propose 90% de mon besoin (sauf le mode kiosk mais pas sûr que cela soit finalement très utile).

Avec la dernière MAJ tu as résolut le problème de la mise en veille, et je t'en remercie.

Mon dernier problème (identifié) vient de la réactivité de la détection de mouvement sous JPI.
Avec les réglages par défaut ou des réglages purement aléatoire, la détection reste lente (plusieurs seconde à faire le clown devant la tablette pour qu'elle s'allume) là où Fully Kiosk est instantané.
Les tests sont fait sous conditions égales (luminosité, distance homme - tablette, etc.) avec Fully Kisok de désactivé quand je test JPI.

Est-ce une limitation du code de JPI, est-ce un mauvais paramétrage, je ne sais pas.
D'où mon appel à l'aide

[benj29]

Euh... perso j'utilise JPI pour la détection de mouvement et c'est instantané.

Tu es sûr que ça ne vient pas de ta Chuwi... dans mon choix, j'ai écarté ces tablettes chinoises fort séduisantes pour rester sur de la marque accessible type Acer ou autre (l'iconia Tab10 par exemple possède 4 hauts parleurs avec une résolution 1920x1080 et se trouve en occasion à 100€...).

[Sartog]

Euh... perso j'utilise JPI pour la détection de mouvement et c'est instantané.

Tu es sûr que ça ne vient pas de ta Chuwi... dans mon choix, j'ai écarté ces tablettes chinoises fort séduisantes pour rester sur de la marque accessible type Acer ou autre (l'iconia Tab10 par exemple possède 4 hauts parleurs avec une résolution 1920x1080 et se trouve en occasion à 100€...).

Bonjour benj29 et merci pour ta réponse.
La détection est instantané sous Fully Kiosk, donc je suis sûr que ça ne vient pas de la tablette.

[benj29]

Regarde peut être tes paramètres sur JPI effectivement, attendons le retour de Djul sur ce point. Mais dans mon cas sur mes ACER, ras !

Djul, au passage, je regarderai ce que tu m'as proposé et te tiendrai au courant dans le weekend, merci !

Par contre, ce matin, encore deux loupés en SMS... pas d'envoi.
En gros, je suis parti (madame était encore à la maison) : j'envoie un texto à moi pour dire au revoir depuis Jeedom. Pas reçu.
Puis madame part : j'envoie un texto à madame pour au revoir, un texto pour dire que l'alarme s'active à madame et un texto à moi pour dire que madame est partie et que l'alarme est activée. Le dernier reçu, pas ceux de madame.



Le log de 7h43 (envoi de au revoir à moi) : sendSMS à 0...

Code : Tout sélectionner

- 16/02/18 07:43:05 - HTTP_EVENT déclenché - http action: sendSms - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 07:43:05 - http_event - scénario: __DEFAULT__
 - 16/02/18 07:43:13 - http_event - action: sendSms => 0
 - 16/02/18 07:43:13 - http_event - action: httpReturn => 1
 - 16/02/18 07:43:13 - HTTP_EVENT terminé
 - 16/02/18 07:43:13 - HTTP_EVENT déclenché - http action: getVolume - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 07:43:13 - http_event - scénario: __DEFAULT__
 - 16/02/18 07:43:14 - http_event - action: getVolume => 2
 - 16/02/18 07:43:14 - http_event - action: httpReturn => 1
 - 16/02/18 07:43:14 - HTTP_EVENT terminé
 - 16/02/18 07:43:14 - HTTP_EVENT déclenché - http action: getBattLevel - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 07:43:14 - http_event - scénario: __DEFAULT__
 - 16/02/18 07:43:15 - http_event - action: getBattLevel => 2
 - 16/02/18 07:43:15 - http_event - action: httpReturn => 1
 - 16/02/18 07:43:15 - HTTP_EVENT terminé
 - 16/02/18 07:43:15 - HTTP_EVENT déclenché - http action: getSmsCounter - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 07:43:15 - http_event - scénario: __DEFAULT__
 - 16/02/18 07:43:15 - http_event - action: getSmsCounter => 2
 - 16/02/18 07:43:15 - http_event - action: httpReturn => 1
 - 16/02/18 07:43:15 - HTTP_EVENT terminé

Et celui de 8h03, à priori 2 textos reçus (le madame est partie et alarme activée pour moi, et seulement 1/2 pour madame).

Code : Tout sélectionner

 16/02/18 08:03:06 - HTTP_EVENT déclenché - http action: sendSms - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:06 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:08 - http_event - action: sendSms => 1
 - 16/02/18 08:03:08 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:08 - HTTP_EVENT terminé
 - 16/02/18 08:03:09 - HTTP_EVENT déclenché - http action: getVolume - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:09 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:09 - http_event - action: getVolume => 2
 - 16/02/18 08:03:09 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:09 - HTTP_EVENT terminé
 - 16/02/18 08:03:10 - HTTP_EVENT déclenché - http action: getBattLevel - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:10 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:10 - http_event - action: getBattLevel => 2
 - 16/02/18 08:03:10 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:10 - HTTP_EVENT terminé
 - 16/02/18 08:03:11 - HTTP_EVENT déclenché - http action: getSmsCounter - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:11 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:11 - http_event - action: getSmsCounter => 2
 - 16/02/18 08:03:11 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:11 - HTTP_EVENT terminé
 - 16/02/18 08:03:12 - HTTP_EVENT déclenché - http action: getWifiStrength - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:12 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:12 - http_event - action: getWifiStrength => 2
 - 16/02/18 08:03:12 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:12 - HTTP_EVENT terminé
 - 16/02/18 08:03:12 - HTTP_EVENT déclenché - http action: getVersion - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:12 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:12 - http_event - action: getVersion => 2
 - 16/02/18 08:03:12 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:12 - HTTP_EVENT terminé
 - 16/02/18 08:03:18 - HTTP_EVENT déclenché - http action: sendSms - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:18 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:26 - http_event - action: sendSms => 0
 - 16/02/18 08:03:26 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:26 - HTTP_EVENT terminé
 - 16/02/18 08:03:26 - HTTP_EVENT déclenché - http action: getVolume - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:26 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:27 - http_event - action: getVolume => 2
 - 16/02/18 08:03:27 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:27 - HTTP_EVENT terminé
 - 16/02/18 08:03:27 - HTTP_EVENT déclenché - http action: getBattLevel - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:27 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:27 - http_event - action: getBattLevel => 2
 - 16/02/18 08:03:28 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:28 - HTTP_EVENT terminé
 - 16/02/18 08:03:28 - HTTP_EVENT déclenché - http action: getSmsCounter - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:28 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:28 - http_event - action: getSmsCounter => 2
 - 16/02/18 08:03:28 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:28 - HTTP_EVENT terminé
 - 16/02/18 08:03:29 - HTTP_EVENT déclenché - http action: getWifiStrength - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:29 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:29 - http_event - action: getWifiStrength => 2
 - 16/02/18 08:03:29 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:29 - HTTP_EVENT terminé
 - 16/02/18 08:03:29 - HTTP_EVENT déclenché - http action: getVersion - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:29 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:29 - http_event - action: getVersion => 2
 - 16/02/18 08:03:29 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:29 - HTTP_EVENT terminé
 - 16/02/18 08:03:48 - HTTP_EVENT déclenché - http action: sendSms - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:48 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:50 - http_event - action: sendSms => 1
 - 16/02/18 08:03:50 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:50 - HTTP_EVENT terminé
 - 16/02/18 08:03:50 - HTTP_EVENT déclenché - http action: getVolume - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:50 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:51 - http_event - action: getVolume => 2
 - 16/02/18 08:03:51 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:51 - HTTP_EVENT terminé
 - 16/02/18 08:03:52 - HTTP_EVENT déclenché - http action: getBattLevel - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:52 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:52 - http_event - action: getBattLevel => 2
 - 16/02/18 08:03:52 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:52 - HTTP_EVENT terminé
 - 16/02/18 08:03:52 - HTTP_EVENT déclenché - http action: getSmsCounter - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:52 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:52 - http_event - action: getSmsCounter => 2
 - 16/02/18 08:03:52 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:52 - HTTP_EVENT terminé
 - 16/02/18 08:03:53 - HTTP_EVENT déclenché - http action: getWifiStrength - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:53 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:53 - http_event - action: getWifiStrength => 2
 - 16/02/18 08:03:53 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:53 - HTTP_EVENT terminé
 - 16/02/18 08:03:53 - HTTP_EVENT déclenché - http action: getVersion - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:03:53 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:03:53 - http_event - action: getVersion => 2
 - 16/02/18 08:03:53 - http_event - action: httpReturn => 1
 - 16/02/18 08:03:53 - HTTP_EVENT terminé
 - 16/02/18 08:05:00 - HTTP_EVENT déclenché - http action: getVolume - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:05:00 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:05:01 - http_event - action: getVolume => 2
 - 16/02/18 08:05:01 - http_event - action: httpReturn => 1
 - 16/02/18 08:05:01 - HTTP_EVENT terminé
 - 16/02/18 08:05:01 - HTTP_EVENT déclenché - http action: getBattLevel - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:05:01 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:05:01 - http_event - action: getBattLevel => 2
 - 16/02/18 08:05:01 - http_event - action: httpReturn => 1
 - 16/02/18 08:05:01 - HTTP_EVENT terminé
 - 16/02/18 08:05:02 - HTTP_EVENT déclenché - http action: getSmsCounter - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:05:02 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:05:02 - http_event - action: getSmsCounter => 2
 - 16/02/18 08:05:02 - http_event - action: httpReturn => 1
 - 16/02/18 08:05:02 - HTTP_EVENT terminé
 - 16/02/18 08:05:03 - HTTP_EVENT déclenché - http action: getWifiStrength - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:05:03 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:05:03 - http_event - action: getWifiStrength => 2
 - 16/02/18 08:05:03 - http_event - action: httpReturn => 1
 - 16/02/18 08:05:03 - HTTP_EVENT terminé
 - 16/02/18 08:05:03 - HTTP_EVENT déclenché - http action: getVersion - CLIENT: 192.168.2.23 (Plugin Jeedom JPI)
 - 16/02/18 08:05:03 - http_event - scénario: __DEFAULT__
 - 16/02/18 08:05:03 - http_event - action: getVersion => 2
 - 16/02/18 08:05:03 - http_event - action: httpReturn => 1

C'est bizarre, je n'avais pas ces problèmes avant ... et pourtant je suis passé sur une ROM rooté, lineage, y a pas plus propre !

[florent.pernice]

Salut DjuL,

Je ne sais pas si j'ai le même problème que sartog avec ma teclast chinoise
Mais j'ai pas mal de problème avec la camera frontale que j'utilise aussi pour allumé/éteindre l'ecran sur detection de mouvement et aussi pour faire du streaming.
Tout est censé s'activer au démarrage de JPI.
La détection de mouvement marche souvent une fois mais après plus rien. Et le streaming semble s’arrêter aussi.
J'ai eu une fois ca dans le log de l'apk:
- 15/02/18 15:12:21 - CAMERA Erreur ligne 140:
java.lang.RuntimeException: Fail to connect to camera service
Des fois j'ai aussi ce message qui me semble bizarre:
- 14/02/18 18:54:08 - Start Streaming (0fps)
- 14/02/18 18:56:27 - Start Streaming (0fps)

Est-ce qu'il serait possible d'avoir un evenement sur l'arret/demarrage du service de la camera?

J'ai une vieille Galaxy tab qui traine au garage, je vais essayer de trouver une image stable et voir si JPI peut tourner dessus.

merci,
Flo

[dJuL]

J'aimerais don basculer à 100% sur JPI qui propose 90% de mon besoin (sauf le mode kiosk mais pas sûr que cela soit finalement très utile).

JPI propose le mode kiosk, voir l'action congifureLayout, ou l'action personnalisée _designFS

Mon dernier problème (identifié) vient de la réactivité de la détection de mouvement sous JPI.
Avec les réglages par défaut ou des réglages purement aléatoire, la détection reste lente (plusieurs seconde à faire le clown devant la tablette pour qu'elle s'allume) là où Fully Kiosk est instantané.
Les tests sont fait sous conditions égales (luminosité, distance homme - tablette, etc.) avec Fully Kisok de désactivé quand je test JPI.

Est-ce une limitation du code de JPI, est-ce un mauvais paramétrage, je ne sais pas.

Aucune idée sur ce point...
Chez moi c'est très rapide, mais je n'utilise pas des masses.

Par contre, ce matin, encore deux loupés en SMS... pas d'envoi.
En gros, je suis parti (madame était encore à la maison) : j'envoie un texto à moi pour dire au revoir depuis Jeedom. Pas reçu.
Puis madame part : j'envoie un texto à madame pour au revoir, un texto pour dire que l'alarme s'active à madame et un texto à moi pour dire que madame est partie et que l'alarme est activée. Le dernier reçu, pas ceux de madame.

J'ai trouvé une correction que j'avais faites assez récemment, en ce qui concerne l'envoie de SMS multiple, c'est le dernier truc que vois qui aurait pu éventuellement changer.
Les sendSms à 0 correspondent-ils à des envois de sms à plusieurs destinataires ?

Des fois j'ai aussi ce message qui me semble bizarre:
- 14/02/18 18:54:08 - Start Streaming (0fps)
- 14/02/18 18:56:27 - Start Streaming (0fps)

Ça ce n'est pas normal du tout.
Et c'est peut être la cause de l'instabilité.
Par contre en théorie c'est complètement impossible que ce cas de figure arrive sauf si :
- Le réglage dans le fichier de config congif.json STREAMING / FRAMERATE_Streaming est à 0 et l'action startStreaming est lancée sans paramètre.
- Il y a des des pb de RAM et l'APK perd la valeur de certaines de ses variables internes.

[benj29]

Quand tu veux dire "multiples" c'est à dire ?

En passant par le plugin JPI, je fais envoi SMS à moi "tel message" puis action SMS à madame "tel message" ; oui.

Par contre, sur ce que tu me proposes de visu, ça ne marche pas. J'ai modifié déjà un peu le code, mais c'est KO, je me prends impossible d’exécuter cette action "sleep".

Pas trop le temps de fouiller, j'ai déjà moins d'erreur en ayant mis le premier sleep à 0. Tu penses qu'il faut nommer le sleep de 60 ?

Code : Tout sélectionner

 - 16/02/18 11:27:04 - motiondetected_event ERREUR: Impossible d’exécuter cette action: sleep

De plus, je reste sur ma question précédente et je suis étonné que cela ne pose de problème à personne.
Le fait de faire le sleep à 240 fait que la tablette ne se rafraichit que si elle s'éteint au démarrage suivant.
Y a pas moyen de faire un refresh toutes les minutes de la page ?

[dJuL]

Il y a un bug dans le CORE avec les sleep nommés que je suis entrain de corriger.
Avec ce code le refresh aura lieu toutes les 60s si un mouvement est détecté (et non pas toutes les 240s) car le resumeMotionDetector se fait au bout de 60s.

Pour les SMS je voulais savoir si tu fais un seul sendSms (numero1;numéro2...) ou plusieurs sendSms à la suite (ce qui revient à les lancer en simultané dans JPI).