Because we don’t expect the use of the ISM unlicensed band to be for our own exclusive use so we expect a level of packet loss due to anything from a dodgy microwave being used for 20 minutes at lunch time or a big bag of water with meat wrapper having a fag whilst leaning up against the sensor housing five times a day. It’s transmitted in the blind, anything else could be in the airwaves at the time and there’s no handshaking or acknowledgement.
If the door is within 2 or 300m, then the NRF24L01 is pretty good for a ‘reliable’ transmission. If you want something shockingly bad, try ASK 433MHz! If you have power, maybe WiFi on a narrow beam antenna. Or a line of sight laser. Or maroon flares.
Before I type the following, if you really really need to know if a door is open, closed or in the process thereof, LoRaWAN is not a good fit but can work.
For the more important uplinks, my devices use a smaller payload, more frequently whilst awaiting a downlink that is initiated by my application server to acknowledge that “the system” is on the case.
For the rarest of circumstances where only LoRaWAN is an appropriate radio system, ie lots of very small battery driven sensors over a distributed area that are mostly ticking over phoning home every few hours until something very bad happens that at least two or three sensors will be triggered on, then they use a confirmed uplink and keep going until they get that confirmation from the gateway, then revert to the a pattern of uplinks with one in X being confirmed, until it gets the back-end acknowledgement.
However, the backend database usually predicts the forthcoming moment of doom based on readings thus far. It can also spot trends and send a downlink to increase the uplink frequency so that data arrives more frequently, thus ironing out some of the dropped packets.
The only time I’ve seen a device go in to full Blue Light Defcon 1 mode was a water trough when on a hot day a pile of horses decided to drink it dry in the morning. They then went on to the next trough, but the device doesn’t have any knowledge of its peers, so whilst no horses went thirsty, it just knew it had gone from enough to empty. As I said, usually the backend system can see the trend and give a prediction of how long before refill time. At some point I may link in weather forecasts to see if that helps plus some mandatory Machine Learning once I have time to play.
We (the boss & I) came to all of this via security systems - security, fire, access control, CCTV etc - so I have a pretty good idea of ways of monitoring a door remotely and it’s all about levels of certitude. I can bypass most security systems or sensors but for 99% of situations, a reed sensor + 120dB siren will do the job, but even then, a can of pepper spray will always persuade you to turn off the alarm for me. So you need to fit the monitoring system to what you are protecting.
I guess the TL;DR version is, send status “all good, I haven’t been stolen, battery level is X” reports every 60 minutes and then if the sensor is triggered, two byte packets on a different port in quick order - for EU on SF7 that’s one every 5 seconds on the 1% duty cycle (bit over the top) or one every two minutes on FUP but that’s spread over an hour so you could do once every 15 seconds. But reality is you just need to send with confirmed and then a normal uplink to get the backend acknowledgement about 10 seconds later and that’s it, alerted.
Now your next problem is, is your phone in service for that all important SMS? For a small fee I can arrange a satellite pager and modify it with a big toe fitted taser module to ensure you wake up.