Cloud IoT step-by-step: Functions, words, words, words

Hi friends!

So, Cloud Functions. They’re pretty awesome, and I covered how to use one to talk to your Raspberry Pi back in this post. While Node.js is a great language, in the IoT world, it’s not the language of choice. According to this survey by the Eclipse Foundation done in 2016 (I realize it’s out of date and things are changing, but it’s at least a baseline) Node.js is 4th behind C/C++, Python and Java when adjusting for the fact that Eclipse is a bit Java biased.

Cloud Functions released first with Node.js so I covered that first, but in the interest of being sure I’m covering our bases, I’ve got code for the same Cloud Function we ran before in Node.js, but now in Python and Go.

The whole process is the same as before, but when creating your Cloud Function, change the Runtime drop-down to the appropriate language.

Everything works the same. Start up your Raspberry Pi with the script from the previous post, then hit the endpoint in the Trigger tab of the Cloud Function details. For this function, if you just go to the URL in the trigger, it sends a config type message of clear. Just like in the previous tutorial, on the page that opened, you could add, for example: ?which=command&message=redand this will send a command message to the device that should (assuming everything’s been setup from the last tutorials) turn all our LEDs on the sense HAT red.

I said everything works the same, but there is one significant change to the code logic I made which may have resulted in our functions not working any more! Something I’m relying on in the new functions is called the default credentials. When you created the Cloud Function, there’s a field there to specify a service account. By default, if you don’t specify any service account like we did in the first version of using the Cloud Function, then it will use that service account to try to authenticate whatever the function is doing. So depending on your access level to the GCP project with your user’s default service account, you might not have access to the IoT Core admin APIs. If you have owner or editor rights on your project, this will likely just magically work because your default account has access to the right access to run that API.

Also, just like before, you may notice that the first time you call a deployed Cloud Function it takes longer to run than you’d think. That’s because there’s still cold start costs. The first time you run any Cloud Function, there will be a significant delay while it starts the back-end to run it. Can be anywhere from a second to a few seconds. Subsequent calls to the function will be fast for awhile, but after a timeout, cold starts come back. I was going to write a nice blog about ways to optimize cold start, and strategies for avoiding them, but lo and behold! My colleague Colt McAnlis already wrote one last year! The techniques there definitely still apply. Check it out.

That’s it for this post! My next post will be all about creating a demo for Google showing off some of our ML/AI capabilities, as well as Firestore and Android.

I’ve already opened sourced the code for that, and I’ll go into lots of detail in the upcoming post(s)!