Go Down

Topic: Mesure de températures et stockage dans deux bases locale et sur le net (Read 838 times) previous topic - next topic

Lacuzon

Mar 09, 2019, 12:11 pm Last Edit: Mar 13, 2019, 09:30 am by Lacuzon Reason: attaching image
Bonjour,

Voici la problématique, je possède deux serres chauffées et pilotées électroniquement. Elles sont situées à une trentaine de mètres de mon domicile. je souhaitais pouvoir contrôler les températures en plusieurs endroits depuis un PC, une tablette ou un smartphone et ce, en temps réel.

J'ai opté pour la partie détection de température et transfert d'information pour les éléments suivants :

- pour l'équipement matériel:

- un arduino pro mini 3.3V 8mHz
- un module RTC DS3231 pour la définition du temps
- un module NRF24L01+ pour le transfert par radio à 2.4GHz
- un adaptateur réducteur de tension 12v--> 3.3v pour le transducteur NRF24L01+
- des capteurs ds18b20 cablés et étanches. Etant  pour certains constamment immergés, je les ai renforcés avec un bout de gaine thermo-rétractable recouverte d'une couche de vernis pour extérieur.
- une boîte de dérivation étanche de 11.5cm x 11.5cm bon marché et de taille adaptée aux plaquettes de CI.
- une plaquette de circuit imprimé prégravée (aliexpress) présente des zones reliées pour 2, 3 et 4 connexions
- une embase femelle jack
- une alimentation réglable 3-12v avec jack (dispo chez conrad, amazon, etc.)
- une diode type  1N4007 pour protéger le dispo car le risque d'inversion de polarité au niveau de l'alim est possible
- une résistance 4.7kw (pour le pullup du ds18b20, ne pas oublier)
- un condensateur de quelques dizaines de mF à placer impérativement sur l'alimentation du nrf24 car les appels en   courant sont importants

au niveau soft :

- Sur l'IDE arduino et soit son éditeur natif soit Sublime Text avec le plugin Deviot


- pour les bibliothèques arduino :


Code: [Select]
#include <Time.h>    // gestion temps        
#include <TimeLib.h>  // gestion temps
#include <Wire.h>  // nécessaire pour gérer le module RTC DS3231        
#include <SPI.h> // nécessaire pour gérer le module nrf24
#include <nRF24L01.h> // nécessaire pour piloter nrf24 (version TMRh20)
#include <RF24.h> // nécessaire pour piloter nrf24
#include <OneWire.h> // nécessaire pour gérer les capteurs ds18b20
#include <DallasTemperature.h> // nécessaire pour gérer les capteurs ds18b20
#include <LowPower.h> // nécessaire pour mettre en sommeil le MCU
#include <RTClibExtended.h> // nécessaire pour piloter le module RTC DSs3231

 

Le principe est le suivant : le MCU associé au transceiver  NRF24 envoie les données fournies par les capteurs DS18b20 au récepteur. (ici toutes les 5 mn)  Les cadences d'envoi sont assurées par le module RTC. Il n'y a pas de vérification de la bonne réception, les émetteurs fonctionnant à puissance max, il n'y a pas de problème de réception.
Le récepteur est donc réglé (ainsi que les bases de données) sur la cadence imposée par l'émetteur. L'expérience montre que cette hypothèse est bien vérifiée.

La réception est basée :

- au niveau matériel  sur :

- un esp8266 (plusieurs types ont été utilisés sans différence de fonctionnement)
- un NRF24L01+
- un adaptateur réducteur de tension 12v--> 3.3v pour le transducteur NRF24L01+ j'ai aussi utilisé des dispos indépendants nécessitant un câblage moins simple et pratique;
- une boîte de dérivation étanche de 11.5cm x 11.5cm
- une plaquette de circuit imprimé prégravée (aliexpress)
- une embase femelle jack
- une alimentation réglable 3-12v avec jack
- une diode type  1N4007 pour protéger le dispo car le risque d'inversion de polarité au niveau de l'alim est possible
- un condensateur de quelques dizaines de mF à placer impérativement sur l'alimentation du nrf24 car les appels en     courant sont importants

-au niveau soft :

- Sur l'IDE arduino et soit son éditeur natif soit Sublime Text avec le plugin Deviot


- pour les bibliothèques arduino :

Code: [Select]

#include <SPI.h> // nécessaire pour le module nrf24
#include <nRF24L01.h> // nécessaire pour piloter nrf24 (version TMRh20)
#include <RF24.h> // nécessaire pour piloter nrf24
#include <WiFi.h> // pour gérer la transmission WiFi
#include <ESP8266WiFi.h> // pour gérer le module esp8266
#include <WiFiUdp.h> // pour gérer la transmission des données vers la base influxdb
#include <ThingSpeak.h> // pour gérer la transmission vers le cloud de thingspeak



