@robert do you know?

Sorry, Divadiow, I do not.

I've already publicly chastised them for ignoring customer issues here for too long.

When Bouffalo was moving with the BL602/BL604, I even really liked the parts and even tried to help vendors track the official BL SDK. Then it split.

Between IOT, SDK, SDK_TINY, COMPONENTS, SDK_APP, ISP, the various LINUX mutants and the dichotomy of the quality, conforming SiFive cores and the T-Head cores that tend to play more loose with the RISC-V specifications and don't even support my preferred build environment, I'll admit that I've kind of detached in recent quarters. That's before we even get into branches of any of the above trees.

For example, Nuttx and Arduino were announced as an supported SDKs a while ago, yet I don't see a single checkin at https://github.com/bouffalolab/incubator-nuttx since it was made three years ago. So is Bouffalo helping to drive NuttX adoption as a way to help provide a quality SDK for their users? How about BL808 with Arduino? Darned if I can tell.

Please give me ONE, well-supported SDK on all three mainstream development OSes in different accents (like ESP-IDF, ahem, with a side of ESP32-arduino and ESP32-platformio) and put some FSE's behind helping people figure questions like this out, and I'd be more enthusiastically BL these days. They've kind of lost me between BL602/4, BL616, Bl70x, and BL808 each being largely unrelated experiences.

Heck, that's even lead people to ask if the company's still supporting some of them. It's hard to tell.

For a while I was really into Bl602 and helping to support a couple of projects under it. I never really saw evidence of them supporting Bl616, though I bought a bunch for dev. use. BL808 for all the OSes was just kind of a mess. I don't know what's going on.

Sorry for the tough love. I've at least explained WHY I've pretty much broken up. But I'm afraid I can't answer your question.

https://openbekeniot.github.io/webapp/devicesList.html

https://github.com/openshwprojects/OpenBK7231T_App

https://www.elektroda.com/rtvforum/forum390.html

/me waves to @Divadiow .

I suppose we can talk smack about BL. It's not like we have any evidence they're listening. :-)

I peripherally (ha!) know of OpenBeken because I'll type nerd words into a search box and land on your pages from time to time. I'm often in a similar orbit as Jason2866 who is a toolsmith for Tasmota. I'm afraid I really don't do much work with home automation and am content to NOT have CPUs in all my light switches - I can be a bit of a cave man in that regard, I suppose, which is a bit odd since I've clearly embraced tech into so much of my other household living over the years. When I see that company's name, I often have to do a double-take as I'm in the U.S. and at least here, "Belkin" is a much better known brand and also of electronic accessories and gizmos so I often have to back up a token and reparse.

I had my hands in the original BL602/604 toolkit. Mostly it was plain ole RISC-V as far as the code emitters and C[++] libs went, which suited me fine. I was a GCC maintainer long, long ago (there's a directory in the g++ testsuite named after me) and it all made sense. Then came Bl70x and the SDKs got all wonky with an artificial split and everything out of sync, but at least everything came from one source tree. Through this time, I was happily building hobbyist things, writing blargh posts, answering forum questions, sending PRs and having fun but the split of the SDK really started to tear at my mental fabric. Then came the BL61[68] and BL808. Suddenly, the SDK wasn't only NOT open source, because the cores were T-Head (for whom I have little respect) and not SiFive but they weren't even available as a prebuild for the OS I choose to sit in front of. The tool situation was such a mess that escalated into a full raging fire and I kind of lost interest. At this time, I was also GAINING interest in a competing chip line. I'm not sure if I should name the company; it's hard to imagine whether I can espress if their tools and SDK were just better built. Their doc was better, and their chips/boards were plentiful and inexpensive. My belly tells me that ignoring the T-Head extensions and treating them like every other RISC-V target and using the same tools is probably find, but it might leave some (probably unimportant outside of microbenchmarks) code speed on the table. I'm just not dedicated enough to The Cause to disassemble every object and look at the GNU code emitters to be sure that it's all legal/valid RISC-V to ensure that it could all be replaced by the commodity RISC-V chains. That's where I got off the train.

So I have to admit that I do no home automation, have little familiarity with the devices that are common in your word, and pretty much have both feet out the door here. (I have some Sipeed BL616 boards I need to find projects for...that's a hundred dollar box that needs to blink lights or something somewhere...) Still, almost none of the chips and even brands that appear in your forums even sound familiar to me. We're kind of those people that meet at a conference whose badges make it sound like we're clones, but in reality, we're just out of sync and running around in the shadows of each other.

I run into Jason in a number of places because he shares those same concerns about espressiveness in code.

So I'm afraid I don't have the background, hardware, and bluntly, interest to help you further your goals.

I will offer that the core of the BL602 is very much like the ESP32-C3. The peripheral set is quite different; with those of the latter unsurprisingly looking more like that of the LX6/LX7 ESP32's.

Good luck and May The Source Be With You!