我正在尝试使用 OTA 更新在 AWS IoT 平台上构建设备。该设备基于 Raspberry Pi（或类似的），有六个传感器，对收集的数据进行一些推理，并且可以执行操作：切换一件事、通知某人、发出声音等。我也想有一个本地 HTTP 服务器运行，以便能够直接与设备交互。
我在看 AWS Greengrass Core。我要得出的结论是，如果我走这条路，我将能够将 Lambda 的 OTA 更新作为“核心”的一部分运行，但必须在与传感器和能够使用设备影子功能的其他接口。此外，还必须烧入本地 HTTP 服务器，因为我没有看到使用本地 lambda 为应用程序提供服务的方法。
这个评估是正确的，还是我遗漏了一个（或两个）难题？
任何通过 Greengrass 部署并在 RasPi 上本地运行的 Lambda，都可以通过 AWS GG 控制台（或 GG API）进行 OTA 更新。通常这些 lambdas 是沙盒的，但如果你给他们明确的权限，以便能够在本地与硬件交互（例如，根据需要将 ggc_user 用户添加到 gpio/i2c/spi 组），并且在 GG 中给 Lambdas 显式访问到特定的本地资源（GG 组 -> 资源 -> 添加本地资源），它们可以与您的传感器进行交互。
一些设备配置很简单，但作为提示，如果 Lambda 需要 GPIO 访问，则需要将 Lambda 附加到/dev/gpiomemAWS IOT Core 上 GG Group 配置中的“设备”。
我自己没有做过，但我不明白为什么你不能将基本的 HTTP 服务器作为本地 Lambda 运行。我已经部署了在 AWS 云 Lambdas 中运行的 HTTP 服务（使用将烧瓶应用程序部署到 AWS 的 Pythons zappa 库），因此它位于 Lambda 容器中的事实不应该成为阻碍。
我要得出的结论是，如果我走这条路，我将能够将 Lambda 的 OTA 更新作为“核心”的一部分运行，但必须在“事物”中进行烧录
您的假设对于 Greengrass v1 是正确的。虽然我建议您从这里使用 greengrass v2 。原因是 greengrass v2 非常易于安装和使用。在 V2 中虽然支持 lambda，但是有组件的概念。（AWS IoT->Greengrass->components）
简而言之，在组件中，您提供以下内容：
之后，您可以轻松地将组件部署到设备组。如果将来该组件需要更新，您可以轻松发布下一个版本并再次部署。
谢谢