Feature(*): Introduce fully async library

[MathiasKoch]

Missing stuff:

• (OTA): Request momentum
• (OTA): HTTP data interface
• (OTA): README
• (Provision): Re-subscribe on None in subscriptions
• (Shadows): integration test
• (Shadows): Documentation overhaul
• (Shadows): README
• CI (Tests & clippy)

Fixes #33

[t-moe]

Whats the status of this PR and this project in general? I'm evaluating using rustot for my next IOT project.

The main branch currently does not build unless using --locked (failed to download base64ct v1.8.0 [...] requires edition2024 when running cargo test).
And this branch here depends on the private embedded_mqtt.... I assume you plan to publish embedded_mqtt?

Thank you :)

[MathiasKoch]

Hi @t-moe
Status is currently that this "draft" PR has become our new production :p
You are correct that it depends on a currently closed-source embedded_mqtt crate, we have on our todo to give it the final shine before doing a public reveal and release of that one.
We were not aware of anyone actually using this :) We might be able to prioritize the release of embedded-mqtt & rustot internally. We are still looking for a new for embedded-mqtt though, as embedded-mqtt is currently taken on crates.io :(

[t-moe]

Got it, thank you!

I'm not actively using this yet. However, in a previous project, I implemented AWS Shadow, Streams, and Jobs myself - before I was aware of rustot. For my next project, I thought it would be great to avoid duplicating effort and build on rustot instead.

A couple of blockers for me:

• It uses const generic expressions and requires nightly. (I assume this will remain the case as long as the crate targets no_alloc?)
• It depends on a specific MQTT implementation (mqttrust // embedded_mqtt), or at least requires pulling in the full crate to implement the necessary traits. Personally, I would prefer if rustot defined its own simple MQTT trait (in absence of a standardized MQTT trait).

I think, I will reuse my own implementation for now, and come back later, when another project arrives.

[MathiasKoch]

Roger.

It uses const generic expressions and requires nightly. (I assume this will remain the case as long as the crate targets no_alloc?)

This is true, and we might be able to address it if its an actual blocker, but for us it makes things a bit easier and we are running nightly anyway.

It depends on a specific MQTT implementation (mqttrust // embedded_mqtt), or at least requires pulling in the full crate to implement the necessary traits. Personally, I would prefer if rustot defined its own simple MQTT trait (in absence of a standardized MQTT trait).

I have attempted to make an abstraction for the MQTT client, but i have failed all of my attempts, due to complex lifetimes in the subscription streams.

[t-moe]

Hi @MathiasKoch ,
As followup to my comment above: Can you give me access to the embedded_mqtt repo 😬 ?
I would like to take a look, and think about how we could join forces on these AWS IoT Topics. Currently I'm still using my own (private/hacky) implementation of it in production, but I would really love to see and contribute to a a public AWS IoT implementation for embedded rust. Ideally, that would build up on existing ideas, instead of creating a 2nd crate/implementation from scratch...