I'm trying to build a device on AWS IoT platform with OTA updates. The device is based on Raspberry Pi (or similar), has half a dozen sensors, runs some inference on the collected data, and can perform actions: toggle one thing, notify someone, make a sound, etc. I'd also like to have a local HTTP server running to be able to interact with the device directly.

I was looking at AWS Greengrass Core. And conclusion that I'm coming to is if I go this route, I would be able to have OTA updates for Lambdas running as part of the "Core" but will have to burn in "thing(s)" that interact with sensors and other interfaces to be able to use device shadows functionality. Also, local HTTP server will have to be burned in as well, as I don't see a way to serve the app using local lambdas.

Is this assessment correct, or am I missing a piece of the puzzle (or two)?

  • its been a couple years. What did you finally do to solve the puzzle ? How's it working ? Jul 26 at 3:47
  • @kalyanswaroop I abandoned AWS IoT platform idea and went simple route of manual updates. This wasn’t a commercial product, but just something I built for myself.
    – Sergey
    Jul 27 at 12:27

Any Lambdas that are deployed via Greengrass and run locally on the RasPi, can be updated OTA via the AWS GG console (or GG API). Normally these lambdas are sandboxed, but if you give them explicit permissions to be able to interact with hardware both locally (i.e. add the ggc_user user to the gpio/i2c/spi groups as needed for example), and in GG give the Lambdas explicit access to specific local resources (GG Group -> Resouces -> Add Local Resource), they can interact with your sensors.

Some of the device configurations are straightforward, but as a hint, if the Lambda will require GPIO access, the Lambda needs to be attached to the /dev/gpiomem "device" in the GG Group configuration on AWS IOT Core.

I haven't done it myself, but I don't see why you couldn't run a basic HTTP server as a local Lambda. I have deployed HTTP services running in AWS cloud Lambdas (using Pythons zappa library which deploys flask apps to AWS), so the fact it's in a Lambda container shouldn't be a blocker.


And conclusion that I'm coming to is if I go this route, I would be able to have OTA updates for Lambdas running as part of the "Core" but will have to burn in "thing(s)"

Your assumption is correct for Greengrass v1. While I recommend you to use greengrass v2 from here. The reason is greengrass v2 is quite easy to install and use. In V2 although lambda is supported, but there is concept of component.(AWS IoT->Greengrass->components)

In a nutshell in component you provide the following:

  1. S3 uri of your code base
  2. Command to execute your code base
  3. Installing some dependency of your code

After that you can easily deploy your component to a device group.And if in future that component require update you can easily publish next version and again deploy that.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.