Typically, a mobile phone is used to control a smart home device. Alternatives are smart devices themselves, such as Google Home or Amazon Alexa. After a command is issued to the controller, the smart device will respond after a short time. How is this done?
When a smart device is first connected, it goes through a setup process which registers it with the controlling app. How is this done?
Once the device is registered, any controller can talk to it. Changes caused by one controller should be reflected by any other controller. How is this done? Also, how does Google Home, Amazon Alexa or any other controllers do this?
The answer lies in the architecture for the device and its controllers.
When a new device is plugged in and switched on, it needs to be configured to talk to the home network. But most devices won't have keyboards, displays or other mechanisms to be configured directly. Instead, some mechanism has to be used.
Access points are required to support a mechanism whereby a button is pressed on the access point, something similar is done on the device, and then an exchange of information is performed using the IEEE802.1X protocol.
A common mechanism is a new device running its own wireless access point using its own SSID. By some means this is known to, say, an app, which can then connect to that wireless network. An exchange of information can then take place, at a minimum the app tells the device which wireless network it should use, what security is used (e.g. WPA2) anf any required password. The app and the device can then switch to the home network and the device will becomes visible on the home network.
Variations include when the device will run its access point. A LIFX bulb will run an access point with SSID "LIFX..." when it is switched on; A Yeelight bulb will reset and run an access point when it is toggled on/off five or six times; A Lanbon switch will run an access point when any of its switches are pressed for about 30 seconds. Neither the Yeelight nor the Lanbon switches document what the SSID is, and at least for the Lanbon, it appears to be hidden.
During the time the device is running its own access point, an app (or other s/w) can connect to it and configure it.
Another variation is what information the device shares with the app. The app (or other s/w controller) must come to know about the device. It may do so directly, by being given an IP address (presumably by DHCP after the device has switched to the home network), by a MAC address (from which it can find an IP address using ARP requests), or some other shared identifier.
Most devices seem to form a connection to one or more system servers. The LIFX bulbs are documented to form a persistent TCP connection to LIFX servers, which is refreshed regularly to keep it alive. The Lanbon switches talk to an undocumented server at 47.52.5.108, among others.
Communication between an app and a device can take place in at least two ways: either via the system server or directly.
Using the system server, the app sends a message to the server which relays it back to the device. The advantages are that the app can be anywhere in the internet, not just at home, and the server can inform all possible controllers of the changed state of the device. The disadvantages are that the external internet must clearly be live for this to work, there may be delays, and there is zero privacy from the device vendor.
Direct communications can take place on the local network. For the Yeelight, the app can do muticast discovery on 239.255.255.250, port 1982 to see what Yeelights are on the network. It then sends commands using TCP to their IP addresses. This is documented, as is a similar mechanism used by LIFX.
The Lanbon app broadcasts messages on 255.255.255.255 port 8866, with a component of the message being the identity of the device. It does not do this for every command: most of the time it talks to its external server. I have no clue as why it chooses one over another! Unfortunately, this behaviour is undocumented.
Technical details of this have not yet been described. There are only general statements such as
If you have already connected an Amazon device like a FireTV, FireTablet, Kindle, or Echo device and chosen to store your password to Amazon, Wi-Fi simple setup will recognize the account linked to your previous device and automatically connect the new Wi-Fi simple setup enabled device using the same password you have saved to Amazon.and
... when you purchase Wi-Fi simple setup devices from Amazon.com using your Amazon account, the device is automatically associated to your account.
There are a large number of devices that use alternative wireless protocols such as Zigbee or Z-Wave to communicate. These include Philips Hue devices, TRÅDFRI devices (sold by Ikea) and many others.
To bring these devices into the IP world requires a bridge or hub which talks WiFi on one side and Zigbee (or other) on the other side. In the case of the Philips Hue bridge, it connects by ethernet to your router, and doesn't need WiFi pairing.
There will be a pairing system between the bridge and its Zigbee devices, but we won't discuss that as out of scope of an IP system.
Such devices may be controllable by a gneric Zigbee controller, but quite possibly they are not. Documentation (or lack of) should be consulted.
The complexity is illustrated by this post about controlling Hue devices using a SmartThings hub from JDRoberts
[an error occurred while processing this directive]The Phillips hue bulbs originally use the ZLL (Zigbee light link) profile. They use this profile to communicate with the Hue bridge, which in turn can communicate with a SmartThings hub over the local area network. In this setup the hub does not speak directly to the bulbs. This is the only setup which is officially supported by SmartThings.
Most brands of zigbee bulbs can be individually reset through a “blink method” where you power the bulb on and off in a specific pattern, and then it will reset itself. Phillips chose not to offer that for their smart bulbs, perhaps because they were concerned about children playing with the light switch and accidentally resetting a bulb to factory specifications.
SmartThings does not use the ZLL profile. Instead, it uses the ZHA ( zigbee home automation) profile. Most ZLL devices, including the hue bulbs, can be paired to a ZHA coordinator like SmartThings and will then use the ZHA profile instead.
The problem comes when you decide you want to take that Hue Bulb off the SmartThings network and move it to a different one. Or reattach it to a hue bridge.
Because the hue bulbs cannot be individually reset on their own, you can end up with a situation where there is no way to move the bulb off of SmartThings without buying an additional device. (In the US, this is most commonly a Lutron connected bulb remote, $30 at Home Depot. Although it’s a different brand, it just happens to use exactly the right commands to reset A ZHA bulb.)
So this is why SmartThings support only recommends using the Hue bridge. Otherwise customers could end up with a bulb that they cannot move back from the SmartThings hub to a Phillips bridge, and Phillips would tell them that it was smartthings’ fault. :wink:
But as long as you’re willing to buy the additional device if you do want to move bulbs off of smartthings again, it will work fine. As long as you have selected an appropriate device handler.