-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Command interface #54
Comments
IMHO a JSON command/payload structure that passes the (JSON) payload on to various handler functions sounds like it will do everything we need, and give a good reward/effort ratio. |
My suggestion and preference is to go to MQTT (or something else if there are good alternatives) as soon as possible. To me this seems much better for a bunch of reasons and it was the plan (#3) all along. There is the beginning of a no-std mqtt parser and some potentially reusable server code that may help. ffi-ing the paho bindings is probably not worth it. It doesn't look too hard to implement the rest. @astro seemed interested and I know @gkasprow has used mqtt for several of his projects. It would be great if we could get a student to lead this. no-std MQTT is a key building block for embedded Rust and I am pretty sure it would receive wide usage (certainly much wider than another cutsom json req-resp). |
I used MQTT from Arduino libs. It is also STM32duino so porting should be trivial. But it is not RUST... |
Or CoAP: Several implementations in Rust and no_std. |
And now there is embedded-mqtt, thanks to @ryan-summers for pointing it out. |
Do you have any examples for what you would consider a well-designed interface using MQTT? I am primarily interested in two interfaces for Stabilizer:
MQTT's pub-sub messaging model doesn't seem to be a good match for either, because of the obvious impedance mismatch in the first case, and the data rate in the second (particularly considering the limited on-device computing power). |
Mqtt is perfectly fine for the first use case (IIR configuration, streaming configuration, flag management, enable/disable, commands, request-response) and also for status monitoring at ~Hz rate. For full/high rate streaming data I see few other options than custom binary (using one of the many serialization options in rust). But streaming is not really within the scope of this issue. And JSON for streaming full-rate data is a terrible idea. |
E.g. look at the AWS IoT Core mqtt topic design guide. Example:
And then you could have the following MQTT topics (PUBLISH/SUBSCRIBE from device perspecitve):
Payloads TBD but could well be some JSON for e.g. straight telegraf/influxdb ingest or AWS IoT core compat. |
Forked into individual issues (see above). |
As we add more features to the firmware, we will need quite a few more commands, e.g. to commit settings to flash storage (#29), to configure high-bandwidth streaming, etc.
We could add more and more TCP ports that just directly parse lines into a given serde'd JSON type, but that seems like it would quickly become unwieldy. Another simple option would be to stick with a JSON object per request, but have a set command type/payload structure.
Any set ideas/preferences?
The text was updated successfully, but these errors were encountered: