cdlog2

Bonjour,

Si je comprends bien, votre alimentation de 17V 1,5A alimente le WES et votre carte à 8 Relais.

Je suis persuadé que c’est la cause à votre problème. Le WES consomme environ 1A voir plus selon l’ajout du dongle Radio 868 Mhz et LCD. Votre carte 8 Relais consomme environ 0,7A. Les différents capteurs connectés au WES consomment aussi leur part.

Il faudrait changer votre ALIM par une autre plus puissante. Celle présentée en lien ci-dessous ferait l’affaire et vous auriez de la marge pour faire des extensions comme rajouter une autre Carte à 8 Relais si besoins :

https://www.cartelectronic.fr/alimentations-piles/69-alimentation-12vdc-125a-rail-din.html

Les résistances de Pul-lUp de 4.7K se connectent entre le +Vcc et le 1W du bus 1Wire et doivent se raccorder au plus près du dernier composant 1W en bout d’une ligne 1Wire.

Pour votre carte 8 Relais vous pouvez vissez directement une 4.7K sur son bornier 1W. Vous pouvez aussi rajouter une autre résistance de 4.7K sur une autre branche éloignée si vous avez un câblage en étoile, donc cela peut résoudre le PB de vos 2 Sondes qui ne répondent plus.

Cdt

Re: Un complément d’info. Je pense que vous l’avez vue, au chapitre 3 de la config DDNS dans la DOC du GL.Inet, on vous indique
que vous pouvez tester votre DDNS afin de voir s’il est opérationnel avant même de le configurer.

Depuis votre PC qui doit être un Client du GL.Inet (Wifi ou Lan) , Il suffit d’ouvrir une Console CMD sous Windows ( taper CMD dans la barre de recherche de Windows ) et dans la fenêtre noire ouverte vous tapez : nslookup wqxxxxx.glddns.com 8.8.8.8

ou wqxxxx est votre Identifiant DDNS visible dans le texte de la Config Cloud au dessus de la config DDNS .
La réponse à cette commande devrait être :

Serveur :   dns.google
Address:  8.8.8.8

Réponse ne faisant pas autorité :
Nom :    wqxxxxx.glddns.com
Address:  176.184.xx.xx

Ou Adresse est l’IP Public Dynamique ou l’IP Privé 4G utilisé par le DDNS et dont sa présence confirme que le DDNS est fonctionnel.
Dans le cas contraire vous devriez lire : *** dns.google ne parvient pas à trouver wqxxxxx.glddns.com : Non-existent domain

Si la réponse est positive avec une Adresse IP, alors essayé de configurer à nouveau votre routeur avec le DDNS et ne tenez pas compte du message :  » Mais ce routeur est derrière NAT ou vous n’avez pas d’adresse IP publique  »

J’ai aussi ce message lors du TEST DDNS mais tout fonctionne correctement. Il ne faut pas tenir compte de ce message. ( Possible Bug logiciel de l’Admin ).

Assurez vous de mettre la Config Réseau du WES en Mode DHCP=ON. car s’il est coincé avec une adresse Static comme par exemple 192.168.1.110, votre WES ne répondra pas. Vous pouvez modifier la config réseau du WES directement depuis son fichier de config RESEAU.CFG situé dans le dossier CFG de la carte mémoire (FTP ou Clé USB). Il suffit de mettre la rubrique DHCP=1 dans le Fichier. Par contre il faut rebooter le WES pour que la config soit prise en compte.

Veillez aussi à ouvrir les Ports Utilisés ainsi que les redirections entre la BOX et le GL.Inet et entre le GL.Inet et le WES.

Essayez ma config NAT avec la redirection du Port Entrant 9100 vers le Port Sortant 9100 pour l’IP du GL.Inet dans la config du Routeur de la BOX et configurer la redirection (Onglet Port Forward  )  du Port Entrant 9100 vers le Port Sortant 80 pour l’IP du WES dans la rubrique Pare-Feu du GL.inet.

N’oubliez pas d’ouvrir les Ports 80 , 443, 9100 pour TCP/UDP dans la config : Onglet Port ouvert sur le routeur, toujours dans la rubrique Pare-Feu du GL.Inet.

