Yea, but his point was that GET requests should be idempotent.. when that's not the important part of GET. That's why I used the example of GET /door/open, because that is idempotent, but it's still gross - it's causing a state change from a GET request while still being idempotent.
GET being idempotent is not the issue the author was dealing with. State change from a GET is the real issue.
He mentions later in the thread that he doesn't have a sensor to indicate door position, which is going to kill this project and absolutely prevents an idempotent approach. There are a bunch of ways to approach this, most of which are patented by Chamberlain, which is the specific reason you don't find many garage automation solutions sold as a bundle in the US.
Typical bolt-on solutions would be a range finder pointing down from the ceiling near the door which can tell if the door is obstructing it, a tilt sensor mounted to the top door panel, or limit switches on the carriage way/tracks. With a door position sensor in place a simple momentary-contact dry relay can be used to trigger door motion.
I wasn't looking forward to running cable for sensors (I need two reed switches per door, as the doors can stop half-open). The D1s are at the back of the garage, so maybe 8m of cable per switch and two doors = 30-ish metres of cable? (90 feet?)
Range finder seems like the best idea. I was thinking of mounting it on the door motor and pointing horizontally down the track at a reflector attached to the chain/handle.
I love the idea of putting a D1 in the car. Thanks for the link!
You can get commercial Z-Wave tilt sensors for approx ~20USD a piece that will last a year or two on a single battery. With those you can mount them directly to the door (because wireless) but obviously you need a Z-Wave radio on your automation platform for that to work.
In either event, are you sure you need two sensors per door? The garage door can stop at any point, but (to my thinking) it's still only open or closed. If it's open by only a bit, open half way, mostly open, etc... it's all open in my system, meaning someone can get in or out if they want. So limit switches (or whatever) at the closed position can tell you if it's all the way closed or "not closed", which is suitable for automation purposes.
My opener runs a tiny little garage door in parallel with the big door in front of my garage, and monitors the position of the little garage door with simple switches. This is all in the plastic housing that holds the motor. If yours is the same, you might be able to steal the same signal.
Sadly, the little garage door doesn't look like a dollhouse garage door; that'd be too cool. It looks like a wire on a track.
Why not simply have your webserver remember what state the door _should_ be in? Maybe don't rely on that from a security standpoint (eg. GET /garage/status => "closed, everything is secure"), but I suspect it would work for most situations.
It's clarified in the next line.
> "The point is, don’t split your game protocol across UDP and TCP."
There is always going to be data transmitted other than the game protocol. Most likely that is going to be limited and not at the same time as real time data is being transmitted.
If you're brave it looks like you can replace it in only 5 steps. The caveat being that those 5 steps look very difficult, and in some cases require special tools.
I didn't downvote your top comment, and miss phones with actual keyboards, but Google Pixel and Samsung Galaxy aren't the only phone brands out there. 5" devices still exist. Devices with replaceable batteries still exist. Devices you easily can install custom ROMs on to not rely on the vendor for updates still exist. It's quite possible the combination you like isn't out there, but it's not total monoculture yet.
Samsung hardware + custom ROMs are a path I took in the past (with the S4 Active, which by the way was waterproof and had a replaceable battery, but somehow never achieved tremendous popularity).
But yeah, it's something worth thinking about. The major appeal of a phone like the Pixel is less the hardware than the vanilla aspect of the Android OS.
All another hardware vendor has to do is attempt to stay up to date, and minimize their own bloatware if that's a bottleneck in their time allocation allotment. I'm surprised no one sees that a lot of Android users clamor for a vanilla, up-to-date Android OS phone.
