Discussion :

[cobra38]

Bonjour à tous

les projets IOT que j'essaie de faire, demandent souvent des connexions sur des serveurs NTP ( heure) et données météo , ces derniers deviennent exigeants et imposent un nombre limité d'accès par heure ou par jour sinon cela devient payant
le nombre de projets augmentant les nombres d'accès aux serveurs aussi ...
C'est pourquoi je me permets de vous solliciter pour savoir s'il était techniquement possible de faire cela à l'aide ESP32 ou autres,
un "serveur" horaire et météo qui me permettrait d'interroger en local via le wifi par exemple et mettre à jour les données horaires et météos des autres appareils
et si oui quel en serait le principe de base et si vous avez en magasin quelques exemples d'applications ou liens
je vous en serais reconnaissant

Bien Cordialement

pascal

[f-leb]

Hello,

Tu pourrais avoir un ESP32 connecté à un module RTC externe. Le module RTC peut retenir la date/heure même en cas de coupure du courant ou d'accès à Internet. Si l'ESP32 est connecté au WiFi, il peut aller chercher l'heure sur Internet (NTP) de temps en temps après une coupure ou pour se resynchroniser. Cet ESP32 serait aussi configuré en serveur Web HTTP, et pourrait servir la date/heure courante aux clients (d'autres ESP32) qui en feraient la demande (requête HTTP).

[cobra38]

merci f-leb

