Mailbox mail-arrived notifier

Some hardware links on this page are affiliate links. As an Amazon Associate I earn from qualifying purchases. We may earn a commission if you buy through them, at no extra cost to you. See the affiliate disclosure.

A flap twitch is not the same as “there is mail.” This workflow treats the delivery flap as a count-up and the collection door (or a button on the notify) as a reset. Each stable flap open increments counter.mail_waiting and sends one push — optionally with a generic camera snapshot. Opening the collection contact, or tapping “collected” on the phone, resets the counter to zero.

Entity ids are blueprint inputs. Do not describe which approach, curb, or camera covers the box.

The flap contact can be a store-bought reed or the battery reed door sensor pack — same binary_sensor contract, deep-sleep wakeup included. Put that sleepy entity on the exclude list of offline devices report so overnight sleep does not look like an outage.

What problem it solves

You want to know mail arrived (and roughly how many drops since you last emptied the box) without walking out to check, and without a second push when you open the box to collect it.

How it works

1. Flap debounce — delivery contact goes on and stays on for a short for (pack default a couple of seconds) so a slam-and-rattle is one event.
2. Increment + notify — counter.increment on mail_waiting, then Companion with the new count. If you wired a camera entity, the pack takes camera.snapshot and attaches the file. If you did not, the message is text only.
3. Collect — collection contact goes on (door opened), or the notify action / dashboard input_button fires. counter.reset, optional “collected” push, snapshot path skipped.
4. Idempotence — a flap event while you are already in a collect window (both contacts open, or the reset fired in the last few seconds) does not increment. That is you emptying the box, not a second delivery.
5. Waiting flag — a template binary sensor mail_waiting > 0 is dashboard candy; it is not a second source of truth. The counter is.

A single-sensor install works if you only have the flap: use the notify action as the reset. Two sensors are cleaner.

Hardware notes

• Flap reed. Magnet on the moving flap, reed on the box. Metal boxes eat 2.4 GHz — offset a Zigbee/ESPHome board into a plastic puck or run the battery reed with the antenna outside the can.
• Collection reed or button. A second contact on the door you actually open to empty the box, or skip the hardware and reset from the phone action / a dashboard button.
• Power. Battery contacts only. Do not pull mains to a curbside box.
• Camera (optional). Any HA camera entity that supports camera.snapshot. The pack never names a mounting point; point it at the box interior or skip it. Do not commit stills.

Snippet

The pack ships a blueprint. Inputs replace real entity ids:

trigger:
  - platform: state
    entity_id: !input flap_contact
    to: "on"
    for: "00:00:02"
    id: delivered
  - platform: state
    entity_id: !input collect_contact
    to: "on"
    for: "00:00:01"
    id: collected
  - platform: state
    entity_id: !input collect_button
    id: collected_manual
action:
  - choose:
      - conditions:
          - condition: trigger
            id: delivered
        sequence:
          - service: counter.increment
            target:
              entity_id: !input mail_counter
          - service: notify.notify
            data:
              message: "Mail waiting: {{ states(mail_counter) }}"
              # optional camera.snapshot + attach: full blueprint in the pack
      - conditions:
          - condition: trigger
            id: collected
        sequence:
          - service: counter.reset
            target:
              entity_id: !input mail_counter

Setup outline

1. Mount the flap reed. Confirm open/close in HA before you enable deep sleep on an ESP32 build.
2. Add the collection reed or the input_button. Create counter.mail_waiting.
3. Import the blueprint. Fill flap, collect, counter, notify service. Leave the camera input empty on the first test.
4. Test: flap once → count 1 and one push; flap again → count 2; collect (or tap the action) → count 0. If you add a camera later, attach a snapshot on the next flap only after text notify is solid.

Troubleshooting

• Two notifies per delivery. Debounce is shorter than the flap bounce. Raise the for on the flap trigger; do not add a second automation.
• Collect increments the count. Both reeds share a magnet or you used the same entity twice. Collection must be a different binary sensor (or the button), and the collect window must suppress flap increments.
• No snapshot on the push. The camera entity does not support camera.snapshot, or the notify service ignores image. Confirm snapshot in Developer Tools, then Companion; do not debug with a real-property still in git.
• Flap works on USB, silent on battery. Deep-sleep wakeup pin is wrong, or run_duration is shorter than Wi-Fi. Fix that on the battery reed node first; this blueprint cannot see a contact that never publishes.

Credits

Based on the community blueprint Simple mailbox notifier — 2 sensors, optional camera. This write-up is an original overview of the increment-on-flap / reset-on-collect pattern.