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

Run without serial monitor connection? #27

Closed
dsghi opened this Issue Oct 25, 2018 · 9 comments

Comments

Projects
None yet
3 participants
@dsghi
Contributor

dsghi commented Oct 25, 2018

Using the example apps; I've tried the temp/humidity and also the button. If I have the Arduino studio open with the serial monitor connected, everything runs great. If I disconnect my USB connection and try to run stand alone, it never fully loads up or sends data. I do get the blue LED, but that's about it. Is there code that I need to change?

@vingarzan

This comment has been minimized.

Contributor

vingarzan commented Oct 25, 2018

This is something that we've also experienced. We're experimenting towards a good solution. Unfortunately, for that, we might have to modify a bit the board base library, as the issue is below our Breakout library.

The SerialDebugPort (aka USB interface) which we use for logging is set to blocking mode. When the buffer fills up, the board base library does not have the function to detect if the USB is actually connected, so it just hangs in there. You will observe that plugging in the USB port fixes it for a bit, but after unplugging, the buffer will fill up again. Setting the port to non-blocking mode is not ideal, as the outputs get truncated and the output is unreliable.

One temporary fix which you can use for now would be to disable logging altogether from here https://github.com/twilio/Breakout_Arduino_Library/blob/master/src/BreakoutSDK/utils/log.h#L37 . Also avoid using SerialDebugPort.print() or anything like that.

We're testing the auto-detecting workaround, which we hope will combine both logging + CLI and stand-alone mode. We'll notify you here if and when that would be available.

Thank you for your feedback!

@dsghi

This comment has been minimized.

Contributor

dsghi commented Oct 26, 2018

Thanks for the quick reply, wasn't sure if I was doing something wrong. Nice to know I'm not dumb. ;)

The kit is Alpha, so totally understandable. Disabling logging is a fair work-around. The ability to enable circular logging to micro-SD would be a nice option; If a device acts up in field, we could pull the SD to look at it.

@vingarzan

This comment has been minimized.

Contributor

vingarzan commented Oct 26, 2018

Logging to SD is a cool idea! We have not considered it yet, but I think it should be fairly easy to modify the logging system to mirror or redirect the output there.

@dsghi

This comment has been minimized.

Contributor

dsghi commented Oct 29, 2018

Unfortunately with logging off, my unit stops responding after about 45 minutes. Of course, no idea why. LOL!

My setup is sending a single message every minute. I haven't tried to see how long it'll run with logging enabled, so this doesn't exactly mean much.

Any suggestion on what the best troubleshooting path would be? I'm wondering if it's a network related issue, is there any default retry logic if it has an issue sending the messages?

@dsghi

This comment has been minimized.

Contributor

dsghi commented Nov 5, 2018

I've deployed the latest updates with #28, plus what's suggested in #29 for my temp/humidity readings. Stability has improved, thank you. I haven't had the board stop responding since updating. However, I do still notice random transmission dropouts that are between 5-10 minutes before it will resume. Is this normal?

Log looks like this:

