Production ready?

[patkepa]

Hello, I'm so happy that this project exists!

I'm currently using the standard matter library in my ESP IDF project and we've had w lot of issues in regards to its binary size, which takes around 1.3MB on flash

It seems like this project puts a good focus, on being well supported on embedded devices, and I was wondering whether this makes library binary size smaller as well?

Would you say there could be a possibility, for using this library already for production ready devices?

Also, do you think it'd make sense, for wrapping this rust implementation for usage in C embedded projects on ESP?

Thanks!

[ivmarkov]

W.r.t. production ready, we are getting close but I would say we are not 100% there yet:

• For one, we have to enable a nightly CI that tests our code base against the Matter C++ TCK tests ([TESTS] End-to-end tests #187). And fix all potential bugs.
• Also, there are some functionalities which are not implemented yet, like support for Matter Events (if you need those), and our subscriptions are very chatty due to [IM/DM] More intelligent reporting on subscriptions #166.

====

W.r.t. the Matter C++ SDK taking too much space... well, our footprint is not that big, i.e. ~ 500 - 700KB with all optimization settings on, but if you factor in the inherent bloatness of ESP-IDF (it is a STD toolkit with a C runtime library) we might approach the 1MB boundary as well.

Also, it is very unfair to say that the Matter C++ SDK is not designed with embedded in mind. Quite the opposite. The Matter C++ folks put A LOT of effort into tracking and optimizing their flash footprint. More than what we currently do in fact. So maybe you can play with the optimization settings of your C ESP IDF project a bit? As in reducing logging (log messages take a lot of space) and optimizing for size, if you don't do that already?

====

W.r.t. wrapping rs-matter in C so that C/C++ folks can use it... I don't see the point. While possible it would be a lot of effort and it a bit defeats the purpose of using rs-matter in the first place: while I think rs-matter might become just as efficient and feature-complete as its C++ cousin, it was not created with the purpose of "smaller" in mind. However you spin it, the Matter protocol is simply big and complex which means lots of code and some flash fatness is unavoidable. I.e. consider shipping your devices with extra flash (which is very possible with Espressif chips at least), rather than risking to move from something stable (Matter C++) to something not quite there yet (rs-matter).

rs-matter was created primarily in mind with folks who use Rust, not C++. They value type-safety and don't really like it when they have unsafe C/C++ mixed with their Rust codebase, with potential use-after-free errors and whatnot. Also, rs-matter is async-first (so I dare say its code-base is simpler and easier to comprehend) and does not use an allocator (more predictable at runtime).

But if you are anyway using a lot of C with ESP-IDF, it does not seem much of a win if the "matter" portion is in safe Rust. Also, ESP-IDF itself allocates a lot, so the "no-alloc" nature of rs-matter in a way is not such a big win, as you can get heap fragmentation still because of your other, non-rs-matter code.

====

Now, if you plan to completely migrate your firmware to Rust, then it is a different story of course.

[patkepa]

Thank you for quick and comprehensive answer @ivmarkov

I didn't mean that in offense with C++ Matter team at all! I guess I had mixed bag of experiences with esp-matter implementation which is based on it, which our team had to do a lot of engineering decisions around our code base, just to support it.

Our team is currently in the land of plucking nails with hands, just to save every byte of flash, so my question came because of that, we've had some experience with wrapping rust in our embedded C code with good results, but I'll listen to you that's not a great idea in regards to Matter 😄

We're actually in discussions about migration to embedded Rust, which would end up using this library, so I'm holding thumbs up for future of this project 😄

Cheers and good luck!

[ivmarkov]

I didn't mean that in offense with C++ Matter team at all! I guess I had mixed bag of experiences with esp-matter implementation which is based on it, which our team had to do a lot of engineering decisions around our code base, just to support it.

No offense taken I guess! (I'm not a member of that team.)

Our team is currently in the land of plucking nails with hands, just to save every byte of flash, so my question came because of that, we've had some experience with wrapping rust in our embedded C code with good results, but I'll listen to you that's not a great idea in regards to Matter 😄

We're actually in discussions about migration to embedded Rust, which would end up using this library, so I'm holding thumbs up for future of this project 😄

That's great to hear!

Personal opinion: don't do it to save flash, as you might still end up hitting the 1MB boundary, or beyond. Matter is just... big. Look at rs-matter ~ 200K LOCs and growing.

If you decide for it, it should rather be for the type-safety, less or no allocations and simplicity (after the initial learning curve) Rust offers. I.e. a better sleep at night with thousands of devices deployed in the field.

With that said I would still strongly suggest (if possible due to e.g. cost reasons) to switch to a chip variant which offers more flash. It is almost a sin to use the Espressif MCU line and not do it. Besides the stock 4MB, there are 8 or even 16MB flash variants.

Cheers and good luck!

Thanks! Hope to see you around!