Cet ESP32 serait aussi configuré en serveur Web HTTP, et pourrait servir la date/heure courante aux clients (d'autres ESP32) qui en feraient la demande (requête HTTP).

c'est là que devrait commencer mon problème ....

pascal

[f-leb]

Il existe des bibliothèques simples comme WebServer sur esp32, regarde dans les exemples.

[cobra38]

ok je regarderai
merci bien

[f-leb]

En très gros, tu lances un serveur avec un gestionnaire pour une requête http :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
server.on("/gettime", gestionnaire_getTime);
 
...
 
void gestionnaire_getTime() {
  // code pour récupérer les date/heure
  // date/heure convertie en chaîne de caractères timeStr
  server.send(200, "text/plain", timeStr) // réponse du serveur au client
}

Côté client (un autre ESP32) tu utilises la bibliothèque HTTPClient, tu trouveras des exemples pour lancer la requête et récupérer la date/heure retournée par le serveur.

Avec un module RTC (type DS3231), tu dois récupérer la date/heure en NTP au démarrage. Tu peux aussi lancer une resynchronisation NTP une fois par jour à la même heure pour compenser la dérive du module RTC. Tu maintiens ainsi une bonne précision sans surcharger de requêtes NTP.

[cobra38]

Selon toi

Quelle est la meilleure façon de communiquer en local entre Serveur & Client
Wifi ou BLE ?

[f-leb]

Je n'ai pas d'expé avec les esp32 et le BLE. La portée du BLE est plus courte qu'en WiFi et les débits sont plus faibles aussi en BLE, mais pour l'internet des objets en intérieur et des échanges de données légers, cela reste une bonne option (connexion rapide, très faible consommation d'énergie pour tes esp32 qui sont sur batterie).

Edit : si par client-serveur tu entends un navigateur Web qui se connecte à un serveur Web en http pour servir des pages web, le BLE n'est pas prévu pour cela. C'est toujours possible mais il faut d'autres technos sur le navigateur.

[cobra38]

Edit : si par client-serveur tu entends un navigateur Web qui se connecte à un serveur Web en http pour servir des pages web, le BLE n'est pas prévu pour cela. C'est toujours possible mais il faut d'autres technos sur le navigateur.

mon but étant d'aller chercher sur internet les infos d'heure et de météo puis de le retransmettre via BLE aux modules clients (ceux sont principalement des informations périodiques telles que la synchronisation de l'heure ou température ou humidité extérieures etc.. )
en fait il s'agit par exemple :
- je possède une pergola avec un toit ouvrant qu'il faut, en toute logique, refermer le soir et en cas de pluie imminente
comme les capteurs de pluie ne fonctionnent pas correctement , je m'appuie sur les infos météos de la région qui m'indiquent la probabilité de pluie de 0 à 100% , ainsi le serveur informe le module client ( ici le module véranda) que le risque de pluie
est important celui-ci déclenche alors un signal lumineux car les panneaux sont ouverts ...
un avis ?

[f-leb]

Attention, je ne pense pas que le serveur puisse "pousser" des données au client, c'est forcément les clients qui font la demande au serveur.

[cobra38]

Est-ce à dire que seul le client doit interroger le serveur de façon périodique pour savoir comme dans mon exemple , si il y a un risque de pluie ou autre ?

[f-leb]

Je m'avance un peu trop... Apparemment il existe un service de notifications (fais des recherches sur les services GATT) qui permet de pousser des notifications aux clients.
En tout cas, cela ne fonctionne pas comme en WiFi.

[cobra38]

j'ai trouvé çà pour GATT

https://letmeknow.fr/fr/blog/175-tut...gatt-sur-esp32

[Jay M]

En Bluetooth Low Energy, le serveur est l’appareil qui contient les données organisées en services et caractéristiques, tandis que le client est l’appareil qui se connecte pour accéder ou modifier ces données.

Pour pousser de l’information vers le client, le serveur utilise soit une notification, soit une indication.

Une notification envoie les données sans confirmation, alors qu’une indication attend un accusé de réception du client.

Pour recevoir ces messages, le client doit s’abonner à la caractéristique concernée.

Sur ESP32, on utilise les objets BLEServer pour créer le serveur, BLEService pour définir un service, et BLECharacteristic pour ajouter une donnée à ce service. Ces objets permettent de gérer les connexions, les lectures, les écritures et l’envoi de notifications ou indications vers le client BLE.

PS: Les termes techniques utilisés à la place de client et serveur en BLE sont central et périphérique (peripheral). Le périphérique (peripheral) est l’appareil qui émet les paquets publicitaires et attend une connexion. Le central est celui qui scanne, choisit un périphérique et initie la connexion ==> central et peripheral définissent les rôles de connexion.

Une fois la connexion établie, les rôles GATT client et GATT server définissent l’échange de données. Le GATT server expose les services et caractéristiques, et le GATT client les consulte ou les modifie. Un périphérique peut être GATT server, GATT client, ou même les deux selon le contexte.

[Guesset]

Bonjour,

Les données n'ont pas nécessité d'être poussées vers les clients car il n'y a pas de gain qui supposerait que la fraicheur de l'information donne une plus grande précision. La dérive sur la RTC du module ESP ne sera ni pire ni meilleure que celle sur les RTC sur les clients. Par ailleurs, sauf si le temps de transport est compensé, il y a déjà un décalage de réception de l'heure transmise par NTP.

La recherche d'une grande précision m'inciterait plutôt à utiliser un module GPS avec l'ESP qui peut l'interroger à volonté. Si on craint les coupures de réception GPS, il peut être utile de lui adjoindre une RTC.

Salutations

[f-leb]

Bonsoir à tous,

En fait, pour limiter le nombre de requêtes NTP, on peut jouer sur l'algorithme d'acquisition des mesures.
Par exemple avec un capteur de température ambiante, en première approche, on a tendance à faire des acquisitions à intervalles réguliers an jouant avec delay() ou millis() (toutes les 10-20 minutes par exemple).
Mais on n'est pas obligé d'enregistrer et publier ces valeurs si la variation de température est très faible (inférieure à 1°C par exemple). On peut faire des acquisitions toutes les 5 minutes, mais on peut très bien attendre 1h avant de publier la nouvelle température avec sa date/heure si la variation sur la dernière heure est inférieure à 1°C.

[cobra38]

Bonjour à tous ,

merci encore pour vos intéressantes réponses à mon petit problème
dans le projet ce qui m'importe, n'est pas tant l'horloge ( dont les données NTP sont gratuites ) mais surtout les données météos ( API)
qui semblent être de plus en plus payantes
ainsi mon but est ici de récupérer en autres les probalités ( %) de pluie car mes essais de détecteurs n'ont pas été concluants
et en ayant plusieurs appareils connectés , je suis actuellement obligé de multiplier les requêtes API ( openweather)
je voulais ajouter cette petit précision

Les requêtes locale seront basées uniquement sur des demandes périodiques au serveur
càd les données d'heures et de météo ,
à savoir si le BLE répond à ce type de montage ?