�[00;49m�[00;49m19:12:40.052 �[01;36mNOTI reinitialize():223 remote_ip=54.145.1.94:5684 - already connected - cycling everything
�[00;49m�[00;49m19:12:40.103 �[01;32mINFO sendUDP():497 Sent data over UDP on socket 0 31 bytes
�[00;49m�[00;49m19:12:40.103 �[01;36mNOTI close():339 Close error=0
�[00;49m�[00;49m19:12:40.305 �[01;32mINFO sendUDP():497 Sent data over UDP on socket 0 67 bytes
�[00;49m�[00;49m19:12:40.305 �[01;32mINFO handler_CoAPDTLSEvent():822 
>>>
>>>DTLS-Event>>> From 54.145.1.94:5684 - level 0 (<unknown>) code 476 (tinydtls_event_connect)
>>>
�[00;49m�[00;49m19:12:40.305 �[01;36mNOTI reinitializeTransport():331 .. CoAPPeer - waiting for transport to be ready (DTLS handshake)
�[00;49m�[00;49m19:12:41.057 �[01;32mINFO processURCReceiveFrom():258 Receive URC for queued received-from data on socket 0 of 60 bytes
�[00;49m�[00;49m19:12:41.160 �[01;32mINFO sendUDP():497 Sent data over UDP on socket 0 99 bytes
�[00;49m�[00;49m19:12:42.212 �[01;32mINFO processURCReceiveFrom():258 Receive URC for queued received-from data on socket 0 of 120 bytes
�[00;49m�[00;49m19:12:42.316 �[01;32mINFO sendUDP():497 Sent data over UDP on socket 0 46 bytes
�[00;49m�[00;49m19:12:42.369 �[01;32mINFO sendUDP():497 Sent data over UDP on socket 0 14 bytes
�[00;49m�[00;49m19:12:42.421 �[01;32mINFO sendUDP():497 Sent data over UDP on socket 0 53 bytes
�[00;49m�[00;49m19:12:44.275 �[01;32mINFO processURCReceiveFrom():258 Receive URC for queued received-from data on socket 0 of 67 bytes
�[00;49m�[00;49m19:12:44.328 �[01;32mINFO handler_CoAPDTLSEvent():822 
>>>
>>>DTLS-Event>>> From 54.145.1.94:5684 - level 0 (<unknown>) code 478 (tinydtls_event_connected)
>>>
�[00;49m�[00;49m19:12:44.378 �[01;36mNOTI reinitializeTransport():348 ... CoAP Peer is ready.
�[00;49m�[00;49m19:12:44.378 �[01;36mNOTI reinitializeTransport():349         B R E A K O U T - re
�[00;49m�[00;49m19:12:44.378 �[01;36mNOTI reinitializeTransport():350 ???????????????????????????????
�[00;49m�[00;49m19:12:44.378 �[01;36mNOTI reinitializeTransport():351 ???????????????????????????????
�[00;49m�[00;49m19:12:44.378 �[01;36mNOTI reinitializeTransport():352 ???????????????????????????????
�[00;49m�[00;49m19:12:44.378 �[01;36mNOTI reinitializeTransport():353 ¦¦¦¦¦¦¦¦   ¦¦¦¦¦¦¦   ¦¦¦¦¦¦¦¦¦¦
�[00;49m�[00;49m19:12:44.379 �[01;36mNOTI reinitializeTransport():354 ¦¦¦¦       ¦¦¦¦¦¦          ¦¦¦¦
�[00;49m�[00;49m19:12:44.379 �[01;36mNOTI reinitializeTransport():355 ¦¦¦¦                       ¦¦¦¦
�[00;49m�[00;49m19:12:44.379 �[01;36mNOTI reinitializeTransport():356 ¦¦¦¦                      ¦¦¦¦¦
�[00;49m�[00;49m19:12:44.379 �[01;36mNOTI reinitializeTransport():357                                
�[00;49m�[00;49m19:12:44.379 �[01;36mNOTI reinitializeTransport():358                                
�[00;49m�[00;49m19:12:44.379 �[01;36mNOTI reinitializeTransport():359                                
�[00;49m�[00;49m19:12:44.379 �[01;36mNOTI reinitializeTransport():360                                
�[00;49m�[00;49m19:12:44.379 �[01;36mNOTI reinitializeTransport():361                                
�[00;49m�[00;49m19:12:44.379 �[01;36mNOTI reinitializeTransport():362                ?               
�[00;49m�[00;49m19:12:44.379 �[01;36mNOTI reinitializeTransport():363      ????????????????          
�[00;49m�[00;49m19:12:44.432 �[01;32mINFO sendUDP():497 Sent data over UDP on socket 0 89 bytes
�[00;49m�[00;49m19:12:44.432 �[01;32mINFO sendReliably():427 remote=54.145.1.94:5684 - sent 60 bytes
�[00;49m�[00;49m19:12:44.432 �[01;32mINFO checkForCommands():653 Sent a POST /v1/Heartbeats - next one is in 600 seconds
�[00;49m�[00;49m19:12:44.432 �[01;32mINFO callback_checkForCommands():583 Transport reinitialized and re-polling started
�[00;49m�[00;49m19:12:46.435 �[01;32mINFO processURCReceiveFrom():258 Receive URC for queued received-from data on socket 0 of 39 bytes
�[00;49m�[00;49m19:12:46.487 �[01;32mINFO dtls_handle_message():3973 ** application data:
�[00;49m�[00;49m19:12:46.487 �[01;36mNOTI readFromPeer():90 Received 10 bytes over DTLS
�[00;49m�[00;49m19:12:46.487 �[01;32mINFO callback_checkForCommands():567 Received ACK for polling - transport is working
�[00;49m�[00;49m19:12:46.487 �[01;34mWARN handler_CoAPResponse():930 Received 2.01 Response Created for unknown Request
�[00;49m�[00;49m19:12:46.487 �[01;34mWARN CoAP Message  Version 1  Type 2 - Acknowledgement  Code 2.01 - Response.Created  Message-Id 60679  Token 0x9d09d7
�[00;49m�[00;49m19:12:46.487 �[01;34mWARN  - CoAPOption 50000 (Twilio-Queued-Command-Count): 0```
@rbeiter

This comment has been minimized.

Contributor

rbeiter commented Nov 5, 2018

@dsghi How often are you sending update commands? It is possible you are hitting a DTLS/NAT related timeout we are in the process of resolving. As a temporary work-around, we would recommend you setPollingInterval to a maximum of 60 seconds. This will keep the NAT alive and the DTLS session current until we resolve the issue.

@dsghi

This comment has been minimized.

Contributor

dsghi commented Nov 5, 2018

OK, I will change to 60 .. I have breakout->setPollingInterval(10 * 60); from the original sample code. Thank you! :)

@dsghi

This comment has been minimized.

Contributor

dsghi commented Nov 8, 2018

To provide feedback, after implementing the change you suggested @rbeiter, the last two days have been much more stable.

@dsghi

This comment has been minimized.

Contributor

dsghi commented Dec 16, 2018

I am going to close this issue, I've been running the kit for a coupe weeks now on it's own without logging attached and haven't had any related issues. Thanks!

@dsghi dsghi closed this Dec 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment