-
Notifications
You must be signed in to change notification settings - Fork 6
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
(feature request): MQTT Retained message support between local broker and IoT Core #77
Comments
Hi, thanks for raising this. Unfortunately this is an issue with the MQTT3 spec itself. The protocol does not provide enough information for us to know whether we should forward a message to another server with the retained bit set. MQTT5 does support this, however, so this can potentially be supported in the future once that is available in IoT Core. |
What I would suggest doing, for now, is to add a prefix on topics which must follow this standard. You can set up a rule in IoT Core to forward those messages to a Lambda function, which can re-publish to the original topic with the retained bit set. https://docs.aws.amazon.com/iot/latest/developerguide/iot-rule-actions.html Take a look at the |
@jbutler Thanks for the suggestion to use lambda + IoT rule as a workaround to republish the messages. I'll give it a try. Would be great to see IoT Core support for MQTTv5 so this limitation can be resolved. I see that Greengrass already supports MQTT v5 so I hope IoT Core supports MQTTv5 soon as well. |
@shumailxyz Let me know how it goes. Do you need both directions? Or is Greengrass to IoT Core sufficient? |
@jbutler Worked for Greengrass to IoT Core using iot-rule & Lambda. Any ideas if we can receive retained messages on Greengrass client using some workaround while we wait for official support to be added? Thanks. |
The workaround in the reverse direction is somewhat ugly. You could follow a similar pattern, except replace iot rule + lambda with another client device which republishes with the retain bit set. You could deploy this client device as a Greengrass component -- the key is that it would need to connect directly to the broker rather than via PubSub. Alternatively, we could also add additional publish parameters as part of the topic mapping configuration. For example, something like this:
...where I'm not sure when we can get around to implementing this, but we'd certainly accept a PR if you're willing to help out. |
@shumailxyz we just released MQTT5 support for bridge, which supports retain-as-published. Please note that retain as published isn't yet supported on IoT Core, so this will only work for LocalMqtt -> IotCore bridging. So this half solves your use case :) To enable, upgrade to bridge 2.3.0 and set add the following configuration:
|
Describe the bug
I am running MQTT bridge on GG core, configured to forward messages between
LocalMqtt
toIotCore
and vice versa. The bridge does not work with MQTT retained messages. When local client device publishes a retained MQTT message on a topic, forwarded by bridge to IotCore - new subscription of IotCore does not receive the retained message.To Reproduce
from_local/test
.from_local/test
.Expected behavior
A local client device publishes a retained MQTT message on a topic, forwarded by bridge to IotCore. I expect that when a new client on AWS IoT Core subscribes on that topic, it receives the retained message.
Actual behavior
When a new client subscribes on topic, it does not receive the retained MQTT message.
Environment
Additional context
We use a specific standard VDA5050 for AGVs - Automated Guided Vehicles (client devices) that requires messages on some specific topics to be sent with RETAINED flag set to true. The services running on AWS cloud following that standard must follow the standard and should be able to receive RETAINED messages sent by local client devices (that communicate through GG core & bridge).
The text was updated successfully, but these errors were encountered: