Raspberry Pi client disconnects after 20 seconds

Hi, all. I have been working on a very simple Raspberry Pi control prototype which works great for 20 seconds, leds light up on command, reed switches read perfectly, so on. I have been testing with the Blynk-library exactly as it exists in Github currently. I assume this means something in my specific use is causing the issue, but I haven’t been able to figure it out. At exactly 20 seconds the client stops processing data and the cpu usage jumps to 80%. I’ve run the client in debug and have used strace to see that the call that is looping is a ‘read()’ in BlynkSocket.h.

I don’t know a terrible lot about C++, so pointers would be really helpful. I have tried both the cloud server and have deployed my own. Both have the same result.

This has been reproduced on both RPi 1 B+ (over ethernet) and RPi Zero W (over Wifi). Same result on both.

This has been tested on both cloud and local servers. Same result on both.

Any ideas?

Since it has been repeatable over multiple devices, then it is likely in your code… of which we will need to see here before we can go any further.

Be aware, that this is NOT a code shop, we do not exist to troubleshoot your code, rather to help you learn how Blynk works… but let’s start with looking at what you have and seeing what, if anything, we can do from there :slight_smile:

Please format all posted code as per directed in the Welcome Topic, which you have read, correct?

Thank you, @Gunner

I assumed it was something in my code as well, so I blew my changes out and tested with the blynk.cpp exactly as it was pulled from github. Trying to start simple and add on til it breaks. The issue continued exactly the same; ie. the client CPU usage spikes and the IOS app reports a disconnected hardware.

To be clear, I am not asking for code lessons. I simply cannot get this service to connect for more than 20 seconds. I’ve posted the code below, per your request. Running this code allows my to send and read values on V1 as expect… for 20 seconds.

I believe you are correct that it is something on my end, but I haven’t changed the code make this happen. Therefore, I am thinking it is some other issue. Possibly networking? (I know you aren’t a networking troubleshooting shop, either) :wink: I have crawled through this source code for three or four days tracing and testing, but I cannot find 20 second timers or limits that would trigger this. I’m very confused. Thank you for responding.

The code:

 * @file       main.cpp
 * @author     Volodymyr Shymanskyy
 * @license    This project is released under the MIT License (MIT)
 * @copyright  Copyright (c) 2015 Volodymyr Shymanskyy
 * @date       Mar 2015
 * @brief
 */

//#define BLYNK_DEBUG
#define BLYNK_PRINT stdout
#ifdef RASPBERRY
  #include <BlynkApiWiringPi.h>
#else
  #include <BlynkApiLinux.h>
#endif
#include <BlynkSocket.h>
#include <BlynkOptionsParser.h>

static BlynkTransportSocket _blynkTransport;
BlynkSocket Blynk(_blynkTransport);

#include <BlynkWidgets.h>

BLYNK_WRITE(V1)
{
  printf("Got a value: %s\n", param[0].asStr());
}


void setup()
{

}

void loop()
{
  Blynk.run();
}


int main(int argc, char* argv[])
{
    const char *auth, *serv;
    uint16_t port;
    parse_options(argc, argv, auth, serv, port);

    Blynk.begin(auth, serv, port);

    setup();
    while(true) {
        loop();
    }

    return 0;
}

For what its worth, when I strace the client code and watch what calls are made starting about 20 seconds in, I see that this block from BlynkSocket.h is repeating:

size_t read(void* buf, size_t len) {
        ssize_t rlen = ::read(sockfd, buf, len);
        if (rlen == -1) {
            //BLYNK_LOG4("Read error ", errno, ": ", strerror(errno));
            if (errno == ETIMEDOUT || errno == EWOULDBLOCK || errno == EAGAIN) {
                return 0;
            }
            disconnect();
            return -1;
        }
        return rlen;
    }

While it is working, I get traces like this:

16:12:02.232626 read(4, "\24='\0\6", 5) = 5
16:12:02.244679 clock_gettime(CLOCK_MONOTONIC_RAW, {108545, 561753000}) = 0
16:12:02.245207 write(1, "[19757] READ HEADER:\n", 21) = 21
16:12:02.248908 clock_gettime(CLOCK_MONOTONIC_RAW, {108545, 566057000}) = 0
16:12:02.251629 write(1, "[19762] >[14]='[00|06]\n", 23) = 23
16:12:02.255150 read(4, "vw\0000\0000", 6) = 6
16:12:02.256719 clock_gettime(CLOCK_MONOTONIC_RAW, {108545, 573774000}) = 0
16:12:02.258726 write(1, "[19769] PROCESS INPUT:\n", 23) = 23
16:12:02.261993 clock_gettime(CLOCK_MONOTONIC_RAW, {108545, 579184000}) = 0
16:12:02.263467 write(1, "[19775] >vw[00]0[00]0\n", 22) = 22
16:12:02.265439 clock_gettime(CLOCK_MONOTONIC_RAW, {108545, 582594000}) = 0
16:12:02.269220 read(4, 0xbeb8b470, 5)  = -1 EAGAIN (Resource temporarily unavailable)
16:12:02.282699 read(4, 0xbeb8b470, 5)  = -1 EAGAIN (Resource temporarily unavailable)
16:12:02.302647 read(4, 0xbeb8b470, 5)  = -1 EAGAIN (Resource temporarily unavailable)
16:12:02.322642 read(4, 0xbeb8b470, 5)  = -1 EAGAIN (Resource temporarily unavailable)

