[Résolu] Module AHT10 (température + Humidité) via I2C

Bonjour, j’ai reçu mes deux modules identique, des AHT10, pour la température et l’humidité. L’info que je recherche n’est que la température.

Les connections, du AHT10 vers mon RPi1B (et aussi testé avec RPi0);

  • VIN → Pin 1 (3.3v)
  • GND → Pin 9 (Ground)
  • SDA → Pin 3 (SDA)
  • SCL → Pin 5 (SCL)

Je n’ai jamais réussi à lire quoi que ce sois, ni le détecter…

  • i2cdetect -y 1 : Me retourne que des « – », dont aucun matériel détecté.
  • Ce site à le même module, j’ai tenté sont guide, j’ai des résultats … même si je débranche le module (4 pin non connectés). Les valeurs change et j’ai une température (~45.00) et un taux d’humidité (~5.65%), mais je pense que c’est la température du CPU et sont usage qu’il me donne en fait… ou des valeurs erronés simplement.

Le DataSheet et autres informations sur ce site; AHT10 RH/TEMP Sensor - Espruino

Alors j’ai besoin de savoir …

  • Peut-ont tester le module de manière simple, comme par exemple en sondant le SCL ou SDA avec un voltmètre, question de savoir si le module est « vivant » ?
  • J’ai lu quelques par dans mes recherches, que <c pourrais être un erreur d’adressage, du fait que le Pi cherche en 7bit et que le module enverrais en 10bit, mais je sais pas comment gérer cette info.
  • La fréquence de communication acceptable est 0~400MHz, selon la doc fournis avec le DietPi que j’utilise, je suis à 100MHz, ce qui est dans les normes.
  • Je ne sais pas si le AHT10 est pris en charge comme en « PnP » ou requière une attention particulière avec un RPi (comparé au Arduino).
  • Je ne sais pas si le i2c est correctement chargé et comment déterminer si il est fonctionnel (sur un forum, le i2c du gars sur son RPi0 était mort, du a un produit défect, sans connaitre plus de l’histoire)

Selon DietPi, le i2c est chargé à 100MHz, j’arrive a démarrer un Pi en « halt » via le GPIO3 (Pin 5) et un Ground.

hello,

as tu essayé i2cdetect -y 0 si j’ai bien compris les « anciens » pi ont les I2C sur 0 !

source :

Mouai j’ai essayé le 0, j’ai une erreur avec, un peu normal, j’ai juste « /dev/i2c-1 » de dispo, alors j’ai pas le premier premier, de toute façon j’ai le même problème sur les RPi0. :frowning:

Bonjour,

Il sont bien alimentés entre 0V et 3.3V ? Ils n’ont jamais été alimenté en 5V ce qui aurait pu les endommager ?
As-tu essayer d’inverser SDA et SCL ?
En général sur les réseaux I2C, certains proposent de mettre une résistance pullup de 10kohm (entre SDA et le +3,3V et entre SCL et le +3,3V) pour fiabiliser le signal.
Faire tous les essais avec un seul module sur le bus I2C.
Pour savoir si il y a de l’activité, un voltmètre ne donnera pas d’information pertinente, il faudrait un oscilloscope et encore, savoir interpréter les signaux !

Aussi à voir ce topic, il semble y avoir des problèmes avec ce module.
https://www.raspberrypi.org/forums/viewtopic.php?t=265734

Bonne bidouilles.

A+

Salut, merci de répondre :slight_smile:

Pour ce qui est de l’alimentation, je mais avec le 3.3v du Pi, j’ai aussi utiliser un alimentation externe dans un test, ou la sortie donnait 3.29v. De ou j’ai acheté, je n’ai pas vraiment d’informations, sur d’autres fiches avec le même produit en image/description, j’ai lu qu’un contrôle d’alimentation 5v est présent et régule pour le 3.3v du sensor. Selon la fiche technique, que je crois plus, c’est du 3.3v. J’ai tenter d’inverser les SDA/SCL, mais pas de résultat.

Je n’a pas eu de résultat avant ni après mes soudures.

Mais je n’ai pas été en mesure de faire marcher le GPS NEO 7 également. Je crois que je ne suis pas douer avec l’utilisation des pins sans passer par un chapeau. Pourtant je fais attention de faire les branchement hors tension, de m’assurer de de ne pas faire de faut contact. Mais je ne suis pas exempt d’erreur de manipulation, mais sur mes 2 modules ? En plus d’avoir eu un GPS qui ne semblais pas marché. (mais l’antenne avait recu un coup et une soudure du couvercle de protection à « lâché », alors surement mort déjà).

