Send MQTT messages to Google Cloud IoT Device

0
votes

We are using Google's IoT Core product and have multiple devices registered. Those devices are able to successfully receive messages from the /config and /command topics as well as publish to other topics we've created.

We want to be able to send multiple messages (with different data) to our IoT device and have it receive them. If the device is offline, those messages should be delivered once it's online and listens to the subscription.

What is the correct way to go about this? /config only allows one message at a time (the newest). Can we create a specific topic for that device and have it subscribe to anything published to it? (We tried, but kept getting errors trying to get the device to pull messages pubsub from a subscription)

Any help appreciated.

1
google-cloud-pubsub

1 Answers

2
votes

This is a non-authoritative answer and if wrong, I'll either correct or delete it on request. Please be cautious with my information.

My understanding is that the Google IoT core story is that it is massively scalable for receiving incoming telemetry from IoT devices connected to the Internet. There appears to be no inherent constraint to the number of devices or their rate of telemetry publish. From the IoT device's perspective, it uses either MQTT or HTTP to send and receive data. The MQTT protocol communications are received at the "edge" of the boundary between the Internet and Google. The messages are then received and relayed into the Google Cloud Platform (GCP) as Google Pub/Sub messages (these are distinct from MQTT protocol messages).

From what I see, should we wish to send data down-stream (from GCP to the device) we can do that but there are constraints. Google defines two types of messages ... configuration and commands. These are described here

https://cloud.google.com/iot/docs/how-tos/commands

Configurations are constrained to 1 per second per device while commands are 1000 per second per project (note the difference in domains there).

Configuration messages are limited to 64K while commands are limited to 256K.

ONE (and only one) configuration message can be active for a device. If the device is off-line then only the last configuration message will be delivered when it comes back. For commands, messages are dropped/lost/discarded if the device is off-line.

So far what I have said is likely summary of what you already know.

I do not believe that there is a mechanism in Cloud IoT to achieve an MQTT queuing of arbitrary numbers of messages for eventual delivery to a device. However, this does not mean that we can't achieve your goal. What you could do is use the configuration message to transmit a flag/indicator that there is data available for the device but not send the data itself. For example a message of:

{
   data_available: true
}

When the device receives this message, it can then (from the device) execute a pull request to pull the data. This pull-of-data would then be outside of Cloud IoT core product and it would be your design as to how you want to achieve that store and retrieval. You could use a data store (Cloud DataStore, Cloud SQL) to store the data and use a Cloud Function or other HTTP request (originated from the device) to retrieve the data. Alternatively, you could run your own MQTT brokers on Compute Engines.