Once is stops working this trace looks like this forever:

16:12:02.502669 read(4, "", 5)          = 0
16:12:02.518190 read(4, "", 5)          = 0
16:12:02.518640 read(4, "", 5)          = 0
16:12:02.523106 read(4, "", 5)          = 0
16:12:02.526461 read(4, "", 5)          = 0
16:12:02.527027 read(4, "", 5)          = 0
16:12:02.527450 read(4, "", 5)          = 0

OK, it seems you are using some of the original WiringPi based Blynk libraries… well, based on the date in the headers that is.

I do not know much about the WiringPi option… I changed course long ago toward the Node.js method as it seems a more common language for RPi.

So basicly, I haven’t a clue what could be the issue… but I can point you to a few more recent topics using the WiringPi method… perhaps you just need to update whatever needs updating? Perhaps the Blynk Library or even the version of WiringPi?

Thanks again, @Gunner

I may just switch over to Node if updating doesn’t work. I was under the impression that the Node documentation and implementation was not quite baked at the moment, but if you recommend using it (as it sounds like you do) I can give it a try.

I’ll report back results shortly!

Well… they are BOTH half baked in my opinion :stuck_out_tongue: … but there does seem to be a more common flow between Blynk and non Blynk javascript examples.

However, one of the biggest issues with Node.js is that there are very few examples of how to port over various Blynk commands, as the syntax is vastly different at times from C++ So I spend a lot of time making up my own syntax until it either works, sorta, :thinking:or I give up :wink:

Hahaha. Fair enough. As long as I can get the thing to connect and stay connected, I don’t care if it is C++ or JS. :joy:

It at least gives me something else to try out

This is my current Node.js test script. It is set to access my Local Server so you will need to modify that for your own or for the Cloud.

There is not a lot here (I am just getting back into it after the summer) and there are components that you will not have in the “running OLED & PiCamera applications” portion, but this might give you some buttons to push and displays to read.

const raspi = require('raspi');
const pwm = require('raspi-pwm');
const wled = new pwm.PWM('GPIO18');

var Gpio = require('onoff').Gpio;  // links variable 'Gpio' to the all important onoff GPIO control library
var Blynk = require('blynk-library');  // Links variable 'Blynk' to the Blynk Library
var AUTH = '05efcb6axxxxxxxxxx29eab9612';  // My top secret auth code... useless to anyone on the cloud ;P
var blynk = new Blynk.Blynk(AUTH, options = { connector : new Blynk.TcpClient( options = { addr: "xxx.xxx.xxx.xxx", port: 8442 } ) });  // This takes all the info and directs the connection to my Local Server.
var process = require('child_process'); // Allows this script to run CLI commands
var vOrangeLEDintensity = 0;
var WhiteLEDintensity;
var v0 = new blynk.VirtualPin(0);  // Setup Button Widget on V0 with variable 'v0'
var v1 = new blynk.VirtualPin(1);  // Setup Button Widget for Orange vLED
var v4 = new blynk.VirtualPin(4);  // Setup Slider Widget for vLED intensity
var v5 = new blynk.VirtualPin(5);  // Setup Button Widget for OLED Invaders Demo
var v6 = new blynk.VirtualPin(6);  // Setup Display Widget for vLED intensity value
var v7 = new blynk.VirtualPin(7);  // Setup Button for OLED PiCamera Photo Demo
var v9 = new blynk.VirtualPin(9);  // Setup Display Widget for Seconds
var v10 = new blynk.VirtualPin(10);  // Setup Orange vLED Widget 
var v11 = new blynk.VirtualPin(11);  // Setup Display Widget for Minutes
var v12 = new blynk.VirtualPin(12);  // Setup Display Widget for Hours



// Vary the intensity of White LED
v0.on('write', function(param) {  // Watches for V0 Slider
WhiteLEDintensity = param;
console.log(WhiteLEDintensity);  // prints value to CLI
wled.write(parseFloat(WhiteLEDintensity/10));  // Sends PWM value to Physical LED (GPIO18)
});



// Activates the Orange vLED
v1.on('write', function(param) {  // Watches for V1 Button
  console.log('V1:', param[0]);  // prints value to CLI
  if (param == 0) {
    blynk.virtualWrite(10, 0);  // V10 Widget (ORANGE) LED OFF
  } else if (param == 1) {
    blynk.virtualWrite(10, vOrangeLEDintensity);  // V10 Widget (ORANGE) vLED ON
  }
});

