Skip to content
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

Broken connection to cloud server is not detected with Ping and never restored #18

Closed
ondrej1024 opened this issue Sep 17, 2019 · 5 comments

Comments

@ondrej1024
Copy link

There is an issue with the connection monitoring with the Ping mechanism.

This can be reproduced with this simple example program:

import blynklib
import time


BLYNK_AUTH =  # insert your Auth Token here

CONNECT_PRINT_MSG = '[CONNECT_EVENT]'
DISCONNECT_PRINT_MSG = '[DISCONNECT_EVENT]'

@blynk.handle_event("connect")
def connect_handler():
    print(CONNECT_PRINT_MSG)

@blynk.handle_event("disconnect")
def connect_handler():
    print(DISCONNECT_PRINT_MSG)

###########################################################
# infinite loop that waits for event
###########################################################
while True:
    blynk.run()

When running this program with a working network connection it prints the [CONNECT_EVENT] message but when unplugging the network cable the disconnect event is never printed. When plugging the cable back in the connection is not restored.

This seem to be due to the is_server_alive() check in the blynk lib. The following statement never returns False:

        if rcv_delta > h_beat_ms + (h_beat_ms // 2):
            return False

because rcv_delta is always 0 as _last_rcv_time is updated after each receive(), even if this fails.
Can someone of the developers here please have a look at this? Thanks.

@antohaUa
Copy link
Collaborator

Hi ondrej1024!
I have tried scenario described by you locally and unfortunately... was not able to reproduce it.
Could you please provide more details:

  • library version
  • HW that is used
  • maybe timing steps to reproduce. Aka "..wait for disconnect then unplug cable" etc
  • you have dhcp or static ip ?

Below you can find my test script with enabled logging, that can be used for investigation.
BTW you can add also debug logs into library ( aka self.log('Value={}'.format(some_variable))
With such debug logs you can check your rcv_delta values.

Hope you will be lucky to find weak or buggy place.
Inform me please about results
Also added my test logs where you can see that connection was restored after some time by itself.
connect_dissconnect.txt
connect_test.txt

@ondrej1024
Copy link
Author

Hi antohaUa,
thanks for looking into this issue.

Please note that in order to reproduce the problem you should not run the connect_disconnect example code but the one I pasted above. Because when the blynk.disconnect() method is called like in the example code you used then it works fine.

However if the code just connects and then waits it will not detect the network cable being unplugged. The problem is with detecting a broken network connection due to external events, not with a disconnection initiated by the device itself. So please try to reproduce the issue with the code I posted (or just remove the blynk.disconnect() from your test code).

I can also provide detailed debug output but will need more time. Meanwhile here is some more information:
library version: lastet from github
HW: RaspberryPi 3
IP from DHCP server

@antohaUa
Copy link
Collaborator

Hi ondrej1024!
Really this is nice bug catch from your side! Thx!

I have added fixes - please update library to latest and try run your test again.
Hope disconnect/connect procedures now will go in correct way.

Also one minor note: pay attention that in your example you have two functions with the same name("connect_handler"). I know that it was "bad" naming from my side)) you just done copy-paste)). Fix also committed from my side for 03_connect_disconnect.py example. Often such duplicates presence - great field for different bugs and "strange behaviour". Better to have unique names within single python file.

Good luck!

@ondrej1024
Copy link
Author

Thanks for fixing this so quickly. 👍
I tried with the latest library version and it is working as expected now.

I had noticed the duplicate function name in the 03_connect_disconnect.py example code but it didn't seem to make any difference. But you are right, of course. It could have unexpected side effects so it's good to have that fixed as well.

@antohaUa
Copy link
Collaborator

Great news! Issue can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants