
Actually I was led to ESPHome from my other project for a benchtop power supply. I ordered this WiFi module for controlling the power supply. Sure, it's possible to adjust the supply using the knob and buttons but tedious. So I wanted to be able to control it from my computer.
The module seems to be made by the same manufacturer that made the amplifier for #Playing music remotely with bluetooth. It uses the same phone app: sinilink. However the reviews for the app were very uncomplimentary. There were more 1-star ratings than 5-star ratings. In other words, a piece of s***. I only used the app for setting up the Bluetooth interface so the app didn't bother me.
Fortunately the MODBUS commands for the power supply are documented, and the WiFi module is just a conduit for the serial commands. There is a ESPHome-Sinilink-XY-WFPOW Github project which interfaces the module to ESPHome.
So what is ESPHome? In one sentence, it's a framework for building a software system for an IoT system. Sensors and output devices that are based on the ESP family of WiFi enabled MCUs, and some others, notably the RP2040, are supported. You generate firmware for MCU modules by specifying components with a YAML file, and the development software pieces the components together and builds the firmware image. Another great feature is being able to update the firmware Over The Air. This is important when the gadget has been deployed and it's not easy to take it back to the workbench to reprogram the firmware. You can explore the website for more details.
So I would need to build new firmware to flash into the XY-WFPOW. You can see the pin connector holes at the top of the module in the photo. I'm guessing I need a USB to serial adaptor which I have.
This extended introduction is just to give the background to the impetus to learn ESPHome. I can foresee that ESPHome will be useful for making ESP module based gadgets even if they work standalone and are not connected to the IoT. For setting up an ESPHome development environment there are various methods.
First method
This was by pip install esphome. This downloaded all the required Python modules to $HOME/.local. I used the wizard to construct a YAML specification for the ESP32-WROOM board I have, to get familiar with the process.
Unfortunately when I tried to compile the project, it failed trying to load uv, which is a package manager, into the Python platformio environment. I did a search for the fix, but many replies to previous questions said give up, use the ESPHome docker image.
I'm a little biased against container environments such as snap, flatpak, and virtualised machines using VirtualBox, even though I use them when I have to, because of the extra layer of complexity. But in this case I think the problems stem from the Python software ecosystem. It's just got over the transition from Python-2 to Python-3. They are still tinkering and adding features such that at the time of writing the version is up to 3.14 and a lot of Python software require a recent release. They still manage to break backward compatibility, for example, in a recent KiCad problem. So much for stability. And it doesn't help that Linux distros add their own quirks and problems. So reluctantly I opted for:
Second method
This involves downloading the docker image for ESPHome. You then run commands from the container to build the firmware and even flash the image, as docker can be given permissions on the host USB ports.
The first compile took a lot of time to download all the supporting Python modules. It generated images for the firmware, including any content for the data partition. One feature of many ESP modules is they come with data partitions in which one can even put a small filesystem. Low-end MCUs generally have small data partitions, if they do. I discovered that a lot of files owned by root were left behind in my project, due to the privilege I gave it to access the USB port. I think I will just build which needs no root permissions and then use esptool to flash the target system. Esptool can use the USB ports that have been made writable via udev.
A more serious problem was that about 2GB of files was left behind in the platformio subdirectory of the project. That's a lot of storage if I have many projects in development. It's occurred to other people too to reuse the platformio files. Fortunately it is already possible by specifying a bind mount for this directory, which can be common to all projects. There is also an open request to reuse the compiled objects across projects as some people have large numbers of similar gadgets to update, but that's another issue.
So now I have the basic infrastructure for building ESP firmware, which I will expand in future logs, when I get a round tuit. 😉
Ken Yap
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.