pas de réaction detectée GPIO12

[Electronlibre2012]

excuse moi,

1-j'ai beau appliquer du 3v3 sur la pin 12, GPIO12, il se passe rien. Je précise que j'ai recommenter la ligne 4 bien sur et rebuild et re uploadé.

2- si je débranche je ne l'alimente plus les sensors dans HA passent pas à unknown, ils restent comme activés. Il y a juste "Smoke Detector Smoke est devenu indisponible" dans le log HA

[xmow49]

1 - étrange, j'ai pas eu ce souci. essais de changer de pin. Attention il faut utiliser un pin RTC (à voir sur le pinout)

2 - Oui c'est tout à fait normal, il est considéré comme un END DEVICE, donc ZHA le passe en offline au bout de 8h sans réponse.

[Electronlibre2012]

1-J'ai essayé la pin 11, ca ne fonctionne pas mieux. J 'ai pas trouvé beaucoup d'info sur les pinout en RTC, ce que j'ai compris c'est que la plupart fonctionnent à part 2 ou 3 et la pin 12 est donnée en example dans la doc espressif.

2-J'ai laissé branché toute la nuit et ce matin les sensors sont "indisponible" (smoke detector et LQI").

je pense que j'ai un autre soucis car ca rafraichit bien le sensor LQI quand je décommente la ligne 4 #define DEBUG_SLEEP mais je n'ai pas de sensor "battery"et le pin 12 n'actionne rien en le mettant a 3v3...

j'ai simplifié le code sans le deep sleep et ca fonctionne parfaitement sur la pin12 donc il y a bien un soucis avec le deep sleep qui ne détecte pas le front montant sur la pin 12.

I (327) spi_flash: detected chip: generic
I (331) spi_flash: flash io: dio
W (335) spi_flash: Detected size(8192k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (349) sleep: Configure to isolate all GPIO pins in sleep state
I (355) sleep: Enable automatic switching of GPIO sleep configuration
I (362) coexist: coex firmware version: 80b0d89
I (367) coexist: coexist rom version 5b8dcfa
I (372) app_start: Starting scheduler on CPU0
I (377) main_task: Started on CPU0
I (377) main_task: Calling app_main()
I (377) gpio: GPIO[4]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0
I (397) phy_init: phy_version 210,23b73e4,Jul 24 2023,21:45:23
I (437) phy: libbtbb version: 851e131, Jul 24 2023, 21:45:54
I (447) main_task: Returned from app_main()
I (457) ZIGBEE: Zigbee stack initialized
I (8667) ZIGBEE: signal: 6, status: 0
I (8667) ZIGBEE: Start network steering
I (8677) ZIGBEE: Joined network successfully (Extended PAN ID: eb:41:14:8a:45:96:4b:91, PAN ID: 0x0baf, Channel:25)
I (8677) MAIN: Not Detected!
I (8677) MAIN: Reset state
I (8677) MAIN: vIN: -13.945300, percentage: 0
I (8687) MAIN: vIN: -13.590100, percentage: 0
I (10687) MAIN: Alert! Smoke detected!  <---------------------------------------PIN12 en 3v3
I (10687) MAIN: vIN: -12.879700, percentage: 0
I (10687) MAIN: vIN: -13.945300, percentage: 0
I (12687) MAIN: Not Detected! <-------------------------------------------------PIN12 en float
I (12687) MAIN: Reset state

toujours pas de sensor battery, mais je n'ai rien branché pour le moment, c'est en float.

voici ma carte, c'est une ESP32-C6-DevkitC-1 V1.2

je vois pas en quoi le deep sleep fonctionnerait différemment...a part que c'est un ESP32-C6 et que tu utilises un ESP32-H2...il y a peut etre une différence au niveau logiciel...desactivation du wifi ou autre...j'avoue que mes compétences sont un peu limitées ...et le temps a passer dessus surtout ;)

Si jamais tu as une piste pour m'aiguiller? merci

[xmow49]

