Blynk in UIFlow

  • I think this BLE Blynk library is similar to the one used in UIFlow.

    There was a problem with a continuous call to blynk.virtual_write. blynk.virtual_write calls _write in class BlynkBLE, _write concatenates the data and sends the data when run() is called. The following code is part of class BlynkBLE.

        def _write(self, data):
            self.bout += data
        def run(self):
            while len(self.bout):
                data = self.bout[:20]
                self.bout = self.bout[20:]
                print('<', data)

    If you call multiple blynk.virtual_write() in a row as follows, data1 and data2 will be concatenated, and when run() is called, the concatenated data will be sent.

    blynk.virtual_write(1, data1)
    blynk.virtual_write(2, data2)

    In this case, the iOS Blynk app was unable to get the second data. Therefore, I added the call "" immediately after blynk.virtual_write as shown below.

    blynk.virtual_write(1, data1)
    blynk.virtual_write(2, data2)

  • @inasawa In this way, it works perfect.

  • @inasawa I am using the thonny editor for python code and it works great.

  • @inasawa Thank you very much for the information and help.

  • Hello. I'd like to inquire about if you experience any problems when using Blynk and EspNow with the native Blynk blocks in Flow? I ran into the problem that EspNow stops receiving when Blynk is initialized either in setup or main loop but this occured with a StickC+ and a Core, using custom blocks. I wasn't aware about the implemenentation of Blynk blocks for Fire and Core2 in Flow until I found this post.

    For the time being I use a brute force method as workaround, calling Blynk init and sending in a timer hourly and then resetting the StickC+ it's running on. But this method causes stress for a connected relay I'd like to avoid.

  • @anvalin

    I'm curious about your use of Blynk and ESPNow within the same program. I think they are overstepping on each other (blocking/flooding) and that is why you implemented a brute force to do the reset every hour. Blynk is selfish on timing and in general, you should always keep your Loop clean with just inside it.
    Even though that article is for Arduino, the same concepts with would apply to uiFlow/uPython.

    I would also think that if you have Blynk, you don't really need ESPNow (or vice versa), as they somewhat achieve the same thing. Though, I look at ESPNow as more of a point-to-point/multipoint communication protocol between hardware devices and Blynk is good if you want to have a smartphone app for visualizations/control vs. device screens and buttons. However, transmitting and receiving sensor data can be achieved by both protocols, so why duplicate? Again, just curious about your implementation... no disrespect.

  • In theory, ESP-NOW should prevent anything else working as it takes over the WIFI transmitter and connects it to another esp32 device preventing it connecting to the wifi.
    @world101 you are correct, ESPnow turns the device in to a point to point devices using the transmitter and preventing wifi coms.

  • Thanks @world101 and @ajb2k3 for your aid. Helps me understanding procedures. Regarding the parallel use of ESPNow and Blynk - my current project comprises 4 points of sensor readings in my garden - water levels, solar battery voltage, moisture readings from AtomLites via ESP to central devices (StickC and a Core later on) for processing (relays) - and an hourly update of values to my Blynk app. As said this works without Blynk being initiated in setup or main loop but a timer. I wonder if there's any other procedure to terminate the (http) Blynk connection after send other than executing a "machine.reset()" and re-run the main loop. Or maybe add another device receiving values via another method than wifi (ideas?) and sending to Blynk?

    Digging into this problem I already purchased two LoraWAN.COM bases to transmit values via TTN and use a Core at home as dashboard and Blynk "gateway". But this seems overwhelming right now and currently Flow modules are only working with the older (blue) bases. Hopefully there's an update coming soon.

  • I managed to send values via UART to an additional StickC - this will act as my Blynk relay. Will try to use an AtomLite for this purpose later on. And all other devices share data via ESPNow hassle free. Problem solved. Thanks again.

  • @anvalin
    Excellent. Seems like you have a nice a setup of products and functionality. Glad you got it all sorted out.

  • I came across a video last night (lost link) that shows that it should be possible to run ESPnow and WIFI at the same time on an esp32. apparently all you need to do is to set ESPNOW to work on a different channel to the WIFI.

  • Hi @ksprayberry @inasawa ,
    Sorry for that.The bug should be resolved, it was our fault, please try again and sorry again.

  • Thank you, @IAMLIUBO
    I have confirmed that it works fine with MicroPython generated from Blynk Blockly.

  • @ajb2k3 said in Blynk in UIFlow:

    I came across a video last night (lost link) that shows that it should be possible to run ESPnow and WIFI at the same time on an esp32. apparently all you need to do is to set ESPNOW to work on a different channel to the WIFI.

    @ajb2k3 Good hint. I will check my router to prevent using the channel I selected as common for the devices.