[JPI-APK android] Tel Android dedié domotique

[guenneguez_t]

Bonjour,

Je découvre ce plugin fort intéressant. Ci dessous 2 idées d'un nouvel utilisateur
Idée suplémentaire : Que le plugin gère sa propre clef API
Exemple de création :
https://github.com/Jeedom-Plugins-Extra ... ll.php#L34
Champ adresse IP très court donc impossible de renseigner un nom DNS.

A+
Thomas

[guenneguez_t]

Bonjour,

Encore une petite coquille dans le code
PHP Strict Standards: Non-static method JPI::cron() should not be called statically in /var/www/html/core/class/plugin.class.php on line 222

A+
Thomas

[dJuL]

Ici c'est le fil de JPI, l'appli android.
Je n'ai rien à voir avec le plugin Jeedom qui a son fil et son créateur: Jerome84

[guenneguez_t]

Ah d'accord désolé.

Envoyé de mon BLN-L21 en utilisant Tapatalk

[benj29]

Merci Djul, bon ski !
Je regarde et profite bien !

Envoyé de mon Moto G (5S) Plus en utilisant Tapatalk

[guenneguez_t]

Bonjour,

Reste quand même le champ IP très court donc impossible de renseigner un nom DNS.

Merci pour le développement
Thomas

[Jeandhom]

Je pars au ski tout à l'heure et mon sac n'est pas encore prêt...

Bonnes vacances et bon ski

[nanard54]

Quelqu'un sait-il s'il est possible de récupérer via un lien la date et l'heure du téléphone ? Je suis en train de me faire un afficheur LED et ce serait plus simple de pouvoir récupérer ces données via un simple URL

[guenneguez_t]

Bonjour,

Je découvre cet outil fort intéressante.

Par contre pour l'envoie de MMS, la puissance de la chose me semble résider dans la capacité de pouvoir envoyer des photos distante asses simplement.

Il faudrait donc une fonction qui permette de faire en un seul appel l'équivalent de : download + sendMms + delete
Celà permettrait d'intégrer dans un second temps cet appel au plugin JPI.

Actuellement, les plugins suivants permettent l'envoi de fichier via message sont :
mail
pushbullet
slack
synologychat
telegram
Les plugins suivants permettent d'utiliser ce mode de notification :
camera
motion
openalpr
openbr

J'espère que ce besoin te semblera sencé.

A+
Thomas

[Theduck38]

Bonjour,

Ma tablette est en service depuis une semaine maintenant... j'ai régulièrement des logs comme quoi le PAW est offline.
A priori par d'impact sur le fonctionnement.

En revanche, j'ai depuis peu des redémarrages du service :

Code : Tout sélectionner

 23/02/18 14:32:30 - PAW is offline
 - 23/02/18 15:14:31 - Activity start
 - 23/02/18 15:59:58 - PAW is offline
 - 23/02/18 16:53:42 - PAW is offline
 - 23/02/18 18:40:06 - PAW is offline
 - 23/02/18 18:59:34 - PAW is offline
 - 23/02/18 19:55:50 - PAW is offline
 - 23/02/18 20:14:33 - Service start
 - 23/02/18 20:20:05 - Activity start
 - 23/02/18 20:20:53 - Error while rebuilding config file
 - 23/02/18 20:20:55 - Service stop
 - 23/02/18 20:20:55 - Service start
 - 23/02/18 20:20:55 - 0 cron task(s) loaded
 - 23/02/18 20:30:53 - Service start
 - 23/02/18 20:35:04 - Activity start
 - 23/02/18 20:35:52 - Error while rebuilding config file
 - 23/02/18 20:35:54 - Service stop
 - 23/02/18 20:35:54 - Service start
 - 23/02/18 20:35:55 - 0 cron task(s) loaded
 - 23/02/18 20:58:51 - Activity start

De plus, j'ai configuré le scénario 'Service OK' de la façon suivante :

Code : Tout sélectionner

{
	"event": "SERVICEOK_EVENT",
	"key": "__DEFAULT__",
	"data": [
		{
			"_designFS;0": "id=3"
		}
	]
}

