After all this time, and all the other units added, is there still not even basic support for the MIC unit?

@rob_d I've also had no luck with the PbHUB, even when using a single unit. Switching to a PaHUB things worked as expected.

In UIFlow, if I take an ENV sensor and hook it up to a port on the PbHUB, the program just gives me an error saying the unit wasn't found (and yes, I indicated the sensor was on the hub and selected to correct port). However, take the same unit and hook it up directly, or through a PaHUB, and everything is fine. I understand the PbHUB isn't suitable for using multiple sensors of the same type, but this is happening even with just a single sensor attached to the hub.

Looking at the latest set of units available in UIFlow, there seems to be good representation, except that the MIC unit seems to be completely missing. Considering that other more complex units are covered, is this just an oversight? Is there a reason the MIC unit is excluded from support? I picked up a stack of them for projects, but using this unit seems to immediately move me out of using UIFlow.

Thanks.

Thanks. I was hoping I'd missed some way to do this in UIFlow, as it is fun to knock up some code that way. But ... back to C for me.

It's disappointing to see no replies to this. It's such a central feature of the whole ESP32 family, that not seeing it supported in UIFlow and other examples here makes me seriously concerned if the M5Stack products are somehow more limited than the vanilla ESP32.

I’ve previously coded up ESP32 devices using C that boot the first time in AP mode, allow the user to connect and provide network information, then reboot in station mode. However, there don’t seem to be any examples in either Blockly or Python for the M5StickC.

This is pretty vital behavior when prototyping a consumer product. Does anyone have an example? Thanks.

I'm working on a project that involves monitoring bees inside a hive. Bees can't see red light, so it's great to use red LEDs to light up the inside of the hive. It doesn't make things too hot, and it doesn't disturb the bees -- it may even help cut down on disease.

However, all the cameras seem to have a red filter that makes it almost impossible to see anything, even when there are a lot of red LEDs. Is there any way to make the cameras work better in red light? Some what to remove the filter, or some version of the camera that works better in red light than others?

Thanks.

I created a number of programs about a month ago, some of which got quite complex. At the time the files (created between 5/30 and 6/5) saved and loaded without an issue, and after developing a prototype of an app, I ordered a dozen more units so we could put some some trials in the field.

But not none of these programs will load completely. When I try to load them, I get just a small part of the original program, sometimes part of the main loop, and even that is missing many commands. These programs were created using 1.5.4, but it doesn't seem to matter which version I use in attempting to load them.

I had put this StickC aside to work with another (I have a dozen or so of them). And then I ran into the same thing about ten StickC's later.

With both of these, it seems to be a screen failure. I can download a program, get the LED to flash, and even connect via network. But the screen remains dead -- even if I just run the burner and start the device over from scratch. I've also tried shorting BAT to GND, just in case, and get the same results. Another 8 StickC's working dandy (I was making a batch of prototype devices) but these two appear to have simply lost their screens.

So it's not really dead. It's just gone dark.

Yes, it sounds like this is what will be needed.

It would be great if UIFlow would just roll up the whole sequence of switching to AP mode, collecting the info, and reconnecting. It's such a standard behavior for ESP-based devices, that it seems like it should be baked-in.