// Vary the intensity of Orange vLED
v4.on('write', function(param) {  // Watches for V4 Slider
vOrangeLEDintensity = param;
console.log(vOrangeLEDintensity);  // prints value to CLI
v10.write(vOrangeLEDintensity);
v6.write(vOrangeLEDintensity);
blynk.syncVirtual(1);  // Runs the button funtion to update the vLED
});



// Run the OLED Example Invaders
v5.on('write', function(param) {  // Watches for V5 Button
  console.log('V5:', param[0]);  // prints value to CLI
  if (param == 1) {  // Runs the CLI command if the button on V5 is pressed
    process.exec('python /home/pi/luma.examples/examples/invaders.py -d ssd1331 -i spi --width 96', function (err, stdout, stderr) {
      if (err) {
        console.log("\n" + stderr);
      } else {
        console.log(stdout);
      }
    })
  }
});



// Run the cOLED example PiCamera Photo
v7.on('write', function(param) {  // Watches for V5 Button
  console.log('V7:', param[0]);  // prints value to CLI
  if (param == 1) {  // Runs the CLI command if the button on V5 is pressed
    process.exec('python /home/pi/luma.examples/examples/picamera_photo.py -d ssd1331 -i spi --width 96', function (err, stdout, stderr) {
      if (err) {
        console.log("\n" + stderr);
      } else {
        console.log(stdout);
      }
    })
  }
});



// Clock Time Displays
v9.on('read', function() {  // Widget calls for data
  v9.write(new Date().getSeconds());  // Sends the seconds 0-59 to the Display Widget
});
v11.on('read', function() {  // Widget calls for data
  v11.write(new Date().getMinutes());  // Sends the seconds 0-59 to the Display Widget
});
v12.on('read', function() {  // Widget calls for data
  v12.write(new Date().getHours());  // Sends the seconds 0-59 to the Display Widget
});



button = new Gpio(17, 'in', 'both');  // Sets up the BCM pin 17 as an input registering both rising and falling for the variable "button"
button.watch(function (err, value) {  // Watches for button press and assigns 0/1 to value
  if (err) {
    throw err;  // Some form of error handling
  }
  if (value  == 0) {
    blynk.virtualWrite(2, 0);  // V2 Widget (BLUE) LED off
    blynk.virtualWrite(3, 255);  // V3 Widget (RED) LED on
  }   else if (value == 1) {
    blynk.virtualWrite(2, 255);  // V2 (BLUE) Widget LED on
    blynk.virtualWrite(3, 0);  // V3 (RED) Widget LED off
  }
});

Thanks for this! I’m far more comfortable in JS.

I started thinking about some potentials (like half-baked builds…) while reading the thread you sent and decided to roll back to a previous release of the libraries. The version I’ve been using is the current beta release 0.5.0 from github. I just tried 4.10 and it is looking good so far.

Maybe this thread could be a candidate for a bug hunt? I’ll keep the 0.5.0 on the hardware for reference in case logs or testing could be helpful to anyone.

@Gunner :point_up:

1 Like

@Gunner could you please make the screenshots a little larger for my failing eyesight.

Hehe… What? I can’t hear you due my failing ears :stuck_out_tongue:

When I changed phones I went from a Quad HD 16:9 phablet to a Quad HD 18:9 skinny phone, the overall size of the image didn’t change, but the aspect ratio did… Unfortunately Discourse (sometimes?) seems to chop and display the top 3rd of that aspect ratio in full width instead of the whole tall n skinny as “normal”.

I guess it actually takes up less vertical space… but does look a little “in yer face” :wink: and you have to click on the image to see all of it… I don’t like it either.

Thanks, everyone, for chipping in on this. My mind is reeling with possibilities right now. Looking forward to building.

:point_up: @Gunner, you especially!

Hi,

I’m having the same problem. After about 20 seconds, the raspberry Pi client disconnects.

I will try roll back to a previous release of the libraries.

Thanks,

It’s work.

Thank you @invalid_ref!

1 Like

Good deal! I have not made time to hunt for the cause of the disconnect, but I don’t know my way around C++ more than a little hacking here and there so I’m not confident that I will find anything helpful anyway. :wink:

Glad to hear you got your project rolling!

Cheers, @contadini

Roll back to Blynk V 0.4.10 - something in version 0.5.0 causes problems on the Pi 3

*and Pi2 and Pi1. This is what I was referencing here:

1 Like

Just a reminder to any RPi users… That is only an option if you are using the WiringPi version of Blynk Client… not the Node.JS version.

And it can get a bit confusing as to which method (C++ or NodeJS) is used when referring to RPi Blynk client sketches :wink:

1 Like