Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
ARTIK Cloud
#1
While exploring the vast array of new voice command and integration options, I came across a cloud service that excited me as much as IFTTT. Since everyoneÔÇÖs experiences might vary, given the wealth of devices that CQC supports, I wanted to (possibly over-) explain my journey so far.

While IFTTT is awesome, in order to integrate CQC with Google Home or Alexa, it has a few short-comings that I was looking to improve on. I have tested both Google Home (via Google Home mini) and Amazon Alexa (via Fire TV), with my personal preference to the former.┬á I can say, ÔÇÿOk Google, turn on <LightName>ÔÇÖ and it sends a HTTP request via IFTTT to my home CQC server. I can use the parameter <LightName> in the url of the web request for command parameter options.

My initial concerns with IFTTT were the lack of security (HTTPS is somewhat costly to implement) and dependency on a open port for incoming connections. Additionally, this also requires a dynamic DNS setup. While an advanced firewall could mitigate these concerns, I hoped to find an alternative connection method that would be persistent and low-bandwidth. Of course, many of the so called ÔÇÿsmart hubsÔÇÖ (Samsung SmartThings, Google Home Max, etc) do much of what I describe. Yet, IMHO, this is why I maintain a server with CQC, in my local network; another ÔÇÿhubÔÇÖ would be redundant. Software smart hubs are seaming nonexistent since there are so many cloud services that are being born.

My search lead me to ARTIK cloud services, a subsidiary of Samsung. Over the past days of testing, I have prototyped light actions (dim and relay) and outlet power operations natively in google assistant, all from devices that only communicate locally to CQC, such as Insteon, X10, and APC Powerstrips via SNMP. This connection is persistent from CQC to ARTIK via a secure websocket.

Future improvements will hopefully allow for text parameters to ARTIK, as they can be parsed in IFTTT now (such as ÔÇÿTurn On <LightName>ÔÇÖ), but these parameters donÔÇÖt yet appear available to ARTIK response actions in IFTTT. However, the native device support capability and security improvements are likely enough drive for me to develop a ARTIK driver that allows for device communication between CQC and ARTIK.

HereÔÇÖs the basic user actions once all the configuration is completed:

Upon ÔÇ£linkingÔÇØ Google Home and ARTIK cloud services using the Google Home app, your devices will be discovered if they match the following criteria:
┬á┬á ┬áÔÇó┬á┬á ┬áThe device type contains the setOn and setOff Actions.
┬á┬á ┬áÔÇó┬á┬á ┬áThe device type contains a percentage type Action, i.e. setLevel (0ÔÇô100), setTemperature (0ÔÇô100).
To interact with ARTIK cloud services devices on Google Home, say Okay Google
┬á┬á ┬áÔÇó┬á┬á ┬á"turn on Living Room Light"
┬á┬á ┬áÔÇó┬á┬á ┬á"turn off Kitchen Light"
┬á┬á ┬áÔÇó┬á┬á ┬á"dim Living Room Light 50 percent"


PROs:
ÔÇö Voice response latency has decreased due to websocket connection
ÔÇö More secure than open HTTP port
ÔÇö IFTTT setup/maintenance not required

CONs
ÔÇö Only On/Off/Dim seems to be supported. Transmitting a text value is still unsupported.
ÔÇö Requires setup/maintenance of light configuration in ARTIK cloud and new ARTIK driver config file
ÔÇö Free service is limited to 100K messages per month


In time, if anyone else is interested, I'll post more details on how I created device templates and devices in ARTIK.

Anyone have any thoughts?
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)