Show HN: Raspberry Pi garage door opener
github.comI'm not going to point out the big things wrong with this project, because someone might think "oh, if I just fix those things I'm good". I will say I think it's the worst garage door opener project I've seen on hackernews yet. Nothing wrong with messing around with motors in the workshop but the author of this one should keep his project away from other human beings. Probably pets too.
Here's the CPSC page on garage door openers: https://www.cpsc.gov/Regulations-Laws--Standards/Voluntary-S...
The pdf "Update of Automatic Garage Door and Garage Door Openers Entrapment Incidents. October 7, 2003" is a good introduction to the real, not internet-smart-guy-hypothetical, hazards of automatic door operation. It includes a summary of every entrapment incident found by the CPSC from 1982-2003.
The UL standard for openers UL325 is incorporated more or less verbatim into the mandatory standard 16 CFR Part 1211: https://www.law.cornell.edu/cfr/text/16/part-1211/subpart-A Have fun. This is the standard that an opener that retails for $99 on sale in the US has been engineered to meet. European and other international standards differ in particulars but are quite similar.
No, you will not accidentally meet real-world safety standards with your project by dint of your sterling virtue, high intelligence, wisdom in the ways of the world, and impeccable engineering skills. Nor will you do so by adding a couple more features. Safety is the result of deliberate processes.
I briefly took a look at the page and checked out the comments and thought you were being a total buzzkill on a cool toy project until I went back and actually looked at the schematic.
This is project taking complete control over the motor that opens and closes the door and NOT using the simple "throw a relay on the door opener" trick that you usually see (ex: https://cdn.instructables.com/F9V/T9JH/I9YBZHM7/F9VT9JHI9YBZ...).
This project is unnecessarily dangerous for such a simple application.
I'll happily be a buzzkill and say don't do that either (outside of your basement garage door opener laboratory) but it's not nearly as egregious.
The 'throw a relay on the door opener' is doing exactly the same thing hitting the interior button to open the door. It sends the same signal to the motors and doesn't bypass any of the load limiting or safety sensors. Those are basically safe.
Those projects can be made safe, but they generally don't mitigate the hazards that compliance with this section will: https://www.law.cornell.edu/cfr/text/16/1211.14 They are not the same thing as a human pressing the button.
Those are a bit overkill, I've not had any garage door that beeped for opening for remotes for example and that's a similar distance of triggered by someone not in the immediate area. They should be safe based just on the break sensors and current limiting.
You are absolutely correct. I have no idea when this site became this way, but a lot of the responses here are disappointing. I can easily close my garage door from well outside of sight range with the regular remote. I can set the wifi one to have even less range by requiring me to be on the same wifi network. There is very little downside to this for my use case.
The standards that require MyQ to make earsplitting noises for seconds before moving just cause headaches.
Those are the industry requirements written by people with understanding of the hazards of running a garage door opener out of line-of-sight of the door. Read them carefully. There are reasons for each of them. Think hard about it.
Remotes also operate differently than your wall button. Did you know that?
Those are industry requirements for garage door openers being sold/used.
The project above is an open source prototype and by no means a product that consumers are expected to buy/use as is.
It's usually good to at least look at the requirements to see what kind of problems can come up.
DIY projects get a load of leeway but this one is actively dangerous and missing really important safety features outside of the remote operation stuff in this thread. If OP is lucky it'll be the garage door instead of an arm or their car because there's no break beam or current monitoring so the motor will happily pin and crush someone unless it stalls out.
Does the project clearly state so? I think such lack of warning is the point here. Note that a warning should include an indication of consequences.
The current disclaimer in the readme just points to electric shock. Not to the wealth of known hazards from malfunctioning electric garage openers, referenced further up in the thread.
I prefer to use BLE microcontrollers rather than real networking because it basically makes a better and more secure remote control rather than opening folks up to this danger.
I think very few people plan to open their garage door from across the continent with these projects
>I think it's the worst garage door opener project I've seen on hackernews yet.
Would you feel encouraged or inspired if someone said this to you?
For example, instead of saying the quote above, you could have as easily said “I think this garage door opener project has a lot of opportunity for improvement”.
Mindset goes a long way, and it might just help make a friend or two along the way.
You are correct. I intended to discourage the poster. Any "opportunity for improvement" could be misinterpreted as "just fix this one thing".
Are you selling garage doors?
I did a similar project at my home & I dare say it is safer, though technically much uglier. It consists of a Raspberry Pi with a PiFace Digital board (with relays). The relays don't drive the motor directly: it "pushes" (shorts/connects) the manual open/close button on the garage door's system board.
Yeah that’s the right way to do this.
I just added your remark as an issue to the submitter's repo:
Yeah I thought this was going to be a page about controlling an existing garage door opener via a Raspberry Pi.
This is nuts.
I will say this. Having seen garage door go down without a warning, I would think twice before attempting it in such a haphazard way. Nothing wrong with a little hacking, but this project seems to be asking for trouble.
> No, you will not accidentally meet real-world safety standards with your project by dint of your sterling virtue, high intelligence, wisdom in the ways of the world, and impeccable engineering skills. Nor will you do so by adding a couple more features. Safety is the result of deliberate processes.
This is unnecessary condescending snark that I hope we see less of on HN. Everyone should be open to criticism, but how does that encourage the inventor?
There is no invention here, and nothing to encourage. Electrically operated doors date from the 19th century, and we have over 100 years of understanding of their hazards.
> nothing to encourage
Absolutely there is. You and I both agree we should encourage them to learn properly, experiment responsibly and proceed with safety in mind.
> There is no invention
I regret that you ever saw the word "inventor" and couldn't think past it. {Creator, engineer, maker, hacker, killer} Pick whatever word it takes for you to ignore the noun and focus on the idea and better way forward.
Indeed... the voting patterns in this thread are amazingly disappointing to me. This is hacker news not discourage and insult you for your mistakes news.
I think that you will find your opinions much easier to get across to a developer if delivered in terms that are much less aggressive. Anyone doing actual work will find your approach rude at best.
I started to think I was a luddite to keep a several decade old remote in my car for wireless garage door control.
Calm down, please. It's "experimental". No sane person is actually going to use this.
>>No sane person is actually going to use this.
What makes you so sure?? I see people using such "experimental" devices all the time. Unless you tell someone explicitly why it's a bad idea they won't know.
Related to "what raspberry pi projects can I start?"
For people that are interested in raspberry pi projects. I compiled a list, mostly for myself, but if it is semi-useful for anyone else, I'd consider that a win. I scoured HN and searched on YouTube, Google and thought of my own ideas to find the rpi projects that fascinated me.
https://docs.google.com/document/d/1xT6-vN4sFnRLMOdj9wC4_ESW...
I'll put this project on there as well under the category "smart home". While the concerns are justified, such as insurance issues and fire hazards, I find it a cool use of what one can do with cheap hardware.
Thanks, I have three of these things hanging out in my desk drawer (and two more that run a NAS and Pi Hole). This weekend's project.
Really cool, thanks for adding and sharing ;)
This is lacking some very critical safety systems such as breakbeam detection (someone walks into the path of a closing door), endstops (the system unexpectedly travels to the end of the track), torque/motor stall monitoring (aka crushing someone to death), and door speed monitor (the door starts moving faster than the motors are moving it)
Exactly, I was looking at the schematic and my jaw dropped when I saw it was connected directly to a mains motor.
I want to say cool project, because I love home automation and have done a fair bit in my own home (though mostly just lights...). But having recently experienced a failure with my own garage door opener that destroyed the door and could have seriously injured a person, I think I'd be reluctant to completely homebrew my own solution.
It's a cool project, but for these kind of things I'd rather use a Shelly1. Runs locally, can easily be flashed with Tasmota firmware and it connects to my Home Assistant instance. This thing has never failed me and it's only $15, way cheaper than a Pi (keep the RBPi as your Home Assistant server!)
Or an ESP8266, using MQTT to "press" buttons on a standard garage door remote control through a relay module. I uploaded mine here: https://imgur.com/a/l2wt40w (green and blue are ground and 5V, gray and white are the pulses to the relays).
This is great. Question - why did you use the relays and not just the GPIO pins on the ESP to short circuit the contact on the remote for a brief moment?
You can't use GPIO pins to short 2 contacts together.
The best you can do is apply voltage to the contacts (which might be workable, depending on how the remote is designed).
To short the contacts you need either a relay or a transistor.
Assuming one of the contacts is connected to either ground or Vcc, one thing you can do is connect a GPIO pin to the other contact. Then when the GPIO is made an input the switch is "open", to close it you first write the value the other contact was connected to, and then you make the GPIO an output. Whether this works depends on the current that is sinked by the remote. This was my plan initially but then I went with the relays.
Ah yes, of course. Perhaps a transistor could work as well for low voltage?
Yes but I wasn't too comfortable with hacking the remote control because I wasn't sure if the button shorted the two contacts towards Vcc or ground (so if I needed an NMOS or PMOS). My knowledge of electronics is super minimal, I can read schematics, design simple circuits, size resistors, etc. but reverse engineering is beyond my level.
Also I used this remote control only because one of the switches was broken, I didn't have a spare one so I couldn't afford breaking it.
An optocoupler would be better but I figured maybe one day I will repurpose the relay shields for something else, or unsolder the relays. Actually my next project involves both optocouplers (for efficient 12V->3.3V conversion) and relays to drive AC but I will probably have a PCB manufactured for that one!
Yes, though you will need to determine whether it should be pull up or pull down, and to what voltage level. And make sure not to provide it with too high a load (too low resistance), or too high a voltage, which may damage the circuit. Since the voltage levels might be different from your microcontroller, so I would probably recommend an optocoupler to simplify the interfacing. Gives the isolation of a relay but without the mechanical operation and size of one.
Yep, should work fine since you only need current flow in one direction!
I second this. Pi is well suited for HA if you don't do have database stuff. And the Shelly allows to still keep manual controls in case your automation is broken.
Although I've grown cautious of products like Shelly which use Wifi as they will become obsolete once their Wifi security protocol becomes broken (like WEP en WPA). But then again the same probably goes for more expensive Zigbee and Zwave devices.
My WiFi-connected IOT devices run on a separate network, with outgoing connections disabled, but that's more out of a privacy concern.
I'm a big fan of IOT and home automation, with one exception: door locks. I wouldn't trust any electronic device with my door lock. There's just so much more that can go wrong, both from a technical and a security standpoint. Also, electronic door locks aren't THAT more convenient than my physical house key.
With locks it's kinda reverse that a homebrew solution might actually be more secure than a commercial one (consumer grade at least). Mostly due to security by obscurity. The average thief won't take the time to reverse engineer your lock solution but just pick the next best break-in option which would be smashing a window or breaking the lock/frame. (Unless of course you have really dedicated enemies that want to specifically get something, but then no solution would be perfect. They will just bash your door in with an axe). But a thief might scan for Bluetooth signatures of known broken lock systems and just do drive by brake ins that way.
I'm thinking of building a elektronic lock solution myself because it would actually increase security for me. As currently I often neglect to lock the doors when going to the back of the yard. Mostly because I don't have the key on me. And my kids are at an age that they will still neglect it for many years. A quick drive-by thief could be in and out in no time. An electric lock with a rfid and keypad would be a proper solution as it always locks when you close the door and are never locked out (unless the power fails but then you use a backup key stored somewhere safe).
An electronic lock doesn't have to be impenetrable, just take more than 5 minutes to break into. This is about as long as a determined thief might spend picking/breaking your regular lock before they're in or they move on to the next target. If you add a bit of obscurity in the mix you could be just as safe. A smartlock that looks like a regular lock, or has all the "smart components" on the inside of the door (like smart bolt-on key turners) would not stand out.
I have a story for you. You see my daughter had hard time turning the key in the old lock. Somebody else had to open the door for her all the time when she was coming home from nearby playground. Even she had her own key she was lacking physical power to turn the key.
So my solution was to buy an electromagnetic lock, which also could be opened by key in case of power outage. And I did exactly this - an RPi was in charge of opening the door via my private WiFi network so when my daughter was coming home, she was connecting her smartphone to my WiFi, launch an app I also wrote and used that to open the door.
Now the funny thing is that the electromagnetic lock was so sensitive that it required a lot less power to open it via its mechanical key so she ended using that most of the time, only in rare occasions of a new friend she was showing off that she is able to open the door via phone.
Thanks for sharing! Will try it out ;)
A RPi Zero W is only $10 where I live and sometimes is on sale for less.
As someone who has built products with a Raspberry Pi, I'm not sure I would bet on a WIFI connection.
I can almost guarantee you that you will sit in your car and scream bloody murder because the WIFI ist not connecting.
My products had to work with a lot of other networks around and were built on a Model 3 B, maybe it has improved since then.
Sadly I can't point you into the direction of solutions because we just switched to Ethernet.
Some kind of LoRa radio would do well. This 433 mhz one would have long range with a bidirectional link.
Haven't heard of LoRa before - is it some kind of alternative to zigbee?
It has been presented to me as an alternative to GSM. It's short for Long Range. They marketed it as a product for smart city, not smart home.
But of course that doesn't mean you can't use it that way.
latest ones seem much more stable. No issues so far. v >= 3b+
Cool. I have been thinking about this myself recently, and I had a different approach in mind. If you already have a remote (which I suppose is mostly the case with garage doors), why not integrate with the remote directly?
I.e. clone an additional remote, then integrate with the buttons from a micro-controller to open/close. In addition, have some kind of way of detecting whether the door is open or closed, so I suppose the remote can be placed near the motor.
That way you can also easily integrate into your house's alarm system later on if need be, as it's most likely linked to your remote.
An easier way to achieve this using a raspberry pi would be to simply have the pi press the right button on the garage remote. I took a pass at this a few years ago. Compared to messing with larger electronics, it’s a much easier setup.
https://www.heyraviteja.com/post/weekend-projects/open-garag...
There are direct hookups on the back of basically every garage door opener for connecting wall switches you could use too to make it even simpler.
Would you need extra electrical components? The cool thing with the garage remote approach is that you don’t need any extra electronics, just plain microcontroller.
Just a simple relay between the contacts.
I love these types of projects. It is not rocket science, nor anyhow complicated to solve and from security standpoint way better than any off the shelf solution. Think about it: you grant access to a random company, with people working there you do not know, security standards out of your control, and if they decide to change the product you simply have to deal with it.
I did a similar solution a while ago, documented all the steps to replicate such setup: https://www.sascha-curth.de/projekte/004_Garagentor.html
I wrote it in german, but chrome/google translate is tested for English, Spanish and Portuguese. And comments/remarks are welcome via github issues.
I'd recommend driving a FET or two to connect at the push button(s) (i.e. GPIO is "pushing the button") rather than the relay board to drive the motor. Not only is jumping the switch(es) more simple, you also stay on the low voltage side of things and any safeties built in would still be present.
ETA: by push buttons, I mean the "normal" garage door buttons that would open and close the door (typically on a wall in the garage.) these typically use some low power, e.g. 12-20V. And the safeties the manufacturer would have built in would still work as it'd be as if you were pressing the manufacturer's open/close button, but remotely.
There's no safeties built in according to their schematic they're directly spinning the motor at full speed with no current monitoring or feedback to the actual position of the door.
Exactly. What I'm saying is they should NOT be driving the motor directly like they've drawn up but instead, they should be "pressing the button via GPIO" on the real door opener attached to the garage wall.
Don't commercial garage door openers have safety mechanisms to cut out the motor if there is a blockage. e.q. if someone gets caught under the door they won't get killed by the motor still trying to close the door but will rather cut out
They do, check the comments the UI has some protection already built in. The rest are feature requests.
Garage door opener using raspberry pi and web technologies.
Features:
- Web interface with multiple user accounts. - React/Material UI front end. - NodeJS backend with registration/login flows.
.. all data stored on SD card and lost during one of power outages / if someone bumps the cable / if it gets too hot in the summer
Not sure this actually happens. In practice.
A friend works at an oil company, and they have dozens of rpis deployed on offshore rigs, and in land rigs in the middle east. They are working in pretty harsh conditions, with high salinity, sand in the air, high vibrations, very low temps, very high temps... and yet over the 6 years they have been running, not 1 has had a fault.
All use SD cards, and they haven't been glued in or secured in any way.
At this point, the RPi SD-card fault thing is becoming a meme.
Not my experience with commodity SD card, power supply and stock settings of Raspbian. They must be using some "secret sauce" to make them run 6 years without outages. I would suspect some industrial grade SD card (SLC or at least AMLC), high quality power supply (e.g. UPS with surge protection) and also some way to limit writes on the SD-card.
Commodity SD cards - there's your problem. It's not a camera you need to buy industrial grade to get 0.5-1M write cycles.
Just bought industrial grade SD cards for Siemens PLCs the other day, almost $2k for 32 gig and due to certification for safety only good for ten years regardless of condition/use.
Equivelents spec cards without the magic S word on them are still around $800.
They are actually a different kind of memory used, so I guess not manufactured in same consumer number quantities.
I always liked the look of something like puppy Linux that loaded to ram, pretty sure most Linux variants allow this as an option, that would potentially make use of consumer grade palletable.
I have an original RPi in my parents garage in Arizona that checks if the garage door is open and sends a notification if it’s left open too long. It’s been there a few years now, survived the hot summers just fine. Using an ordinary SanDisk SD card and a decent quality phone charger for power. Occasionally it locks up and my parents unplug it and plug it back in and it boots fine.
Any disk-IO heavy application will brick a card in record time. I worked on a lot of Pi-based systems at my last job (long term time-lapse photography) and we learned quickly to:
1. Buy high quality SD cards
2. Remove as much disk-IO as possible, using an external USB stick for raw data storage, logs, swap, etc
3. If you really need to make it stable, make the OS read-only
You mentioned USB sticks, but I just assumed they used the same type of flash memory that SD cards use?
Aside from USB sticks, any ideas on alternative storage suitable for RPis (something small)? I know you can get eMMC modules that fit into the SD card slot, but I would have guessed they'd have the same issue with writes.
They are running stock Raspbian. For SD cards, they are using a mix of SanDisk, Kingston and others - consumer versions.
They are indeed using UPS', and the workloads naturally have a low write load.
That's nuts. I had to replace some old Cisco media players that we used as digital schedule boards outside of ~20 classrooms. The Cisco players were quite old and only needed to load a webpage that pulled schedule info from elsewhere and displayed it in the proper format.
I decided to do this with RPi and went through several revisions as I learned/relearned a lot about Linux. The first version was built on full Raspbian and added a basic server listening on some port or another so I could remotely reboot the things by clicking links on a simple website I put together. That build would usually crap out after a few months and the Pis would stop booting fully from the Sandisk MicroSD cards.
Most recent rev was built from the "Lite" version of Raspbian as I was looking to stay slim and have less stuff to update/run in the background/cause issues with the basic operation of a device that only needed to boot, load Chromium, and open a webpage defined in the startup script.
Those have been a lot more stable (no more reimaging a card here and there every month or two) but they still occasionally crap out and a reimage is the only option (maybe once every 6-8 months). This is in an air conditioned building with stable power, wired LAN connection, and fast SD cards. I can't imagine they would be even this reliable running all the time in any sort of "hostile" environment or even using wireless networking.
I looked into network boot but didn't really have the time or resources to set it all up on the school's network.
Is the OS perhaps booting in readonly mode? My experience with the first and second gen pi was of frequent data corruption. I have the later models, but i have hardly used them, so cant tell.
The problem ia not vibration or heat, it is power off while data is being written.
The default rpi os writes to disk all the time, there is even syslog with periodic messages. I bet your oil company uses read-only root, or at least a customized os which does not log things unless it has to.
Nope, it's stock Raspbian.
I mentioned in another comment though, that the particular workload doesn't result in many writes.
I've have first hand experience with a failure or two. I'd bet the SD card failure rates depend mostly on write load.
Optional Firebase integration is a potential feature ;)
So much for this:
> Works locally only, via WLAN (it's a feature, not a bug!)
Yeap, the opposite of all the IoT solutions. This can be again an optional feature, preferred for security
You can use a usb stick instead. Are these particularly "hot summer" sensitive?
One of my first projects with the gen 1 raspberry pi in 2013 was controlling my garage door opener by pulsing a optocoupler and that could be triggered via a simple http endpoint that would run a out script It worked well , but didn't quite pass the WAF. So switched to a commercial product that had a mobile app. (zwave/Samsung smart things)
Might as well show off my own attempt from high school :)
Nice, thanks for adding them
Cool project. I built a couple myself (albeit not with a Pi, but with some Wemos D1) and can share a few lessons learned.
First of all, safeties. I was lucky to add my work to existing motorized garage doors - which already came with enough sensors, but since you are providing everything including the motor, these should be in from the very start, or in any accident you'd be held liable. Actually you may even be held liable if someone implements it from your github repo and then has an accident. I know you have a disclaimer, but I wouldn't rule out being sued.
You want a sensor which detects any anomalous power draw in the motor and immediately cuts off power. Something as simple as an ACS712 (follow guides for reading an inductive load though!) which is a couple bucks (or less if you buy a bucket from China). The motor may come with built in safeties if it's meant for a garage, but this is something I'd still consider.
You will want not only a sensor but also a couple emergency buttons on both sides of the door which instantly stop all movement. While you're there, activating a couple very visible flashing LEDs for a few seconds before you start any movement is also a good safety precaution. You have 2 relays which could due to a bug or other unexpected circumstance be energized at the same time - Depending on the motor this could cause a fire, or fry your relay board/Pi. I would use one relay with its NO contact going to the DOWN motor pin, and the NC going to the UP motor pin, and connect it in series with the other relay which cuts all power. This way it's not possible to energize both in any case (beware: even abruptly switching directions may ruin a motor - always cut power first, THEN toggle direction, THEN provide power again)
Happy to discuss a few more points if you feel like.
As someone who owns a normal Liftmaster garage door opener that malfunctioned last week and destroyed the door because it didn't adequately sense that the door was blocked, I have to say I don't think I'd want to homebrew my own opener. Especially not with kids in the house.
Very cool project, I've been wanting to do something with my Raspberry Pi as well.
I mainly wanted to focus on turning my AC units on and off. I assume I'll need some sort of IR transmitter, and possibly a receiver to understand the signals the remote is sending.
If they use IR remotes, I imagine you could plug in a network connected Pi with a USB IR blaster next to each AC unit. Then stick the IR emitter LED on the little window where the IR receiver is on the AC unit.
Then it's just a matter of capturing the remote codes and setting up a way to remotely command a given Pi to send that pattern of pulses out of its IR emitter.
edit: I just did a quick search and Sparkfun sell WiFi IR blaster boards for $20. I'd imagine you could find cheaper ones on Aliexpress or other places where you typically find cheap electronics. This would probably be simpler to set up versus a Pi with less things to break since it's not booting a "full" general purpose OS.
I can't speak to the quality of this yet, but I just bought https://www.amazon.com/gp/product/B016D5L5KE/ref=ppx_yo_dt_b... kit to dork around with myself. It comes with an IR transmitter and a whole host of other stuff to play with.
That said, I do love adafruit and sparkfun for most purchases. My bank account doesn't, but I certainly do.
Oh, nice! I hadn't thought to look for multi-part kits like that but the next time I am looking for a sensor or emitter or whatever, I might check some of these kits if only because "more stuff!!"
I am the same with Adafruit et al. Their stuff is tested, easier to exchange/return if broken, often ship quickly since it's domestic to the US, etc. But when I need a bunch of something I tend to order more direct/bulk. My early LED strip projects were fine with a meter or two of "Neopixels" but when I wanted many many meters for bigger stuff, it was time to order reels from Ali Express. Shipping was slower, but even if I paid an extra $20 for fast shipping, it was much, much less than ordering from Adafruit. I just had to be aware that some of this stuff may not work and returning will be next to impossible. Luckily I had no issues.
Yep, that's my thought processes too; I usually go to Adafruit, and if they don't have it, I go to Sparkfun, and if they don't have it AND I know precisely what I want, Digikey, and then if all else fails, I go to amazon and buy a pack of "everythings" and see what I get.
Everything I've been doing is stepper motor related, and I didn't know what else I'd even use 3/4 of those sensors on, but for 25$ or whatever I figured I could buy them, try them, and see what comes out of it. They're like a flight of microbrews or something; just enough to tease me and get me started so I know what I actually want :D
I looked into the IR blasters before, was wondering if they're strong enough to transmit to multiple targets.
I've previously written a Telegram bot, so was thinking to reuse some of that.
Very nice! I only have one question: I see there are pull-up resistors connected to push buttons. Aren't there built-in pullups on RPi GPIOs? Maybe you can enable them and use fewer elements on the breadboard.
Can confirm that the internal pull up/down are there and most libraries can enable them (alternatively this can be done manually via terminal after each restart).
Is there anywhere you can get hardware that can interface with HomeLink as a receiver, like to signal an opener like this, or to trigger smart home actions like turn on the lights?
I recently replaced my physical garage door buttons with arcade push buttons (my kids love it) and I was thinking...."this box could hold a pi".
Really cool. How do you trigger the opening ? Just via the pwa upon entering Wi-Fi range ?
Yeap exactly.
Cool! I did something similar and it was a fun little project.
Yeap, started as a small project, then grew and added proper front end with user signup/login flows. user roles admin/non-admin. Built progressive web app. And planning to add more elements. Camera for live streaming etc.
Do you have a repo to share?