Why Is There No Direct Association Option in Wi-Fi Automation?

[upstatemike]

With the wide adoption of voice assistants like Amazon Echo and Google Home there seems to be a bu surge of Wi-Fi automation devices on the market. These are easy to set up for voice or phone control but one key thing that seems to be missing is the ability to link devices by direct association, there doesn't seem to be any way to program a Wi-Fo switch to work in tandem with another Wi-Fi switch, bulb, or module. This is basic stuff that is commonly done with Insteon or Z-Wave so why not Wi-Fi? I don't see where there is anything about the TCP/IP protocol that would prevent it from being implemented. 
 
Ideal application would be a Wi-Fi switch that you could pair to a handful of Wi-Fi color bulbs in a ceiling fixture. The switch LEDs could be color changing and could sync to the color you have set on the bulbs, Besides the main rocker there could be some discrete set buttons used to set up pairing and program default color and dim level for the switch , maybe using multiple paddle taps to cycle through a couple of color settings you program in. 
 
I'm confused as to why the features on Wi-Fi based automation seems so crude and basic compared to other protocols? Does Wi-Fi direct association exist somewhere and I just missed it?

 

[vc1234]

Ideal application would be a Wi-Fi switch that you could pair to a handful of Wi-Fi color bulbs in a ceiling fixture. The switch LEDs could be color changing and could sync to the color you have set on the bulbs, Besides the main rocker there could be some discrete set buttons used to set up pairing and program default color and dim level for the switch , maybe using multiple paddle taps to cycle through a couple of color settings you program in. 
 
I'm confused as to why the features on Wi-Fi based automation seems so crude and basic compared to other protocols? Does Wi-Fi direct association exist somewhere and I just missed it?

 
Theoretically, there is nothing preventing a wifi automation device manufacturer from implementing a "direct association" over TCP/IP,  e.g. changing device status would lead to sending a tcp/ip packet to another device assuming the latter "knows" what to do with it -- that's how a typical  zwave association  works, more or less.
 
It's just that noone bothered to implement that for wifi devices for whatever reason, as far as I know.

 

[upstatemike]

It seems like this would be the logical next step if Wi-Fi devicee makers want to expand beyond small one or two device installations. Nobody is going to do a whole house using Wi-Fi devices if there is no practical way to implement local controls. The notion that people are going to walk around their house using a phone as the primary means to turn lights on and off is a silly marketing delusion.

 

[Dean Roddey]

In a real automation solution you would do that via the automation controller, where you can keep it on one place and not spread out so that you lose it if you have to replace a switch or something. And of course the other advantage is that the automation controller can work across devices from various vendors whereas something like you are talking about is very unlikely to work other than among devices from a single vendor, even if they were to implement it.

 

[upstatemike]

I need to think about that a bit. It is true that the color control could be done using an HA controller but you would not want to depend on that for basic control such as having the switch turn a ceiling light on and off when the light is not able to be directly wired as a load to that switch. Many ceiling lights in my house were wired with pull chains and must be automated via smart bulbs or fixture modules tied logically to a smart switch that I added later.
 
Using Insteon as an example I have fixture modules in the ceiling fixtures plus switches or keypads on the walls but no direct wiring between the fixture and switch. I use an ISY99 as the technology bridge and Homeseer as the automation controller. Alexa control can be configured using devices in either Homeseer or the ISY. If the Internet link fails no problem because the switch will still work. If Homeseer fails because some unrelated plugin (say the weather station for example) uses all the CPU and locks things up no problem because the switch will still work. If the ISY99 fails because the caps on the powerline interface fail (again) it is still no problem because the association is programmed into the switch and ceiling modules themselves and so the switch will still work just the same as if the light was actually wired as a local load.
 
I believe you could do the same sort of thing with Z-Wave associations as well as UPB and some other technologies that do no depend on a hub or controller for virtual links to work. I just don't see a good reason why Wi-Fi devices could not be built to work that way as well.

 

[LarrylLix]

Interesting idea. The devices could use their own SSID network but then there would need to  be a dual port/SSID main unit available somewhere. Most routers have multiple SSID networks they can create now, anyway.
 
One of the problems may be the time delay incurred. If a socket is not maintained open by repeatedly banging the device every minute or two.
 
Insteon still had the best idea, being designed without central control hubs, if only the pricks would open the protocol up to the public, for third party development.
 
Are you actually running an old ISY99 or was that a typo?

 

[upstatemike]

Just too lazy to type out ISY994. I probably still have a 99 somewhere that needs to be recycled.