ah oui, pour le deepsleep, la fonction esp_sleep_enable_ext1_wakeup ne marchais pas sur le H2. donc j'utilise la esp_sleep_enable_ext1_wakeup_with_level_mask qui marche pour moi.

Pour la batterie, c'est normal :). La librarie ESP Zigbee ne permet pas de définir le node descriptor: donc de base le device est considérer comme alimenter par le secteur. Pour "régler" ce souci, j'ai créer un "quirks" dans ZHA pour modifier le node descriptor mais coté ZHA. Il faut télécharger ce fichier: gammatroniques_smoke.py

et le mettre dans /config/zha_quirks/

j'ai ajouter ca dans la conf HA

zha:
  custom_quirks_path: /config/zha_quirks/
  enable_quirks: true
  database_path: zigbee.db

apres un reboot de HA; tu devrais avoir ca:

[Electronlibre2012]

merci pour ton aide.

J'utilise déja les quirksmais malheureusement ca ne fonctionne pas mieux :

Dernière vue: 2023-09-03T14:49:37
Source d'énergie: Mains

même en supprimant/réappairant l'ESP, je reste en "mains" pas battery.

Et j'ai essayé l'option "esp_sleep_enable_ext1_wakeup" mais ca ne fonctionne pas non plus, mais je crois comprendre pourquoi ;) 👍

esp_err_t esp_sleep_enable_ext1_wakeup(uint64_t io_mask, esp_sleep_ext1_wakeup_mode_t level_mode) Enable wakeup using multiple pins This function uses external wakeup feature of RTC controller. It will work even if RTC peripherals are shut down during sleep. This feature can monitor any number of pins which are in RTC IOs. Once selected pins go into the state given by level_mode argument, the chip will be woken up.

Parameters: io_mask – Bit mask of GPIO numbers which will cause wakeup. Only GPIOs which have RTC functionality can be used in this bit map. For different SoCs, the related GPIOs are: -ESP32-C6: 0-7 - ESP32-H2: 7-14

donc le GPIO12 risque pas de marcher avec le C6 ! lol

je continue....

[xmow49]

ok, nickel pour le gpio.

Pour les quirks, essaie de supprimer l'appareil (lorsqu'il est allumé et pas en deepsleep), reset l'esp et de le réappairer

[Electronlibre2012]

merci pour ton aide. ca ne fonctionne pas mieux, pas de sensor battery.

J'ai reussit à tout faire fonctionner sauf la partie "sleep_watchdog" car ca reste dans la boucle (Sleep watchdog timeout) et ne check plus le GPIO, et redemarre l'esp toutes les 30s. J'ai commenté cette partie et modifié la ligne 118 dans smoke_detector.h par

esp_sleep_enable_ext1_wakeup((1ULL << SMOKE_PIN), ESP_EXT1_WAKEUP_ANY_LOW);

et ajouté juste en dessous

esp_deep_sleep_start();

mais j'ai un boot loop si je laisse activer le GPIO trop de fois (genre 4-5 boucles et j'ai baissé timer wake up à 5s au lieu de 30s mais ca n'a pas d'influence sur ce soucis) :

I (46) boot: Enabling RNG early entropy source...

après recherches c'est peut etre du à la taille de la ROM : j'ai ce warning :

W (337) spi_flash: Detected size(8192k) larger than the size in the binary image header(2048k). Using the size in the binary image header.

sais tu ou je peux changer la taille du header de 2M à 8M stp?

[xmow49]

tu as changer le nom de l'appareil ? si oui il faut le changer dans le fichier py.

pour la taille de la flash, ca se change de le menuconfig. mais ici ca na pas d'importance, c'est juste un warning.

si le sleep watchdog se décanche, c'est que le code prend plus de 10s a se mettre en sleep.

[Electronlibre2012]

Non je n'ai pas changé le nom.

Ok pour le flash ;)

Ok je vais investiguer. Merci pour tes éléments de réponse

[Electronlibre2012]

tu as changer le nom de l'appareil ? si oui il faut le changer dans le fichier py.

