@iamliubo Thanks for the info. I wonder about wether it's going to be possible to upgrade firmware of said LoraWAN module M031-C. How can this be done?

When connecting Burner or UI.FLow to a M5Stack account a device management is available to bind devices. Yet this tool is somehow cumbersome to use since the only device identifier is a MAC adress - a note field could let users add an own identifier / note on the currently used API key.

Hi @sodoku
first COM.X LoraWan blocks became available with UI.Flow 1.7.5. Unfortunately still no support for the european frequency model.

I now run a public TTN gateway myself covering a portion of the Gleisdreieck area filling a blind spot. Hopefully adding an external LoraWan antenna with higher gain will solve my range problem at my nodes location - half a kilometre distance in a dense urban area can really be a show stopper with LoraWan when there's no gateway around ;)

Hello @teddygag.
I have experienced this before with a Stick-C+. Maybe the same fix might work for you:
https://forum.m5stack.com/topic/1815/bricked-m5stickc-after-bad-axp192-config/4

I succeeded in reviving it with a simple paperclip :) But please do some research first on wether you might need to add a capacitor when doing the same with your Fire.

1.7.5 is supporting only COM.X LoraWan 470 and 915 modules but not the 868 MHz version M031-C?

I can confirm they are for M2 screws. E.g. for mounting a stick on the battery stick you'll need M2x10mm like shown here https://m5stack-store.myshopify.com/collections/m5-hat/products/m5stickc-18650 Turns the Stick into a nice handheld device for mounting a joystick, thermometer etc.

@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.

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.

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.

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.