How long a simple blynk.run() from examples complete? about lib-python

[kindmartin]

Adding related to this issue is that using BlynkLib from other source and almost same terminal or any other example like the ones at https://github.com/vshymanskyy/blynk-library-python blynk.run() is as fast is it has only takes 0.1 secs each round.
code between v0.2.6 and this other v0.2.1 (esp32) is not fully compatible and also isa oldes version seems with not new realeases. so I hope Im wrong with something or v0.2.7 provides better performance.

[antohaUa]

Hi kindmartin!
I am not sure that fully understand what kind of issues do you have:
Scripts allows you to have aka CLI session with ESP32 - do you see timing gaps in communication?
Or you just frustrated with such strange loop values = 60 seconds?

For ESP32 due to memory limitations I suggest check such things:

• script uploaded without doc headers ( everything until line 36 should be deleted )
• esp32/esp8266 allows to have compiled and optimized libraries in RAM
  please read "Micropython libraries compiltation" section from this doc
  https://github.com/blynkkk/lib-python/tree/master/examples/esp32
• after all optimized libs and scripts were loaded better to check available sys RAM

>>> import gc
>>> gc.collect()
>>> gc.mem_free()

Let's check these thing first and then continue investigation.

[kindmartin]

Thanks antoUa for replying. to explain my self better I just was saying that using this v0.2.6 library even using examples the time consumptions for blynk.run() loops is about one minute. I tried all, using a mpy byte code lib, extract all comments, etc, overclocking the ESP32, etc. ALL.
At the end this quarantine morning I moved back to the other library v0.2.1 from @vshymanskyy and all works perfectly, each loops only consumes 0.1 seconds, including timer.run from BlynkTimer lib. Also, I have a core running a ftp thread in one core and all this other script main.py loop working in background in other thread. now I have access via webrepl, ftp, serail repl working all very responsive (not blocked) plus my script.
I will retry next realease/ thanks/

<M

[antohaUa]

Kindmartin,
I have double checked behaviour described by you and seems we have only strange time numbers that does not reflect real time. For example I have used not time.time() but time.ticks_us call that shows time in microseconds and have such results:

---->> Delta RunLoop : 5119324
---->> Delta RunLoop : 3070375
---->> Delta RunLoop : 4096995
---->> Delta RunLoop : 5119370
---->> Delta RunLoop : 3071083
---->> Delta RunLoop : 1022475
---->> Delta RunLoop : 1024228
---->> Delta RunLoop : 2047899

But if to measure real time of command response with timer clock it will be less that 1 sec
You can ensure with this just frequently typing 'ls' command in terminal widget - all responses will be within 1sec ( max 2 sec).

Anyway i will try to investigate such strange situation with time displaying.
BTW what time import you have used for script under https://github.com/vshymanskyy/blynk-library-python ?
Can you share the whole test script with me? It may be helpful in scripts compare and further investigations.

[kindmartin]

I use same time import with the other lib, and blynk.run() just consume ~100ms, including timer.run()

I have two codes. I m learning python so it is not any clean or optimized, full of global variables usages, etc so for that reason I was back to basic examples check.

now im focus the other lib, that have other problem with text input widget updates messages from server to device. but I will like to help/

one coment, if I just use instead time.time() prints just prints like print('PRINTING NOW') I see those prints in the REPL console each minute, so no doubt blynk.run() do not pass fast to next command.
here the almost working code.

main.py.gz

[antohaUa]

I see the diff in imports import time ( your main.py) vs import utime as time ( terminal example)
If you will have time please double check what will be if for your micropython port you will use
example without utime - just import time call. I think this can be really port specific cause not all micropython systems can support such Cpython imports.

[antohaUa]

Closed (no reply for a long time). But feel free to re-open