For the TP-Link Cloud Integration, the exposure is can be depicted as the flows:
Path: SmartThingsServer ==> TP-LinkCloud ==> SmartThingsServer
URI : The uri path is always https.
Token Attainment
Frequency - once every week (changing to every 2 weeks?)
URI: "“https: // wap. tplinkcloud. com”"
Data ==> TPLinkCloud: Username and Password
Data ==> SmartThingsServer: Token
Get Devices
Frequency: Initial installation, on comms error, and when adding devices.
URI: "“https :// wap. tplinkcloud. com”"
Data ==> TPLinkCloud: Token
Data ==> SmartThingsServer: Device Serial Number, Device MAC (no address info)
Control Devices
Frequency: about every 15 minutes
URI: "“https: // wap. tplinkcloud. com”“
Data ==> TPLinkCloud: Token, device MAC.
Data ==” SmartThingsServer: Cmd Response (device data, but not IP, etc. in these apps)
Risk factors (compared to Z-Wave/Zigbee). The big risk factor is the trust level of the cloud server. These are not evaluated (but should be). However, for TP-Link, this is a large company with knowledge of security issues as well as a strong interest in maintaining their reputation (since their primary products employ security features).
Reliability Factors:
a. SmartThings Platform and service. About a nine out of 10.
b. TP-Link Cloud. 9.5 out of 10 (I have had no problems, looking at blog, do not see many).
c. Service Manager and Device Handler. Very reliable
1. Cloud Based: 1.5 months, 8 devices, no errors.
2. Hub Based: 6 months, 8 devices, no hard failures, about 0.5% SW errors not leading to failure (PC Hub)
PS - do not blame SmartThings. Although the TCP interface would be relatively simple to implement, the return formats are widely different and SmartThings would have to figure out how to manage this wide-variety of returns to successfully pass back to the requesting handler. It just does not fit well into the planned architecture.