Bonjour,
Ce petit serveur permet d’envoyer l’heure exacte à tous les périphériques présent sur votre réseau local.
Cela permettra à l’Ecodevices ou à l’IPX800 d’ètre parfaitement autonome même en cas de perte d’internet.
Il ne dispose que d’un seul écran de configuration, largement suffisant pour régler l’heure et les quelques paramètres réseaux.
Le produit est encore en phase béta.
Astucieux 
et précieux pour la bonne tenue des stats de nos appareils préférés.
question : un protocole M2M spécifique permet il d’obtenir les infos du time device ou bien doit on utiliser un client NTP et considérer le time device comme un serveur NTP ?
Je suis en particulier intéressé à pouvoir récupérer l’EPOCH time pour dater des envois à un service.
GCE démontre une fois de plus l’écoute des ses clients et sa capacité d’innovation
+1
Bonjour,
Il s’agit d’un serveur ntp mais rien ne nous empèche d’ajouter des fonctions.
Il est tout à fait possible de renvoyer l’epoch time via json ou m2m.
Il suffit de demander 
Cdt
Bonjour,
Je suggère de faire évoluer votre Time-device en le transformant en watchdog intelligent.
Il pourrait surveiller via des ping plusieurs boitiers connectés.
Puis alerter via des push ou des Email afin de déclencher un reset des boitiers défaillants.
Cela permettrait notamment de surveiller l’activité de l’ipx800 (qui peut-être n’a pas de watchdog intégré?)
C’est juste une idée mais je pense que cela rendrait nos installations domotiques un peu plus sûres…
Slts
Christophe
Bonjour,
C’est une très bonne idée…
On va y réfléchir et mettre ça dans les tuyaux d’autant que le code du ping watchdog est déjà opérationnel.
Cdt
Bonjour
Une fonction Timers en pilotage Http sur IPX V3 V2 pro etc…
cela permet la centralisation des timers sur plusieurs IPX (plus facile en gestion)
cdt
Bonjour Didier,
C’est une bonne idée aussi
Bon je vais rajouter de la mémoire car si ça continu on va être limite .
Mais c’est cool on à de bonne pistes pour faire évoluer ce produit
Même idée que didierm, cette fonctionnalité est très importante d’autant qu’une IPX ne peut pas « s’auto-push ». Du coup, le fait qu’une autre boîtier puisse envoyer des commandes http ce serait un énorme plus !! On pourrait reprogrammer une IPX en fonction de timers, ce qui décuplerait les possibilités en termes de programmation.
Bonjour
Sera-t-il DCF77 ?
Merci
DV
Bonjour
Je suis finalement peut être un peu trop ambitieux pour votre nouveau produit, car dans la capture d’écran je ne vois même pas la configuration d’un serveur de temps NTP pour que lui même soit toujours à l’heure (sans ça, il ne sert à rien, car une horloge autonome se dérègle très vite, et elle ne fera que transmettre son décalage horaire à tous les composants du réseau qui lui sont inféodés pour la maj du temps.
Une fois que la configuration possible d’un serveur ntp sera régler sur votre produit, il serait alors peut être judicieux de la coupler au système DCF77 afin d’avoir quand même la synchro de l’heure gmt en l’absence temporaire ou permanente d’une connexion internet.
Ainsi votre nouveau produit pourra alors rivaliser sans complexe avec les produits gorgy-timing, qui sont pour moi une référence dans la synchro horaire sur un LAN.
Excusez-moi de casser l’ambiance, mais l’euphorie nombriliste n’est pas dans mes habitudes car les chinois ne sont jamais très loin en embuscade…avec des produits très complets et des frais de port gratuits depuis shenzhen, hong kong ou singapour.
Salutations.
DV
Juste une précision, vu le texte en fin de page 1. GCE a développé ce boitier justement pour les personnes ne disposant pas d’internet (pas du tout). Donc je vois pas en quoi la synchro possible avec un serveur NTP sur internet serait un plus, car à ce moment-là c’est le Time-Devices qui devient inutile, puisque les périphériques type IPX800 auront bien accès à un serveur NTP quelqu’il soit sur internet.
Et si Time-Devices doit servir à prendre le relais NTP en cas de coupure de la connexion internet, on en revient au même : si la coupure est courte, ça ne gêne pas les boîtiers GCE comme l’IPX800, et si la coupure est longue, alors Time-Devices pourra se décaler et donc ne plus être synchro avec l’heure GMT…
Bref, je comprends pas votre remarque. Time-Devices sert avant tout à des personnes qui, sur un LAN, n’ont pas du tout accès à internet. Comme l’IPX800 ou ECO-DEVICES ont besoin d’un serveur de temps pour être à l’heure, ce boitier trouve là tout son intérêt. Je ne pense pas que ce soit si grave que ça si Time-Devices se décale de quelques secondes par rapport à l’heure GMT. Il n’est pas destiné à synchroniser des serveurs informatiques ou des bases de données qui, eux, ont un réel besoin d’être exactement à la même heure.
Dans ce cas le DCF77 prend tout son sens pour garantir la validité de l’heure… En plus, c’est très peu couteux et très facile à implémenter. Ca a été conçu pour être interprété par de la logique combinatoire discrète et quelques bascules et registres ! Avec un microp, c’est d’une utilisation triviale.
Jetblack
Bonjour
Nous allons sortir le Time-device afin de pouvoir donner une heure exacte (à quelques secondes) à nos produits.
Il ne sera pas synchronisé sur l’horloge atomique mais je vais laisser l’option possible pour notre clientèle pro.
Je vous invite à vous renseigner sur le cout d’un serveur de temps NTP synchronisé sur l’horloge atomique, Dvador cite une marque dans un post précédent.
Perso je doute que l’utilisateur lambda soit prêt à mettre + de 400€HT pour etre sur que le timer de l’ipx800 commute bien à la seconde gmt.
Cdt
Je comprends tout à fait l’argumentation, cependant:
-Une pendule murale radiopilotée DCF77 ca coute environ 20 euros, et donc le hardware de la réception DCF77 est vraiment très peu cher.
Ce serait bien plus cher (et moins fiable en intérieur) de récupérer l’heure du signal GPS par exemple.
-Ca peut être gênant d’avoir des dérives de qq secondes qui se transforment en minutes au fil des mois… Le time-device pouvant se trouver dans un endroit à fortes variations de température, pas évident de garantir une bonne stabilité. Tout dépendra du « prix » du quartz à l’intérieur et de la sophistication de la stabilisation/compensation associée. Typiquement la stabilité standard c’est 5 ppm, soit 0.5 seconde par jour… au mieux…
Si le time device sert de référence à un IPX qui doit ouvrir le volet roulant ou la grille du parking d’un magasin à heure fixe le matin pour que le personnel puisse entrer, il ne vaut mieux pas qu’il prenne 15 minutes de retard en quelques mois…
Jetblack
Bonjour,
Oui ça coute environ 20 euros fabriqué en millions d’exemplaires en Chine.
Nous on produit en centaines de pièces et en France, les tarifs ne sont pas les mêmes.
Votre argumentation tient la route en ce qui concerne la précision mais on va etre trop cher.
Lionel le dit plus haut avec raison, on ne va pas synchroniser des serveurs mais les timers de l’ipx800. Bon ça va décaler un peu et alors…
La plupart vont préférer remettre à l’heure 2 fois par an que d’investir des centaines d’euros dans un serveur NTP de précision.
Ceux qui s’en serviront comme horloge de secours en cas de perte d’internet n’auront aucun décalage de temps car le système se remet à l’heure automatiquement via ntp dès le retour d’internet
Pour le GPS je ne suis pas daccord, récupérer l’heure revient moins cher par GPS par contre ça ne marche que si l’antenne est en, extérieur contrairement au DCF77 qui fonctionne en intérieur.
Maintenant si vous connaissez une astuce pour rajouter le DCF77 à moindre cout avec la directive R&TTE 99/5/CE je suis preneur et pret à l’implanter.
Je vais faire des recherche de mon coté pour essayer de trouver une solution qui soit sympa pour tous.
Cdt
Le problème du DCF c’est la basse fréquence et donc la taille de l’antenne, même si on doit pouvoir compenser avec une bonne sensibilité de récepteur.
En ce qui concerne la directive, il me semble que les équipements de réception radio utilisés exclusivement pour la réception des services deradiodiffusion sonore et télévisuelle ne sont pas concernés par la directive 99/5/CE.
Si on considère le time-device comme un récepteur permettant de lire sur un écran l’heure exacte à distance de l’horloge de référence, ca devient un récepteur de radiodiffusion télévisuelle. Et donc, pas concerné par la directive
Bon je ne suis pas sûr que ca marche
Cordialement,
Jetblack
Une solution serait d’utiliser le signal horaire émis par TDF radiofrance à 162kHz. L’émetteur fait 2000 kW donc il porte loin et la fréquence est dans le spectre des grandes ondes radio, donc le système de réception devient un système de réception de radiodiffusion sonore : pas concerné par la directive !
Je vais essayer de trouver un module déjà certifié…sinon ce sera un GPS…
Bonjour
400€ (même 20€), on ne doit pas vivre sur la même planète car il y a qq années j’ai installé sur un linux un module DCF77 en suivant ce tuto
pour exactement 10.70 € TTC.
Le module vient de chez Conrad, donc allemand donc concernant le DCF77, ils savent de quoi ils causent puisque l’émetteur est chez eux.
En plus vous avez le binaire, donc le code.
Aussi l’idée de mettre le DCF en option est très bonne, vous laissez juste un socket sur la carte électronique pour y mettre la puce DCF à la demande et un BNC en sortie pour y brancher une antenne orientable intérieure.
N’oubliez pas d’y mettre aussi la connexion à un serveur ntp, ne vous fermez pas la porte à l’administration système des LAN (ainsi que le marché allemand de la domotique, ils vont sans doute apprécier que vous utilisiez leur émetteur).
Tiens si vous en sortez un, tel que je le conçois, je vous en prendrez un (avec toutes les options !) même si je n’en ai absolument pas besoin sur mon LAN et en plus j’en parlerai à mes collègues administrateurs système qui sont souvent à la recherche d’un relais ntp autonome. Je mettrai mon Gorgy-Timing en vacances et je mettrai le votre à la place !
Pour info: Pour des raisons de sécurité sur un LAN et ceci pour plein de services IP, on met en place des relais en sortie afin qu’aucun client du LAN ne sortent jamais sur internet directement. On le fait pour le ntp, le dns, et même pour le web en utilisant des serveurs proxy.
En plus ces systèmes de relais préservent la bande passante de la connexion internet. Les paranos de la sécurité installent même tous ces relais dans la DMZ.
Par contre petite précision technique en passant, si vous utilisez pour votre time-device, un port réseau 10 Mb/s et comme il va dispenser un service sur port UDP (et non TCP), il peut y avoir une perte de la connectivité à ce time-device au bout d’un moment due à d’éventuelles émissions multicast qu’il peut y avoir sur le LAN (tout simplement une camera IP qui émet son flux vidéo en multicast, ou une imprimante réseau qui émet des trames multicast sans que personne ne le sache). Le multicast ne fait pas bon ménage avec le 10 Mb/s d’autant plus que le multicast utilise lui aussi le protocole UDP, ce qui va rendre plus sensible votre time-device à ce pb de blocage éventuel. Le blocage peut arriver rapidement ou au bout de quelques mois, tout dépend de l’activité multicast sur le LAN. Un redémarrage du module permet de vider la pile multicast non digérée par le port 10 Mb/s. Ce pb reste très aléatoire, le risque est acceptable, mais c’est pas facile de voir que le service ntp sur un LAN est tombé, il faut déclencher une demande de mise à l’heure manuelle d’un périphérique et voir qu’il y a échec.
Avec un port réseau 100 Mb/s, aucun pb et vous pouvez alors oublier tout ce que je viens de raconter.
DV