Si le Pare-Feu du routeur de votre BOX est activé, il faut aussi débloquer et autoriser ces même Port Entrant et Sortant selon la config disponible.

Tester votre liaison avec : http://wqxxxxx.glddns.com:9100/

Je croise les doigts !

Cdt

Correction : Dans la config Client du GL.Inet j’ai activé la mise en Static de cette IP 192.168.8.177 du WES avec le bouton de droite mis en Vert.

Surtout ne pas faire, j’avais mal compris, cela BLOC la liaison !! Mais cela n’est pas visible de suite ?

Par ailleurs, j’ai remarqué que toute la config n’est réellement prise en compte qu’après avoir coupé le 5 volt quelques seconde et au redémarrage après avoir fait un Reset avec le bouton sur le côté du GL.Inet. ??

Bonjour,

J’ai reçu mon tout petit routeur modèle GL-MT300N-V2. Je vous donne mon retour d’expérience.

J’ai connecté la RJ45 WAN du GL.Inet sur une des RJ45 LAN de ma BOX ( FAI ).
J’ai connecté un PC via le WIFI en tant que Client WIFI du GL.Inet. j’accède sans problème au menu Admin via l’adresse 192.168.8.1. Le GL.Inet lui à fourni l’IP local 192.168.8.101

J’ai configuré la config Câble (WAN) du GL.Inet sur DHCP, MA Box lui à donné l’IP 192.168.1.39. Via l’ADMIN du GL.Inet, J’ai fait la mise à jour de son Firmware à la dernière version 3.102.

Comme j’ai un 2eme WES qui me sert de test,  j’ai configuré sa propre config Réseau en mode DHCP=ON. J’ai connecté la RJ45 du WES à la prise RJ45 LAN du GL.Inet. Le WES à reçu l’IP locale du GL.INET 192.168.8.177. Dans la config Client du GL.Inet j’ai activé la mise en Static de cette IP 192.168.8.177 du WES avec le bouton de droite mis en Vert.

Dans ma BOX j’ai forcé l’IP locale 192.168.1.39 fourni au GL.Inet en Mode Static afin d’être assuré d’avoir toujours cette IP affecté au GL.Inet depuis ma BOX. Toujours dans ma Box, j’ai configuré le NAT afin de laisser passer le Port Ext: 1900 vers le Port Int. 9100 associé à l’IP et MAC du GL-Inet. soit IP 192.168.1.39 et Mac xx:xx:xx:xx:xx:xx

Dans la config Pare-Feu du GL.Inet, dans la rubrique Port Forward, J’ai autorisé pour l’IP local 192.168.8.177 (WES) la redirection du Port 1900 vers le Port 80.

Toujours dans le Pare-Feu du GL.Inet, dans la rubrique Port entrant sur le routeur, j’ai autorisé les Port 80. 443, 22 et 9100 comme Port Entrant. Je n’ai pas configuré le DMZ qui permet toutefois un trafic dans les deux sens et sans dicris des Ports.

Dans le menu Application du GL.Inet, rubrique Accès à Distance, J’ai Activé le DDNS avec les protocole HTTP, HTTPS, SSH. J’ai testé la liaison DDNS par Test DDNS du bandeau Texte bleu.

Il trouve l’IP Dynamique Publique de ma BOX mais m’affiche comme Vous le message :  Votre DDNS est réglé en tant que 176.184.xxx.xxx. Mais ce routeur est derrière NAT ou vous n’avez pas d’adresse IP publique.

J’ai revérifié toute ma config, et comme vous je ne comprends pas pourquoi cela ne répond pas au TEST vue que tout est bien configuré.
J’ai vue juste au dessus du DDN Dynamique la config Gestion du Cloud. Je n’ai pas activé cette gestion Cloud mais dans le texte en bleu de cette rubrique on me dit que mon identifiant d’appareil est: wqxxxxx.

Juste par curiosité j’ai voulu tester le DDNS du GL.Inet et j’ai lancé depuis mon navigateur : http://wqxxxxx.glddns.com:9100/

Et Plouf je tombe sur le login du WES, je me logue et j’accède au WEB du WES : Cela Fonctionne !

