Home Assistant does great at tying all kinds of things together.
People had a habit of leaving the basement lights on here. Now they turn themselves off after a timer expires, and also whenever nobody's home. Using HA and a cheap Shelly relay (chosen for form factor), I was able to do this while retaining the existing lighting circuits, light switch, and the lights themselves.
It works perfectly, is completely local, and the end-user UI is completely natural. Toggle the same plain-Jane light switch that has always been there at the top of the basement stairs and the lights change state. (UI doesn't get more intuitive than that.)
Or: Fans. This house has a good furnace and central aircon, but the ductwork doesn't really extend upstairs. By default, this makes the upstairs-parts very hot in the summer and cooler than I'd like in the winter -- even though it's nice downstairs during all seasons.
I fixed that to my satisfaction by putting a fan on the landing that is controlled by an inexpensive smart switch, just to improve circulation. HA runs this show; the fan runs when the HVAC is doing something, and whenever people are home and it is either too hot or too cold upstairs (based on a temperature sensor). It's not a perfect solution, but it's kept the temperatures sane (and provided logging to prove it), it was cheap to implement, and it is cheap to run.
I already had the parts kicking around; it just took software and time.
(The best option for efficiency and comfort is probably installing mini-splits up there, but... sheesh, that's into the realm of orders-of-magnitude more expensive. Maybe some day.)
I put the Shelly relay in a pre-existing junction box in the basement.
Previously, this box worked like this: There were romex cables for power/neutral, lights, and the switch itself all inside of that box. The switch, located elsewhere, interrupted power to the lights. (This isn't necessarily the most-typical arrangement, but it's how it is in the house I've got.)
Currently, the box works like this: We still have romex cables for power/neutral, lights, and the switch itself inside of that box. That part hasn't changed at all. But now the Shelly relay interrupts power to the lights.
Thus, the lights are always controlled by software.
And the light switch? That just provides an input that is acted upon by a software script.
The script (which runs internally within the Shelly relay) only does 3 things:
1. If relay is on and switch toggles, turn relay off.
2. If relay is off and switch toggles, turn relay on.
3. If relay is turned on by any mechanism, start timer, and then turn off after timer expires. (Plus other useful timer mechanics like resets on additional toggling, but you get the idea.)
---
It's easiest to think of a Shelly relay like a replacement for a light switch, but that's kind of a limiting way to think about it because that line of thought strongly implies that it should to be located where the switch is. And while it certainly can be installed that way, in practice it really doesn't have that limitation.
For my unfinished basement, there's no neutral at the light switch location so using a regular smart switch didn't pan out. (I could have added a neutral but that would have meant using more parts and getting into some drywall and paint.)
Instead, there's that neat (who am I kidding, it's a mess) junction box I that described, up on the ceiling where all of the things come together... So that's where I put the relay.
Or: There's a box behind a light fixture (well, there "should" be anyway). Often, this box will have the same functions available inside that my junction box happened to have. Power, neutral, light(s), switch input. A relay can go there.
But many houses do have neutral at the light switch location, so a relay can go there instead. Power/neutral feeds in, power for lights feeds out, with a switch (and/or relay!) in the middle. All in one accessible box on the wall. This matches the easy-to-think-of scenario. (IIRC all new homes are supposed to be this way in the US, but...)
It's (usually!) just a matter of finding the right physical location in which to install the relay.
(Note: None of this is intended to be an exhaustive list of variations. Things can and do get weird with household wiring, and regional variations of what "normal" means can vary quite tremendously.)
My only fear is my HA box will fail and now nothing works. Most likely because I move and forget to tear everything out. Still something I'm interetsed in
So everything I automate has a fallback option that exists outside of HA. My regular light fixtures, with smart bulbs? I can turn those on and off using their light switch in the event that Home Assistant is dead, like I would if they were dumb bulbs. (I seldom use them that way, but I can.)
And my basement lights have their smarts all programmed directly in the Shelly relay. It works without networking or HA or anything else. So while the basement lights are completely software-operated, they aren't dependent upon the relatively giant stack of software and complex hardware that HA brings
As long as the Shelly relay works, then the basement lights also work -- with a timer.
(That relay can fail, but it is is unlikely to fail soon. I don't worry about it any more than I do a major appliance failing: If/when it happens, I'll deal with it. It's easy to take out again.)
Interesting, I had a similar setup with smart bulbs, dumb switches and HA. My experience was that when the bulbs lose connectivity (Zigbee or Wifi in my case) you could maybe still turn them on but they would start flashing like crazy or use different colors (as indicators for their "reconnecting" state). Also Zigbee doesn't really love losing mesh nodes periodically, so turning the bulb completely off using the switch would cause the whole network to fall into broken states that had to be manually fixed from time to time.
None of the bulbs I've had (which have been a pretty wide mixture: Proprietary clown, proprietary local wifi, matter wifi, esphome wifi, zigbee) have that problem.
I just turn them off and back on one time using the switch, and the light bulb's state goes to some variation of "on" within no more than a second or two (maybe not an ideal variation of "on", but good enough to get through a dark hallway). Turn back off with the switch, and it's obviously off. On the next "on" cycle of the switch, it goes back to "on".
And while it is freshly "on", it's trying to reconnect to whatever its programmed mothership is (whether local or afar). This works every time, so far in my experience, as long as that mothership is reachable.
The only time blinkey-mode has been imparted is when I've reset things, which takes rapid iterations of off-on cycling of the light switch. (I test this all the time with the Zigbee bulb in my pantry because the light switch in there sure is convenient. It works fine, even if it has been completely off for hours or days. I just tested it again after pulling the USB zigbee dongle from HA, and the pantry light still worked fine with the switch on the wall.)
I've moved these bulbs and other widgets between houses. No issues (other than renaming things after a move). It's really been OK.
Additional background: For Zigbee in particular, I'm doing that in what is probably the least-preferred, least-effort method: I've got a cheap Chinese CC2531 dev kit that is flashed with different firmware (because that was the cheapest approach ~5 years ago), and I'm using it with ZHA in HA (because that's the easiest approach). All of my Zigbee devices have been buttons or light bulbs, all of those bulbs have been from Sengled, and none of any of them support Zigbee router mode at all. There is no Zigbee "mesh" here to speak of at all, so there's no weird interconnections to break: Endpoints talk directly with the CC2531 and that's that.
Other than some range issues (which were broadly resolved by using an old-school non-3.0 USB extension that I found on Amazon in iMac-esque coloration for a dollar), Zigbee has really been OK for me.
---
But I've been migrating to wifi, anyway. My favorite light bulbs, from Athom, actually come to me with open-source ESPHome already installed...but Matter-wifi light bulbs are often a bit less expensive than those are. (Tradeoffs.)
This migration started on the basis that my old Zigbee bulbs are -- well -- old. They simply don't produce the same quality CRI that even very cheap dumb department store LEDs do these days.
Besides, I've also already built a quite lovely wifi network for my home, wherein I do not care at all about the performance of the 2.4GHz radios at all so they may as well focus their energy on a sea of IoT devices.
I like the idea of having only one set of wireless networking gear to futz with and optimize instead of having multiples of them. (But I'll probably goof around with Matter-Thread, too, if/when that makes sense to me. I'm by no means done tinkering or learning new things.)
Thanks for the response! Refreshing to hear that it can actually work - I think the main difference between your setup and mine might be that I actually needed the mesh because I had bulbs in behind a couple of steel concrete walls. I installed always-on Zigbee outlets thinking that bulbs would route over those but never actually got around to debugging why they didn't.
Currently I'm also mostly on Tasmota-powered Athom bulbs. They work well, but after not powering them on for longer timeframes (presumably after their internal battery or whatever runs out) they forget my wifi and switch to setup.
After these experiences I'll probably go with dumb bulbs and smart switches/relays for our new apartment. Still keeping an eye on the market and open for recommendations though, mainly because I like being able to control light color through HA.
I think you've nailed the key difference for zigbee, indeed. And I'd love to share some first-hand insight about how Zigbee works with either intermediate repeaters or routers scattered around, but I just don't have any to share.
You did remind me of a thing, though: My Athom bulbs, with ESPHome, do have an annoying mode they drop into when their Home Assistant mothership is unavailable. They still work mostly like dumb light bulbs in this state, but they do a periodic blinky-thing (with a cadence in minutes, not seconds) that is annoying until the HA rig comes back.
But since they're running a copy of ESPHome that I compiled locally, that's almost certainly an ESPHome function that I can hack out/turn off/modify/whatever.
I don't have any direct experience with Tasmota. I remember looking into it with some giddiness several years ago (just because hacking on home electronics does that to me), but by the time it came to start actually buying hardware I decided to go in a different direction.
But I don't recall the Athom bulbs, with ESPHome, ever dropping out and not coming back. Even after the last move where some of them were in a box for weeks: If there was any difficulty, it wasn't something that took a lot of steps to resolve. I think I'd remember if it were challenging in some way.
So I'm lead to wonder what mechanism it is that makes your stuff go goofy with Tasmota.
Inside of these things is just a small power supply, an ESP, some MOSFETs and some LEDs. On-device configuration data is stored in flash right alongside the firmware itself. There's no battery, nor any no real-time clock (if the time is useful, it is set over the network).
Athom does publish steps for switching [some of] their hardware back and forth between Tasmota and ESPHome, if that's ever useful to you: https://github.com/athom-tech/athom-configs
---
More broadly, having smart switches and/or dimmers with dumb bulbs does sound appealing. I've got all of the lights in my garage on one smart switch, for instance, and it works well for that environment.
Smart switches would also Grandpa-proof the installation: If a dumb bulb goes out and Grandpa is watching the place, he can just swap it out and things would work fine. (Knowing my own old man, he'd probably use a dusty incandescent bulb that he's had in the glovebox of the car since he stopped to pick it up along the side of an unpaved road somewhere outside of Lincoln Nebraska in 1973...but it'll still work fine.)
But smart switches and relays alike want neutral wires. It's not always straight-forward to integrate them, as I've written extensively about elsewhere here.
And right now, I've got the usual lights in the common areas downstairs set (via the Adaptive Lighting integration) to smoothly adjust their color temperature based on the position of the sun. And I really like that function: I get intense 6000k light during the day that more-or-less emulates the ambient sunlight that comes in through the windows, and a much more serene 3000k light when it's ~dark outside. And nobody has to think about it at all on a day-to-day basis; it Just Works.
This is, quite frankly, pretty glorious to me in ways that I don't think I ever want to give up...so I'm stuck with smart bulbs in lots of places.
I actually didn't try ESPHome yet, thx for mentioning it. That will be my next experiment then. The adaptive lighting also sounds really cool, will try that as well.
Do you know if the Athom bulbs even have some kind of persistent memory that can survive longer timeframes without power?
You can run HA in a Docker container and set it to generate backups periodically. If your virtual box (or the host) dies, spinning up a replacement will take up a few minutes, as long as you still have you have a computer capable of running Docker or Podman.
That is no use if my boss says move to different city - there is a lot to deal with in a short time which leaves no time to tear that stuff out. if the house doesn't work for the new owners the courts will make me pay an electrition to make it work.
HA failing is annoying but not nearly as stressful.
It is my intention that when I move, I move my smart home shit with me.
I keep this in mind as I add smartness. All of it can be reversed to normal-house-status in a few hours, at most -- including a trip or two to the hardware store.
It can go back to what it once was almost as soon as "We're showing the house on Thursday" is uttered by anyone.
(The new owners won't want any of it, anyway. Buying someone else's bespoke smart home is like buying someone else's bespoke race car: It may have been a serious investment in time and money as well as a source of tremendous joy for one person at one point, but for the next guy it's just kind of a nuisance.)
I'm using a Zigbee button from Samjin/Samsung/whoever-that-was which reads temperature, my Nest thermostat (via a convoluted-but-supported path to a remote API), and a couple of Amazon Echo Dot speakers (the integration of which is cursed, but it's easy to set up and usually works).
I was going to try to score some cheap BLE temperature sensors and use the Shelly relay as a gateway to bring those into HA (yeah, it does that too), but then the big mystery ball of tariffs happened and I lost track of that idea.
Same, it's so nice to throw together a yaml that pretty much does exactly what you want, with the only ambiguity being knowing the ins/outs of the pins.
It just makes stuff so easy - I’ve been on an absolute spree lately, and have built out:
Ultrasonic tank & river level monitors, with temperature compensation and a battery fuel gauge - managing to make a 3000mAh battery stretch almost a year. Some of the river monitors use LoRa.
Remote control to stop/start the previously pull-start generator
Gas bottle level monitors
Made the coffee machine dangerous
And my current project is seeing if I can make solar/battery powered LED bulbs that I can hang on trees and use BLE to make them automatically turn on some distance ahead of you as you walk down the long path through the forest, and turn off once you’ve passed.
I only really got started a few months ago, and my approach is far more breadboards, DuPont cables and superglue, because I know damned well that the moment I go “ok I’m done let’s get a PCB” I’ll decide on a modification.
Anyway. I don’t have enough good things to say about ESPHome. I get to save thousands of euros, and have fun at the same time. What’s not to like.
Just wait until Espressif gets some greedy shareholders/or some manager that needs a raise and then suddenly you're paying 30% to get your app into the ESP Store.
ESPHome is owned by the same group as Home Assistant, not Espressif. So Espressif getting greedy would just mean higher prices for their chips (or they could lock down development on their chips, but that seems very unlikely).
ESPHome isn't really Espressif exclusive, there's Beken support already, which most cheap Chinese IoT gadgets use nowadays. And there are 'made for esphome' products which is a safer bet than buying Sonoff and praying the ESP32 inside doesn't have its secure boot bits fused.
I don't like the notion of doing speed control by putting a digipot in series with a motor. It worked because the fan happened to be low enough power but it doesn't seem like the author gave thought to the power handling capability of the digipot. If the fan happened to be beefier he's letting the smoke out with this design.
Plus, this is more complicated than just doing PWM.
Based on the description of the wiring to the motor (24V, GND, POT1, POT2, NC), it doesn't sound like the original setup would have been drawing much power through the pot either -- there's probably something else on the other end of that wire that is doing modulation based on the sense resistance, and the motor is itself drawing power from the 24V line. So while it's true that there should be a check for the allowable limits on the digipot, I don't think it's actually being used to sink much power.
Hey, author here. That's correct. The potentiometer has 5V going through it, with a current range of 30-164μA, which fell within limits of the digipot. I opted to use the digipot instead of my own PWM because something else must be doing PWM closer to the motor, where I didn't want to go modifying.
>Everything joined up via a 2-pin and 5-pin connector on the PCB. From there, it was a straightforward matter of measuring voltages and continuity to work out what connected to what: the 2-pin connector was offering 24V DC. The 5-pin connector was what went off to the motor itself. Two of its pins were passing through the 24V DC and ground directly. Two more pins were connected to the potentiometer. The fifth pin was not connected.
> there's probably something else on the other end of that wire that is doing modulation based on the sense resistance
And it would have been great if that arbitrary assumption had been tested by the OP and the results were documented in the article so that they wouldn't come off as somewhat clueless as to the limitations of their design.. oh well.
These passive aggressive posts are a far worse violation of the HN Guidelines than what they're in reply to almost all of the time - and this is no exception.
No, no they're not. I would much rather people are warned about the guidelines and adhere to them going forward than the opposite and we then just let violations run rampant.
There are a lot of people who read or watch stuff from the Internet and then play with mains voltages without giving a though to how dangerous that is.
See: any craze which uses the high voltage transformers from microwaves
I've been toying with a variant of this project for my Honeywell home air filters. I have one in all my "big" rooms, and I like to keep them running at a low speed most of the day.
But I also have time-of-day energy pricing, and it would be nice to automatically turn off (or at least slow) my air filters during the 5pm-8pm window. This project inspires me to at least look into the feasibility of adding that functionality myself.
Depending on your air filter you might be able to just use a smart plug, I went down a similar route this summer before realizing that mine would remember their power state and settings when powered off.
So now I just have them plugged into a few smart plugs with automations in homeassistant
I would need a device with a physical switch rather than a touch control. Sadly many devices, mine included, have "power was cycled = device is off" logic.
It's been working so well I was actually surprised one night when the dehumidifier in the bedroom turned itself on from the automation (which I have set to do after dark if humidity is higher then 70%).
It had been within tolerance for ages and I just hadn't had to even think about it.
You should, it is very DIYable! I did it and reverse engineered it myself a while back. You dont need to make a custom circuit board if you are fine with losing the touch controls
The digipot is vaguely similar to how a R2R ladder DAC works. There are two resistor values used: R and 2R. The "interesting part" of the circuit has bits x 2R resistors in parallel. One end of each resistor (let's call it input) is connected directly to the digital bit from the PWM sample.
Then there is the series bits x R resistors. The output of each 2R resistor is connected in-between the two resistors that straddle its bit position. So:
Out
|
R
+-2R-bit0
R
+-2R-bit1
...
R
+-2R-bitN
And that's it (apart from pull-up/down resistors)! Due to the way that resistors in series and parallel work, each input step in the ladder provides twice the voltage of the previous if powered: it's base 2 enshrined in a physical object.
These are relatively uncommon because they are highly sensitive to the resistor (and trace) tolerance, but this circuit is my Euler's identity of electronics: it very literally bridges the digital and analog worlds.
I saw the diagram in the original blogpost, laughed, but after a bit of sketching it out I think we're both wrong. R/2R ladders are useful in DACs (and are really cool there) but don't look like they're used in digipot applications.
It seems like actual digipot ICs use the "2^n discrete resistors" approach. The IC used in this project is a MCP4141 which explicitly states in section 5.1 of its datasheet that for 7-bit (8-bit) devices there are 128 (256) resistors in a string between the terminals.
I'm a bit surprised this seems to be the best approach, but with IC manufacturing the joint problems of "a bunch of identical components" and "wiring it all up" are much less of a problem than if you were to wire this up by hand.
I've noticed that some things can make the price suddenly skyrocket. Certain PCB specifications for one (though couldn't name anything in particular off hand). The one thing that caught me by surprise was that if I wanted to have JLCPCB solder the ESP32 for me the cost would jump by more than double, and the PCB would have to be physically larger. Something about their "Economic" vs. "Standard" PCB assembly where, for reasons I'm not clear on, the ESP32 could only be done under the latter. I opted to solder that component myself, of course.
My current record is $19 (including shipping!) for two assembled boards of https://github.com/xobs/soundoff which is a little device that shuts off 5V power to a USB-A port when it detects the PC it's connected to goes to sleep.
This is a very fun project with a corsi-rosenthal filter (a box fan taped to a bunch of normal house filters). To control the fan, you'll have to have some fun with a relay connected to MAINS voltage -- if you dare. The salon power relay hat is a reasonable solution (just remember to get voltage up/on for fail-dead). It's possible to squeeze everything inside of those cheap lasko fans you can get, too, if you want a challenge.
Slightly easier/less mains electrical work required is to just use a smart plug of some sort, and there are multiple options you can put your own firmware on (e.g., Sonoff supports ESPHome).
One caveat about this most people don't know is that most basic fans with a fully mechanical switch always order the speeds from High to Low, so that if you for instance want to turn it on to Low you have to briefly go through High (and Medium). This is on purpose, to briefly supply higher current to the motor for it to start spinning. Some fans might not like it if you start them from an external switch in low, especially larger ones with heavier blades. This also applies to the one in the article, but you can sequence things in software if you have full control of the fan speed, too.
What's odd is that while what you describe is true for fans with a rotary mechanical switch, where you have to physically turn the contacts through "High" to get to "Low", it's also very common for fans with independent speed buttons to put the "High" button next to "Off", with "Low" furthest away. I don't know if that's just a hold-over from rotary switches because people are used to the sequence, or if there's something else mechanical going on inside the switch unit which has the same effect. And on this occasion I'm not taking mine apart to find out.
Hey, author here. There's a line in the digipot datasheet that says the voltage on the A/B/W pins must be within -0.3V to VDD + 0.3V. The fan's line for the wiper pin is 5V, which would fall well outside of that if I gave the digipot's VDD 3.3V.
Fair point, I hadn't thought to consider that aspect of the ESP8266. I mainly opted for the shiny new ESP32-C6 with the idea that I might one day set it up to use Thread instead of WiFi.
That's exactly what I did :) and a convenient thing I realised afterwards is that the push-button function of the rotary encoder gives me the ability to turn the thing on and off with my foot!
I purchased a Phillips fan in a shopping spree. It was hot outside, needed something, did not pay much attention beyond that it worked and was not noisy.
At home my eyebrows went halfway on my forehead seeing that there is a remote and the remote is supposed to be my mobile! Need to download the app for it, connect the fan to the Wifi, but it also had bluetooth for some reason. No way Jose!
Yet, it was so incredibly stupid like 4K zoom camera in a hammer that I had to try. Carefully. Data collection notice in the app shop is not promising, not at all. Location data, ID, I do not remember in full but perhaps contacts too? Unsure, but a lot. Anyway, will not enable access to most, airplane mode on, no bluetooth device in sight, so went ahead and installed the app, router disconnected from the internet, then run it.
First thing: refusing access to location. App: sorry, you cannot use me if I cannot access your location, network, and my mothership. And it stops. Big laugh, delete the whole thing. Leaving feedback for other customers about this incredibly stupid intrusion.
Then I got answer from Phillips! Something along the line: "This is for the best interest of our customers, we need your precise location so we can share personalized pollen and climate data and whatnot, we absolutely must insist this!"
For a fan!
Meanwhile the fan has physical buttons on it, can adjust speed, timer, and the cycle. Not completely useless. However some buttons need two press to register the action once. Beeps twice, does thing once. Likely some interference with The App, need to make sure that I am in the same room with the fan with a warning press and then the real press, or whothef knows what was in the head of these guys when they put this piece of thing together!? But really, are they nuts? Ruining use along pollen data?!
Are we already living the movie Idiocracy when it is about the Phillips product design department?! Did they loose all sense with reality? I am sure they already pushing through some new AI function for this very fan and are sad that mine cannot connect to the mother ship through satellite or something just so the update can be pushed to it learning my breath patterns for optimal fan speed. They are nuts! They are nuts!
> Need to download the app for it, connect the fan to the Wifi, but it also had bluetooth for some reason.
Bluetooth could be there for initial setup.
To connect the fan to WiFi you have to somehow get the WiFi credentials to the fan. There are a few ways to do that.
One of the most common is for the device when it has not yet been set up to make itself available over Bluetooth. The app can then connect to it and give it the WiFi credentials.
Another common way is for the device to create its own WiFi network with a name that the app can somehow recognize. The app can then find that network, connect to it, and use it to talk to the device.
I don't think this is as popular as the Bluetooth method, probably because it used to require that the user go to their network settings and connect to the device's WiFi network. Plus, when they are connected to the device they are not connected to their "real" WiFi which could disrupt other apps.
However, newer Apple and Android mobile operating systems provide ways for applications to change the network connection in the background or with minimal interaction, which makes this method more friendly so maybe it will become more popular.
There also are supposedly some IoT devices that use WPS (WiFi Protected Setup), where you bring the device near your router, press the WPS button on the router, then press the WPS button on the device, and magic happens to add the devide to your network. I've never actually had any device I've bought support this so it is either uncommon or I've just been unlucky.
Anyway, from what I've read Philips has used both the bluetooth method and the access point method on their WiFi products.
The location access is often needed for the app to be able to find the WiFi networks in the neighborhood. This is because that can be used to triangulate your location, so they bundle it in with the same permission (unfortunately, there isn't a very good way to separate this, since it theoretically can be used to locate you and therefore you should let the user know that).
Why does a fan app need to find the WiFi networks? The OS does this, and then serves an internet connection to the app. It doesn't need to know what the available networks are.
I love upgrading simple home appliances with homebrew smarts using ESPHome so that they retain their original interface. I've mostly done lights that are still correctly switched at the original wall switches but up next is my fan and toaster oven! Then to tackle the thermostats.
As low as $10 if you all components are from JLCPCB's basic component library. For this board, more since there are some through-hole components and neither MCP4141 nor ESP32 (nor the buck modules used) are in the basic library.
IMO anything with unnecessary digital interfaces is already down the path.
I have a Vornado fan that I would love to automate with a simple wifi-enabled plug, but due to the digital on/off/speed button, when you cut-off and restore power to the device, it stays off. If it had a dumb analog dial or switch, it would both be fine for normal use, and could be easily, cheaply made "smart."
They do sell wifi-enabled fans; none of them are in a form factor that would fit in my window.
ESPHome and homeassistant have been really great, just like a nice breath of fresh air in a world of cloud saas stuff.
Home Assistant does great at tying all kinds of things together.
People had a habit of leaving the basement lights on here. Now they turn themselves off after a timer expires, and also whenever nobody's home. Using HA and a cheap Shelly relay (chosen for form factor), I was able to do this while retaining the existing lighting circuits, light switch, and the lights themselves.
It works perfectly, is completely local, and the end-user UI is completely natural. Toggle the same plain-Jane light switch that has always been there at the top of the basement stairs and the lights change state. (UI doesn't get more intuitive than that.)
Or: Fans. This house has a good furnace and central aircon, but the ductwork doesn't really extend upstairs. By default, this makes the upstairs-parts very hot in the summer and cooler than I'd like in the winter -- even though it's nice downstairs during all seasons.
I fixed that to my satisfaction by putting a fan on the landing that is controlled by an inexpensive smart switch, just to improve circulation. HA runs this show; the fan runs when the HVAC is doing something, and whenever people are home and it is either too hot or too cold upstairs (based on a temperature sensor). It's not a perfect solution, but it's kept the temperatures sane (and provided logging to prove it), it was cheap to implement, and it is cheap to run.
I already had the parts kicking around; it just took software and time.
(The best option for efficiency and comfort is probably installing mini-splits up there, but... sheesh, that's into the realm of orders-of-magnitude more expensive. Maybe some day.)
I'm curious how you used the shelly? They look neat but I'm not sure how people are wiring them into existing switches.
Good question.
I put the Shelly relay in a pre-existing junction box in the basement.
Previously, this box worked like this: There were romex cables for power/neutral, lights, and the switch itself all inside of that box. The switch, located elsewhere, interrupted power to the lights. (This isn't necessarily the most-typical arrangement, but it's how it is in the house I've got.)
Currently, the box works like this: We still have romex cables for power/neutral, lights, and the switch itself inside of that box. That part hasn't changed at all. But now the Shelly relay interrupts power to the lights.
Thus, the lights are always controlled by software.
And the light switch? That just provides an input that is acted upon by a software script.
The script (which runs internally within the Shelly relay) only does 3 things:
1. If relay is on and switch toggles, turn relay off.
2. If relay is off and switch toggles, turn relay on.
3. If relay is turned on by any mechanism, start timer, and then turn off after timer expires. (Plus other useful timer mechanics like resets on additional toggling, but you get the idea.)
---
It's easiest to think of a Shelly relay like a replacement for a light switch, but that's kind of a limiting way to think about it because that line of thought strongly implies that it should to be located where the switch is. And while it certainly can be installed that way, in practice it really doesn't have that limitation.
For my unfinished basement, there's no neutral at the light switch location so using a regular smart switch didn't pan out. (I could have added a neutral but that would have meant using more parts and getting into some drywall and paint.)
Instead, there's that neat (who am I kidding, it's a mess) junction box I that described, up on the ceiling where all of the things come together... So that's where I put the relay.
Or: There's a box behind a light fixture (well, there "should" be anyway). Often, this box will have the same functions available inside that my junction box happened to have. Power, neutral, light(s), switch input. A relay can go there.
But many houses do have neutral at the light switch location, so a relay can go there instead. Power/neutral feeds in, power for lights feeds out, with a switch (and/or relay!) in the middle. All in one accessible box on the wall. This matches the easy-to-think-of scenario. (IIRC all new homes are supposed to be this way in the US, but...)
It's (usually!) just a matter of finding the right physical location in which to install the relay.
(Note: None of this is intended to be an exhaustive list of variations. Things can and do get weird with household wiring, and regional variations of what "normal" means can vary quite tremendously.)
My only fear is my HA box will fail and now nothing works. Most likely because I move and forget to tear everything out. Still something I'm interetsed in
I have the same fear.
So everything I automate has a fallback option that exists outside of HA. My regular light fixtures, with smart bulbs? I can turn those on and off using their light switch in the event that Home Assistant is dead, like I would if they were dumb bulbs. (I seldom use them that way, but I can.)
And my basement lights have their smarts all programmed directly in the Shelly relay. It works without networking or HA or anything else. So while the basement lights are completely software-operated, they aren't dependent upon the relatively giant stack of software and complex hardware that HA brings
As long as the Shelly relay works, then the basement lights also work -- with a timer.
(That relay can fail, but it is is unlikely to fail soon. I don't worry about it any more than I do a major appliance failing: If/when it happens, I'll deal with it. It's easy to take out again.)
Interesting, I had a similar setup with smart bulbs, dumb switches and HA. My experience was that when the bulbs lose connectivity (Zigbee or Wifi in my case) you could maybe still turn them on but they would start flashing like crazy or use different colors (as indicators for their "reconnecting" state). Also Zigbee doesn't really love losing mesh nodes periodically, so turning the bulb completely off using the switch would cause the whole network to fall into broken states that had to be manually fixed from time to time.
None of the bulbs I've had (which have been a pretty wide mixture: Proprietary clown, proprietary local wifi, matter wifi, esphome wifi, zigbee) have that problem.
I just turn them off and back on one time using the switch, and the light bulb's state goes to some variation of "on" within no more than a second or two (maybe not an ideal variation of "on", but good enough to get through a dark hallway). Turn back off with the switch, and it's obviously off. On the next "on" cycle of the switch, it goes back to "on".
And while it is freshly "on", it's trying to reconnect to whatever its programmed mothership is (whether local or afar). This works every time, so far in my experience, as long as that mothership is reachable.
The only time blinkey-mode has been imparted is when I've reset things, which takes rapid iterations of off-on cycling of the light switch. (I test this all the time with the Zigbee bulb in my pantry because the light switch in there sure is convenient. It works fine, even if it has been completely off for hours or days. I just tested it again after pulling the USB zigbee dongle from HA, and the pantry light still worked fine with the switch on the wall.)
I've moved these bulbs and other widgets between houses. No issues (other than renaming things after a move). It's really been OK.
Additional background: For Zigbee in particular, I'm doing that in what is probably the least-preferred, least-effort method: I've got a cheap Chinese CC2531 dev kit that is flashed with different firmware (because that was the cheapest approach ~5 years ago), and I'm using it with ZHA in HA (because that's the easiest approach). All of my Zigbee devices have been buttons or light bulbs, all of those bulbs have been from Sengled, and none of any of them support Zigbee router mode at all. There is no Zigbee "mesh" here to speak of at all, so there's no weird interconnections to break: Endpoints talk directly with the CC2531 and that's that.
Other than some range issues (which were broadly resolved by using an old-school non-3.0 USB extension that I found on Amazon in iMac-esque coloration for a dollar), Zigbee has really been OK for me.
---
But I've been migrating to wifi, anyway. My favorite light bulbs, from Athom, actually come to me with open-source ESPHome already installed...but Matter-wifi light bulbs are often a bit less expensive than those are. (Tradeoffs.)
This migration started on the basis that my old Zigbee bulbs are -- well -- old. They simply don't produce the same quality CRI that even very cheap dumb department store LEDs do these days.
Besides, I've also already built a quite lovely wifi network for my home, wherein I do not care at all about the performance of the 2.4GHz radios at all so they may as well focus their energy on a sea of IoT devices.
I like the idea of having only one set of wireless networking gear to futz with and optimize instead of having multiples of them. (But I'll probably goof around with Matter-Thread, too, if/when that makes sense to me. I'm by no means done tinkering or learning new things.)
Thanks for the response! Refreshing to hear that it can actually work - I think the main difference between your setup and mine might be that I actually needed the mesh because I had bulbs in behind a couple of steel concrete walls. I installed always-on Zigbee outlets thinking that bulbs would route over those but never actually got around to debugging why they didn't.
Currently I'm also mostly on Tasmota-powered Athom bulbs. They work well, but after not powering them on for longer timeframes (presumably after their internal battery or whatever runs out) they forget my wifi and switch to setup.
After these experiences I'll probably go with dumb bulbs and smart switches/relays for our new apartment. Still keeping an eye on the market and open for recommendations though, mainly because I like being able to control light color through HA.
I think you've nailed the key difference for zigbee, indeed. And I'd love to share some first-hand insight about how Zigbee works with either intermediate repeaters or routers scattered around, but I just don't have any to share.
You did remind me of a thing, though: My Athom bulbs, with ESPHome, do have an annoying mode they drop into when their Home Assistant mothership is unavailable. They still work mostly like dumb light bulbs in this state, but they do a periodic blinky-thing (with a cadence in minutes, not seconds) that is annoying until the HA rig comes back.
But since they're running a copy of ESPHome that I compiled locally, that's almost certainly an ESPHome function that I can hack out/turn off/modify/whatever.
I don't have any direct experience with Tasmota. I remember looking into it with some giddiness several years ago (just because hacking on home electronics does that to me), but by the time it came to start actually buying hardware I decided to go in a different direction.
But I don't recall the Athom bulbs, with ESPHome, ever dropping out and not coming back. Even after the last move where some of them were in a box for weeks: If there was any difficulty, it wasn't something that took a lot of steps to resolve. I think I'd remember if it were challenging in some way.
So I'm lead to wonder what mechanism it is that makes your stuff go goofy with Tasmota.
Inside of these things is just a small power supply, an ESP, some MOSFETs and some LEDs. On-device configuration data is stored in flash right alongside the firmware itself. There's no battery, nor any no real-time clock (if the time is useful, it is set over the network).
Athom does publish steps for switching [some of] their hardware back and forth between Tasmota and ESPHome, if that's ever useful to you: https://github.com/athom-tech/athom-configs
---
More broadly, having smart switches and/or dimmers with dumb bulbs does sound appealing. I've got all of the lights in my garage on one smart switch, for instance, and it works well for that environment.
Smart switches would also Grandpa-proof the installation: If a dumb bulb goes out and Grandpa is watching the place, he can just swap it out and things would work fine. (Knowing my own old man, he'd probably use a dusty incandescent bulb that he's had in the glovebox of the car since he stopped to pick it up along the side of an unpaved road somewhere outside of Lincoln Nebraska in 1973...but it'll still work fine.)
But smart switches and relays alike want neutral wires. It's not always straight-forward to integrate them, as I've written extensively about elsewhere here.
And right now, I've got the usual lights in the common areas downstairs set (via the Adaptive Lighting integration) to smoothly adjust their color temperature based on the position of the sun. And I really like that function: I get intense 6000k light during the day that more-or-less emulates the ambient sunlight that comes in through the windows, and a much more serene 3000k light when it's ~dark outside. And nobody has to think about it at all on a day-to-day basis; it Just Works.
This is, quite frankly, pretty glorious to me in ways that I don't think I ever want to give up...so I'm stuck with smart bulbs in lots of places.
I actually didn't try ESPHome yet, thx for mentioning it. That will be my next experiment then. The adaptive lighting also sounds really cool, will try that as well.
Do you know if the Athom bulbs even have some kind of persistent memory that can survive longer timeframes without power?
You can run HA in a Docker container and set it to generate backups periodically. If your virtual box (or the host) dies, spinning up a replacement will take up a few minutes, as long as you still have you have a computer capable of running Docker or Podman.
That is no use if my boss says move to different city - there is a lot to deal with in a short time which leaves no time to tear that stuff out. if the house doesn't work for the new owners the courts will make me pay an electrition to make it work.
HA failing is annoying but not nearly as stressful.
I see where you're headed with that now.
It is my intention that when I move, I move my smart home shit with me.
I keep this in mind as I add smartness. All of it can be reversed to normal-house-status in a few hours, at most -- including a trip or two to the hardware store.
It can go back to what it once was almost as soon as "We're showing the house on Thursday" is uttered by anyone.
(The new owners won't want any of it, anyway. Buying someone else's bespoke smart home is like buying someone else's bespoke race car: It may have been a serious investment in time and money as well as a source of tremendous joy for one person at one point, but for the next guy it's just kind of a nuisance.)
What are you using as your temperature sensors, if you don't mind?
You'll laugh, but:
I'm using a Zigbee button from Samjin/Samsung/whoever-that-was which reads temperature, my Nest thermostat (via a convoluted-but-supported path to a remote API), and a couple of Amazon Echo Dot speakers (the integration of which is cursed, but it's easy to set up and usually works).
I was going to try to score some cheap BLE temperature sensors and use the Shelly relay as a gateway to bring those into HA (yeah, it does that too), but then the big mystery ball of tariffs happened and I lost track of that idea.
Not the GP, but any supported BLE sensor [0] with a Bluetooth proxy ESPHome node should work.
[0] https://custom-components.github.io/ble_monitor/by_property#...
Same, it's so nice to throw together a yaml that pretty much does exactly what you want, with the only ambiguity being knowing the ins/outs of the pins.
I'm just hoping it stays cheap as a hobby
It just makes stuff so easy - I’ve been on an absolute spree lately, and have built out:
Ultrasonic tank & river level monitors, with temperature compensation and a battery fuel gauge - managing to make a 3000mAh battery stretch almost a year. Some of the river monitors use LoRa.
Remote control to stop/start the previously pull-start generator
Gas bottle level monitors
Made the coffee machine dangerous
And my current project is seeing if I can make solar/battery powered LED bulbs that I can hang on trees and use BLE to make them automatically turn on some distance ahead of you as you walk down the long path through the forest, and turn off once you’ve passed.
I only really got started a few months ago, and my approach is far more breadboards, DuPont cables and superglue, because I know damned well that the moment I go “ok I’m done let’s get a PCB” I’ll decide on a modification.
Anyway. I don’t have enough good things to say about ESPHome. I get to save thousands of euros, and have fun at the same time. What’s not to like.
Just wait until Espressif gets some greedy shareholders/or some manager that needs a raise and then suddenly you're paying 30% to get your app into the ESP Store.
ESPHome is owned by the same group as Home Assistant, not Espressif. So Espressif getting greedy would just mean higher prices for their chips (or they could lock down development on their chips, but that seems very unlikely).
ESPHome isn't really Espressif exclusive, there's Beken support already, which most cheap Chinese IoT gadgets use nowadays. And there are 'made for esphome' products which is a safer bet than buying Sonoff and praying the ESP32 inside doesn't have its secure boot bits fused.
The next step would be to monetize it with ads, and put some of the features behind a monthly subscription.
Premium oscillation package, only $9.99 a month.
Need $150 a month to add SSO though
Single Sweat Off is an Enterprise Only requirement.
Premium oscillation package. We still talking fans? Or only fans?
OnlyFans...I see what you did there :-)
$9.99 is for a single user. Extra users cost $14.99 each sold in packs of 5 with a three year minimum contract.
I don't like the notion of doing speed control by putting a digipot in series with a motor. It worked because the fan happened to be low enough power but it doesn't seem like the author gave thought to the power handling capability of the digipot. If the fan happened to be beefier he's letting the smoke out with this design.
Plus, this is more complicated than just doing PWM.
Based on the description of the wiring to the motor (24V, GND, POT1, POT2, NC), it doesn't sound like the original setup would have been drawing much power through the pot either -- there's probably something else on the other end of that wire that is doing modulation based on the sense resistance, and the motor is itself drawing power from the 24V line. So while it's true that there should be a check for the allowable limits on the digipot, I don't think it's actually being used to sink much power.
Hey, author here. That's correct. The potentiometer has 5V going through it, with a current range of 30-164μA, which fell within limits of the digipot. I opted to use the digipot instead of my own PWM because something else must be doing PWM closer to the motor, where I didn't want to go modifying.
You're right, I didn't read thoroughly enough.
>Everything joined up via a 2-pin and 5-pin connector on the PCB. From there, it was a straightforward matter of measuring voltages and continuity to work out what connected to what: the 2-pin connector was offering 24V DC. The 5-pin connector was what went off to the motor itself. Two of its pins were passing through the 24V DC and ground directly. Two more pins were connected to the potentiometer. The fifth pin was not connected.
> there's probably something else on the other end of that wire that is doing modulation based on the sense resistance
And it would have been great if that arbitrary assumption had been tested by the OP and the results were documented in the article so that they wouldn't come off as somewhat clueless as to the limitations of their design.. oh well.
From the HN guidelines:
> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
> Don't be curmudgeonly. Thoughtful criticism is fine, but please don't be rigidly or generically negative.
These passive aggressive posts are a far worse violation of the HN Guidelines than what they're in reply to almost all of the time - and this is no exception.
No, no they're not. I would much rather people are warned about the guidelines and adhere to them going forward than the opposite and we then just let violations run rampant.
They're not "warnings". They're passive aggressive internet dick waving virtue signalling. The flag button exists.
I, for one, appreciate knowing why people have flagged my comments. The "flag and move on" strategy is for use against bad actors.
There are a lot of people who read or watch stuff from the Internet and then play with mains voltages without giving a though to how dangerous that is.
See: any craze which uses the high voltage transformers from microwaves
I've been toying with a variant of this project for my Honeywell home air filters. I have one in all my "big" rooms, and I like to keep them running at a low speed most of the day.
But I also have time-of-day energy pricing, and it would be nice to automatically turn off (or at least slow) my air filters during the 5pm-8pm window. This project inspires me to at least look into the feasibility of adding that functionality myself.
Depending on your air filter you might be able to just use a smart plug, I went down a similar route this summer before realizing that mine would remember their power state and settings when powered off.
So now I just have them plugged into a few smart plugs with automations in homeassistant
I would need a device with a physical switch rather than a touch control. Sadly many devices, mine included, have "power was cycled = device is off" logic.
You might have luck with these... https://uk.switch-bot.com/products/switchbot-bot
Why not just use a dumb timer plug from a hardware store?
Ten bucks, and completely hacker-proof: https://www.acehardware.com/departments/lighting-and-electri...
$16 if you need a remote control: https://www.acehardware.com/departments/lighting-and-electri...
Or $17 if you want to get all digital and fancy: https://www.acehardware.com/p/3001323
Sure those work, I've tried them before, but I find them more fiddly and less fun to program than homeassistant.
Also I can easily turn them on or off from my phone which is nice if I'm feeling lazy.
This is what I do with my dehumidifiers.
It's been working so well I was actually surprised one night when the dehumidifier in the bedroom turned itself on from the automation (which I have set to do after dark if humidity is higher then 70%).
It had been within tolerance for ages and I just hadn't had to even think about it.
You should, it is very DIYable! I did it and reverse engineered it myself a while back. You dont need to make a custom circuit board if you are fine with losing the touch controls
https://github.com/flaviut/Honeywell-HPAx00-ESPHome
Holy shit, perfect!
Why not this? 24-hour programmable timer https://www.amazon.com/dp/B0D7ZS6PGK
The digipot is vaguely similar to how a R2R ladder DAC works. There are two resistor values used: R and 2R. The "interesting part" of the circuit has bits x 2R resistors in parallel. One end of each resistor (let's call it input) is connected directly to the digital bit from the PWM sample.
Then there is the series bits x R resistors. The output of each 2R resistor is connected in-between the two resistors that straddle its bit position. So:
And that's it (apart from pull-up/down resistors)! Due to the way that resistors in series and parallel work, each input step in the ladder provides twice the voltage of the previous if powered: it's base 2 enshrined in a physical object.These are relatively uncommon because they are highly sensitive to the resistor (and trace) tolerance, but this circuit is my Euler's identity of electronics: it very literally bridges the digital and analog worlds.
I saw the diagram in the original blogpost, laughed, but after a bit of sketching it out I think we're both wrong. R/2R ladders are useful in DACs (and are really cool there) but don't look like they're used in digipot applications.
It seems like actual digipot ICs use the "2^n discrete resistors" approach. The IC used in this project is a MCP4141 which explicitly states in section 5.1 of its datasheet that for 7-bit (8-bit) devices there are 128 (256) resistors in a string between the terminals.
I'm a bit surprised this seems to be the best approach, but with IC manufacturing the joint problems of "a bunch of identical components" and "wiring it all up" are much less of a problem than if you were to wire this up by hand.
>> The PCB was ordered from JLCPCB, where I opted to have most of the components pre-soldered.
very expensive, you are committed! :)
you should have gone Full Giertz and added a badd little robot arm that turn the pot.
esp32 are really nice: hundreds of code examples that do what you want without having to read too many pages. did you use ARDUINO IDE or idf.py SDK?
I was actually pleased with how cheap it ended up: less than $20 USD for the board + assembly + every component.
I set ESPHome to use IDF under the hood, you can check out my full ESPHome config for this: https://git.ellis.codes/e/esphome-configs/src/branch/main/vo...
interesting! i tried to order some assembled boards and was told $200+ (US) for only ~20 smd parts.
I've noticed that some things can make the price suddenly skyrocket. Certain PCB specifications for one (though couldn't name anything in particular off hand). The one thing that caught me by surprise was that if I wanted to have JLCPCB solder the ESP32 for me the cost would jump by more than double, and the PCB would have to be physically larger. Something about their "Economic" vs. "Standard" PCB assembly where, for reasons I'm not clear on, the ESP32 could only be done under the latter. I opted to solder that component myself, of course.
My current record is $19 (including shipping!) for two assembled boards of https://github.com/xobs/soundoff which is a little device that shuts off 5V power to a USB-A port when it detects the PC it's connected to goes to sleep.
Reading the comments here I feel like… I have found my people. I love toying with the esphome and homeassistant.
I actually like this idea. Makes more sense than smart fridges. Would be cool if this ESPHome thing worked with RP2350/Rpi Pico 2.
It's there, but you have to configure a custom platform due to politics between PIO and RPI.
[0] https://github.com/esphome/feature-requests/issues/2837#issu...Could tie it to a thermometer and turn it on automatically on hot days. Very cool.
Ideal for a beer fridge. Is today a beer in the sun day? If so, chill those bad boys. Otherwise, save the energy.
Ah yes, buying tens of dollars worth of hardware to save cents worth of power. What being a hardware hobbyist is all about!
This is a very fun project with a corsi-rosenthal filter (a box fan taped to a bunch of normal house filters). To control the fan, you'll have to have some fun with a relay connected to MAINS voltage -- if you dare. The salon power relay hat is a reasonable solution (just remember to get voltage up/on for fail-dead). It's possible to squeeze everything inside of those cheap lasko fans you can get, too, if you want a challenge.
Slightly easier/less mains electrical work required is to just use a smart plug of some sort, and there are multiple options you can put your own firmware on (e.g., Sonoff supports ESPHome).
One caveat about this most people don't know is that most basic fans with a fully mechanical switch always order the speeds from High to Low, so that if you for instance want to turn it on to Low you have to briefly go through High (and Medium). This is on purpose, to briefly supply higher current to the motor for it to start spinning. Some fans might not like it if you start them from an external switch in low, especially larger ones with heavier blades. This also applies to the one in the article, but you can sequence things in software if you have full control of the fan speed, too.
What's odd is that while what you describe is true for fans with a rotary mechanical switch, where you have to physically turn the contacts through "High" to get to "Low", it's also very common for fans with independent speed buttons to put the "High" button next to "Off", with "Low" furthest away. I don't know if that's just a hold-over from rotary switches because people are used to the sequence, or if there's something else mechanical going on inside the switch unit which has the same effect. And on this occasion I'm not taking mine apart to find out.
Why is there level conversion though if the digipot (MCP4141) is 2.7V to 5.5V?
Personally I'd just use breadboard, it's just a 8 pin IC and a ESP module, for a one-off hack..
Hey, author here. There's a line in the digipot datasheet that says the voltage on the A/B/W pins must be within -0.3V to VDD + 0.3V. The fan's line for the wiper pin is 5V, which would fall well outside of that if I gave the digipot's VDD 3.3V.
Thanks. Thinking more about that, might have been easier to just use 5V tolerant esp8266 :)
Fair point, I hadn't thought to consider that aspect of the ESP8266. I mainly opted for the shiny new ESP32-C6 with the idea that I might one day set it up to use Thread instead of WiFi.
This is amazingly cool. Did you consider putting a rotary encoder on the PCB to maintain local control over the speed?
That's exactly what I did :) and a convenient thing I realised afterwards is that the push-button function of the rotary encoder gives me the ability to turn the thing on and off with my foot!
(Facepalm) I looked at the pictures and skimmed, missing the encoder part. Awesome!
I purchased a Phillips fan in a shopping spree. It was hot outside, needed something, did not pay much attention beyond that it worked and was not noisy.
At home my eyebrows went halfway on my forehead seeing that there is a remote and the remote is supposed to be my mobile! Need to download the app for it, connect the fan to the Wifi, but it also had bluetooth for some reason. No way Jose!
Yet, it was so incredibly stupid like 4K zoom camera in a hammer that I had to try. Carefully. Data collection notice in the app shop is not promising, not at all. Location data, ID, I do not remember in full but perhaps contacts too? Unsure, but a lot. Anyway, will not enable access to most, airplane mode on, no bluetooth device in sight, so went ahead and installed the app, router disconnected from the internet, then run it.
First thing: refusing access to location. App: sorry, you cannot use me if I cannot access your location, network, and my mothership. And it stops. Big laugh, delete the whole thing. Leaving feedback for other customers about this incredibly stupid intrusion.
Then I got answer from Phillips! Something along the line: "This is for the best interest of our customers, we need your precise location so we can share personalized pollen and climate data and whatnot, we absolutely must insist this!"
For a fan!
Meanwhile the fan has physical buttons on it, can adjust speed, timer, and the cycle. Not completely useless. However some buttons need two press to register the action once. Beeps twice, does thing once. Likely some interference with The App, need to make sure that I am in the same room with the fan with a warning press and then the real press, or whothef knows what was in the head of these guys when they put this piece of thing together!? But really, are they nuts? Ruining use along pollen data?!
Are we already living the movie Idiocracy when it is about the Phillips product design department?! Did they loose all sense with reality? I am sure they already pushing through some new AI function for this very fan and are sad that mine cannot connect to the mother ship through satellite or something just so the update can be pushed to it learning my breath patterns for optimal fan speed. They are nuts! They are nuts!
> Need to download the app for it, connect the fan to the Wifi, but it also had bluetooth for some reason.
Bluetooth could be there for initial setup.
To connect the fan to WiFi you have to somehow get the WiFi credentials to the fan. There are a few ways to do that.
One of the most common is for the device when it has not yet been set up to make itself available over Bluetooth. The app can then connect to it and give it the WiFi credentials.
Another common way is for the device to create its own WiFi network with a name that the app can somehow recognize. The app can then find that network, connect to it, and use it to talk to the device.
I don't think this is as popular as the Bluetooth method, probably because it used to require that the user go to their network settings and connect to the device's WiFi network. Plus, when they are connected to the device they are not connected to their "real" WiFi which could disrupt other apps.
However, newer Apple and Android mobile operating systems provide ways for applications to change the network connection in the background or with minimal interaction, which makes this method more friendly so maybe it will become more popular.
There also are supposedly some IoT devices that use WPS (WiFi Protected Setup), where you bring the device near your router, press the WPS button on the router, then press the WPS button on the device, and magic happens to add the devide to your network. I've never actually had any device I've bought support this so it is either uncommon or I've just been unlucky.
Anyway, from what I've read Philips has used both the bluetooth method and the access point method on their WiFi products.
Miniscule sideline thingy here, but thanks for your insightful thoughts nevertheless.
The location access is often needed for the app to be able to find the WiFi networks in the neighborhood. This is because that can be used to triangulate your location, so they bundle it in with the same permission (unfortunately, there isn't a very good way to separate this, since it theoretically can be used to locate you and therefore you should let the user know that).
Why does a fan app need to find the WiFi networks? The OS does this, and then serves an internet connection to the app. It doesn't need to know what the available networks are.
I love upgrading simple home appliances with homebrew smarts using ESPHome so that they retain their original interface. I've mostly done lights that are still correctly switched at the original wall switches but up next is my fan and toaster oven! Then to tackle the thermostats.
I love these things toying with home assist
I think this is the opening to a Korean horror movie...
I love this - but honestly I was expecting this to end with the fan not functioning due to wifi issues. :)
How much does it cost to get a pcb made with all the components?
I hate soldering but breadboards are limiting.
As low as $10 if you all components are from JLCPCB's basic component library. For this board, more since there are some through-hole components and neither MCP4141 nor ESP32 (nor the buck modules used) are in the basic library.
[flagged]
Oh no don’t tell vornado this is possible and give them an enshittificafion pathway for their products
IMO anything with unnecessary digital interfaces is already down the path.
I have a Vornado fan that I would love to automate with a simple wifi-enabled plug, but due to the digital on/off/speed button, when you cut-off and restore power to the device, it stays off. If it had a dumb analog dial or switch, it would both be fine for normal use, and could be easily, cheaply made "smart."
They do sell wifi-enabled fans; none of them are in a form factor that would fit in my window.
I'm not even alone in this gripe, lots of other maniacs have done the hard work of conversions. Unfortunately I'm not confident enough in my soldering skills to try :\ https://www.reddit.com/r/electrical/comments/vaiskf/bypass_p...