Bien que je voie les évènements dans le log, je n'ai pas le design qui apparaît à chaque redémarrage du service, il se remet à chaque fois sur l'écran d'accueil de JPI :

Code : Tout sélectionner

- 23/02/18 20:32:30 - http_event - action: httpReturn => 1
 - 23/02/18 20:32:30 - HTTP_EVENT terminé
 - 23/02/18 20:35:03 - Le service de l’APK est arrêté et ne communique plus depuis au moins 180 secondes
 - 23/02/18 20:35:03 - Redémarrage automatique de l’APK
 - 23/02/18 20:35:04 - HTTP_EVENT déclenché - http action: getVolume - CLIENT: 192.168.1.13 (Plugin Jeedom JPI)
 - 23/02/18 20:35:04 - http_event - scénario: __DEFAULT__
 - 23/02/18 20:35:04 - http_event - action: getVolume => 2
 - 23/02/18 20:35:05 - http_event - action: httpReturn => 1
 - 23/02/18 20:35:05 - HTTP_EVENT terminé
 - 23/02/18 20:35:07 - HTTP_EVENT déclenché - http action: getBattLevel - CLIENT: 192.168.1.13 (Plugin Jeedom JPI)
 - 23/02/18 20:35:07 - http_event - scénario: __DEFAULT__
 - 23/02/18 20:35:07 - http_event - action: getBattLevel => 2
 - 23/02/18 20:35:07 - http_event - action: httpReturn => 1
 - 23/02/18 20:35:07 - HTTP_EVENT terminé
 - 23/02/18 20:35:09 - HTTP_EVENT déclenché - http action: getSmsCounter - CLIENT: 192.168.1.13 (Plugin Jeedom JPI)
 - 23/02/18 20:35:09 - http_event - scénario: __DEFAULT__
 - 23/02/18 20:35:09 - http_event - action: getSmsCounter => 2
 - 23/02/18 20:35:10 - http_event - action: httpReturn => 1
 - 23/02/18 20:35:10 - HTTP_EVENT terminé
 - 23/02/18 20:35:11 - HTTP_EVENT déclenché - http action: getWifiStrength - CLIENT: 192.168.1.13 (Plugin Jeedom JPI)
 - 23/02/18 20:35:11 - http_event - scénario: __DEFAULT__
 - 23/02/18 20:35:12 - http_event - action: getWifiStrength => 2
 - 23/02/18 20:35:12 - http_event - action: httpReturn => 1
 - 23/02/18 20:35:12 - HTTP_EVENT terminé
 - 23/02/18 20:35:13 - SERVICEOK_EVENT déclenché
 - 23/02/18 20:35:13 - serviceok_event - basic scenario
 - 23/02/18 20:35:13 - serviceok_event - action perso: _designFS => 2
 - 23/02/18 20:35:13 - SERVICEOK_EVENT terminé
 - 23/02/18 20:35:14 - serviceok_event (_designFS) - évaluer: SI ( "3" != "_NULL_" ) => VRAI
 - 23/02/18 20:35:14 - serviceok_event (_designFS) - évaluer: SI ( 3 > 0 ) => VRAI
 - 23/02/18 20:35:14 - serviceok_event (_designFS) - action: configureLayout => 1
 - 23/02/18 20:35:14 - HTTP_EVENT déclenché - http action: getVersion - CLIENT: 192.168.1.13 (Plugin Jeedom JPI)
 - 23/02/18 20:35:14 - http_event - scénario: __DEFAULT__
 - 23/02/18 20:35:14 - serviceok_event (_designFS) - action: goToDesign => 1
 - 23/02/18 20:35:15 - http_event - action: getVersion => 2
 - 23/02/18 20:35:15 - serviceok_event (_designFS) - action: httpReturn => 1
 - 23/02/18 20:35:15 - http_event - action: httpReturn => 1
 - 23/02/18 20:35:15 - HTTP_EVENT terminé
 - 23/02/18 20:35:15 - serviceok_event (_designFS) - FIN du bloc CONDITION
 - 23/02/18 20:35:17 - serviceok_event (_designFS) - FIN du bloc CONDITION
 - 23/02/18 20:35:18 - SERVICEOK_EVENT déclenché
 - 23/02/18 20:35:18 - serviceok_event - basic scenario
 - 23/02/18 20:35:18 - serviceok_event - action perso: _designFS => 2
 - 23/02/18 20:35:18 - SERVICEOK_EVENT terminé
 - 23/02/18 20:35:19 - serviceok_event (_designFS) - évaluer: SI ( "3" != "_NULL_" ) => VRAI
 - 23/02/18 20:35:20 - serviceok_event (_designFS) - évaluer: SI ( 3 > 0 ) => VRAI
 - 23/02/18 20:35:20 - serviceok_event (_designFS) - action: configureLayout => 1
 - 23/02/18 20:35:20 - serviceok_event (_designFS) - action: goToDesign => 1
 - 23/02/18 20:35:21 - serviceok_event (_designFS) - action: httpReturn => 1
 - 23/02/18 20:35:21 - serviceok_event (_designFS) - FIN du bloc CONDITION
 - 23/02/18 20:35:22 - serviceok_event (_designFS) - FIN du bloc CONDITION
 - 23/02/18 20:35:59 - STARTOK_EVENT déclenché
 - 23/02/18 20:35:59 - startok_event - basic scenario
 - 23/02/18 20:35:59 - startok_event - action: toast => 1
 - 23/02/18 20:35:59 - STARTOK_EVENT terminé
 - 23/02/18 20:40:03 - HTTP_EVENT déclenché - http action: getVolume - CLIENT: 192.168.1.13 (Plugin Jeedom JPI)

