Upon using the Google Cloud IoT Core platform, it seems to be built around the idea of sending configurations down to the device and receiving states back from it.
Google's own documentation suggests using that approach instead of building around sending commands down (as a config) and getting responses back (as a state).
However in the very end of the documentation they show an example of exactly that.
I am struggling to understand how does one support both approaches? I can see the benefit of how it was designed but I am also struggling to understand how would one be able to talk to the device using such an idiom of values and results as the config.
Has anybody implemented a command/response flow? Is it possible to subscribe to the state topic to retrieve the state of the device in my own application?
Edit based on clarifying comment below:
We've got a beta feature we're calling "Commands" which will do the reboot you're talking about. So the combination of config messages (for persistent configuration that you want to send a device on startup/connect to IoT Core) and Commands for fire and forget like a reboot message can do what your'e talking about. Current state is a bit trickier, in that you could either have a callback mechanism where you send a command to ask, and listen on the events/ channel for a response, or have the device report state (/state/ MQTT topic) and just ask IoT Core's admin SDK rather than the device.
Commands just went open beta, you should have access to it now. If you're using the gcloud SDK from command line, you'll need to do a
gcloud components updateand thengcloud beta iot devices --helpwill show the commands group. If you're using the console, when you drill down to a single device, you should now see "Send Command" next to "Update Configuration" on the top bar.Old Answer: As a stab at answering, it sounds like rather than using the state topic, you could/should just use the standard /events/ topic and subscribe to the Pub/Sub topic the devices go into instead?
It really depends on the volume and number of devices we're talking about in terms of keeping that state machine in sync.
Without knowing what specifically you're implementing, I'd probably do something like send configs down, respond from device on the /events/ topic, and have a Cloud Function that tracks the Pub/Sub topic and updates something like a Firestore instance with the state of the devices, rather than using the /state/ topic. Especially if you're doing something in response directly to the state reporting of the device.