C’est quoi le résultat attendu ?
C’est quoi du coup ta config actuelle ?
Pour ma part, je suis en ws sur du https et tout ce qui arrive sur du http est de toute façon illico basculé sur du https
La configuration du plugin est celle-ci:
Je précise plusieurs points:
- j’ai un dns local qui résout les noms du domaine « home.lan »
- j’essaie de faire fonctionner cette solution avec mon tel sur le wifi local mais quand je suis connecté en 4G, j’ai la solution magique du VPN IPsec qui me ramène à la situation précédente
- j’ai laissé la valeur proposée par défaut par le plugin sur l’adresse ws interne même si elle utilise une IPv4 et que je préférerais de loin, un nom de domaine.
- j’ai également essayé de remplacer l’adresse ws externe par du https et aussi par wss (on ne sait jamais!)
Avec cette configuration, la connexion de l’app au serveur se termine avec une erreur TIMEOUT.
Et je constate dans les logs et sur un enregistrement tcpdump côté serveur qu’il y a des échanges « sendTojcApi » en http vers l’url interne définie dans la configuration du plugin
@ngrataloup : es-tu sûr que ta solution n’utilise pas de connexion http côté serveur?
C’est exact que j’ai fait un raccourci dans mes messages : port 80 = http, port 443 = https. Je n’ai rien contre ce numéro 80 mais plutôt contre le protocole qui utilise par défaut ce port.
Comme je n’ai pas trouvé la solution à mon problème (= faire fonctionner Jeedom-Connect en utilisant le protocole https), je peux me livrer à une dissertation philosophique.
C’est vrai que le système le plus secure est celui qui n’ouvre aucun port à l’extérieur mais est-ce que ce genre de système sert à quelque chose?
Après, pourquoi vouloir utiliser le protocole https alors qu’on est sur son réseau local. C’est vrai que les hackeurs internes potentiels sont notre famille, nos amis…
D’abord, il ne vous aura pas échappé que les navigateurs web envoient toutes sortes de message d’avertissement quand on entre une url http. OK, vous allez me répondre qu’ils sont faits pour consulter des pages web sur internet et que c’est normal qu’ils vérifient l’authenticité du serveur et qu’ils chiffrent les communications. ça n’empêche que l’apparition des ces messages provoquent un sentiment d’insécurité (du moment qu’on maîtrise ce qu’on fait, pas de pb, vous allez me répondre).
Ensuite, dans une vie antérieure, j’ai eu une expérience en SSI (sécurité des systèmes d’information). Au début, j’étais comme vous à mettre en cause les mesures de sécurisation dans les zones dites de confiance. Un de mes collègues me disait alors: « La défense en profondeur, tu connais? ». Je vous laisse le soin de rechercher le sens du concept si besoin.
Je suis peut-être un peu paranoïaque mais je pose la question: que coûte aujourd’hui, le passage d’une communication http en https? Pour moi, c’est peanut donc pourquoi rester en http et supporter les désagréments cités plus haut?
Moi aussi j’aime les débats philosophiques
Et du coup il vous faut un deuxième certif sur jeedom pour encrypter le trafic local pour faire ceci:
Sur des réseaux pro c’est pas « amené à disparaître », ca ne se fait plus depuis plus de 20 ans…
Mais dans votre cas vous avez toujours tout votre trafic interne en clair derrière le reverse proxy
Que coute ajd l’utilisation d’un certif un minimum correct au lieu d’un auto-signe qui n’apporte que des ennuis?
On se comprend alors, la plupart des intervenantssur votre post sont actifs à des degrés divers en IT
Ps: chez moi, jeedom connect (et donc jeedom car votre problème n’est pas sur JC mais sur jeedom) est accessible en https, même en interne
Mais on ne sait pas de quoi on parle, nous 
1 « J'aime »
Merci @Mips pour ta réponse.
Même si je ne suis pas d’accord à 100%, elle m’ouvre en effet une autre solution: configurer le serveur Jeedom directement en https, ce qui permettra de me passer du reverse proxy qui me crée peut-être des difficultés supplémentaires.
J’ai dû déjà l’écrire: j’utilise Jeedom en docker et je suis donc tributaire de l’image que j’utilise pour exposer des ports et intégrer les certificats. J’aurais peut-être pu le faire en interactif dans Jeedom mais je veux pérenniser la configuration.
ce n’est pas ca que je voulais dire
je pense que c’est beaucoup plus raisonnable, en utilisation « maison » d’avoir un reverse qui termine le flux ssl et de passer en http ensuite et donc de ne pas toucher à l’installation de jeedom.
Ce que je dis depuis le début, c’est que SI votre jeedom est accessible en https (de préférence via reverse proxy), alors jeedom connect le sera également;
Alors il doit y avoir qqchose que je n’ai pas compris.
L’accès à Jeedom en https via reverse proxy ne pose aucun pb.
Et l’app JC ne se connecte pas au serveur. J’utilise de préférence la méthode par QR-code mais la manuelle a le même résultat: Network Error.
Et la configuration côté telephone dans le plugin est elle correcte?
En tout cas, si j’entre l’url jeedom en https dans un navigateur, j’ai bien l’interface jeedom.
Y a-t-il une subtilité que je ne connais pas:
- redémarrer l’app avant chaque nouvelle connexion?
- redémarrer le démon JC côté serveur?
Désolé, je reviens sur ce sujet après 8 mois de sommeil … mais je ne comprends pas les réponses qui m’ont été faites selon lesquelles le protocole de connexion est défini par Jeedom et non par JC.
Tout d’abord, je précise que j’utilise beaucoup la fonction « Interface Web » de l’appli sur mon tel Android.
Ensuite, je confirme que lorsque j’accède à Jeedom en httpS via un navigateur internet sur mon tel, les pages web s’affichent correctement.
Ensuite, j’ai paramétré la connexion de l’appli JC avec le QR code fourni par le plugin.
Quand je consulte les paramètres de connexion de l’appli, je constate que le protocole utilisé est http
C’est confirmé par le dump du traffic sur le port 80 de mon serveur Jeedom:
22:36:53.038228 IP (tos 0x0, ttl 64, id 52857, offset 0, flags [DF], proto TCP (6), length 877)
192.168.1.144.60254 > raspi5.home.lan.http: Flags [P.], cksum 0x04f6 (correct), seq 4145:4970, ack 149761, win 1433, options [nop,nop,TS val 3587802252 ecr 1129986394], length 825: HTTP, length: 825
GET /core/css/icon/loisir/fonts/loisir.woff2 HTTP/1.1
Host: jeedom.home.lan
Connection: keep-alive
User-Agent: Mozilla/5.0 (Linux; Android 16; Pixel 8a Build/BP3A.250905.014; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/144.0.7559.109 Mobile Safari/537.36
Origin: http://jeedom.home.lan
Accept: */*
X-Requested-With: com.jeedomconnect.app
Referer: http://jeedom.home.lan/core/css/icon/icons.css
Accept-Encoding: gzip, deflate
Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: registerDevice=mtyNJsh9YSjvQ2Ri6AwlsGseatv0Hj7bYPLQ0QCzAXSWSGo9cHpQRmGuRBUqtXwL-H8nAXJxumRb1yvfDeHWHtC6Flk19yMjhFUTeF5ip81MOsaBUx03hYJ7VmFypLEvO; PHPSESSID=vo71nfqocohh01hu7b905iot5mou8i449igndgoofkq1sjctkjmmdp95v81ujdv1
If-None-Match: "151c-63714f8af27ad"
If-Modified-Since: Sun, 08 Jun 2025 20:04:31 GMT
22:36:53.038285 IP (tos 0x0, ttl 63, id 41725, offset 0, flags [DF], proto TCP (6), length 52)
raspi5.home.lan.http > 192.168.1.144.60254: Flags [.], cksum 0xa194 (correct), seq 149761, ack 4970, win 525, options [nop,nop,TS val 1129986457 ecr 3587802252], length 0
22:36:53.038807 IP (tos 0x0, ttl 63, id 41726, offset 0, flags [DF], proto TCP (6), length 1500)
raspi5.home.lan.http > 192.168.1.144.60254: Flags [.], cksum 0x15c5 (correct), seq 149761:151209, ack 4970, win 525, options [nop,nop,TS val 1129986458 ecr 3587802252], length 1448: HTTP, length: 1448
HTTP/1.1 200 OK
Date: Wed, 04 Feb 2026 21:36:53 GMT
Server: Apache
Last-Modified: Mon, 05 Jan 2026 22:07:53 GMT
ETag: "151c-647ab4a6b4bae"
Accept-Ranges: bytes
Content-Length: 5404
X-Content-Type-Options: nosniff
X-Frame-Options: sameorigin
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: accelerometer=(),battery=(),fullscreen=(self),geolocation=(),camera=(),ambient-light-sensor=(self),autoplay=(self)
Content-Security-Policy: default-src 'self' file: data: blob: filesystem:;script-src-attr 'self' 'unsafe-inline' 'unsafe-eval' *.google.com *.google.fr *.googleapis.com *.openstreetmap.org;script-src 'self' 'unsafe-inline' 'unsafe-eval' *.google.com *.google.fr *.openstreetmap.org;script-src-elem 'self' 'unsafe-inline' 'unsafe-eval' *.google.com *.google.fr *.openstreetmap.org;img-src 'self' * data:;style-src 'self' 'unsafe-inline';style-src-attr 'self' 'unsafe-inline';worker-src blob:;frame-src 'self' *.jeedom.com *.google.com *.google.fr *.googleapis.com *.openstreetmap.org data:;
Keep-Alive: timeout=5, max=95
Connection: Keep-Alive
Content-Type: font/woff2
J’en conclus peut-être à tort que c’est l’appli JC qui est mal configurée.
Ma question est donc « comment la configurer correctement pour que le traffic ip entre l’appli et le serveur soit en httpS? »
salut
si c est vraiment uniquement pour ca, alors il ny a AUCUN interet a utiliser l application, passe directement par ton browser sur ton mobile et c est réglé…
tu parles pour une connexion via reseau interne ou via externe (4/5G) ?
si c est en interne : pas de conf. pour du httpS il faut un certificat valide, je doute que tu en aies un dans ces conditions (et quel interet d ailleurs!?)
pour l externe : meme punission il faut aussi un certif valide, et dans ce cas la connexion s effectuera
envoie moi, en message privé, la partie haut du bloc « configuration » de ta page setting du plugin
Bonjour
Ce qu’il faut bien comprendre c’est que quand tu es dans ta maison ton téléphone est connecté en Wifi sur ton réseau interne et donc tu es en http, dans les préférences de JC tu constates que la connexion est en http. Lorsque tu quittes ton habitation ton téléphone bascule en 5G hors de portée de ton Wifi et dans les préférences de JC tu constates que tu es en https. Bien entendu si tu as bien réalisé le paramétrage adéquat. Tu peux faire l’essai en désactivant le Wifi de ton téléphone.