Le module semble ayant été plus conçu pour Arduino, et ne connaissant pas l’univers Arduino, je ne sais pas si justement il marche pas mieux sous Arduino et que sous Raspberry Pi il faut autre chose … un « pilote ».


Je met également en doute mes talents de soudure… mon coloc a commandé 2 kit DIY d’horloge à souder sois même, dans les deux cas, le résultat n’est pas fonctionnel, je passe les détails mais je soupçonne que je chauffe trop les composants. Je tente de minimiser mon contact avec les matière, j’approche mon fil de la surface ou jeu veux appliquer mon « plomb » et écrase pour le « coller ». Mais je veux m’assurer du meilleur contact, alors, il m’arrive de repasser 2 ou 3 fois ou de refaire « fondre le plomb » pour qu’il pénètre mieux entre la pin et l’orifice. Alors dans mon désire de bien faire mais sans attendre de refroidir avant chaque tentative, je crois que les pièces en sont affecter (chaleur suit le circuit…).

Mais dans ce cas si, j’ai testé avant mes soudure (fil dénudé au bout replier dans les orifices). Pour le Pi, ce sont des prise propre comme sur cette image;

La sur le module, vu que j’ai soudé les pins, je relis les deux molex (l’un le RPi, l’autre le Sensor) via leur autre extrémité selon les coordonnantes requises. Comme ça je limite les mauvais contact et peux sonder mon voltage par exemple facilement.


Sur cette page, le voltage est indiqué être entre 1.8v et 6.0v. Alors que j’utilise le 3.3v ou 5v change rien selon cette info.

