Oui c’est bien ça, après un reboot les données sont bien prise en compte, Merci
cool 
Salut @djul,
Merci pour ton retour.
Cela va être compliqué de faire des tests d’ici plusieurs jours.
Je pense que je ne reviendrai vers toi que 2/3 semaines.
Merci et bonnes vacances 
! (et bonnes nuits à toi).
Pas de soucis, merci
Bonjour, Je n’arrive pas à me connecter au PAW web app. Je mets tous par défaut avant cela fonctionnais maintenant plus mais il me dit pas que le mot de passe est incorrect juste il rafraîchit la page et me remet au login.
Merci pour vos retour, je débute avec JPI donc soyez indulgent .
Bonne journée
J’ai le meme problème sur une install neuve, ça fonctionne quand JPI n’est pas installé mais plus quand JPI est installé…
Exactement, mais est-ce que les paramètre son les mêmes que sur jpi ?
Bonjour à tous, je cherche à faire un scénario avec JPI
Si avec le téléphone ou jpi est installé, il n’y a aucune interaction avec celui ci, durant par exemple 2 minutes alors j’effectue une action, pour ma part remettre un design jeedom.
Si quelqu’un peut me dire si c’est possible
Bonne journée
Bonjour,
je cherche à sécuriser les connexions à mes différents services http (dont Jeedom) lorsqu’on s’y connecte via internet mais aussi via le wifi (voisins indélicats potentiels). J’ai mis en place un proxy reverse nginx (https://github.com/jc21/nginx-proxy-manager) dans une DMZ, ce qui permet de piloter très facilement les redirections avec sous-domaines et certificats en automatique. Je peux faire de l’HTTPS vers service.domaine.com depuis n’importe où et les URLs du type https://jeedom.domaine.com/core/api/jeeApi.php?apikey=APIJEEDOM&type=cmd&id=IDCOMMANDE fonctionnent correctement.
Lors du paramétrage de Jeedom dans JPI, il est possible de saisir uniquement une IP et un port et si la connexion est en HTTPS ou pas.
Y-a-t-il une astuce pour saisir un nom de domaine dans le paramétrage de Jeedom dans JPI, plutôt qu’une adresse IP ?
Il faudrait paramétrer Jeedom pour qu’il accepte les connexions en https en certificat autosigné ? Quelle méthode préconiseriez-vous pour que la solution soit pérenne ?
Merci d’avance pour vos lumières !
Normalement avec un reverse proxy c’est ton reverse proxy qui securise les connexions avec un cettificat wildcard du coup si tu as plusieurs sous domaine.
Les connexions interne n ont pas besoin d etre sécurisée donc pas de certificat a gerer sur tes vm ou serveurs internes jeedoms,…
Tu ne rediriges plus tes connexions vers le bon serveur avec le nat classique mais uniquement avec le reverse proxy en fonction du sous domaine
Se pose alors la question du wifi en revanche pour proteger ton lan.
A mon sens si tu as une clé wifi assez forte ce n’est pas piratable et vraiment pas a la portee de tous… Probablement encore moins de tes voisins
Exactement : du client au reverse proxy on fait de l’https et derrière le reverse proxy on est en filaire et on peut se permettre de faire de l’http (quoique…). Un autre avantage (avec le paramétrage adéquat de redirection DNS etc.) est de n’avoir à paramétrer qu’une URL et de pouvoir s’y connecter depuis internet et depuis son réseau local sans distinction ou changement de paramétrage (très pratique sur un smartphone qui peut basculer très facilement de la 4g au wifi).
Je pense qu’il faut considérer le wifi comme une prise Ethernet accessible depuis la rue, donc je lui applique des restrictions similaires à l’internet (restrictions de ports, redirections strictes de machine connue à machine connue etc.)
C’est mon point de vue, que vous pouvez trouver paranoïaque mais nous divergeons du sujet JPI 
Est-ce que JPI peut pointer sur autre chose qu’une IP dans le cadre d’une communication HTTPS ?
Dans le cas contraire, il faut obligatoirement passer par un certificat autosigné sur Jeedom ?
Je crois savoir que certains OS/navigateurs peuvent refuser complètement de se connecter en https sur un serveur présentant un certificat autosigné.
C’est aussi un risque sur android un jour non ?
Bonjour à tous, j’aimerais géré la luminosité de mon écran mais quand je lance la commande rien ne se passe, j’ai tout de même le message « ok » qui apparaît avez vous une idée ? J’ai une android 6 conçu pour la domotique mais la marque exacte je ne sais pas si c’est vraiment important demander le moi et je l’écrirai. Je n’ai pas de caméra donc je n’ai pas un mode de gestion automatique de la luminosité.
Bonjour à tous
Je rencontre un petit souci.
Je me suis fait des commandes action Jeedom qui appelle des fonctions de JPI pour allumer et eteindre l’écran.
Quand je fait EcranOFF, l’écran de la tablette JPI s’éteint bien mais se rallume quelques secondes apres.
Je ne comprends pas bien pourquoi.
Savez vous m’aider ?
J’ai une tablette Huawei
Sinon idem quand j’éteint l’écran manuellement avec le bouton de la tablette, l’écran se rallume soit quelques secondes après soit quelques minutes. Complètement aléatoirement
EDIT :
Je met quelque log pour bien comprendre qui démarre au moment ou depuis JEEDOM je demande l’arret de l’écran JPI.
Je ne comprends pas bien cet évènement
SCREENOFF_EVENT désactivé et SCREENON_EVENT désactivé
A quoi correspond t-il par qui est il généré
- 14/08/20 23:40:53 - HTTP_EVENT déclenché - http action: _Ecran - CLIENT: 192.168.2.12 (Plugin Jeedom JPI)
- 14/08/20 23:40:53 - http_event - scénario: _Ecran
- 14/08/20 23:40:53 - http_event - évaluer: SI ( "0" == "0" ) => VRAI
- 14/08/20 23:40:53 - http_event - action: screenOff => 1 [OK]
- 14/08/20 23:40:53 - http_event - FIN du bloc CONDITION
- 14/08/20 23:40:53 - http_event - action: httpReturn => 1 [OK]
- 14/08/20 23:40:53 - HTTP_EVENT terminé
- 14/08/20 23:41:04 - SCREENOFF_EVENT désactivé
- 14/08/20 23:44:21 - GATEWAYOFFLINE_EVENT déclenché - Gateway IP: 192.168.2.1
- 14/08/20 23:44:21 - gatewayoffline_event - scenario: 0
- 14/08/20 23:44:21 - gatewayoffline_event - action: toast => 1 [OK]
- 14/08/20 23:44:21 - GATEWAYOFFLINE_EVENT terminé
- 14/08/20 23:44:22 - SCREENON_EVENT désactivé
- 14/08/20 23:44:28 - GATEWAYONLINE_EVENT déclenché - Gateway IP: 192.168.2.1
- 14/08/20 23:44:28 - gatewayonline_event - basic scenario
- 14/08/20 23:44:28 - gatewayonline_event - action: toast => 1 [OK]
- 14/08/20 23:44:28 - GATEWAYONLINE_EVENT terminé
- 14/08/20 23:45:01 - SCREENOFF_EVENT désactivé
- 14/08/20 23:45:01 - HTTP_EVENT déclenché - http action: getVolume - CLIENT: 192.168.2.12 (Plugin Jeedom JPI)
- 14/08/20 23:45:01 - http_event - scénario: __DEFAULT__
- 14/08/20 23:45:02 - http_event - action: getVolume => 2 [47]
- 14/08/20 23:45:02 - http_event - action: httpReturn => 1 [OK]
- 14/08/20 23:45:02 - HTTP_EVENT terminé
- 14/08/20 23:45:02 - HTTP_EVENT déclenché - http action: getBattLevel - CLIENT: 192.168.2.12 (Plugin Jeedom JPI)
- 14/08/20 23:45:02 - http_event - scénario: __DEFAULT__
- 14/08/20 23:45:02 - http_event - action: getBattLevel => 2 [100]
- 14/08/20 23:45:02 - http_event - action: httpReturn => 1 [OK]
- 14/08/20 23:45:02 - HTTP_EVENT terminé
- 14/08/20 23:45:03 - HTTP_EVENT déclenché - http action: getSmsCounter - CLIENT: 192.168.2.12 (Plugin Jeedom JPI)
- 14/08/20 23:45:03 - http_event - scénario: __DEFAULT__
- 14/08/20 23:45:03 - http_event - action: getSmsCounter => 2 [0]
- 14/08/20 23:45:03 - http_event - action: httpReturn => 1 [OK]
- 14/08/20 23:45:03 - HTTP_EVENT terminé
- 14/08/20 23:45:03 - HTTP_EVENT déclenché - http action: getWifiStrength - CLIENT: 192.168.2.12 (Plugin Jeedom JPI)
- 14/08/20 23:45:03 - http_event - scénario: __DEFAULT__
- 14/08/20 23:45:03 - http_event - action: getWifiStrength => 2 [75]
- 14/08/20 23:45:03 - http_event - action: httpReturn => 1 [OK]
- 14/08/20 23:45:03 - HTTP_EVENT terminé
- 14/08/20 23:45:04 - HTTP_EVENT déclenché - http action: getVersion - CLIENT: 192.168.2.12 (Plugin Jeedom JPI)
- 14/08/20 23:45:04 - http_event - scénario: __DEFAULT__
- 14/08/20 23:45:04 - http_event - action: getVersion => 2 [0.9924]
- 14/08/20 23:45:04 - http_event - action: httpReturn => 1 [OK]
- 14/08/20 23:45:04 - HTTP_EVENT terminé
- 14/08/20 23:45:04 - HTTP_EVENT déclenché - http action: getScreenTime - CLIENT: 192.168.2.12 (Plugin Jeedom JPI)
- 14/08/20 23:45:04 - http_event - scénario: __DEFAULT__
- 14/08/20 23:45:04 - http_event - action: getScreenTime => 2 [30]
- 14/08/20 23:45:04 - http_event - action: httpReturn => 1 [OK]
- 14/08/20 23:45:04 - HTTP_EVENT terminé
- 14/08/20 23:48:49 - SCREENON_EVENT désactivé
Bonjour à tous,
Tout d’abord un grand bravo pour JPI.
Je ne l’utilise que depuis une semaine, et j’ai essayé d’activer les options d’authentification HTTP.
Pour info PAW répond en https.
Tout fonctionne, sauf les commandes API depuis Jeedom. Je n’ai pas trouvé ou renseigner dans le plugin JPI de jeedom les identifiants.
Du coup je n’ai plus de remonté d’état de batterie, wifi, etc. dans l’affichage de mon smartphone
et un joli message comme quoi je ne suis pas authentifié. Normal je n’ai pas trouver ou le faire
Avant d’activer l’option d’authentification pour les API dans l’interface de JPI, je remontait bien les informations. Pas de souci, et tout fonctionne parfaitement avec un script qui envoi une commande https. Là c’est clairement indiqué dans le bloc de commande ou entrer les identifiants.
Merci pour votre aide.
Hello. C’est le post de l’apk pas du plugin…
Bonjour a tous
Concernant mes problemes d ecran qui ne s éteint pas, j ai fait d autres tests.
Cela n’a rien a voir a priori avec le reseau wifi qui se coupe sur la tablette…
Par moment je n ai aucin log de reseau et le fait de mettre en veille manuellement la tablette rallume l ecran au bout de quelques secondes.
Hello,
De retour de congés, j’espère que tu dors la nuit :).
J’ai testé et à priori cela est du au fait que les valeurs passées par la modification du sleepscreen ne sont pas codées dans la gestion Android.
Ce qui me fait dire ça, c’est que si je fais un screenoff, le paramètre affiché dans l’écran Affichage/Délai avant veille est « blanc ». Alors que si je rentre un duration valide, il est reconnu (et me met 15s, 30s etc).
Du coup, j’ai l’impression que :
- pour l’allumer, il faut faire un screenON et un sleepscreen avec duration à 120.
- pour l’éteindre, il faut faire un sleepscreen à 15. Dans ce cas, l’écran devient noir une première fois, il change la durée de 2min à 15 tout en restant allumé puis s’éteint ensuite. (donc il faut 2m + 15s).
Pas trouvé mieux. Vu que mes scénarios sont sur des tempos de 2min, je fais donc prévoir plus en allumage et laisser jeedom piloter cela.
Testé avec chargeur, c’est OK.
Par contre, chargeur déconnecté (par la prise pilotée), le premier « screenoff » (c’est à dire sleepscreen à 15secondes) « rallume » la tablette et il me faut attendre la répétition suivante pour qu’elle s’éteigne 2min plus tard. Cela va être sale mais je vais ajouter si alim coupée alors screenoff de nouveau…
Pour rappel, j’utilise une gestion par répétition de screenon/off (toutes les 2 min) plus pratique pour les tablettes (Xiaomi ou les feu Acer que j’avais). Et j’utilise un capteur de mouvement xiaomi plus celui de la tablette pour détecter un mouvement.
Salut @benj29
Penses tu que j’ai le même souci que toi au vu de mes posts précédents ?
Bonjour @dJuL ,
J’ai un Android 8.1.0 qui tourne sur un Xiaomi Redmi Go. Je n’arrive pas à installer 0.9925-minAPI19 puisque JPI me demande la permission « Ne pas déranger » (qui n’est pas disponible sur mon appareil) et m’affiche le message d’erreur « Vous devez accepter la permission d’activer le mode ne pas déranger ! L’application va se terminer ».
Est-ce qu’il y a un contournement ? si non, à partir depuis quelle version de l’APK de JPI la permission « ne pas déranger » est requise ? (que j’install la version d’avant le temps qu’une solution soit trouvée)
Merci par avance
À première vue oui. Cela fait 6h que je tourne sur mes modifications pour la lenovo et c’est OK.