Donc je déduis que le message rendu lors du TEST DDNS qui spécifie : Mais ce routeur est derrière NAT ou vous n’avez pas d’adresse IP publique.  veut seulement dire que logiciel de l’ADMIN du GL.INET n’arrive pas à remonter le NAT du Routeur GL.Inet ( port 1900 > 80 ) ainsi que le NAT de ma Box ( port 1900 > 1900 )

J’ai relue la Doc du GL.Inet est on peut lire en tout petit dans une image de configuration du DDNS que pour faire fonctionner le DDNS il faut une adresss IP Publique.

Note : You have to have an Internal Public IP address to use the Dynamic DNS. If this router is behind NAT you may need to set up port forward in you ISP router.

Cela veut dire que le DDNS du GL.Inet n’est pas un Serveur VPN comme je le supposais mais un Serveur de DynDNS dédié au matériel de GL.Inet comme l’est NO-IP.

Donc c’est bien la gestion GLOUD qui permet les liaisons VPN.

Je ne peux pas essayer ce Cloud car je n’ai pas deux GL.Inet. Mais je pense que votre Pb avec le protocole HTTP qui ne passe pas est du à la config et autorisation du Port 80, dans vos divers Configs.

A moins que le Cloud utilise le Port 443 (HTTPS) pour faire la passerelle (Tunneling) entre les deux Clients GL.Inet et dans ce cas il faut convertir le protocole HTTPS en HTTP. (Il faut voir les Codes retour des transactions)

En tout cas ce petit Routeur, est vraiment génial et permet pleins de configs. Comme vous l’avez démontré il peut aussi utiliser la 4G depuis un Tel: Mobil pour faire un petit réseau local et se connecter à internet en Nomade avec un PC dans le cas ou le WIFI ou Hot Spot Wifi n’existe pas.

Cdt

Bonjour,

Lorsque vous rajoutez une ligne Programme et que vous la validez par Transférer, cette nouvelle ligne est ajoutée en FIN du fichier PROG.DAT mais aussi en Zone Mémoire interne au WES.

Le WES gère ensuite la logique de programmation depuis sa Mémoire interne. Le Fichier Prog.dat ne sera utilisé que lorsque le WES Reboot.

Lorsque le WES Redémarre, il perd une partie de sa gestion mémoire et récupère Toute sa Config via les Fichiers du dossier CFG. C’est alors que le fichier Prog.Dat  intervient. Il permet au WES de retrouver Toutes les lignes de programmes enregistrés suite à un redémarrage. Donc si vous supprimez le fichier Prog.dat et que vous forcez au WES de redémarrer, au retour vous avez perdu vos lignes de PROG.

Donc si une ligne de programme que vous créez et enregistrée  ( disons la dernière ligne),  fait ensuite planter les Process qui gèrent l’ensemble des lignes de programmation, Vous constatez les malfonctions mais aussi probablement un problème pour afficher à nouveau la page Programme.

Dans ce vous aurez beau redémarrer le WES, vous  aurez toujours le même Problème puisque le WES récupère la même config Prog. depuis le Fichier Prog.dat et vous tournez en ROND.

Le seul moyen de sortir de cette situation :

— c’est soit de supprimer ce fichier Prog.dat mais dans ce cas vous perdez toutes vos lignes de Programme au redémarrage du WES,

  — Ou soit vous éditez ce fichier  Prog.dat avec un éditeur de texte lambda ( Bloc-Notes par ex:)  et vous supprimez depuis la fin du fichiers texte la ou les dernières lignes qui ont été Rajoutés et que vous pensez faire planter la Programmation. Chaque lignes dans ce fichier Prog.dat représente une ligne de programmation dans le WES.

Il faut enregistrer le fichier, puis redémarrer le WES. Si vous avez trouvez la ou les ligne(s) qui Bloque en la supprimant, Votre problème est réglé.

Ensuite à vous de voir pourquoi ces lignes programmées font planter la gestion Programme. Ex: envoie de Requête mal formatée ou pas de réponse du distant ou un capteur supposé être testé dans la programmation à été enlevé sans avis de la programmation.

Cdt

Bonsoir,

Votre message d’erreur en appel du WES en HTTP,  semble indiquer peut être que le WES se plante et reboot ?

