search

espressif / esp-aws-iot

AWS IoT SDK for ESP32 based chipsets
Apache License 2.0
257 stars 154 forks source link

Beta -- Order of Operations for Unified Code?? (CA-174) #80

Open SolidStateLEDLighting opened 2 years ago

SolidStateLEDLighting commented 2 years ago

mqttMutualAuth - MQTT_Init->TLS_FreeRTOS_Connect->MQTT_Connect

Jobs - TLS_FreeRTOS_Connect->MQTT_Init->MQTT_Connect

ThingShadow - TLS_FreeRTOS_Connect->MQTT_Init->MQTT_Connect

otaMQTT - MQTT_Init->TLS_FreeRTOS_Connect->MQTT_Connect

I have successfully used mqttMutualAuth to create Fleet Provisioning by Claim. It works for generating the new cert/key. But, you can't use the same algorithm to use the new cert/key to connect to the ThingShadow from some reason.

I then imported the new cert/key into the ThingShadow demo and it worked flawlessly.

I looked into all the mqtt based demo projects that I wanted to merge into my formal work.

It appears that we have some primary differences in the order of operations for Initializing and connected to the MQTT endpoint (as seen above).

Can anyone comment on the predictable way forward with one path which should work for all use cases?

SolidStateLEDLighting commented 2 years ago

I made it past my problem above. Shadow, Jobs, OTA all work with the cert/key provided by Fleet Provisioning method.