/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!
