Option 2 requires power, which not all doors have. There are wireless doorbells, but perhaps OP doesn't want to have to remember to charge or swap batteries.
While option 1 requires connectivity, which not all doors have. I live in a large apartment block. There is zero phone signal at my front door. WiFi, yes, but I’m not giving some random access to my WiFi network.
My app idea is to tell guests to "Connect to this SSID to knock", and have a way of scanning for new MACs on the network and notifying the door owner... /s
For security of course it'll be an SSID that doesn't connect to anything else, because hey, we care about security. ;-)
Another app is: "connect to this SSID and ping6 2345:0425:2CA1:0000:0000:0567:5673:23b5 to ring doorbell!".
This sounds far too simple for something as complex as dealing with unsolicited attendance notification injections occurring at randomly defined intervals against a primary public<>private security surface.
Particularly when you consider that some of those attendance injections may contain potential threats or unsolicited commercial messaging, or be designed to cause interference with predefined private processes, or even be designed just to consume processor cycles in unnecessary communication processing across the security layer.
While I like your implementation suggestion it feels a little lightweight for something this important. Please revisit the scope and come back with a more fully fleshed out project proposal.