Concernant les stockages et visualisations des données, j'ai utilisé d'une part thingspeak (bien documenté fonctionne sans souci en s'appuyant sur les exemples donnés) C'est un site ou l'on peut stocker et visualiser  gratuitement (en nombre limité) les données produites localement.
J'ai utilisé d'autre part un serveur local installé sur un rapsberry 3b+. j'ai opté pour un transfert de flux utilisant le protocole udp et une base de donnée influxdb. La visualisation est réalisée au moyen du visualisateur de graphe grafana interfaçable de manière simple avec udp/influxdb.  


Les deux serres sont équipées des mêmes émetteurs. Elles envoient donc sur un seul récepteur situé dans la maison leurs données. Celles-ci sont vues soit au moyen de thingspeak soit au moyen du serveur local sur raspberry.

L'intérêt du premier cas est que l'on peut contrôler en temps réel le comportement des serres, n'importe où sur la planète si l'on possède une liaison sur le net. Son défaut est que l'on reste dépendant d'un fournisseur qui peut à tout instant changer de politique et imposer de payer l'hébergement (ou simplement fermer boutique). la seconde solution évite cet écueil mais ne permet pas d'accéder à ses données hors  du réseau local, l'autre intérêt est une grande sécurisation : les données ne sortent pas de la maison. La combinaison des deux solutions est un bon compromis.

Voici une capture d'écran de ce que donne grafana avec toutes mes données, visualisable en bloc, l'une par une, deux par deux avec possibilité de moyenne glissante, de soustraction, entre autres, etc.



Merci au forum et aux tutoriels arduino, à la réactivité des membres actifs et à tous les sketches trouvés ici ou là sur la toile

Cordialement






al1fch

Bonjour

réalisation intéressante !
as-tu prévu de publier  ton code ?

Je suis finalement  arrivé à la même combinaison ThingSpeak (distant) + infuxDB.Grafana (local)

(en redirigeant le port 3000 j'accède hors réseau local au tableau de bord Grafana)
ThingSpeak c'est aussi pour le Matlab gratuit  qui va avec !

Lacuzon

Bonsoir,

Oui la combinaison local +grafana avec toute la puissance de influxdb et d'autre part, thingspeak avec la simplicité et matlab c'est  plutôt sympa.

pour le code, il n'y a pas de souci, En fait, je pensais ouvrir un blog car ce n'est que la partie finale de mon projet : je pilote le chauffage de ma "grande" serre depuis plusieurs années avec un arduino uno qui gère les diverses sources de chauffage (entre autres, tampon thermique de 3000litres) donc il y a pas mal de code et de discussions à échanger mais un blog c'est du boulot...

comment dois-je procéder pour publier le code ?


J'ai une question : même en local, je passe par la box, y-a-t'il un moyen de s'affranchir de la box quand je suis strictement en local ?

J'ai depuis quelques mois des soucis de déconnexion dont je ne vois pas l'origine.

Ne pourrait-on pas dialoguer plutôt en bluetooth (en remplaçant dans mon cas l'esp8266 par un esp32 ? Les distances seraient compatibles.

Cordialement

Artouste

J'ai une question : même en local, je passe par la box, y-a-t'il un moyen de s'affranchir de la box quand je suis strictement en local ?

J'ai depuis quelques mois des soucis de déconnexion dont je ne vois pas l'origine.

Ne pourrait-on pas dialoguer plutôt en bluetooth (en remplaçant dans mon cas l'esp8266 par un esp32 ? Les distances seraient compatibles.

Cordialement
Bonsoir Lacuzon
Reponses un peu en vrac  :smiley-mr-green:


Un esp8266 (esp32)  peut se comporter en AP (point d'acces)  , il est vu alors comme un reseau distinct
je ne me represente plus completement ton ensemble actuel (qui fait quoi et qui communique avec qui)
Mais j'ai vu que tu avais implementé influxdb et grafana sur RPI.
Le bluetooth sur esp32 dans l'environnement arduino est encore un peu/beaucoup indigent 

Lacuzon

Bonsoir Artouste,

En un mot, enfin une phrase ;

je reçois mes données d'un nrf24. Les données sont captées par un nrf24 connecté à un esp8266, celui-ci les redirige via le WIFI soit sur mon serveur soit sur thingspeak.

Je pensais reprendre le même schéma en remplaçant l'esp8266 par un esp32 (dans un premier temps) et comme l'esp32 gère le bluetooth pourquoi pas transmettre les données directement sur le pi plutôt que passe par la box et le wifi.

Si je fais cela c'est que mon autre projet (ruche) est au point mort, Tout fonctionne sauf que la portée est insuffisante. un montage tout esp32 semblerait plus efficace.


al1fch

Bonsoir

Comme évoqué par Artouste la prise en charge  des fonctionnalités Bluetooth d'un ESP32 sous IDE Arduino est encore sommaire.
En BT classique on trouve un exemple d'émulation série
En BLE (faible portée) plusieurs petits exemples

Une liaison  Bluetooth ESP32 vers PI 3  (ou PI Zero W)  parait néammoins envisageable  avec les moyens disponibles aujourd'hui sous IDE Arduino

Lacuzon

OK ce n'est pas trop encourageant...

Je vais quand même creuser un peu le sujet.

J'ai joint mon sketch ci-dessous.


Cordialement


Lacuzon

Bonjour,

voilà encore une capture d'écran de grafana où l'on voit l'évolution des températures durant cette froide nuit.

- Les courbes petite serre et chipRTC montrent des oscillations serrées très corrélées avec un petit gain pour le chip protégé par son boîtier. Les oscillations sont dues à la mise en marche du radiateur électrique à bain d'huile maintenant une température moyenne d'environ 6 degrés.
- La courbe grande serre montre des oscillations plus longues dues à la mise en marche automatique d'un radiateur à gaz maintenant une température moyenne de 9 degrés.

- La courbe bac externe montre une décroissance de 3 degrés complétant le chauffage par effet tampon (circulation d'eau forcée).

- Quant à la courbe bac interne, elle montre aussi une décroissance moins marquée car la nuit, l'échange thermique fonctionne simplement par thermosiphon.

 Tout est piloté au moyen d'un arduino uno permettant une ventilation régulée par PWM.

L'information est envoyée comme expliquée plus haut au moyen d'un arduino promini 3.3v associé à un nrf24L01+. Aucun bug constaté depuis sa substitution à l'association arduino nano/nrf24L01+ qui buguait de temps en temps.

Cordialement



 

Go Up