On our most recent IoT Podcast, Keith called in with a unique question. He’s using Wi-Fi devices exclusively in his smart home. That might sound like a good idea at first, but his specific question raises a potential problem.
There really aren’t any options for this solution because of the potential problem of relying solely on Wi-Fi for your smart home. You’ll essentially need all of your devices to either be hardwired or plugged in. That’s because out of all of the radio protocols used in the smart home, Wi-Fi is the least power efficient.
Sure, you might gain more network coverage and faster throughput speeds on Wi-Fi as compared to Bluetooth, Zigbee, or Z-Wave, for example. But the price you pay is in power consumption. If you could find a battery-powered smart switch that uses Wi-Fi, you’d be changing the batteries on a frequent basis.
You could effectively simulate this with a smartphone: Turn off the cellular and Bluetooth radios, then use the phone only to control your smart home devices.
How long will that battery last? I realize the display will use battery power, so it’s not a perfectly controlled test. Regardless, I suspect that you might get a week at most in this case. Do you really want to be changing batteries in wireless wall switches every week or two? Trust me: You don’t.
We did dig around for any potential Wi-Fi switches that run on batteries, checking with all of the major bulb and switch vendors. But we came up empty, save for one product that’s no longer available. iDevices used to sell a Wi-Fi (and Bluetooth) enabled light socket but we checked with the company and it no longer does. Even then you’d still need to use a voice assistant or the iDevices mobile app to control your lights.
Even though there’s no device available for Keith’s specific question, we don’t want to live him high and dry. So we do have some options although most would require swapping out his current smart bulbs.
Depending on the brand of his current brand of smart bulb, he can check if the same vendor offers a wired Wi-Fi switch. Cync (formerly known as C by GE) has a range of these. for example, but they will only control Cync bulbs. It’s worth noting that the company also does sell a wireless, battery-powered switch that works with its bulbs. The batteries are expected to last up to two years, likely because these use Bluetooth instead of Wi-Fi.
If Keith is going to replace wired switches anyway, then we suggest looking at Lutron switches. They’re a bit more expensive than competing smart switches, require a hub, and work with standard bulbs, but they’re an excellent choice. And, although these don’t use Wi-Fi, Lutron offers wall-mountable pico remotes that are battery-powered for light control. So then Keith would have the option of using his wired switches or the remotes as needed.
To hear Keith’s question, as well as our discussion in full, tune in to the IoT Podcast below:
They did make those. They were the little hotspots that the mobile guys sell. They support usually 8 devices. The problem is getting back to the main router.
I am using the Deco system which as soon as I deployed it, my IoT ecosystem became stable and quick. All the user needs is an AC outlet.
There is an simple solution to this which is used by almost no one. I suspect this is due to IOT chip vendors pushing their non-wifi mesh solutions.
Matter wants BLE in all of the devices for setup. It is not absolutely required but I suspect 90%+ of Matter devices will contain BLE. Wifi devices are great when mains power is available.
To solve this use-case Matter should implement a Matter-BLE proxy in all of these mains powered nodes. This does not mean run Matter on the battery powered BLE nodes. Leaves the BLE nodes running their normal OS which has been extremely optimized for power consumption. Mains based Matter devices would pair with nearby BLE devices and turn them into proxied Matter devices. Now it becomes trivial to make a battery powered BLE based light switch.
@Jon Smirl wrote:
“ Mains based Matter devices would pair with nearby BLE devices and turn them into proxied Matter devices. Now it becomes trivial to make a battery powered BLE based light switch.”
I believe the intended Matter solution for this will initially be Thread devices. They are low power and work very well as battery powered devices and are already used as Matter examples. The Matter docs mostly discuss Wi-Fi for Mains power and Thread for battery power.
BLE has turned out to lack the reliability that most home automation customers demand. It’s one of the reasons that Eve is converting their entire line from Bluetooth to Thread, and they aren’t the only ones.
For a direct comparison, just look at the reviews of the Wemo battery powered scene controller from when it was first released with Bluetooth to its current version with Thread.
And you will be able to run both Wi-Fi and thread devices on the same matter installation so you don’t need to add a second radio to most of the Wi-Fi devices. (Which is the same way HomeKit handles Wi-Fi and Bluetooth now.)
There are lots of engineering analyses available comparing Thread to Bluetooth so you can examine the data for yourself, but it seems pretty conclusive.
There’s already one Thread-enabled battery powered wall switch, the one from WeMo, but so far it only works with HomeKit. I expect to see many more in this category by fall of 2023.
BATTERY FREE OPTIONS
Another possible option for those using a Hue bridge are the battery free switches which use the EnOcean green power protocol (a Zigbee variation) to harvest the kinetic energy when the switch is pushed to power the radio. These are really nice looking and available in a number of different colors and styles for Europe and at least different colors for the US. They already work with the hue app or with HomeKit. No announcement yet on whether they will work with Matter, but they may, at least through the Hue bridge.
I don’t know if they meet the OP’s requirement, because while the hue bridge uses local Ethernet the devices connected TO it, including the Hue smart bulbs, are using Zigbee. But for someone who does use a Hue bridge, these are an interesting option that require neither wiring nor batteries.
This is a complex topic. Thread can be perceived to be better when it is using 900Mhz and meshing. 900Mhz plus meshing can effectively cover a house. And for sure this is one way to build a home automation system. This is due to 900Mhz being more effective at penetrating walls than 2.4Ghz is.
Thread also works at 2.4Ghz. At 2.4Ghz there isn’t much difference between an 802.15.4 (thread) radio and a BLE one. In fact several vendors make chips that can flip between the two modes. So at 2.4Ghz the radio performance of thread and BLE is basically identical.
As for Matter, all of the devices I have seen are using 2.4Ghz Thread and these radios that can flip between the two protocols. Given that BLE and Thread are using the same physical radio, performance should be identical. Using Thread makes Google happy and it meshes with their legacy devices.
As far as I know the model I proposed has not been deployed in the industry. The basic idea is that the BLE signals are contained within a room and meshing is not used. Each room containing a BLE device also needs a mains powered proxy node. This architecture does not use meshing.
You can build this same architecture using Thread, it is just more expensive to do it. The vendors making those multi-protocol radio are not shy about charging a hefty premium for the chips.
I am particularly excited about the recently announced support for Bluetooth proxies in Home Assistant. Just drop an ESP32-powered device (on AC mains) into the room, & let it bridge the Bluetooth devices back to the hub via Wifi.
@Jon Smirl said:
“ As far as I know the model I proposed has not been deployed in the industry. The basic idea is that the BLE signals are contained within a room and meshing is not used. ”
It hasn’t been used for Matter because nothing has come on the market for matter yet and not very much is in the proposal stages. But it’s definitely been used in the past, that is, having a battery operated Bluetooth device which speaks directly to a mains powered Wi-Fi and Bluetooth device. (We used to call this a “bridge and tunnels“ approach back in about 2013.) The IDevices switch for an outlet mentioned inthe article used this method. Quite a few smart locks did as well, the ones that had a plug-in bridging device. Bluetooth between the lock and bridging device, Wi-Fi between the bridging device and everything else. It’s OK, but still more limited than thread.
It’s not about the frequency: Thread still has advantages when measured using exactly the same frequency as Bluetooth. (Both Eve and Wemo are using the same radios for most of their devices when they change over from Bluetooth to thread.)
This site did an article on exactly this topic on May 8, 2021, and I had a post in the comment section then linking to some benchmarks from SI labs, for example, showing the differences, as well as an article on flooding. There’s also the fact that thread supports IPv6 addressing. All highly technical, but the Thread advantages are real.
Here’s the link to that article:
https://staceyoniot.com/why-not-bluetooth-in-the-smart-home-instead-of-thread/
I am not disagreeing with this, if you want to build large meshes Thread is the better protocol.
Personally I do not like large meshes because they can be very difficult to debug when they don’t work reliably. I have experience with a large mesh installed in a commercial building where the motion of elevators through the mesh kept it in a constant flux of reconfiguration. It took months of engineering effort to get it functioning.
So I prefer the reliably and static behavior of point to point links. This static link nature makes the network far, far easier to debug when it doesn’t work right. You just need to check if you have a link or not. In the model I proposed BLE mesh is not used, you install enough mains powered proxy devices such that the BLE devices are always directly connected to one of them. Of course you can build the same architecture using 802.15.4 (thread), you just need more expensive radios.
Good point, if you’re willing to pay the dollar cost in components and extra devices, as well as the energy cost for the mains powered bridges, a point to point bridge and tunnels structure in each room will certainly give you the best reliability. For home automation and many sensor nets, the engineering challenge is to keep the costs way down, which is pretty much why mesh was invented to begin with. So it just depends on your own priorities. Again, choice is good. 😎
The bridges are inside smart light switches. There is no need for anything extra.
Your wifi Hub is not part of the switch. That is something extra.
Battery powered switch for an AC circuit? is this a Hue set up?
A battery powered wifi switch does not need to use power except when transmitting so there is no problem. I use one from Shelly and it works fine
Any switch devices in a home automation network needs to be listening for the next network command. this could be turn on, turn off, or dim. That listening function can end up using up a lot of battery life.
Shelly has done some exceptional work on batterypowered WiFi devices (working closely with SI), but it is unusual engineering and ahead of its class. Most Wi-Fi devices don’t have the same level of efficiency.
And as of this writing even Shelly doesn’t have a battery powered switch. They have a batterypowered button, which by definition doesn’t listen. It only transmits. You can’t turn on a Shelly button from an app or a routine. When you physically press the button, then it transmits.
But the question asked in this topic was about switches, the kind that you can turn on from an app, voice, or an automation. Those need the listening function, which is why very few of the WiFi ones are battery powered. Maybe in the future, with the work the SI is currently doing. It would certainly be nice to see.
Submitted with respect.
It is possible to construct efficient battery powered wifi switches. When they wake up just send a single broadcast packet using a rolling code like a garage door opener uses. Switches like that don’t have to connect to the AP or listen to the network to work. They can, but it is not required. A BLE radio will beat a wifi one for power efficiency but it is not a huge difference.
There are no standards for this type of switch that I am aware of.
Hi. I agree with you but I think a lot of people get confused by the terminology. I thought the original question was about a wall mounted battery powered switch that could be mounted anywhere without need for cabling and would send signals via wifi to a relay that would control the light. Whether we call this device a “button” or “switch” does not matter as long as it runs on batteries, can be attached anywhere, and controls lights.
The “conventional” wifi switch is very different. It is physically attached to the light’s powerleads. It can be operated manually or remotely and can control other devices. But this type of switch would always be connected to power so the question of battery power does not arise.
Let’s hope more manufacturers catch on and start marketing battery powered wifi buttons and switches.
In networked home automation for the last 30 years a “smart switch” could be actuated (turned on or off) from a network command. A “smart button” could not. It would send a network message when it was pressed, but you could not control it with a routine, an app, voice control, or another device on the same network.
So these are two different device classes. A “switch” has to be always listening so it can hear the next network command to turn on or off. A “button” does not. (A button may also be called a controller or a remote, but it’s the same functionality: it cannot itself be turned on/off from the network.)
What you have described falls into the button device class. Not switch.
If all you want is something you can physically push to tell the network to do something then, sure, battery use needs are low.
But if you want a device you can turn on/off from an app, by voice, another device, or an automation, then it has to be listening for the next network message and battery use needs go way up.
Two different device classes, two very different engineering challenges.
Submitted with respect.