Forum Replies Created
- Replies
-
- 26 octobre 2018 à 16 h 00 min
- in reply to: Pulses : Configuration Pulses et Graph ique corrompue
Bonsoir,
Désolé de vous avoir froissé Mairot, ce n’était pas mon intention, mais en toute logique hormis un oublie d’un F5 au passage dans la V2, ce pb de script jsapi était un peu illogique en V2.
Heureux que vos problèmes soient résolus,
Cordialement
Christian
00- 26 octobre 2018 à 15 h 10 min
- in reply to: Pulses : Configuration Pulses et Graph ique corrompue
Ok Mairot pour votre retour. Je ne mets pas votre parole en doute mais vos erreurs retournées ne sont pas logique en étant dans la V2 !
Lorsque l’on se connecte au serveur WES, le 1er fichier chargé et index.cgi ce qui vous affiche en 1er la V1 du WES. Puis ensuite vous basculez sur la version V2 du WES par les menus (si c’est bien toujours comme cela pour la version V0.83F car je ne l’ai pas encore chargé et testé).
Hors le Script Jsapi corechart est chargé dans le index.cgi au chargement de la V1 mais reste néanmoins en mémoire cache du navigateur lorsque vous basculez en V2 WES.
Peut être que ce que vous avez lu dans la console était le reliquat du chargement de la V1.
Vider par F5 votre navigateur dès que vous passez en V2. cela devrait faire disparaître l’ensemble ainsi que ce Jsapi. Par contre si vous avez ensuite dans la console les mêmes erreurs de Jsapi en étant en V2 après un F5 alors la je ne puis l’expliquer.
Par contre si vous constatez toujours des blocages dans la configuration des pulses, relancer les outils de développement de Chrome (F12) en V2 après un F5 et cette fois cliquer dans le champs réseau. On va vous demander de recharger la page en cliquant sur le bouton. regardez bien vous allez voir tous les fichiers du WES qui sont chargés les un après les autres. Si le blocage intervient ce pourrait être le dernier fichier chargé qui pose problème.
Cdt
00- 26 octobre 2018 à 13 h 46 min
- in reply to: Pulses : Configuration Pulses et Graph ique corrompue
Oui en effet il n’y a pas de connexion au lancement, j’ai fait le test. Par contre des requêtes sont bien préparées certainement pour être ensuite lancées à la demande par appels à quelques méthode du Script ?
Par contre et en effet il n’y a pas de lien avec le problème soulevé par Mairot au début de ce FIL
En plus je me suis Fourvoyé car j’avais compris que les erreurs de Mairot étaient produites en étant dans la V2 du WES.
Hors en regardant mieux les erreurs qu’il nous fournies, Erreurs lues dans la Console des Outils de développement de son navigateur CHROME on voit bien que le Script en erreur est :
———————-
jsapi:23 A parser-blocking, cross site (i.e. different eTLD+1) script, https://www.google.com/uds/?file=visualization&v=1&packages=corechart, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.
———————–
API corechart du JDK jsapi de Google !!!
Et que si je comprend bien, Google n’est plus utilisé lorsque l’on est en V2 du WES pour afficher les Graphiques, on en déduit donc que Mairot était dans la V1 du WES pour nous sortir ces erreurs !!!
En plus la version V2 utilise des fichiers HTML et la V1 des fichiers CGI. Il est impossible de mélanger les deux ?
J’en conclus tardivement que Mairot à des problème de connectivité en accès internet, certainement des connexions assez lente. Ou bien Son Google Chrome est chargé de plugins complémentaires qui lui mange toutes les ressource du navigateur ou lui provoque des ralentissement ? Je n’irais pas à dire qu’il y a peut être un Malware !
Donc en résumé rien à voir avec le WES !!! Si ce n’est peut être un problème dans la carte mémoire SD comme vous le pensiez.
Désolé pour ce surplus de travail !
Cordialement
Christian
00- 26 octobre 2018 à 10 h 04 min
- in reply to: Pulses : Configuration Pulses et Graph ique corrompue
Ouvrez le fichier Graph.js avec un éditeur. faites des recherches de http …, vous verrez au moins 4 voir 5 requêtes vers le site W3.
Je n’ai pas analysé ce qu’il fait exactement, mais je peux penser qu’il essais de se caler au site W3 ( Site officiel qui à généré ce Script) au lancement ou lors de renvoie d’un Log en cas d’erreurs rencontrées, pour leur infos de suivi ou ???
Pour en être sur, modifier pour test ces requêtes https://../…. dans ce fichier graph.js par un appel local vers un de vos serveur (192.168.x.x) vous verrez bien ainsi si ce script essais de ce connecter ou pas. Ce ne sont que des supputations pour ma part , je n’ai pas essayé !.
Par contre Les erreurs lu dans la console des outils de développement du navigateur Chrome fourni par la personne qui à lancé ce fil de discussion, précise qu’il y a un fichier Script JS qui bloque le chargement de la page sur une connexion Tierce. Sa page reste bloqué.
Comme cela ce produit sur une gestion de Graphique, j’ai tout de suite fait le rapprochement avec ce fichier graph.js !
Cdt
Christian
00- 26 octobre 2018 à 8 h 50 min
- in reply to: Pulses : Configuration Pulses et Graph ique corrompue
Bonjour Nicolas,
Concernant Graph.js, ce script est toujours chargé dans INDEX_V2.html de la v0.83F et comme je l’ai précisé ce script est basé sur W3C scalable vector graphics (SVG). Il y a des appels à W3…. et non à google ( appel au site Tier W3 ! ) . Si ce Graph.js n’est pas utilisé pour la V2, il pourrait être retiré de index_v2.html et laissé seulement dans les fichiers CGI de la V1 ou il y a lieu d’être utilisé.
Concernant async vous pourriez le placer pour lancer les scripts secondaires. Par contre ne pas le placer pour charger le script de JQUERY qui doit être le 1er Script à charger immédiatement. Mais ce n’est pas Jquery qui bloque je pense. Des tests pourraient vous permettre de trouver les Scripts secondaires. Async vous permet quand même d’améliorer le chargement des pages et élimine pas mal de retard et d’éventuel blocage.
Concernant la version de Jquery, en principe il reste compatible (sauf exception) en ascendant avec les anciens Scripts JS. Par contre en effet il est un peu lourd. Peut être que la version V5.4.1 plus récente que la votre pourrait mieux convenir.
Cdt
Christian
00- 25 octobre 2018 à 19 h 25 min
- in reply to: Pulses : Configuration Pulses et Graph ique corrompue
Bonjour,
D’après vos messages lues, on vous explique :
en Anglais « . A parser-blocking, cross site …. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity……… »
Traduit en Français : Blocage à l’accès à un Site Tier…. La requête réseau pour ce script PEUT être bloquée par le navigateur lors de ce chargement de page ou lors d’un futur chargement de page en raison d’une connectivité réseau médiocre.…..
Il peut y avoir plusieurs causes à votre problème :
_ Bien sur l’un des premiers problème peut venir de la carte SD et fichiers chargés comme Nicolas peut le penser. Essayez de formater votre carte SD et de recopier l’intégral du ZIP de la version V0_38F avec vos fichiers CSG.
_ D’après les messages d’erreurs : Une connexion Tierce est bloqué par le navigateur lors d’un lancement d’un Script. Je Suppute que l’un des Scripts Javascript qui se trouve bloqué et qui utilise une connexion Tierce peut être » graph.js » lancé depuis le fichier Index.html au lancement du site WES. Ce Script JS est utilisé par le WES pour générer tous les graphiques. Ce Script utilise un langage interprété par le site Tier W3C scalable vector graphics (SVG). Je peux penser que votre Navigateur bloque les connections à ce site Tierce W3C pour des raison de connectivité faible ou manque de ressource.- Vous avez peut être une connexion Internet un peu lente ? ou un pare feu ou module qui vous bloque.
_ Un autre problème peut également provoquer ce type de blocage. Certain FAI internet (ex: SRF ) configure dans les paramètres de leur BOX les DNS principal et secondaire de Cloudflare DNS 1.1.1.1 et 1.0.0.1. Cloudflare est un site américain qui est utilisé comme serveur de DNS. Il est concurrent au serveur DNS de Google et remplace celui de base du FAI. Il se veut être plus Rapide et sécurisé ? Par contre Cloudflare peut dans certain cas provoquer des blocages comme celui d’un Cross Réference. En Plus on peut se demander ce que fait ce site Américain de nos infos qu’il reçoit lors de la demande de toutes nos connections qui lui sont transmises ?!!! On peut modifier les DNS en remettant ceux qui sont propre aux Serveur DNS du FAI si vous lisez les DNS 1.1.1.1 et 1.0.0.1 de Cloudflare dans les Params de config de votre Box.
– Vous avez peut être dans Google Chrome un ou des modules complémentaires qui vous provoque des perturbations. Avez vous chargez des modules dans Google Chrome pour visualiser par exemple le trafic et vos accès WEB ou bien des modules pour partager vos connexion avec d’autre Réseau sociaux ou Modules pour sécuriser vos connexions. Il semble peut être y avoir « urlscan.io » qui est activé ? Voyez à désactiver pour essais tous vos modules complémentaire dans Google chrome ou autre Navigateur. Vous verrez si le problème vient de l’un d’entre eux.
_ Il y a aussi une solution pour Nicolas afin d’éviter à d’autres d’avoir ce problème ou de minimier ce type de blocage par Google Chrome ou autre Navigateur lors de connexion internet un peu lente ou par manque de ressource. Il serait bien que Nicolas apporte une petite modification dans ses Pages HTML lors du chargement de ses Script Java.
en effet les Scripts JS sont tous chargés dans le WES ainsi : <script src= »http ../… /… / « name ».js »> </script>
Il serait bien de modifier le chargement de ces Scripts par <script type= »text/javascript » async src= »http ../… /… / « name ».js »> </script>. En effet » ASYNC » donne ordre aux navigateurs de ne pas attendre la fin du chargement d’un Script JS pour passer au suivant. Les Scripts seront tous chargés ainsi de façon asynchrone à leurs rythme.
Pour terminer, le dernier message spécifie que le fichier actuellement chargé de JQUERY version V2.1.4 de 2015, est un peu Obsolète pour
des requêtes de type Synchronous XMLHttpRequest. La dernière version de JQUERY est actuellement la 3.3.1. Peut être serait t’il bon que Nicolas modifie et charge la dernière version pour se mettre à jour ?Mais ceci ne sont que des conseils amicaux sans autre procès d’intention.
Cordialement
Christian
00- 23 octobre 2018 à 20 h 00 min
- in reply to: Pulses : Configuration Pulses et Graph ique corrompue
Bonjour,
Pour juger au mieux le problème, Lancer la page des « Outils de développement » de Google Chrome par appuie sur la touche F12 du clavier si vous êtes sur un PC. Sinon y accéder par le bouton menu (en haut de la page de chrome à droite > 3 barres noire superposées horizontal) puis > plus d’outils > Outils de développement.
Un bandeau doit apparaît, cliquer dans le champ « console ». Vous devriez voir les erreurs et tous les fichiers ou Scripts qui dysfonctionnent ou non chargés et non reconnus. ( ex : fichier non chargé, erreurs de script ? Jquery ou autres , version chrome pas compatible ? etc etc).
Cela peut aider et Nicolas pourra mieux cerner le problème.
Cdt
Christian
00- 8 octobre 2018 à 14 h 37 min
- in reply to: Présentation et Triphasé
Bonjour,
Pour répondre aux questions de Nicos et de Flo. Personnellement je ne connais pas les Miniserveur LOXONE. Mais j’ai regardé un peu les spécifications de ce serveur.
Il semble qu’il y a la possibilité d’envoyer des requêtes HTTP et/ou UDP/TCP. Il y a aussi la possibilité de commander 4 Sorties Analogiques et gérer des Entrée analogiques.
Pour lire les tensions ou courant des phase en TRI par simple HARD :
En utilisant seulement 3 entrée Analogique vous pouvez lire n’importe quel module type capteur qui mesure des tensions ou courant directement. Vous en avez pour quelques 5€ à 10€.
En utilisant 3 sorties Analogiques et une 1 entrée Analogique, si le Serveur Loxone est capable de programmer en une seule ligne les 3 sorties en High/Low ( 0,0,0 <> 1,1,1) et lire dans la foulé l’entrée analogique dédié, alors à l’aide d’un simple 8-channel analog multiplexer/demultiplexer 74HC4051, il vous est possible d’augmenter le nombre de capteurs à lire jusqu’à 8 entrées Analogique. Chaqu’une des 8 entrée Analogique peuvent être connecté à n’importe quel capteur (courant, tension etc) et le résultat d’un capteur parmi 8 peut être lue sur la seule entrée Analogique. par l’OXONE. C’est l’adressage des 3 sorties analogique qui détermine le capteur analogique lue en entrée.
Si vous avez l’extension 1WIRE OXONE alors à l’aide de 3 DS2438 vous pouvez réaliser les 3 circuits qui vous permettrons de lire les Tensions et Courant du TRI.
Par Requêtes HTTP ou UDP:
Si vous pouvez intercepter et analyser la réponse après envoie d’une requêtes, alors il est très facile de réaliser vos projet par de simple ESP8266 en WIFI.
pour Nicos :
Le ESP8266 monté en tant que Serveur HTTP WIFI, peut facilement avec quelques composants autour, mesurer les tensions des 3 phases du TRI ainsi que les courants dissipé sur chaque phase et peut renvoyer les valeurs lues en réponses aux requêtes reçus du LOXONE.pour Flo :
Le ESP8266 peut aussi gérer un bus 1WIRE en mode Master et lire la plus part des Composants DALLAS 1Wire comme des sondes de température, Carte Relais, etc.. même des cartes électroniques Complexe fonctionnant en protocole I2C et lue via un DS28E17 PONT (BRIDGE) 1Wire vers I2C.Si votre carte électronique et une carte 8 relais 1Wire, alors vous avez aussi la possibilité de connecter cette carte au bus 1Wire d’un WES si vous en avez un et commander les relais par l’envoie de requêtes comme le préconise Nicos.
Pour utiliser les ESP8266, bien sur il faut avoir quelques connaissance sur la programmation qui est assez facile via l’IDE Arduino par exemple.
Cordialement
Christian00- 16 septembre 2018 à 8 h 53 min
- in reply to: Configuration Port sur box thomson
Bonjour,
Je ne connais pas votre box Thomson, mais il me semble qu’elle se comporte comme une passerelle en lien entre plusieurs processus externes.
A la vue de la page de configuration fournie en pièce jointe, il me semble que l’on vous propose de configurer la traversé de FLUX de PROTOCOLES Spécifique définis par leurs PORTS en toute transparence vers des points d’accès externe définis par une Addr IP locale connectés à la passerelle de la Box.
Le WES fonctionne en Protocole HTTP (flux TCP internet) via le port 80 par défaut, toutefois on peux remplacer le port 80 par le port 90 par une mise à jour disponible du WES.
Le WES propose aussi des transactions sous forme de requêtes soit de type TCP ou UDP. La définition de ces 2 Ports se font dans le menu M2M dans le WES.
Donc logiquement en partant dans cette analyse, pour laisser-passer par exemple le protocole HTTP (flux Internet) pour l‘Addr IP locale allouée au WES, la configuration des Ports Forwarding serait pour le START le Port 80 et pour le END le Port 80. Normalement seul le Port 80 sera utilisé.
De même vous pouvez rajouter une ou deux ligne pour configurer le (les) Ports concernant les requêtes M2M (TCP et/ou UDP) , pour l’Addr IP du WES, en fonctions des Ports définis dans le menu M2M du WES. De même il n’y a qu’un seul port pour chaque Protocle, donc le Port END devrait être identique à celui du Port Start.
Certains Serveurs peuvent fonctionner pour un Flux d’un Protocole donné sur un Groupe de PORT consécutifs réservés à ce Serveur (Start < > End). C’est pourquoi vous avez la notion de Port DEBUT (Start) et de Port FIN (End)
Je répète, je ne connais votre Box Thomson, mais je pense ne pas trop me tromper.
Cordialement
Christian
00- 3 septembre 2018 à 23 h 44 min
- in reply to: Programmation: détecter une transition
Mon exemple donné ci-dessus ne fonctionne pas ! Il faut forcer SW2 à OFF pendant plus de 20s en continue pour arrêter le cycle , j’ai voulu compliquer le test pour rien ??? (•̀ᴗ•́)൬༉
pour simplifier dans le même esprit :
Source SW1 = ON — Sortie SW1 — Action OFF si Cdt vrai pendant tempo — Tempo(seconde) = 20
Source STemp < 19,00 — Sortie SW1 — Action ON si Cdt vrai pendant tempo — Tempo(seconde) 40 — Actif Suivant Switch Virtuel SW1 OFF
Source STemp > 22,00 — Sortie SW1 — Action ON si Cdt vrai pendant tempo — Tempo(seconde) 40 — Actif Suivant Switch Virtuel SW1 OFFSW1 = ON sert de test de la transition des valeurs en dépassement des limites extrêmes. SW1 est remis automatiquement à OFF après 20s.
L’utilisation de Sondes de Température dans l’exemple n’est pas le plus approprié à ce genre de test vue la rémanence des Sondes. Par contre cela peut mieux convenir pour la mesure entre deux seuil de consommation en Courant ou deux seuil de mesure d’une valeur de Capteur Analogique.
Cdt
Christian
00- 3 septembre 2018 à 20 h 43 min
- in reply to: Programmation: détecter une transition
Bonjour,
Si vous entendez une transition, un changement d’état entre deux valeurs d’un ou deux capteur par exemple entre mini et maxi alors vous pouvez faire le test comme suit :
– Exemple d’une transition de température d’une sonde T « STemp » comprise entre T <= 19,00° et T >= 22,00° et utilisation par exemple du Switch SW1 = ON ou SW2 = ON comme test du point d’entrée pour activer une commande en relatif, La transition entre la valeur Mini et Maxi de la température sera confirmé après un passages de seuil d’au moins 40s (valeur d’exemple). Pour réinitialiser l’ensemble il faut remettre soit SW1 ou SW2 = OFF. On peut se passer de SW2 et faire le test du chg d’état uniquement sur SW1. Mais sans l’Usage de SW2 le processus se réarme automatiquement cycliquement sans avoir la main sur l’initialisation.
Bien sur le test peut se faire de la même manière avec une plage de valeur sur 1 ou 2 valeurs de sondes de température différente ou entre la valeur de 1 ou 2 Capteur Analogique voir même entre 2 valeurs de consommation instantané de compteur à Impulsion ou Pince Ampèremétrique.
Source SW1 = ON — Sortie SW1 — Action OFF si Cdt vrai pendant tempo — Tempo(seconde) = 20 — Actif Suivant Switch Virtuel SW2 OFF
Source SW1 = ON — Sortie SW2 — Action ON
Source STemp < 19,00 — Sortie SW1 — Action ON si Cdt vrai pendant tempo — Tempo(seconde) 40 — Actif Suivant Switch Virtuel SW1 OFF
Source STemp > 22,00 — Sortie SW1 — Action ON si Cdt vrai pendant tempo — Tempo(seconde) 40 — Actif Suivant Switch Virtuel SW1 OFFFaire le Test de la transition sur SW2, Pour permettre un nouveau cycle du Test, remettre SW2 = OFF après usage.
Cordialement
Christian
00- 22 août 2018 à 2 h 52 min
- in reply to: Port extention wes V2
Bonjour,
Concernant la configuration d’une adresse IP DHCP en IP FIXE locale, il faudrait peut être communiquer le FAI ou modèle de votre Box !
Mais trouvez ci-dessous les liens concernant la configuration des BOX des principaux FAI : FREE, SFR, BUYGUE, ORANGE :
FREEBOX FREE
lien : https://www.astuces-pratiques.fr/informatique/freebox-revolution-dhcp-assigner-une-ip-fixe
BOX SFR >> ici on donne un exemple de paramétrage d’une IP DHCP en IP Fixe pour une caméra, mais c’est pareil pour tous les équipements. Lire WES en lieu et place de Caméra !
lire à partir de : 2ème Étape – Paramétrage de votre box de SFR > 2.1 Attribution d’une adresse IP locale fixe à la caméra
BBOX BUYGUE
lien : https://www.01net.com/actualites/configurez-correctement-votre-bbox-552354.html
voir attribution d’une adresse ip privée fixe à un ordinateur du réseau local
BOX ORANGE
Si votre FAI n’est pas référencé ci-dessus, il vous suffit de faire une recherche avec ces mots clés :
Configuration BOX « votre FAI » attribuer une ip fixe a un equipement
Cordialement
Christian
00- 6 août 2018 à 6 h 25 min
- in reply to: Récupérer la valeur d'une seule sonde température
Bonjour,
La requête UDP ou TCP pour lire la valeur d’une sonde = gW0xx (xx = numéro de la sonde 00 <> 31
Voici un exemple éclaté pour lire toutes les sondes du WES par requête UDP à partir d’un Arduino.
On suppose que l’Arduino est équipé d’un shield ethernet et est déjà connecté au même réseau local (WIFI ou RJ45) que le WES.
Au préalable il faut préciser qu’elle est le numéro de Port UDP à utilisé par le WES depuis les menus M2M du WES.
Include et Variables Globale pour cet exemple:
#include <WiFiUdp.h>
bool RW = false; // FlipFlop Envoie/Lecture requête UDP
int numTemp = 0; // Numéro de la sonde courante à lire (init à zero pour démarrer la Lect)
IPAddress WesServer = IPAddress(192, 168, x, x); // Adresse IP du WES
uint16_t UDPPort = 1000; // ex : numéro de Port UDP déclaré dans le M2M du WES
const int PACKET_SIZE = 20; // Taille buffer de réponse UDP
char packetBuffer[ PACKET_SIZE]; // buffer reception réquete UDP
WiFiUDP Udp; // Instance UDP///////////
setup() {
///////////////////////////////////////////////////////////////////////
// On suppose le Arduino est déjà connecté au LAN via le shield ethernet à partir d’ici
Serial.println(« \nStarting connection to UDP server… »);
Udp.begin(UDPPort); // Init de la connection UDP
delay(500);}
//////////////
void loop() {if (!RW) { // RW FALSE = envoie une requete UDP au WES
numTemp += 1; // n° sonde incrémental à lire
if (numTemp > 31) numTemp = 1; // On lit toutes les sondes entre 1 <> 31
sendPacket(WesServer, UDPPort, numTemp); // envoie une requete lect sonde (n) UDP au WES
RW=true;
delay(500); // tempo envoie
}
else if (Udp.parsePacket()) { // RW TRUE = Verif réeponse requete UDP WES
Serial.println(« packet UDP reçu »);
int len = Udp.read(packetBuffer, PACKET_SIZE); // lecture de la réponse UDP
if (len > 0) {
packetBuffer[len] = 0; // Prepare et affiche la valeur Temp réceptionnée
String sval = String(packetBuffer);
Serial.print(« Valeur sonde Temp num « );
Serial.print(numTemp);
Serial.print( » = « );
Serial.println(sval);
}RW=false; // On prépare une nouvelle requête d’envoie UDP
delay(2000); // Lecture des sondes WES toutes les 2 secondes
}
}/////////////////////////////////////
// Demande par envoie d’une requete UDP la valeur d’une sonde (n) au WES
// arguments : Adresse IP Wes, num UDP port, num Sonde Temp
void sendPacket(IPAddress& address, uint16_t port, int ntemp) {// Creation de la requete UDP lecture Sonde Temp = gW0xx (xx = num de la sonde 01 < > 31
String sTemp = (ntemp < 10) ? String(« gW00 »)+String(ntemp,10) : String(« gW0 »)+String(ntemp,10);Udp.beginPacket(address, port); // UDP WES requests IP + Port
Udp.write(sTemp.c_str(), sTemp.length()); // Envoie la requete UDP ex : gW001 = dme val sonde Temp 1
Udp.endPacket();
}Cordialement
Christan
00- 1 août 2018 à 19 h 47 min
- in reply to: Horloge NTP: petite astuce
Depuis la dernière Mise à jour WES V 0.83F le fichier horlcgf.cgi n’existe plus.
Donc pour reprendre et corriger mes précédents propos :
Pour mettre le WES à l’heure manuellement via une requête externe par un quelconque processus et depuis les dernières version WES :
http://admin:password@192.168.x.x/AJAX.CGX?time=hh:mm:ss (hh = heure, mm = minute, ss = seconde)
Pour forcer le WES à gérer son heure par serveur NTP :
http://admin:password@192.168.x.x/AJAX.CGX?hntp
Cdt
Christian
00- 1 août 2018 à 19 h 05 min
- in reply to: Horloge NTP: petite astuce
Bonjour,
Pour mettre le WES à l’heure manuellement via une requête externe par un quelconque processus est :
http://admin:password@192.168.x.x/horlcfg.cgi?time=hh:mm:ss (hh = heure, mm = minute, ss = seconde)
Pour forcer le WES à gérer son heure par serveur NTP :
http://192.168.x.x/horlcfg.cgi?hntp
Cdt
Christian
00
