As per Google IoT documentation, the gateway device acts as a device to store and process data from the devices. But in the MQTT gateway example, I couldnt find how the gateway is storing the data. Hence I was wondering if the connection between the gateway and the cloud is lost for sometime, will that result in a loss of messages from the device? How is this handled in practice?
0
votes
2 Answers
1
votes
Think of the Cloud IoT gateway as an application you are responsible for writing (or for sourcing). The gateway isn't an "implementation" that Google provides but is rather an architectural component of GCP Cloud IoT. It is typically used as a proxy from devices which have no native Internet networking capability. For example, a Bluetooth device wouldn't be able to connect to the cloud directly but it may be able to connect to a device that speaks BOTH Bluetooth and has Internet access.
Imagine you have a device (D) that can't reach the internet but wishes to publish telemetry. It does have the capability to connect to a gateway device (G) which may be a computer or some richer piece of hardware. How D and G communicate is outside of the story ... for example it may be Bluetooth or serial or USB or something else. We then assume that G is able to receive data from D (or multiple devices). When G receives the data, it will then execute an MQTT publish request over an MQTT connection to GCP Cloud IoT. This publish request comes from the G but identifies D as the source.
Now to your question ... if G can't succeed in sending the publish then it is up to your local logic (and your own implementation of G) on what you do. Your logic may store the request locally at G and retry in the future, it may discard or it may report an error back to D that may itself retry in the future. All are valid possibilities.
0
votes
When the gateway loses connection to GCP, depending on your implementation, the GCP client usually disconnects the gateway out and waits for it to reconnect. In the basic case of a gateway it shouldn't save anything it should just act as a device that can talk to the cloud on behalf of a device that cannot connect to the cloud using MQTT or HTTP.
For example, if you have many devices that had BLE capabilities but without HTTP/MQTT you can have a gateway to send the data of those devices to the cloud.
For your case, if you're worried about losing messages when the gateway isn't connected you could implement some sort of saving code that would store messages in a JSON file when the gateway loses connection, and when the gateway reconnects it would send those messages before new messages. This is probably is not the best implementation since you'd run into a backlog of messages.
