The unbearable fussiness of the smart home

Same. I'm someone that built a cellphone from parts and programmed my own phone OS, so I get the tinkering for the sake of tinkering aspect, but I can't connect with the need to automate all these workflows in my house. Whenever someone describes how much convenience these workflows provide, all I can think of is how big and complicated their homes must be.

I'd rather have a 2-way light switch at either end of the hallway and hit a switch when I walk down it, rather than program in every exception like "turn on the hall light when it detects motion unless it's 3 am and I'm walking to the bathroom to pee, or if it's 3pm and my girlfriend is napping on the sofa next to the hall and I don't want to turn on a light and wake her, also ignore cats triggering the motion detectors." My small apartment with regular old deterministic switches is fine. I had a Nest once and hated it. At least for me, the ideal temperature for a room must be a very subjective and non-rational desire. Sometimes I want to blast the heat, sometimes I want to feel cold, it's probably emotional/psychological on a level that Nest can't model.

I know someone will point out that 100 years ago I would think washing machines sounded ridiculous because I could scrub my clothes by hand easily enough. That might be true, but I would counter that there are diminishing returns on home automation. Indoor lighting was a massive improvement over living by daylight hours. Electricity over gas was a big improvement, but not as big as going from dark to light. Turning lights on with Alexa, to me, sounds like the benefit/cost curve has plateaued.

Just buy Open Source stuff. I recently bought a smart plug from "athom.tech" (on aliexpress) that came with ESPhome. No phoning home. I also had access to the HTTP API in less than 5 minutes.

I could open it and connect more stuff to the GPIO, patch out the annoying LED or do something else with it. Install tasmota instead. It's quite liberating :)

You mean, a standard like Bluetooth Mesh? https://www.bluetooth.com/learn-about-bluetooth/recent-enhan...

There are many factors when choosing your communications layer. Bluetooth Mesh was designed specifically with lighting in mind, so that you can for example ensure that dimming multiple lights simultaneously happens in sync.

I agree, and power negotiation is great.

But things that can use it seem to be expensive. I checked, the chips are fairly cheap; but all the PoE stuff I might use aren't "one per light socket" prices. Plus I'd still like a decent mains relay board that is appropriate to put in a wall - the Shellys' are a good form for this, but I cannot see a similar wired solution (although some Sonos devices get close).

> I have some 433MHz kit, plus a bundle of various arduinos, but (for me) the complexity of getting them to talk back to base has kept me procrastinating for years.

The transmit side is pretty easy. Here's the xmit.ino file from my rain gauge project [1].

The receive side using one of those typical 433 MHz receive modules looks like a complete pain in the ass. I spent a while with the transmitter and receiver both on a breadboard hooked up to my oscilloscope, one channel on the transmit data in signal, one channel on the receiver data out signal, and one channel on the receiver receiver linear out signal.

Triggering on transmit and looking at the receiver output it didn't look too bad. But triggering on receiver output it was terrible. It was almost always outputting a mostly random looking stream of 1s and 0s of variable lengths. You have to watch that and look for things you recognize embedded in it.

Triggering on the linear output was more promising. My understanding is that the way these cheap receivers work is that they automatically adjust the gain until they are seeing something, so when you aren't actually receiving a signal they are just amplifying noise. When you actually are receiving a decent transmission the gain turns down. When that transmission ends the gain goes back up. (This, I've read, is one of the reasons most transmissions start with a long intro pulse before going into the actual bits. It gives the receiver a chance to turn down the gain so that it won't be including a lot of noise in the output).

The linear out signal is analog. It is higher when receiving a strong signal, and lower when receiving a weak signal or ambient noise. So it looks like using the linear out signal to decide when it is worth looking at the digital out to check if your device is being received could considerably cut down the processing needed at the receiver. By adjusting the trigger level on the scope I could get it to usually only trigger when an actual device that I can get a decent signal from was transmitting.

The good news is that you can say "to heck with all that" and cheat like I did. Forget the 433 MHz receive modules. Cheap SDR dongle on the receiving computer, rtl_433 [2] to do all the work of finding and decoding the signals among the noise, and you are all set plus as a bonus you can also see other 433 MHz sensors that happen to be in your area.

PS: if anyone looks at that transmit code and wonders why there is no checksum that is because I haven't gotten around to adding one. It is a tipping rain gauge and according to models I found for my area at my state's department of transportation site at the highest short term (5 minute) intensity that I would expect to see on average once per 100 years it would be tipping at 10 tips a minute. Thus the tip count should be an increasing sequence that when it changes mostly should change by 1, and rarely by more. It is easy to spot when the data is corrupt and so I've not found much need to add a checksum. I'll do that when I add my wind speed and direction sensors).

(Departments of transportation are good places to look for rainfall models for an area because their engineers need them to figure out how much runoff they have to deal with when designing drainage for road projects).

[1] https://pastebin.com/7Aus3U3R

[2] https://github.com/merbanan/rtl_433