Avec la Console WEB de Chrome vous pouvez voir les événement et Status des réponses Réseau.

Pour lancer la console faire F12. Une fois la console ouverte cliquez en haut dans l’onglet NETWORK. Complètement à gauche sur la rangé juste en dessous du bandeau Onglet vous trouver un petit rond, s’il est noir cliquer pour le mettre en rouge, c’est le play/pause de l’affichage des événement. En rouge l’ensemble est en PLAY.

Dans la grande fenêtre en dessous faites un clic droit puis clic sur Header Option. Vous avez une liste d’options à sélectionner. Chaque option sélectionnée va créer une colonne dédiée. Il faut au minimum : Name, Path, Url, Status, Remote Address, Type, Initiator, Eventuellement Size et Time. A fur et à mesure des sélections, des colonnes  apparaissent en relatif.

Toujours dans la suite de ces options à sélectionner vous trouvez response Header, c’est un menu qui ouvre une petite fenêtre. Sélectionner Connection et Server.  Ensuite, toujours dans la liste des sélections vous trouvez en bas Waterfall. Idem cela ouvre une autre fenêtre et vous sélectionnez Response Time.

Les Codes de Réponses aux requêtes et appels  Http sont lus dans la colonne Status.

Essayez d’agencer vos colonnes. elle pourront être redimentionnée en sélectionnant les tirets entre chaque Texte des colonnes.

Il suffit maintenant de lancer votre Connexion au WES, Normalement vous devriez voir toutes les transactions se réaliser au fil de l’eau dans la grande fenêtre au milieu. Chaque colonne va se remplir de leur spécificité.

Si les échanges se font du haut vers le bas de la grande fenêtre, descendre la barre de l’acensseur située à droite complètement vers le bas et vous faîtes l’inverse si les échanges apparaissent au fil de l’eau du bas vers le haut de la fenêtre.

Vous pouvez arrêter le défilement des lignes en cliquant sur le point rouge (Play/pause) et reprendre en cliquant lorsqu’il est noir.

Dans la colonne à droite Waterfall, vous avez des Graphs de couleur qui vous montre les temps d’accès pour chaque requêtes. En passant la sourie sur une des barre de couleur, on vous les infos et timing plus complète.

Voila peut être que vous pourrez trouvez le Code erreur renvoyé à la demande de connexion du WES.

Trouvez en pièce jointe une image de la page de Chrome avec sa console WEB ouverte.

Cdt

Re: Je ne sais pas quel navigateur vous utilisez, mais essayez d’ouvrir la console Web depuis le menu des outils de développement et rentrer dans l’onglet des transactions Réseau. Normalement vous allez pouvoir lire le compte rendu de la tentative de connexion au WES et son N° d’erreur vous donnera peut être une piste ?

Code 500 : Erreur interne du serveur
Code 502 : Mauvaise passerelle
Code 503 : Service indisponible
Code 504 : Temps d’attente expiré

Bonjour,

J’avais bien décrypté vos hiéroglyphes :

« Sinon effectivement, je viens de vérifier sur Cartoradio le pylône sur lequel il y a SFR affiche aussi une antenne Bouygues. Et comme le nom qui apparaît est : N° identification : 1782494 – Description du support : Pylône autostable / 14m / SFR , j’en déduis que l’antenne est partagée SFR/Bouygues. Cela peut être une solution avec IP dynamique si je ne réussis pas avec mes mini-routeur. Super conseil, merci »

ça, c’est une bonne nouvelle pour vous !

J’ai péché par curiosité et j’ai finalement passé commande de votre routeur modèle GL-iNet GL-MT300N-V2(Mango) .

Concernant votre problème de blocage après avoir rentré vos logins pour vous connecter au WES, cela ressemble à un problème plus ou moins identique, qu’un autre personne sur ce site m’a fait part, il y a moins d’une heure et on en n’a déduit que son logins et mots de passe étaient composés de caractères spéciaux (accent etc) qui pourraient dans votre cas ne pas être traduit de façon transparent par le Cloud vers le WES.

Si c’est le cas pour vous, reformater votre login et password dans le WES avec des caractères normaux (Lettres minuscules) et sans accents. Possible que votre Pb vienne de cela, il faut le tester !

Cdt