pour la taille de la flash, ca se change de le menuconfig. mais ici ca na pas d'importance, c'est juste un warning.

si le sleep watchdog se décanche, c'est que le code prend plus de 10s a se mettre en sleep.

Petite nouvelle, je suis un boulet :)

1-En fait pour le Quirk j'ai fait "copier la source du lien" ce qui met plein de code CSS et HTML dans le fichier....une fois le bon fichier copié j'ai vu que l'ESP une fois reconnu s'appel "smoke detector" et fabriquant "GammaTroniques" donc j'ai renommé le fichier smoke_detector.py et TADA, j'ai le sensor "battery".

2-En cherchant dans ton code je me suis rendu compte que l'ESP-C6 est connecté sur le channel 11 de mon dongle zigbee qui est dédié a Zigbee2Mqtt!!! aie aie pas bon ca. Normalement on peut pas faire cohabiter Z2M et ZHA sur le même dongle! et ben non seulement on peut, mais non seulement ca n'a pas planté! incroyable.

Bon du coup j'ai changé le channel Zigbee dans ton code pour le channel 25 ou j'ai une autre Gateway Zigbee en Ethernet (une gateway type Sylvercrest de chez Lidl hackée).

3-Pour le soucis du sleep_watchdog, je l'ai passé a 10000 au lieu de 5000 ms et ca ne le déclenche plus.

Maintenant je vais essayer de créer un modèle "standard" avec toutes les option (switch, light, binary_sensor) pour adapter facilement a des applications différentes. Pas simple car tu n'as pas fait la même structure dans ton ESP32H2-SmokeDetector-main et ESP32H2-ZigbeeDemo-main.

Je vais regarder si c'est faisable sans y passer des jours ;)

Merci encore pour ton aide et je te souhaite la réussite dans tous tes projets, je ne sais pas quel age tu as, mais ce que je sais c'est que tu es doué!

EDIT: j'ai repassé le sleep_watchdog a 5000ms et ca fonctionne bien, vu que je suis plus sur mon dongle Z2M j'imagine...c'était la source de mon problème depuis le début en fait (a part la mauvaise PIN 12 puisque j'ai un C6 et pas un H2). Ca pourrapeut etre aider des prochains noob comme moi ;)

[xmow49]

Super si ça marche, oui, ça fait des infos pour aider d'autres personnes.

Pour les structures, oui j'ai un peu fait ça à l'arrache. N'hésite pas à partager si tu as une autre solution. On est vraiment au début du zigbee avec les ESP, va falloir maintenir ce code, il change beacoup de chose dans la lib...

[Mazikin001]

Hello, Je sais que le problème est règlé, mais je débute sur Zigbee et je galèrais sur mes projets plus complexe jusqu'à me plonger un peu (très peu en fait, c'est ch* à lire) dans la documentation officielle Zigbee. J'utilisais (ou copiais) ce que tout le monde semble utiliser comme protocole de reporting de l'ESP32 vers HA: .dst_endpoint = endpoint, .src_endpoint = endpoint, Et ça marche mais les status updates sont parfois un peu long (voire inexistants). Pourquoi ne pas utiliser l'adresse broadcast (0xff)** à la place? .src_endpoint = 0xff, Dans un broacast, toutes les entités du réseau recoivent le message et seul celles concernées réagissent.

Mais j'ai peu être raté un truc..

(Super video à propos. Et super réalisations)

[xmow49]

Slt, c'est pas plutot .dst_addr_u.addr_short = 0xFFFF, le broadcast ? et l'adresse 0x0000 c'est ladresse du coordinateur zigbee (HA) Les endpoint sont des groupe de clusters.

Je nais pas eu de souci avec les reports de mon coté

[Mazikin001]

Il y a plrs type de broadcast, 0xFFFF est un broadcast device (ce qui n'est pas intéressant dans ce cas), là je parlais du broadcast EP comme décrit dans le Zigbee Cluster Library v8 Chap 2.3.2.1