I made a write-up of my 2 year in-the-making mail box notification project. Maybe someone will find it useful.
Have you made something similar?
6 Likes
FWIW, the german computer magazine c’t published an article about a similar project in 2019:
The author uses a Broadcom HSDL 9100 infrared proximity sensor instead of a micro-switch and an ATtiny84 instead of a ATMega328p.
I don’t have experience with that particular sensor, but it feels like it’s challenging to use it to detect new mail. And it probably increases power usage significantly in contrast to a micro switch/reed-contact connected to an interrupt. The author argues that a switch just detects open-events and thus might yield false-positives in case someone opened the box without depositing a letter. On the other hand, I could imagine that small letters and post-cards don’t easily register with the infrared sensor, either, thus, yielding false-negatives.
Thanks for sharing! I love the bare-bones approach regarding the selection of components. I don’t have a subscription so I haven’t been able to read the details, but it seems like a good solution. Just being able to support a full LoRaWAN stack driven by coin cell is an amazing accomplishment, I have yet to make this work. I wonder what sort of current this solution draws at the different modes? My sensor has run on the same 2xAA batteries for almost 4 years.
That suggests that they’re using a custom LoRa scheme and not LoRaWAN, or at least are failing to fully implement LoRaWAN (including reception and support of MAC configuration downlinks) in the way a TTN node must.
Power could probably be managed by only pulsing the sensor briefly at long intervals. Personally I’d consider monitoring both that the door has been opened since yesterday, and any hints of contents. Some kind of IR-transparent triangular “shelf” inside might help orient things in a way that could be more easily optically detected, but at some point one probably runs into postal regulations.
Could also have some IR (or even visible?) reflectance sensors scattered around at and pulse them in different combinations.
Ideally what would be seen would be a sequence of door opening, then closing with the internal reflection measurements now being different than they were before it opened.
I feel like a notification that “mailbox door cycled, reflectance change suggests 79% probability of mail in box” is something I could work with especially compared to what else I was doing with my time and how urgently I was awaiting a particular piece of mail.
Unlike your project page, the c’t article doesn’t include detailed power measurement results. The author basically just reports that he didn’t need to change the CR2032 battery during his 6 week long test period, while using a 5 minute check interval.
FWIW, the c’t project uses a RFM95W LoRa module and the article describes how to register the device with TTN (using ABP instead of OTAA). The author’s github repository gives some hints on the used LoRaWAN stack and RFM95W library: radio-mailbox/03_lora_test/lib at master · jamct/radio-mailbox · GitHub
There are also some schematics: radio-mailbox/00_circuit diagram/briefkastensensor.sch at master · jamct/radio-mailbox · GitHub
So I don’t know if a full LoRaWAN implementation is possible when using such a RFM95W module.
It’s an issue of software (and MCU memory resources to support it) not of the radio hardware, which would be fine for LoRaWAN if driven by a complete LoRaWAN software stack.
The link you shared makes it clear their software is drastically short of correctly implementing LoRaWAN. That software must not be used to attempt to interact with TTN as doing so will cause problems by wasting network bandwidth on repeatedly ignored configuration downlinks - jamming things up as much if not more so for other users as for the person actually trying to get their incomplete system reporting data.
Have lid, only wake on microswitch interrupt, battery life > 10 years.
Waking a bit after the switch to try the optics would be good if you can do a meaningful optical test in isolation.
If the optical test needs to be more of comparing the before vs. after internal reflection then you need a “before” which implies either some kind of letter-carrier proximity detection (“about to open the door”) or long period polling.
For an enclosed space with a decent lid there should be a base line value that can be established at startup and maybe periodically updated.
But with a switch on the lid and some other sensor, there should be plenty of time to read the level as the lid is being opened and then after to compare.
Alternatively, unless you have a clutch of naughty children in the area, you could just see how many false positives you get from lid openings but nothing being left.
just imagine what would happen if someone stuffed a blinky bike light in there
1 Like
Attention, the project from Heise is a little buggy… 
It has any bugs that must be cleared before it will work.
And with the ATTiny84 you will have not enough memory and power to implement an LMIC. They use ABP.
They don’t even use ABP correctly.
They lazily implement just a tiny fraction of LoRaWAN. Doing that on TTN is prohibited, nodes must completely implement LoRaWAN, regardless if they chose a complete implementation of ABP, or preferably a complete implementation of OTAA.