-
Notifications
You must be signed in to change notification settings - Fork 76
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
Sketch stops updating AWS IoT after some period of time #55
Comments
Hi @eczajk1 , Thank you very much for providing the information. From the log you provide, it seems that there is no new incoming messages for the yield call to dispatch, which means there is no incoming messages from the subscription (shadow/non-shadow). Can you print out the received response on 32u4 from AR9331 when you are experiencing the yield failure? I would like to exclude the possibility of a serial1 communication issue. Thanks, |
I am not certain what you are asking for here. Here is a snippet from the Serial monitor:
The AR9331 log output pasted previously was logged using this guidance this message. |
Hi @eczajk1 , What I mean is the output from the Serial1 connection from AR9331 to ATmega32u4. You can find the details instructions here: #47
Basically I would like to know what gets transmitted over the Serial1 connection to ATmega32u4 that results in a yield failure. Thanks, |
Thanks! But, I'm not seeing anything extra:
|
Hi @eczajk1 , Thank you very much for providing the information. If you take a look at the lines near where "Yield failed" happens, you can find the following:
The first inter-chip protocol seems to be broken, resulting in a yield failure. SDK logic details can be found here: This could be caused by byte loss in serial1 communication. Provided that yield is a frequently invoked call. What we can do here is just simply retry "contacting" the linux chip. Apart from this, what is more interesting is that, on successful yield attempts, there is no further messages routed back to 32u4. From the logs on Python runtime that you previously attached, there is no explicit incoming messages from the cloud being captured as well. I would suspect that the client might get disconnect or the subscriptions some how get lost. To further detect the issue, you can utilize the AWS IoT Lifecycle events to detect if the client is connected/disconnected/subscribed. I would like to confirm if there is any silent disconnect happened when you were experiencing the issue. Thanks, |
Are you saying that this is a technique that could be implemented in the Sketch itself? I subscribed to the Lifecycle Events using the AWS IoT MQTT client. But, so far, I have not seen any unexpected
|
I have tried listening on on Lifecycle events several times in the last week. But I am still experiencing the same issue while not seeing ANY lifecycle events showing up. I only see them when the sketch is first started. Any advice on actions I can take to further diagnose this issue? |
@eczajk1 Are you still facing this issue? |
Yes, I was not able to resolve it. |
I have been working with a sketch that reads from some different sensors and reports values to AWS using Thing Shadows. Things seem to work up until some point when the sketch seems to lose its ability to do updates. I have had a hard time pinpointing the issue, so I tried to use a slight modification of
ThingShadowEcho
example, where the loop function looks like this:Things mostly work. Over the period of several hours I do get a handful (9) 'Yield failed.` errors. It is hard for me to tell from the logs, but I believe the shadow updates stopped working somewhere in the vicinity shown below.
Can you offer any pointers on why this would be happening? Am I just trying to do updates too often? If so, is there a recommended minimum interval?
The text was updated successfully, but these errors were encountered: