- 最新
- 最多得票
- 最多評論
Hi phirmware. Presumably that modem message length is TCP, not MQTT? Are you using AWS IoT SDK libraries to interact with IoT Core? If so, did you develop the transport interface? https://aws.github.io/aws-iot-device-sdk-embedded-C/202211.00/libraries/standard/coreMQTT/docs/doxygen/output/html/mqtt_porting.html#mqtt_porting_transport. It's normal for MQTT messages to be fragmented during transport. Can you share details about your modem?
One other question: can you perhaps use a different provisioning method than fleet provisioning (so you don't have to use this API)? This whitepaper may be useful: https://docs.aws.amazon.com/pdfs/whitepapers/latest/device-manufacturing-provisioning/device-manufacturing-provisioning.pdf
Dear phirmware, Please contact Sequans support at sequans-cloud@sequans.com to get a fix for the MQTT limitation that you are facing.
相關內容
- 已提問 6 個月前
- AWS 官方已更新 2 年前
- AWS 官方已更新 3 年前
- AWS 官方已更新 3 年前
- AWS 官方已更新 2 年前
Thanks for the answer Greg,
The modem chip itself (Sequans GM02s) is building the entire network stack all the way through MQTT; therefore I am not using the AWS IoT SDK since the modem is handling the MQTT. All I do is send what I want to send through the modems "AT+SQNSMQTTPUBLISH" command and subscribe using "AT+SQNSMQTTSUBSCRIBE" command and read data through the "AT+SQNSMQTTRECVMESSAGE". In the data sheet for AT+SQNSMQTTRECVMESSAGE it says "Currently only messages with payloads up to 1024 characters are supported."
I am trying to do fleet provisioning for scalability reasons. I need to create keys and certs for thousands of devices but don't want to flash them with their own separate keys and certs during the manufacturing process.
Thank for the info. If the modem is limiting the MQTT size, then yes that will be a problem for any larger messages. If you persist with this modem and a fleet provisioning by claim approach, you will not be able to use just the standard fleet provisioning APIs and yes I think you will need to develop something custom.