I’ll quibble with that on one point: There’s no reason why wifi enabled devices should have to be cloud connected. It should be just as possible to build a wifi device for local control as it is a z-wave device. Having said that, clearly, the trend is for wifi devices to also be cloud connected. But that’s a marketing decision, not a technical limitation. I’d love to see more wifi-based devices for the HA market.
Still and all, I’m favoring z-wave devices for the reason you state.
True but the vendors producing the equipment have decided otherwise. There is also no reason W-Fi devices could not use the 5 GHz Wi-Fi which is less interference prone.
Z-Wave and Zigbee were designed for local control and much lower overhead than Wi-Fi, especially for battery powered devices.
there is, power consumption
I have besides RF, everything based on Wifi, yet non of my devices are using internet at all… so yes, why not.
I think it is more due to the market glut of 2.4 GHz radios and antennas. It is all about lock-in, mining data, and maximizing profit.
small devices can’t really have 5ghz antennas, it might be marketing as well, but something like wemos d1 with 5ghz would not be very usable.
There is a technical problem that pushes the vendors towards a cloud, remote access. These vendors have a hard requirement that users be able to control/interact with their devices remotely (i.e. not on a person’s LAN). Safely setting up a port forward (shudder) or creating a VPN is something that is going to be well beyond the ability of most users to achieve. So the only way to meet that requirement is through a cloud service, i.e. a service where the device on the LAN initiates the connection to and the app on the phone initiates the connection to and the cloud service then acts as the go between. No need for dyndns and port forwards (and security risks of exposing your LAN to the internet), no need for OpenVPN or Wireguard.
You cannot support remote access to “average joe” users without a cloud service of some sort. So there are legitimate reasons why a wifi enabled device should be cloud connected. I’m not saying that all wifi devices should be cloud connected, but there are completely valid reasons why that would be the case.
You can argue whether or not the requirement for remote access/control is marketing or not. But so is the choice to use WiFi over 433 MHz and any number of other requirements that drives the development of a device. All requirements are driven by marketing decisions. But if one has the requirement to support remote access for average users, a cloud service is the only viable technical solution, at least until personal VPNs become much easier to set up and essentially standard (I’m not holding my breath).
Did you have a look at the Shelly devices? They are WIFI based and they can work without cloud. There is a dedicated binding for OH but you can also connect them via MQTT (what I do).
I think that these devices are a tough competitor to all Z-Wave devices as they have numerous adavantages and cost less than half the price than comparable Z-Wave devices.
4 years ago I fitted my new home completely with Z-Wave devices (130 things) also partly because of the local control ability. Now I am replacing these devices over time with Shelly devices. Why?
I am not sure how good their battery operated devices perform and they do not have the complete range of device types as Z.Wave currently has. But all my new invests at the moment are Shellies.
The mere difference is whether the vendor makes it an option to install/run without cloud. And frankly I have not yet seen any device maker trumpeting “hey but you can also use it standalone” although that would be a big marketing plus, wouldn’t it.
Shellys I believe do as they’re coming from the HA space. As opposed to e.g. Tuya (with all their reseller brands) which is no-option-but-Chinese-cloud. Well, none except to reverse engineer, that is.
I was reminded of the video below when you mentioned looking for non cloud connected devices.
This was a DIY smart thermostat that only relied on the automation system to operate (at the time of production it was HA, which could easily be converted to OH)
Worth a watch…
It depends. They would have to have an increase in sales large enough to justify the creation, maintenance, and documentation for a completely separate and new API. If you are using a cloud service for remote access than they already have created an API for the device to interact with the cloud and for their app to interact with the cloud. Local control will need to be implemented using a wholly separate API. That can be a significant amount of work and come with a significant cost.
This community and communities like it are simply not large enough to justify that cost for many vendor makers. There are not enough of us who are:
When you look at the wide world of WiFi devices, Shelly is the stand out, not the rule. Everyone else does cloud only APIs if they offer an API at all (cough Wyze cough). Most of the stuff that offers local control either doesn’t have a cloud service in the first place (e.g. zwave, zigbee, etc.), has a separate hub (Hue, Xiaomi, etc.), or local control is done through reverse engineering or replacing the firmware on the device.
These vendors are not ignorant of the market. They are able to determine to a reasonable degree of accuracy predict what adding/removing certain features will do for sales. If we were a big enough market; more vendors would be offering local control APIs because enough of us would be buying them to justify the extra cost.
If DYI(ish) is something you are willing to use, https://hestiapi.com/ is an option. It runs openHAB even to define the thermostat rules. And I’m currently in the process of rewriting the openHAB configs for them to make it work a lot better on the under powered RPi 0. As an aside, it is amazing how much faster and smoother OH runs when everything possible is put into JSONDB (including Rules). I’ve taken it from a ~30 minute reboot time to just over ten minutes right now and I’m on target to get it down to about seven minutes. That’s still too long IMHO, but much closer to reasonable than 30 minutes.
Also, surprisingly, it’s not RAM that’s the problem, it’s CPU and loading those text configs is very CPU intensive.
Rather than treating cloud control like it’s a cancer on home automation, let’s call it what it really is: entry level. It’s a way for average consumers to get into this space with a minimum of fuss, and as with all things it comes with trade-offs. It’s not surprising that companies would focus on entry-level products, and it’s not surprising that OH users have largely outgrown the inherent limitations of those entry-level products.
From this perspective, cloud access/control is a feature. No more, no less. If you don’t agree with that feature, just don’t choose the vendor. It really is that simple, particularly in a luxury category such as home automation.
I, for one, wouldn’t be here today if not for the entry-level Belkin Wemo plug that I bought in 2013 to control my cat feeder remotely. If you had told me that the only way to accomplish this was to get a Raspberry Pi kit, Z-Wave stick, Z-Wave plug, multiple SD cards, and a UPS for 5x the price of my single Wemo switch (plus significant time and effort), I would have happily stuck with a mechanical timer.
It’s worth noting that TP-Link Kasa switches can be controlled locally with the OH binding. You need cloud access to set them up, but once that’s done you can deny Internet access. I believe that’s also the case with Belkin Wemos, but I prefer Kasas for reliability and cost.
AFAIR, Sonoff had the information about firmware alternative tasmota on their website. I don’t know if it’s still there, though.
Thanks @vossivossi for pointing out the Shelly devices. I like what I see, but they way they work breaks my rule that the device must still do its job without a controller e.g. it’s still a wall switch with a mechanical flop, and also can be managed by a controller. Still, I’ll be keeping them in mind for cases where that type of installation works.
I must say it’s educational to hear do many well-considered thoughts from all angles.
I’m enjoying reading the perspectives from the voices of experience. I agree with @rpwong that cloud-enabled wifi isn’t a cancer. It’s more like diabetes. You sometimes get it out of a lack of self discipline (and I’m looking at myself, here), and once you have it, it makes some of the things you want to do difficult or impossible.
Again, I’m quibbling, but that “requirement” itself isn’t a technical one, it’s a marketing one. As you say yourself later, all of these requirements are marketing ones. In my world, I regularly see projects fail to live up to their full potential because both marketers and developers are laser-focused on the letter of the requirement. Marketers are told to promote a product to the AJ (Average Joe) market, and don’t think to ask “where else can we find an audience for this”. Engineers are tasked to build a AJ-compatible device, and never think to raise their hand and and say "for n% more effort, we could have an API and capture the PH (Propeller Head) market too.
AJ-type people are more than willing to drop a box on their premises that does magic they don’t understand (Echo, Google Home). If I could wave my magic wand, I’d have GE or Leviton or Lutron or someone say “Here’s the MarvyHome line of standard wifi enabled devices, from switches to thermostats to cameras to sensors. They’re easy as pie to set up right from your own web browser, with no with no cloud eavesdropping on your privacy and no internet connection needed. You can drop our MarvyBox on your network, and then you can control and coordinate them all together with your phone or computer, from within your home or optionally from halfway around the world. Don’t want a MarvyBox? You can use any of the many home automation controllers on the market to craft your perfect home experience exactly the way you want it.”
Companies like Apple, Lutron, Samsung, etc. have been nibbling around that (not necessarily with wifi), but they limit their own success by the very tactic they think will ensure their success: making it closed, proprietary or cloud dependent.
The MarvyHome approach would require a company willing to risk that they’re diving into a pond where anyone can swim, but willing to do so because the open standards and privacy angles will make more people will be willing to dip their toe in, and confident enough in their brand and quality that they can carve out a leadership position. In other words, a disruptor.
Anyway, that’s my dream. Meanwhile, I’ll live with the reality.
Again, cheers to you all for being willing to engage in this conversation with a relative noob!
I think you misunderstood, place the shelly behind your physical switch, attach the switch to shelly input and your light or whatever to shelly output, Voila, achieved what you want, unless I misunderstood you.
Ahhhh, I did misunderstand … I’ll have another look! Thanks!
What happens when the mechanical switch is toggled to on? Does it defeat the Shelly, or does the Shelly recognize that the switch has been toggled and switch the state? I don’t think that’s clear on the Shelly website (and perhaps it’s specific to devices).
Now I’m quibbling, but I just don’t see any reason to attach negative connotations to all cloud-enabled devices. You can change them any time you want, same as you can change your car, TV, refrigerator, or any other consumer technology. If you have diabetes, you can’t wake up one day and decide not to have diabetes.
Sorry, this is a general pet peeve of mine. I personally think there’s too much complaining about luxury goods and services by people with disposable incomes. Let’s just do what’s best for ourselves and not judge others (companies and their customers) for making different choices.
What does someone’s income level have to do with anything? If a consumer in a free market economy doesn’t like the product, they are free to:
Most all manufacturers welcome comments on their products - hence the many online communities where users share their likes and dislikes…but to say hey you…you have too much money - you’ve lost the right to complain is asinine.
If there was not a demographic of users with extra disposable income…many of these products would not exsist.
Geez…what some people will bitch about…
The Shelly will recognize that the switch was toggled and change its state. So it works perfectly without any Home Automation System behind it. It does not behave different than all similar Z-Wave devices I have.
However, to be precise it - of course - also depends on the device configuration option you choose for the Button Type, see a screenshot from the WebUI:
As you can see the device firmware offers plenty of options to fine control the button behaviour. It even allows to completely abstract the button from the physical relay (which IMHO is rare, I have not seen this on many Z-Wave devives). And as the device reports any physical button switch immediately (very fast), you can use it in several scenarios (and you do NOT have to mess around with association settings or delays of multiple seconds as which some Z-Wave devices). Don’t get me wrong, I was a big Z-Wave fan (and still am), but the Shellys are simply one generation ahead.
That’s a fair interpretation of what that I put out there. I don’t mean to sound like I’m complaining about the complainers, but I totally get how you read it.
To clarify, I’m not saying that people shouldn’t be allowed to complain because they have too much money. I’m differentiating between the people who have disposable income that allows them to buy luxury goods and those who are struggling to put food on their tables. However, I was trying to avoid making it a “people are living in poverty” statement, so I oversimplified.
That’s what I’m getting at. It wasn’t meant to be an attack on a demographic, but to say that we should be grateful for any and all products, even when they don’t suit us personally. Spend less time complaining that companies have evil intentions, and more time enjoying what we have.
In retrospect, I should have just left that sentence out. Sorry to upset you or anyone else @KidSquid. That was the furthest thing from my intentions. I’m glad you called it out.