Que se soit sur n’importe quel système ( arduino, Rpi,esp32,etc.) le principe est le même; un fichier contient les informations nécessaire pour utiliser le module; en C/C++ c’est un fichier en .h ( EXEMPLE POUR ARDUINO : https://github.com/enjoyneering/AHT10/blob/master/src/AHT10.h) en python c’est un module à importer.(GitHub - gejanssen/aht10-python)

on doit pouvoir appeler ça un « driver » !

la soudure…
je me suis pas mal pris la tête aussi pour les soudures; trouver le bon fer à souder j’ai finit par opter pour un de 30 W (camping gaz ) avec une panne ( la pointe au bout ) fine et pointue.
de l’étain 1mm et je me suis entraîné sur un PCB en soudant des fils, des headers juste histoire de se faire la main.( avec un tuto sur utube )
j’ai aussi un truc pratique avec des pinces et une loupe pour tenir et voir (!) le truc à souder ( marque dexter - grandes surfaces bricolage )

l’autre aspect pénible de ces montages c’est les wires pour bredboard ! je viens de passer 2 plombes sur un montage parce que j’en avait un « pourri » qui passait pas le signal…( et que bien sur j’avais pas testé :roll_eyes:)

le dernier truc c’est la taille des câbles et leur diamètre la notion d’AWG (https://falaisemodeleclub.fr/section-cable-awg/) le but du jeu etant d’avoir le bon par rapport à l’ampérage qu’ils transportent et leur resistance (AWG en mm2 - Assemblage américain du câble)

Pour ce qui est des outils, je suis assez bien équipé je crois.

J’ai le support avec pince et loupe, j’ai un autre aussi « à plat ». J’ai du gros plomb, petit plomb, deux fer a souder; l’un plus vieux avec l’embout pas mal usé (je ne trouve pas les pièces de rechange pour lui) et un autre avec la pointe très pointu. J’ai mon « Gun à colle » et autres accessoires et pièces.

Sur l’image ont ne voit pas mes cables que j’utilise, qui sont fait pour le breadboard, et mon testeur de voltage.


J’ai reçu mon module RTC, j’attend les batterie et je vais tester avec lui si j’ai plus de chance a la détection I2C.

Je viens de recevoir ma batterie pour mon module RTC, je l’ai mis sur le RPi1 mais il ne le trouve pas sur le I2C, j’ai allors tenté de le mettre sur mon RPi0, et miracle, il le vois!!! (#68) alors je le remet sur le RPi1 et toujours rien… je soupçonne le DietPi (OS) d’être le problème du I2C. Je vais devoir retester le AHT10 sur le RPi0 pour voir si il … le voit.

Je vous tiens aux nouvelles. Si vous avez des astuces avec le I2C, je suis preneur. :slight_smile:


Sérieux, mon RPi0 me fais rager. Au point que je me demandais si mes GPIO sont pas différent vu que c’est du 26pins et non du 40pins. Selon cet ouput, tout est à la bonne place;

root@RPi1CAM:~# gpio readall
 +-----+-----+---------+------+---+-Model B1-+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 |     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |
 |   2 |   8 |   SDA.1 | ALT0 | 1 |  3 || 4  |   |      | 5v      |     |     |
 |   3 |   9 |   SCL.1 | ALT0 | 1 |  5 || 6  |   |      | 0v      |     |     |
 |   4 |   7 | GPIO. 7 |   IN | 1 |  7 || 8  | 1 | ALT0 | TxD     | 15  | 14  |
 |     |     |      0v |      |   |  9 || 10 | 1 | ALT0 | RxD     | 16  | 15  |
 |  17 |   0 | GPIO. 0 |   IN | 1 | 11 || 12 | 0 | IN   | GPIO. 1 | 1   | 18  |
 |  27 |   2 | GPIO. 2 |   IN | 1 | 13 || 14 |   |      | 0v      |     |     |
 |  22 |   3 | GPIO. 3 |   IN | 1 | 15 || 16 | 1 | IN   | GPIO. 4 | 4   | 23  |
 |     |     |    3.3v |      |   | 17 || 18 | 0 | IN   | GPIO. 5 | 5   | 24  |
 |  10 |  12 |    MOSI | ALT0 | 0 | 19 || 20 |   |      | 0v      |     |     |
 |   9 |  13 |    MISO | ALT0 | 0 | 21 || 22 | 0 | IN   | GPIO. 6 | 6   | 25  |
 |  11 |  14 |    SCLK | ALT0 | 0 | 23 || 24 | 1 | OUT  | CE0     | 10  | 8   |
 |     |     |      0v |      |   | 25 || 26 | 1 | OUT  | CE1     | 11  | 7   |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+-Model B1-+---+------+---------+-----+-----+

Mais pourtant …

 root@RPi1CAM:~# i2cdetect -y 1
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 70: -- -- -- -- -- -- -- --

Et lsmod…

 root@RPi1CAM:~# lsmod
 Module                  Size  Used by
 spidev                 20480  0
 raspberrypi_hwmon      16384  0
 bcm2835_codec          36864  0
 i2c_bcm2835            16384  0
 v4l2_mem2mem           36864  1 bcm2835_codec
 bcm2835_v4l2           40960  0
 bcm2835_isp            28672  0
 bcm2835_mmal_vchiq     28672  3 bcm2835_isp,bcm2835_codec,bcm2835_v4l2
 videobuf2_vmalloc      16384  1 bcm2835_v4l2
 videobuf2_dma_contig    20480  2 bcm2835_isp,bcm2835_codec
 videobuf2_memops       16384  2 videobuf2_dma_contig,videobuf2_vmalloc
 videobuf2_v4l2         32768  4 bcm2835_isp,bcm2835_codec,bcm2835_v4l2,v4l2_mem2mem
 videobuf2_common       61440  5 bcm2835_isp,bcm2835_codec,bcm2835_v4l2,v4l2_mem2mem,videobuf2_v4l2
 spi_bcm2835            20480  0
 videodev              241664  6 bcm2835_isp,bcm2835_codec,videobuf2_common,bcm2835_v4l2,v4l2_mem2mem,videobuf2_v4l2
 mc                     45056  6 bcm2835_isp,bcm2835_codec,videobuf2_common,videodev,v4l2_mem2mem,videobuf2_v4l2
 vc_sm_cma              32768  2 bcm2835_isp,bcm2835_mmal_vchiq
 uio_pdrv_genirq        16384  0
 uio                    20480  1 uio_pdrv_genirq
 fixed                  16384  0
 rtc_ds1307             28672  0
 regmap_i2c             16384  1 rtc_ds1307
 i2c_dev                16384  0
 i2c_bcm2708            16384  0
 ip_tables              28672  0
 x_tables               32768  1 ip_tables
 ipv6                  475136  16

rtc_ds1307, i2c_dev et i2c_bcm2708 sont chargé, ce qui devrais me donner accès aux appareil sur le I2C.

Il y a un regmap_i2c avec le rtc_ds1307, est-ce normal ? un signe de quelque chose de changé, vu autrement par le Pi ?

Tu aurais pas une carete SD sur laquelle tu installerais un Raspbian pour tester si l’I2C du PI1 fonctionne ?

A+

Mouai, bien retourner sur Raspbian semble l’option la plus intelligente, juste long faire un backup de 64gb. Mes autres SD sont de 32GB et servent sur mes autres Pi. Vaux mieux faire sur cell la de toute façon, car si c’est le DietPi qui déconne, je vais devoir rester sous Raspbian.

En bon québécois je dirais « TA BAR NACK ».

J’ai mis Raspbian OS lite sur la carte SD (après backup mon projet). J’ai boot et config le i2c pour tenter de le configurer, il trouve personne.

La je me dis que le problème doit être carrément le port i2c qui est défect ou différent vu que c’est du 26pins et non 40pins. Alors je met la carte SD avec mon kit PiZero, l’Idée est d’avoir la meme config, et je boot avec le RTC attaché.

Et la, *pouf*, j’ai mon RTC en 68, aucune modification logiciel, alors c’est un bug matériel, c’est la que j’ai lâché mon « TA BAR NACK ».

La je me trouve dans un dilemme logistique; c’est que j’ai 3 RPi sous la main et plus d’une manière de me satisfaire :stuck_out_tongue:

J’ai un RPi3 qui me sert actuellement de Media Center pour ma chambre, il est performant et tout, mais je songais justement à le remplacer par mon PiZero avec son chapeau USB+ETH pour le remplacer, comme sa j’utiliserais mon RPi3 avec mon écran 5" pour mes tests. Ce que le PiZero fait actuellement.

Dans cette vision, mon RPi1 était pour le Dashcam. Mais la, si il peux pas lire le i2c, je dois revoir tout.

Le RPi1 ira alors comme Media Center, ce qu’il était avant. Le RPi3 sera ma plateforme test et le RPiZero la Dashcam, mais j’avais opté pour le RPi car justement, je n’ai pas le Wifi et ce n’est pas une fonction utile (pas PnP). Et ajouter un chapeau pour le ETH, je ne suis pas fan (devien trop gros la), alors je vais devoir utiliser la fonction OTG ?! (j’ai l’adapteur) Mais maudit que Windows a de la misère à le prendre en charge. Faudrait alors le démarrer comme disque USB avec tout ce que ça va compliquer comme code (montage etc…). (et oui, un autre Tabarnack ici) Le RPi qui servira de Dashcam dois avoir une sortie composite (RCA).

Alors la avant de tout foutre en l’air, j’aimerais bien savoir si;

  • Le i2c sur RPi 1B (26 pins) a besoin d’attention ? Car j’ai 3 sections de pin non « populé », et je me demande si je dois faire quelque chose, car certain parle de résistance 1.0Kohm ou 1.8Kohm (selon le RPi) pour le i2c, mais est-ce que ça s’applique à mon cas ? Et est-ce que les blocs P1, P2 et P3 ont un lien avec le GPIO, voir avec le i2c ? Sur cette phot ont voi le P1 (en dessous, à gauche du GPIO) et le P2 et P3 (à droite du port RCA jaune)
  • J’ai parlé plus haut de tester avec un voltmètre, j’en conviens que l’outils idéal est un oscilloscope qu’il faudrait vraiment pour analyser le signal. Je cherche plutot un moyen de vérifier si il est complètement mort ou qu’il y a une activité quelconque, comme je peux tester un signal vidéo en vérifiant le microvolt qui passe (0.01~0.25v), mais c’est simple pour moi car c’est du +(data) et -(gnd). En d’autres mots; a-t-il un moyen de vérifier si des ports sur le GPIO serait défectueux ?
  • Le RPi1 require t-il des pilotes supplémentaire pour utiliser certains fonction, comme le i2c, car je crois que cette version du RPi est moins compatible et « PnP » qu eles autres modèles à 40 pins.

Dans cet image, il y a les noms des ports, la ont voi que P1 est inutile et P2/P3 pour JTag.

Mais regardons les pins 1 3 5 7 9

  • 1 : 3.3V; ok good, c’est ce que je retrouve aussi sur le GPIO 40 pins,
  • 3 : I2C SDA; ok, encore la good, même chose
  • 5 : General Clock; bon, sur les GPIO40, il est indiqué comme i2c Clock, est-ce la même « clock » ?
  • 7 : DNC (Do Not Connect); Hum… un autre différence, même si je ne l’utilise pas, sur les GPIO40 il est indiqué comme GPIO#4 (1-wire),
  • 9 : GPIO#17 : Encore la pas pareil, sur les GPIO40 il est défini comme « Ground », alors tandis que le Ground sur la photo est à la pin 6

Alors la je dois avouer, j’ai surement fait le con et foutu en l’air mon RPi, car je me fiait à un guide image qui disait miser le GPO26 et le GPIO40, définissant les 26 première pins identique de l’un à l’autre, mais je dois avoir que si je me fi à la photo, j’ai relié des points à des place non prévu, car si je me fiais au ground de mon guide en pin 9, mais qui n’est pas conçu pour ça, j’ai surement fait sauter de quoi, je me sert pas du ground de la pin #6 durant mes tests. Mais rien n’est peut être perdu.

La je vais devoir tester autrement, je vais tester le AHT10 avec le ground différent, et tenter de trouver le schéma de mon module RTC pour savoir si il utilise le ground de la pin 6 et tant qu’a y être, les autres également.


Sur le RPi1, mon 3.3v donne 3.26v et le 5v donne 4.93v et descent à 4.50v une fois booté, mais durant ce test du 5v, c’est que le module y est connecté, sous le 3.3v j’ai aucune variation.


J’ai relié le 5V, GND, SDA et SCL du module RTC à mon RPiZero; il le detect toujours, meme setting sur le RPi1; il voit rien.

Mon i2C sur le RPi1 semble ne pas marcher. et je n’ai pas les même voltage que sous le RPiZero, le 5v donne un beau 5.11v stable sur le RPiZero.

Bon, j’en conclus ceci à ce stade;

  • Les modules AHT10 ne marchent pas, ils sont probablement defect, du a mes tests.
  • Le module RTC marche sur le RPiZero mais pas sur le RPi1
  • Les voltages entre le RPi1 et RPiZero ne sont pas identique et doivent causer des problèmes.
  • Le GPIO du RPi1 est différent du RPi0/2/3, pas juste un niveau du nombre de pins, mais également des définitions

Alors il reste à savoir si le port i2c du Raspberry Pi 1B est vraiment défect OU une autre chose doit être fais pour l’utiliser. Avez-vous une idée de comment je peux faire pour tester ultimement mon i2c sur le RPi1 ?

Bon, fermons le sujet une fois pour toute :stuck_out_tongue:

Les modules AHT10 que j’ai semble mort, de toute façon, ce n’est pas un élément important du projet. Alors oublions ce point la.

Pour le i2c, ne jamais utiliser DIetPi; impossible d’avoir une détection pour une raison inconnue, même sous le RPi0, impossible de le détecter. Alors je suis revenu à Raspbian.


Encore la, je suis tombé sur l’un de ces bizarrerie. Sachant comment activer le module (ayant testé sous mon Raspbian Desktop sur lequel j’ai fais mes tests précédent), je prépare dont le « config.txt » et complète avec les « raspi-config », un « apt update & upgrade » et installation des outils i2c.

La je regarde avec le « i2cdetect -y 1 » et le #68 est en « UU », alors parfait, le RTC est chargé et utilisé par le system dès le départ, alors je tente le « hwclock -r » et la erreur. Alors comment il peut être chargé et que le « hwclock » dit ne pas connaitre de moyen de contacter l’horloge.

Je vous évites mes recherche et j’ai trouvé… par moi même, car aucunement documenté (dans mes recherches). Alors quand ont édite le fichier « /lib/udev/hwclock-set », il faut porter attention à un information. La variable d’appel du chemin RTC peut être erroné.

Alors vous trouver dans le document la ligne suivante;

  • HCTOSYS_DEVICE=rtc0

« /dev/rtc0 » existe, mais pour une raison inconnue, il ce peut que ça ne marche pas, alors changer le pour cette valeur;

  • HCTOSYS_DEVICE=rtc
    Dans mon cas, sur Raspbian Lite, une fois fait, la commande « hwclock -r » marche parfaitement et le RTC synchronise le temps.

Alors sujet clos.