[Le log d'erreurs est vide]

Il y a un truc que j'ai mal fait ?

[Theduck38]

Encore pareil ce matin : reboot apk en boucle :

Code : Tout sélectionner

 - 25/02/18 09:20:04 - Activity start
 - 25/02/18 09:20:19 - SERVICE Erreur ligne 2385:
java.net.SocketTimeoutException
 - 25/02/18 09:20:53 - Error while rebuilding config file
 - 25/02/18 09:20:55 - Service stop
 - 25/02/18 09:20:55 - Service start
(...)
 - 25/02/18 12:02:04 - Error while rebuilding config file
 - 25/02/18 12:02:06 - Service start
 - 25/02/18 12:02:28 - Service stop
 - 25/02/18 12:02:54 - Activity start
 - 25/02/18 12:03:47 - Error while rebuilding config file
 - 25/02/18 12:03:49 - Service start
 - 25/02/18 12:04:22 - Service stop
 - 25/02/18 12:05:08 - Error while rebuilding config file
 - 25/02/18 12:05:10 - Service start

(j'en ai mis qu'un petit bout...)

Cette fois il y a des erreurs dans le log :

Code : Tout sélectionner

 - 25/02/18 11:46:44 - Main ERREUR!: Problem with internal command (net): main
Null Pointer in Method Invocation
 - 25/02/18 12:02:55 - Main ERREUR!: Problem with internal command (net): main
Null Pointer in Method Invocation

Le problème c'est que JPI repasse en premier plan à chaque fois. Même si ce n'est pas sain que le service redémarre en boucle, c'est acceptable dans la mesure où pour le moment c'est Fully Kiosk qui me sert d'explorateur.

Pour info, la tablette ne redémarre jamais : elle n'est pas rootée (donc pas possible via le soft) et le bouton physique est 'caché' dans le cadre, ce qui impose de la détacher du mur pour la redémarrer.
Pas trouvé de solution "logicielle" pour le moment pour rebooter.

Donc plusieurs questions pour @dJuL (après le ski....) :
- Quelle manip puis-je faire pour aider à comprendre pourquoi ma config est instable ?
- Est-il possible d'ajouter une option pour que JPI reste toujours en arrière plan ?
- Pourrais-tu rendre le navigateur intégré 'Zoomable' (c'est le seul truc qui me manque pour utiliser JPI intégralement à la place de Fully Kiosk)... ?

[Edit] Et je viens de me rendre compte que je n'ai plus les boutons de mise à jour/quitter sur l'APK... ça sent pas bon !

[dJuL]

Il faudrait donc une fonction qui permette de faire en un seul appel l'équivalent de : download + sendMms + delete
Celà permettrait d'intégrer dans un second temps cet appel au plugin JPI.

Côté JPI c'est possible de se faire une action perso (un scénario donc) qui fait toutes les actions qu'on souhaite en un seul appel.
On peut affecter tous les paramètres qu'on veut à cette action.

Côté Jeedom il faut voir avec Jérôme, le dev du plugin.
Ou avec le framework SC où il est assez simple en bloc code de faire les manips.

Encore pareil ce matin : reboot apk en boucle :

Code : Tout sélectionner

 - 25/02/18 09:20:04 - Activity start
 - 25/02/18 09:20:19 - SERVICE Erreur ligne 2385:
java.net.SocketTimeoutException
 - 25/02/18 09:20:53 - Error while rebuilding config file
 - 25/02/18 09:20:55 - Service stop
 - 25/02/18 09:20:55 - Service start
(...)
 - 25/02/18 12:02:04 - Error while rebuilding config file
 - 25/02/18 12:02:06 - Service start
 - 25/02/18 12:02:28 - Service stop
 - 25/02/18 12:02:54 - Activity start
 - 25/02/18 12:03:47 - Error while rebuilding config file
 - 25/02/18 12:03:49 - Service start
 - 25/02/18 12:04:22 - Service stop
 - 25/02/18 12:05:08 - Error while rebuilding config file
 - 25/02/18 12:05:10 - Service start

(j'en ai mis qu'un petit bout...)

Cette fois il y a des erreurs dans le log :

Code : Tout sélectionner

 - 25/02/18 11:46:44 - Main ERREUR!: Problem with internal command (net): main
Null Pointer in Method Invocation
 - 25/02/18 12:02:55 - Main ERREUR!: Problem with internal command (net): main
Null Pointer in Method Invocation

Le problème c'est que JPI repasse en premier plan à chaque fois. Même si ce n'est pas sain que le service redémarre en boucle, c'est acceptable dans la mesure où pour le moment c'est Fully Kiosk qui me sert d'explorateur.

Pour info, la tablette ne redémarre jamais : elle n'est pas rootée (donc pas possible via le soft) et le bouton physique est 'caché' dans le cadre, ce qui impose de la détacher du mur pour la redémarrer.
Pas trouvé de solution "logicielle" pour le moment pour rebooter.

Donc plusieurs questions pour @dJuL (après le ski....) :
- Quelle manip puis-je faire pour aider à comprendre pourquoi ma config est instable ?
- Est-il possible d'ajouter une option pour que JPI reste toujours en arrière plan ?
- Pourrais-tu rendre le navigateur intégré 'Zoomable' (c'est le seul truc qui me manque pour utiliser JPI intégralement à la place de Fully Kiosk)... ?

[Edit] Et je viens de me rendre compte que je n'ai plus les boutons de mise à jour/quitter sur l'APK... ça sent pas bon !

Tu as un pb de config déjà.
Dans l'interface web il faudrait que tu importes ta config en cours et que tu sauves pour régler ce problème.
CONFIGURATON / Bakcup import
Importer config.json (le premier) et sauvegarder.

Pour le zoom c'est possible avec l'action configureLayout.
Pareil pour les boutons qui ont disparus, cela vient surement de configureLayout

Si tu utilises l'action perso _designFs, il faut aller éditer le scénario et modifier l'action configureLayout pour activer le zoom:
ÉVÉNEMENTS / Api Http / Actions persos puis la clef _designFS

[benj29]

Salut Djul, alors ces vacances bien ?

Bon, pour donner des news de mon souci, j'ai changé totalement ma manière de faire.
J'ai introduit des sleep de 3 secondes (après avoir testé plusieurs tempo) entre l'envoi des textos et plus aucun souci.
Je suis resté via le plugin JPI pour l'envoi et non le SC.
Donc de ce côté, tout roule. Merci pour ton aide via SC, mais au final, je reste sur cette manière de faire maintenant.

[Theduck38]

Tu as un pb de config déjà.
Dans l'interface web il faudrait que tu importes ta config en cours et que tu sauves pour régler ce problème.
CONFIGURATON / Bakcup import
Importer config.json (le premier) et sauvegarder.

Pour le zoom c'est possible avec l'action configureLayout.
Pareil pour les boutons qui ont disparus, cela vient surement de configureLayout

Si tu utilises l'action perso _designFs, il faut aller éditer le scénario et modifier l'action configureLayout pour activer le zoom:
ÉVÉNEMENTS / Api Http / Actions persos puis la clef _designFS

Bonjour, @dJuL

J'avais essayé de réinjecter la config, sans que ça ne change rien à l'instabilité.
J'ai essayé de réinitialiser la config => idem
J'ai finalement opté pour une réinstallation de l'apk... nickel depuis (j'ai toujours régulièrement des events 'Paw Offline', mais bon, ça n'empêche pas le fonctionnement). Elle a aussi retrouvé les réglages que j'avais refaits entre temps.

OK pour les boutons, c'est peut-être moi en appelant le designFS, mais j'avais pourtant laissé les paramètres par défaut...

Quelle est la condition pour avoir un event 'PAW Offline' dans le log ? 180s de non réponse de PAW ? Ou ça a à voir avec les paramètres avancés 'Vérification du réseau' ? J'aimerais bien comprendre les 'Paw Offline' pour les éradiquer. J'aime bien avoir des logs propres

[Theduck38]

Bon, je sais, je suis lourd, mais maintenant j'ai ça :

Capture.JPG (44.05 Kio) Consulté 2564 fois

Le log d'erreurs est vide.
Le log de l'application ne montre que des 'PAW Offline' de temps en temps (mais pas à 14h03)
L'event log montre ça :

Code : Tout sélectionner

- 26/02/18 14:00:19 - HTTP_EVENT déclenché - http action: getVersion - CLIENT: 192.168.1.13 (Plugin Jeedom JPI)
 - 26/02/18 14:00:19 - http_event - scénario: __DEFAULT__
 - 26/02/18 14:00:20 - HTTP_EVENT terminé
 - 26/02/18 14:01:55 - HTTP_EVENT déclenché - http action: screenOn - CLIENT: 192.168.1.13 (Plugin Jeedom JPI)
 - 26/02/18 14:01:55 - http_event - scénario: __DEFAULT__
 - 26/02/18 14:01:56 - HTTP_EVENT terminé
 - 26/02/18 14:04:13 - GATEWAYOFFLINE_EVENT déclenché - Gateway IP: 192.168.1.1
 - 26/02/18 14:04:13 - gatewayoffline_event - scenario: 0
 - 26/02/18 14:04:13 - GATEWAYOFFLINE_EVENT terminé
 - 26/02/18 14:04:21 - GATEWAYONLINE_EVENT déclenché - Gateway IP: 192.168.1.1
 - 26/02/18 14:04:21 - gatewayonline_event - basic scenario
 - 26/02/18 14:04:21 - GATEWAYONLINE_EVENT terminé
 - 26/02/18 14:05:07 - HTTP_EVENT déclenché - http action: getVolume - CLIENT: 192.168.1.13 (Plugin Jeedom JPI)
 - 26/02/18 14:05:07 - http_event - scénario: __DEFAULT__
 - 26/02/18 14:05:07 - HTTP_EVENT terminé
 - 26/02/18 14:05:11 - HTTP_EVENT déclenché - http action: getBattLevel - CLIENT: 192.168.1.13 (Plugin Jeedom JPI)
 - 26/02/18 14:05:11 - http_event - scénario: __DEFAULT__

Jeedom prend bien les informations de JPI puisque le niveau de batterie se met à jour et l'écran s'allume et s'éteint suivant la détection du capteur de mouvement comme configuré dans mon scénario Jeedom.

Mes logs sont en niveau 2.

Y'a une config qui permet de 'forcer' le test de Jeedom après la perte de la passerelle ?

[dJuL]

Salut Djul, alors ces vacances bien ?

Bon, pour donner des news de mon souci, j'ai changé totalement ma manière de faire.
J'ai introduit des sleep de 3 secondes (après avoir testé plusieurs tempo) entre l'envoi des textos et plus aucun souci.
Je suis resté via le plugin JPI pour l'envoi et non le SC.
Donc de ce côté, tout roule. Merci pour ton aide via SC, mais au final, je reste sur cette manière de faire maintenant.

Oui ça se passe bien merci, juste il fait -15 aujourd'hui

Ok je vais rajouter un settings tout de même pour relancer le sms automatiquement en cas d’échec pour ceux qui aurait le même genre de soucis que toi (je pense tout de même que ça vient du dual sim car j'arrive pas à reproduire avec mes appareils)

Bon, je sais, je suis lourd, mais maintenant j'ai ça :

Capture.JPG

Le log d'erreurs est vide.
Le log de l'application ne montre que des 'PAW Offline' de temps en temps (mais pas à 14h03)
L'event log montre ça :

Code : Tout sélectionner

- 26/02/18 14:00:19 - HTTP_EVENT déclenché - http action: getVersion - CLIENT: 192.168.1.13 (Plugin Jeedom JPI)
 - 26/02/18 14:00:19 - http_event - scénario: __DEFAULT__
 - 26/02/18 14:00:20 - HTTP_EVENT terminé
 - 26/02/18 14:01:55 - HTTP_EVENT déclenché - http action: screenOn - CLIENT: 192.168.1.13 (Plugin Jeedom JPI)
 - 26/02/18 14:01:55 - http_event - scénario: __DEFAULT__
 - 26/02/18 14:01:56 - HTTP_EVENT terminé
 - 26/02/18 14:04:13 - GATEWAYOFFLINE_EVENT déclenché - Gateway IP: 192.168.1.1
 - 26/02/18 14:04:13 - gatewayoffline_event - scenario: 0
 - 26/02/18 14:04:13 - GATEWAYOFFLINE_EVENT terminé
 - 26/02/18 14:04:21 - GATEWAYONLINE_EVENT déclenché - Gateway IP: 192.168.1.1
 - 26/02/18 14:04:21 - gatewayonline_event - basic scenario
 - 26/02/18 14:04:21 - GATEWAYONLINE_EVENT terminé
 - 26/02/18 14:05:07 - HTTP_EVENT déclenché - http action: getVolume - CLIENT: 192.168.1.13 (Plugin Jeedom JPI)
 - 26/02/18 14:05:07 - http_event - scénario: __DEFAULT__
 - 26/02/18 14:05:07 - HTTP_EVENT terminé
 - 26/02/18 14:05:11 - HTTP_EVENT déclenché - http action: getBattLevel - CLIENT: 192.168.1.13 (Plugin Jeedom JPI)
 - 26/02/18 14:05:11 - http_event - scénario: __DEFAULT__

Jeedom prend bien les informations de JPI puisque le niveau de batterie se met à jour et l'écran s'allume et s'éteint suivant la détection du capteur de mouvement comme configuré dans mon scénario Jeedom.

Mes logs sont en niveau 2.

Y'a une config qui permet de 'forcer' le test de Jeedom après la perte de la passerelle ?

Le test de jeedom se relance automatiquement quand la passerelle redevient en ligne.
Ton problème vient plutôt de Paw.
Car si il est offline les statuts ne se rafraichissent plus.

Il n'est pas normal d'avoir paw offline, cela veut dire qu'il n’est pas stable sur ton appareil.
Je n'ai pas de solution à ça malheureusement...

[benj29]

C'est quoi comme tablette theduc ?

Envoyé de mon Moto G (5S) Plus en utilisant Tapatalk

[Sartog]

@dJuL, est-il normal que resumeMotionDetector fasse éteindre l'écran de la tablette ?

Il m'a fallut contrer ce phénomène en activant le paramètre "toujours allumé quand JPI est affiché" pour empêcher la tablette de s'éteindre dès que l'action, dans mon scénario, resumeMotionDetector était exécuté.

[benj29]

Marrant je n'ai pas ce phénomène il me semble. Tu es sur ?

Envoyé de mon Moto G (5S) Plus en utilisant Tapatalk

[Sartog]

Certains même.

Si l'option "toujours allumé quand JPI est affiché" est désactivée, l'écran s'éteint dès qu'il exécute resumeMotionDetector.
Si l'option "toujours allumé quand JPI est affiché" est activée, l'écran reste allumé lors de l’exécution de resumeMotionDetector.

Si chez toi ça fonctionne, soit ça vient d'Androïd soit du driver de la tablette