-1

We have an already running MQTT setup for communication between smart home devices and remote server, for remotely controlling the devices. Now we want to integrate our devices with Google Home and Alexa. These two use HTTP for communication with third party device clouds.

I have implemented this for Google Home and after receiving the request to device cloud, the request is converted to MQTT. This MQTT request is then sent to smart home device. The device cloud waits for few seconds to receive reply from smart home device. If no reply is received within predefined time, it then sends failure HTTP response to Google Home else it sends the received reply.

Is there a better way to handle this? Since this is a commercial project I want to get this implemented in the correct way.

Any help will be appreciated.

Thanks

Pradip Shenolkar
  • 818
  • 1
  • 14
  • 34
  • 1
    Given that HTTP is a synchronous protocol and MQTT is asynchronous, it's the only way to do this. – hardillb Feb 01 '19 at 07:46

2 Answers2

1

We're using AWS IoT and I think it's a good way to handle IoT issues, below are some features of it:

  • Certification, each device is a thing and attached its own policy, it's security
  • Shadow, it's device's current state JSON document, The Device Shadow service acts as an intermediary, allowing devices and applications to retrieve and update a device's shadow
  • Serverless, we use lambda to build skill and servers, it's flexible
  • Rule, we use it to intercept MQTT messages so that we can report device's state changing to Google and Alexa. BTW, to Google, Report State implementation has become mandatory for all partners launch & certify.
  • You can choose either MQTT or HTTP

It’s time-consuming but totally worth it! We've sold 8k+ products, so far so good.

troy
  • 2,145
  • 2
  • 23
  • 31
0

At least Google Home doesn't really require synchronous operation there. Once you get the EXECUTE-intent via their API, you just need to sent that to your device (but it doesn't necessarily has to report its state back). Once its state changes, you either store it for further QUERY-intents or provide this data to the Google Homegraph server using the "Report State" interface.

I'm developing gBridge.io as a project providing quite similar functionality (but for another target group). There, it is strictly split as described: A HTTP endpoint listener reacts to commands from Google Home and sends it to a cache, where it is eventually sent to the matching MQTT topic. Another worker is listening to MQTT topics from the users and storing there information in the cache, so it can be sent back to Google once required.

Peter K.
  • 1
  • 2