Posts made by anvalin

EzData 1 is running again, but the outages occur more and more often.

Hello everyone,
EzData with UiFLow1 stopped working a fortnight ago and currently doesn't accept new topics and refuses interaction with (my) ESPs. Web interface and Remote+ still are available but data section remains empty even when generating a new token. Anybody at M5 involved in this can give us a hint if and when it'll work again? Is there any roadmap for this databroker?

Switching to UiFlow2 seems to be a necessity in the near future. Unfortunately its EzData2 iteration still lacks a web dashboard. Any idea if this is going to be a planned featured?

Which firmware version are you using?

| Experienced problems pushing data to EZData with 1.9.8 on Atoms. Reproduceable error not occuring after reverting to firmware 1.9.7.

@ajb2k3 Kind of. I am using push of data in a time-based function (UIFlow). Tried normal and async save methods of a string and an integer. The Atom then freezes without transmission and the function is never terminated. Previous Firmware 1.9.7 allows continuous transfers of two values and reverts to the main loop after finishing the function.

Experienced problems pushing data to EZData with 1.9.8 on Atoms. Reproduceable error not occuring after reverting to firmware 1.9.7.

COM.LoRaWAN Module 868MHz V2.0 (ASR6501, product code MS03031-C4) is now listed at retailers. Hopefully this new module will finally see full UIFlow support.

@chefrocker Upvoting your request since I am waiting for the same. Unfortunately the 868 module seems to need a firmware update to match the same set of AT commands as the others. See https://community.m5stack.com/topic/3199/uiflow-1-7-5/11 for details.

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

Hi Dragon.
Picking up this thread because I ran into the same problem. Caused by an empty value when out of sync with the sender in a P2P network transmission scheme (not ESP related but similar). Resulting as "None" for a value that should be converted into an integer used in an if/else process. I solved this by putting the if/else in a try/except statement and settting the except(ion) to a failsafe value until sync.