Bonsoir,
J’ai passé en debug aussi et pas de log GSH.
Merci pour vos explications sur les soucis et les pistes.
Je vais continuer à chercher pourquoi ca ne résout pas.
merci encore
grace à tes pistes, j’ai pu voir dans le log GHSD un souci avec le port 3311.
Je l’ai ouvert et lors de la synchro j’ai le log gsh qui c’est créer ce message.
[2021-04-17 20:58:37][INFO] : Lancement : sudo nodejs /var/www/html/plugins/gsh/core/class/../../resources/gshd/gshd.js --udp_discovery_port 3311 --udp_discovery_packet 4A6565646F6D --pid /tmp/jeedom/gsh/deamon.pid --loglevel debug >> /var/www/html/core/class/../../log/gshd 2>&1 &
[2021-04-17 20:58:37][INFO] : Démon Google Smarthome local lancé
On avance
Salut
Oublié le démon les port ou autre ça ne sert a rien en temps normal et encore moins lors de la synchronisation.
Le log qui se créé oui c’est normal ya des lignes a écrire dedans ça n’apporte aucune information…
Merci de ton retour Loic.
Tu as indiqué que si le log GSH ne se créait pas c’est que la requête Google ne communique pas avec le jeedom.
Sans ouverture de ce port, le log ne se créait pas, donc si il se créée avec l’ouverture du port 3311 c’est qu’une communication se fait et que l’ouverture du port sert à quelque chose ou alors j’ai loupé un truc.
Désolé, j’essaie de comprendre la logique 
Non non et non. Le demon c’est juste la pour que google valide le plugin il ne sert a absolument rien d’autre ensuite je suis juste obligé de le laisser sinon google bannirai l’application jeedom du store.
Il ne faut donc JAMAIS regarder la partie demon.
Quand google envoi un ordre a ton jeedom ca passe par nos serveur qui prenne l’url externe de ton jeedom pour lui transmettre la demande et absolument rien d’autre. Si il n’y a pas de log c’est que nos serveurs n’arrivent pas a contacter ton jeedom et donc comme je le dis depuis le debut c’est soit :
- une mauvaise url
- un certificat pas 100% ok (il faut bien le intermedaire et le root)
- la resolution de ton nom de domaine vers l’ip qui ne marche pas sur NOS SERVEURS (le test chez toi dans ton navigateur ne suffit pas forcement). Et pour rappels nos resolutions dns c’est ovh qui s’en occupe donc si c’est ca c’est dans 100% des cas un mauvais reglage ou une mauvaise propagation de la zone dns.
Non, ce n’est pas ce qui a été dit, relisez.
Loic a dit que le démon n’était pas utile, qu’il était inutile d’ouvrir le port 3311 et que les dépendances ne servaient à rien.
Mais aucun de vous ne le croit et vous continuez à vouloir fixer ce problème de dépendances et de démons qui n’en est pas un d’après Loic (qui à priori connait le plugin…)
le log que vous montrez c’est juste le lancement du démon dont on se fiche.
et principe logique: « si pas de log c’est que la communication ne se fait pas » ne peut pas être inversé; donc avoir un log ne veut pas dire que la communication se fait.
Y a pas généralités à faire ici: j’ai posté les logs que j’ai. on est 2 avec un soucis similaire.
on essaie de comprendre le problème pour avancer ensemble.
j’ai avancé de mon coté: re-set du port 443 dans la conf réseau pour le https.
c’est ok chez moi, je vous laisse aider mydlina
Perso j’ai bien le nok dans os/db mais tout marche et tout à toujours marché
Avoir un nok me faisait tilt mais j’avoue que quand Loïc a dit « c’est ok checkez pas le nok ou les dépendances » j’ai laissé tombé.
Les infos données par Loïc m’ont perso été une nouvelle fois utiles merci à lui.
Pardon, je ne souhaite froisser personne mais j’essaie de comprendre.
Je ne prétendrai jamais connaitre le produit mieux qu’un développeur car je ne suis qu’un humble utilisateur.
J’entend ce que tu dis et donc le résultat que j’ai eu n’est pas a prendre en compte dans le soucis
@Mips: Ok je comprends aussi tes explications et je ne remets pas en cause ce que Loic a expliqué ;).
Je vais continuer à regarder du coté URL et certificat.
Etant pas très doué en linux, comment puisse je faire pour vérifier que tout est bon coté certificat?
Concernant la résolution DNS, je passe aussi par OVH donc ca sera balot que le soucis soit un soucis de résolution 
Bonjour
Justement ça met arrivé cette semaine un utilisateur avec dns chez OVH ça marchait pas avec nos serveurs chez OVH aussi. Malheureusement de notre côté je peux absolument rien faire je crois que pour corriger il est passé chez gandi
Et si je souscris à votre offre DNS ça va résoudre le souci ?
Je vais aussi voir si ça vient pas de ma config
Même si depuis le market il le dit ok, j’ai une config avec un reverse proxy sur mon Synology.
Peut être pour le dns mais je peux pas le certifier.
Test aussi en 4g avec le téléphone pour être sur de pas être sur le réseau local
Ok merci
Je vais continuer à chercher tranquillement.
Merci votre aide et du temps que tu prends.
je pense que j’ai compris.
en vérifiant depuis l’extérieur, le certificat vu est celui du nas qui fait reverse proxy et il me semble avoir vu que le certificat syno ne fonctionnait pas bien.
Le « certificat syno » c’est vague.
Sur syno on peut mettre soit un let’s encrypt soit un auto-signe.
Les auto-signe ça ne fonctionne pas.
Par ailleurs il faut que le nom de domaine corresponde à un des noms enregistrés sur le certificat.
Oui en fait c’est le certificat auto signé qui est vu car mon syno prend le dessus lorsque j’attaque l’URL.
J’avais pas ce souci dans ma précédente maison.
Je pense que j’ai trouvé la Root cause de mon souci.
Et vous avez éclairer ma lanterne donc je vous remercie du temps que vous avez pris.
Pour ma part le sujet peut être clos.
Je vais résoudre mon souci de réseau au final
1 « J'aime »
C’est bon j’ai enfin résolu mon souci en dissociant les ports depuis l’extérieur et en faisant les bonnes redirections.
j’ai pu associé à nouveau jeedom avec GH.
2 « J'aime »