I am working on a fairly large project related to home automation.

Specifically, I'm building my own hub as well as some hardware devices that replace components of my home.

Currently, I'm using off-the-shelf sensors and actuators with well-supported dev communities and APIs in Python.

However, I (may) want to build my own boards at some point so I'm not sure if writing more and more python code would eventually turn into tech debt that I have to rewrite down the line (e.g., into C).

My questions are -- is switching to C/C++ inevitable at some point? Or is using Python a viable approach in 2022 (e.g., micro-python, but not sure how well it's supported)? What are some factors that I should be considering?

 

Welcome to AAC.

The answer to your question is not generic. Whichever choice you make will involve compromises and optimization is the order of the day.

For example, if you particularly prefer Python, MicroPython offers a way to stick with that while still having access to a wide range of devices. If you are building these boards only for yourself or small batches, you can use something like the RPi RP2040 on a dev board with castellated holes on the edges and surface mount them.

This is done commercially a lot, particularly with things like the ESPxx where it provides WiFi connectivity to a larger device. At about $4 a piece, the RPi RP2040 isnt so expensive that using it wholesale on your own board is outrageous. It also has other peripheral hardware on-board so you won’t have to duplcate toes things.

The RP2040W has the WiFi connectivity you probably need, and it’s just a bit more. There are already many third party boards (some quite tiny) that use the RP2040 chip, and offer surface mount options in additional to wireless communication. Even if you go with the original RP2040, which doesn’t have WiFi, an ESP-01 board is cheap as dirt and can be used to handle WiFi.

So, it really comes down to goals. It is as much of a mistake to engage in premature optimization as it is to ignore the future and go into technical debt. But you should make a notional roadmap, with some specific functionality you image you might need so you have a framework for decision-making about platforms.

One thing you can do now is make sure you have carefully defined private APIs for your own development that can accomodate growth, and use them without “cheating”. This way any part of your own system can be replaced so long aa it respects the API. This is also a good exercise with regards to avoiding redundancy and to normalize functions, avoiding later finding that a particular component is handling two disparate functions and hafing to untangle that.

The RP2040 was only an example because of its exemplary MicroPython support. There are other options that offer MicroPython support, and of course almost anything can be used with C. It is very possible you will choose to write some time critical inner loop type functions in C to call from (Micro)Python, but you may not need to.

In any case I think the roadmap, even if it is largely notional, will provide you with a more rational and constrained basis for choices.