Then probably the fact that Atom S3 currently supports only tiny subset of UIFlow features should be made clearer in the product description. I bought an Atom Matrix for a DIY watering project, was fairly impressed with the device (and the whole M5Stack concept) and decided that small local display for current humidity etc would be even better. So I bought the new AtomS3 (described as supporting UIFlow development platform) and currently can't connect it neither to my Watering sensors nor the MQTT data collection server. I will switch my development back to the Matrix and will be looking forward to switch it again when the features I need will be supported in UIFlow 2

@kawabatapaper said in M5Station-485: @ajb2k3 I'm still learning and it will take some time before I can share it. We recycle paper from waste paper at our factory. I would like to manage production by atacching M5Stack to various machines and taking values with sensors. I introduced M5Stack and Stick a few months ago, and now I can stably obtain 4 current values, send them to the database from Node-red, and manage them with Excel. If the test of Station goes well, I want to use Station a lot. There are many machines in our factory and the future is long, so please give me some advice if I have any more questions. Thanks Cool thanks, I’m still waiting on mine as it was stuck at the airport in china

Have you tried re writing for the core as there are pin differences

Just now, I have confirmed it to be downloadable. Thanks!

@yu_with_a_mission said in M5Burner does not work in MacOX 12.3.: @yopita I tried you way and get another error, "File"/Applications/M5Burner.app/Contents/Resources/packages/tools/serial/tools/list_ports_osx.py", line 32, in <module> kIOMasterPortDefault = ctypes.c_void_p.in_dll(iokit, "kIOMasterPortDefault") ValueError: dlsym(RTLD_DEFAULT, kIOMasterPortDefault): symbol not found ================= Burn Failed =================" How can I solve? System: MacOS Monterey 12.4 Device: M5StickCPlus There is an Issue Montery. Have you installed Xcode from the App Store? Have you instilled the latest Python 3 from the python site? Have you installed the drivers? Have you set the PATH variable correctly? Have you copied the M5Burner V3 to the Applications folder? Have you erased the controller first before writing the correct firmware?

@felmue, it does not have the sticker, so I'm going to assume it's version 2 based on that.

I have same problem , after some time EspNow recieve callback block returns duplicate message. Uiflow 1.10.7 , firmware m5 tough 1.10.6

@dario I had the same issue, using UiFlow Beta as a version I see UiFlow 1.8.2 and for both Core2 as well as Fire I can see and add them (the THERMAL unit). Only issue I personally now have is that I have a pretty unstable connection from the Fire or Core2 to the web IDE so I can't really apply the 1.8.2 blockly code. And the Desktop IDE at the moment is stuck at 1.7.5 that can't handle the files I save using version 1.8.2. Maybe for you with a stable UiFlow internet connection you can use version 1.8.2 to test and deploy your Thermal code. Make sure to ofcourse burn 1.8.2 to your device also.

@héctord It's actually the opposite as you describe. A higher layer takes visible priority. So when displaying text or shapes on the screen, an object on layer 8 is "on top of" (or covers over) an object on layer 3, and there is no transparency (see through). The tricky part is once you move your rectangle to highlight the next label, you have to redraw (or show) the changed areas of the screen. So the layers and screen management take some getting used to within uiFlow. Here is an example flow of what you are looking to achieve. Layers 0-3: reserved by uiFlow by default Layer 4: rectangle Layer 5: Label 1 Layer 6: Label 2 Layer 7: Label 3 Layer 8: Label 4 Note: In the M5StickC UI simulator on the left, you could manually change Labels 1 through 4 to all be on layer 5 and it will still work, since those labels do not overlap.

Hi @Nili while reading the touch IC (GT911) documentation I found that there is a mechanism which allows to select which of two I2C addresses should be used. Depending on how the touch INT line is driven by the ESP32 (low or high) when the reset line goes back to high, either I2C address gets selected. But since the touch INT line is connected to GPIO36 of the ESP32 and GPIO36 is an input only GPIO the ESP32 cannot drive it. From the ESP32 documentation: GPIO34-39 can only be set as input mode and do not have software pullup or pulldown functions. I further found that the 10k pull-up resistor (R87) on the touch INT line, listed in the schematics, is not populated in my M5Paper. I guess this mean when the touch IC is not driving the INT line it is floating and the touch IC could end up with either I2C address. Now, in the GT911 library I found the following code in function begin() which I tries to figure out which I2C address the touch IC actually started up with: Wire.beginTransmission(0x14); if (Wire.endTransmission()) { Wire.beginTransmission(0x5D); if (Wire.endTransmission()) { log_e("Touch screen IIC connection error"); return ESP_FAIL; } _iic_addr = 0x5D; } I wonder if that auto detect mechanism fails sometimes leaving the touch IC with one I2C address and the ESP32 trying to talk to it with the other? Thanks Felix

Hello, sounds interesting! right now you can already use the graphic on the left to add labels and other items and change it although full simulation is not available yet.

@ikabou Bug confirmed and reported, we will release a fix in the next update.