Problem with delay in Grow R503 automation on ESP32

Joma87 · January 13, 2023, 8:23am

Hi all,

i am using a Grow R503 fingerprint sensor which really works nicely, i only have one better said two small problems:

The “delay” for switching on/off the aknowledgment Tone (event: esphome.test_node_finger_scan_matched) on a YL-44 Buzzer only works very imprecisely. It somehow works but the actual duration of the tone depends on how I scan my finger and probably also the weather Since I want to work with different PWM frequencies and durations and tone sequences to have a good user experience i need to adjust the duration exactly!
Even if i put the output.turn_off in the “on_boot” event there is a small beep at boot. Why is the ledc interface set to 100% by default?

esphome:
  name: weg-tuer
  on_boot:
    - output.turn_off: buzzer

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "XXXXXXXXX"
  services:
  - service: enroll
    variables:
      finger_id: int
      num_scans: int
    then:
      - fingerprint_grow.enroll:
          finger_id: !lambda 'return finger_id;'
          num_scans: !lambda 'return num_scans;'
  - service: cancel_enroll
    then:
      - fingerprint_grow.cancel_enroll:
  - service: delete
    variables:
      finger_id: int
    then:
      - fingerprint_grow.delete:
          finger_id: !lambda 'return finger_id;'
  - service: delete_all
    then:
      - fingerprint_grow.delete_all:
ota:
  password: "XXXXXXXXXX"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

# Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Weg-Tuer Fallback Hotspot"
    password: "2vJbYWKPiH28"

captive_portal:

#define buzzer

output:
  - platform: ledc
    pin: 16
    id: buzzer
    inverted: true

#Fingerprint sensor:

uart:
  rx_pin: GPIO1
  tx_pin: GPIO3
  baud_rate: 57600

fingerprint_grow:
  sensing_pin: GPIO5
  on_finger_scan_matched:
    - homeassistant.event:
        event: esphome.test_node_finger_scan_matched
        data:
          finger_id: !lambda 'return finger_id;'
          confidence: !lambda 'return confidence;'
    - fingerprint_grow.aura_led_control:
        state: BREATHING
        speed: 200
        color: GREEN
        count: 1
    - output.turn_on: buzzer
    - delay: 200ms
    - output.turn_off: buzzer
  on_finger_scan_unmatched:
    - homeassistant.event:
        event: esphome.test_node_finger_scan_unmatched
    - fingerprint_grow.aura_led_control:
        state: FLASHING
        speed: 25
        color: RED
        count: 2
  on_enrollment_scan:
    - homeassistant.event:
        event: esphome.test_node_enrollment_scan
        data:
          finger_id: !lambda 'return finger_id;'
          scan_num: !lambda 'return scan_num;'
    - fingerprint_grow.aura_led_control:
        state: FLASHING
        speed: 25
        color: BLUE
        count: 2
  on_enrollment_done:
    - homeassistant.event:
        event: esphome.test_node_enrollment_done
        data:
          finger_id: !lambda 'return finger_id;'
    - fingerprint_grow.aura_led_control:
        state: BREATHING
        speed: 100
        color: BLUE
        count: 2
  on_enrollment_failed:
    - homeassistant.event:
        event: esphome.test_node_enrollment_failed
        data:
          finger_id: !lambda 'return finger_id;'
    - fingerprint_grow.aura_led_control:
        state: FLASHING
        speed: 25
        color: RED
        count: 4

Many thanks for your help!

Johannes

Mahko_Mahko · January 13, 2023, 9:16am

For #2, I don’t know, but here’s some random things you could try if you haven’t already:

Set inverted: false and remove your on boot turn off?
Try another pin. I don’t think GPIO16 is pulled high or pwm on boot but yeah dunno.

Joma87 · January 13, 2023, 12:02pm

If it’s not inverted the logic of output or switch (I tested both) is wrong. I believe it’s an hardware issue from the PWM Controller which is initialized to late during boot, I would have to try other pins and see if the behaviour is different on other GPIOs… But actualy i already got used to it… Many devices have a beep at startup

Unfortunately #1 is still a huge Problem!

Best
Johannes

Joma87 · January 13, 2023, 9:30pm

UPDATE:

In the meantime i performed some tests, the problem is not the delay - it is a general problem:

If you release the finger quickly everything works smoothly and instead of the beep you could even play a whole song with rtttl… But if you leave the finger on the sensor everything slows down so much, that even sometimes the connection to the API fails:

[22:23:57][V][fingerprint_grow:019]: No touch sensing
[22:23:57][V][fingerprint_grow:019]: No touch sensing
[22:23:58][V][fingerprint_grow:019]: No touch sensing
[22:23:58][V][fingerprint_grow:019]: No touch sensing
[22:23:59][D][fingerprint_grow:092]: Scan and match
[22:23:59][D][fingerprint_grow:123]: Getting image 1
[22:23:59][D][fingerprint_grow:133]: No finger
[22:23:59][V][component:200]: Component fingerprint_grow took a long time for an operation (0.09 s).
[22:23:59][V][component:201]: Components should block for at most 20-30ms.
[22:23:59][D][binary_sensor:036]: 'beruehrung': Sending state OFF
[22:23:59][D][fingerprint_grow:092]: Scan and match
[22:23:59][D][fingerprint_grow:123]: Getting image 1
[22:23:59][D][fingerprint_grow:144]: Processing image 1
[22:24:00][I][fingerprint_grow:148]: Processed image 1
[22:24:00][D][fingerprint_grow:101]: Fingerprint matched
INFO weg-tuer.local: Error while reading incoming messages: Error while reading data: [Errno 104] Connection reset by peer
INFO weg-tuer.local: Ping Failed: Error while reading data: [Errno 104] Connection reset by peer
INFO Disconnected from ESPHome API for weg-tuer.local
WARNING Disconnected from API
INFO Successfully connected to weg-tuer.local
[22:24:15][V][fingerprint_grow:019]: No touch sensing

In parallel I tried to let the Aura-Led breathe when idling but this made the whole situation significatnly worse and there was a 99% chance the API get’s disconnected while attemping to scan…

So i came to the conclusion that:

To much tasks, the cycle time skyrockets
The power supply breaks

I was able to check the power supply and there seems to be no issue. With the cycle time i am unsure on how to check it and if it would make a difference in general? I don’t understand exactly how this automations are treated since i come from PLC and C Programming and have less experience with object orientation (C++ etc.)…

I am thankful for any hint you can give

Johannes