The "problem" with compiling on underpowered hardware

Same on my Rpi4. Works like a dream when compiling my twelve nodes. Never felt the urge to use anything else

So RPi 3b+ will also have the same problem due to ram? Im fine if the compiling process lasts long, but the unresponsiveness and lag happening to the whole system is not okay.

Yes, I think the Rpi 3B+ will have the same problem.
The HW is sufficient to run HA, but insufficient for esp compilations and more demanding operations.

To add to the lot, there are likely to be many of us(all) who have a secondary(primary) computer capable of doing this sort of compiling with ease, and is only turned on every now and then, so such a function i suggest here could be really helpful. For those who have a Rpi 4 with bigger ram or another more powerful computer, could gain lots of speed when compiling can be forwarded to happen on another machine even having a Ryzen Threadripper or an Intel Xeon with 64GB of ram to them…at best. I have no idea how this sort of function could be made to happen, maybe its not about ESPHome coding but all the underlying coding that need to allow it.

Im sure you get the point of the idea.

I was struggling with compile times on my pi4 and was investigating options.

I was chatting to a dude on Discord who said you can run ESPHome on windows in a VM so you get the dashboard, but that you should also be able to run the dashboard via HA add-on on your pi at the same time.

I didn’t investigate further as I ended up upgrading my pi4 to an upgraded ancient laptop. Works great.

Here’s the thread. You’ll need to join the ESPHOME Discord first if you haven’t already.

Some of the ESHome devs suggested it was probably more about CPU than RAM.

You’ll see at the end on this post I really needed the extra overhead.

It’s probably just a matter of looking at your own cpu/ram utilisation though…

One thing you could try is a new option (atm only in beta and dev) that allows limiting the cores used to compile :gear::

compile_process_limit (Optional, int): The maximum number of simultaneous compile processes to run. Defaults to the number of cores of the CPU which is also the maximum you can set.

https://deploy-preview-2391–esphome.netlify.app/components/esphome.html#configuration-variables

If you just use 1 core (instead of 4?) on your RPi you might be able to continue using HA “normally” while increasing the compile times from esphome in exchange. :weight_lifting_man:

I ran HA on an rpi3 for a while. The limiting factor is not the CPU (ok, stuff takes a while) but actually the RAM.
1GB is filled up extremely fast when running AddOns.
The default config for HA is to only have 200MB of swap size. That also runs out quick and when that happens you go into weird unresponsive states which sometimes catch themselves, sometimes they don’t.

The solution is to increase swap size. Sadly there is no easy config for this, but there is a hack.
Try this, it worked wonders for me!

I doubt that heavy swapping is the fastest way to kill a sd card. Quicker approach is definitely to just “deactivate” it physically - for example with the help of some pliers and a hammer :hammer:

But if short on tools killing valuable flash cells just by hammering on it with heavy writes probably will get the job done over time too. :put_litter_in_its_place:

Actually that isn’t a swap on storage (sd card for example) but instead a compressed zram which is (ab)using cpu cycles instead of a storage.

Also for that reason it might be a good try with the compile_process_limit mentioned in my last post :point_up:

Well, I was using it with an external SSD (and a SSD usage is also referenced in the linked post). So I wasn’t to worried about my SD Card…

Im fine with this kind of solution too, as long as it doesnt kill the single core, and that all my compiling could be done in one day after pressing that overly sweet “update all”-button.
A raging wife in the dark hallway isnt fine when the HA motion controlled lights light up 10minutes too late, i could always tell her to have a flashlight as backup :smiley:

Feel free to just do it and tell us about your mileage. If you want fast and furious updates of all your esphome nodes (if you have a critical amount of them) you surly avoid a raspberry pi 3 anyways :wink:

To update my ~100 esphome nodes I just fire up my workstation and let the 16 cores do the work together with 16GB of memory :bulb:

Just do all your development work on another HA instance running on a Linux VM on your desktop system, and copy the config to the Raspberry Pi when you’re done making constant changes that require recompilation.

But if you’re like me, you never really get done making changes, so maybe that won’t work… :slight_smile:

To speed up the compilation process for Home Assistant on a Raspberry Pi, follow these steps:

  1. Start by installing Home Assistant on your Raspberry Pi as usual.

  2. Create a folder called “ESPHome” on your computer’s desktop (assuming you’re using Windows).

  3. Open a command prompt (CMD) and navigate to the newly created folder by running
    cd desktop/esphome

  4. In the CMD, install the necessary packages by running the following commands:

    pip3 install wheel
    pip3 install esphome
    
  5. Confirm that the packages are installed correctly by checking the esphome version with:

    esphome version
    
  6. If you don’t see the esphome version, ensure that you installed the packages in the correct directory and added the installation location to your PATH.

  7. With esphome successfully installed, you can now use it in the CMD. Navigate to your esphome folder again with cd desktop/esphome

  8. Create a new esphome project by running:

    esphome wizard <your_project_name>.yaml
    
  9. This will generate a YAML configuration file (<your_project_name>.yaml) in the esphome folder. You can modify this file to include sensors and other configurations.

  10. After editing the YAML file, compile the code with your faster PC by running:

    esphome run <your_project_name>.yaml
    
  11. Once the compilation is complete, you’ll be prompted to choose whether to upload the firmware “via USB” or “over the air.”

By following these steps, you can significantly reduce the compilation time for new firmware, avoiding the slow process on the Raspberry Pi.

For more detailed information, you can refer to the following resources:

3 Likes

This is basically what the second post said. Run the compiles on your regular desktop or laptop, instead of the machine running HA.

Oh, and if it’s a Windows desktop, use backslashes (\) in the path names, not the forward slashes (/) shown above.

You can still use the ESPHome dashboard in HA for everything else. Or use the one on you desktop or laptop while you’re there, and the HA dashboard the rest of the time.

It’s really a simple process. If you do your development on your desktop or laptop anyway, running ESPHome there is the best option.

Would be soo handy if i could send the compiling to another computer on local. Like if there was a setting where i could choose another computer having esphome installed to do the hard work. Transferring those files over there and back is not a big job at all compared to compiling.

1 Like

Would be soo handy if i could send the compiling to another computer on local. Like if there was a setting where i could choose another computer having esphome installed to do the hard work. Transferring those files over there and back is not a big job at all compared to compiling.

With this kind of setup the ESPhome dashboard could simply say that the compiler is not available when trying to compile while the compiler computer is not powered on, and end the compiling process there instead of 3 hours of unresponsiveness from something like rpi3b, or even a crash trying to do compiling with it.

And as an addition, on something like rpi3b it could simply give a warning that im trying to do compiling on a harware that is likely going to crash doing this kind of action due to its capabilities (Do you want to continue?) and give me a link to wiki regarding this stuff.

Taking this idea to it’s logical next step, it would be possible for the ESPHome UI to be web-based (like it is in the HA add-on.) Then you could access it from anywhere, including inside the HA dashboard.

If someone on the ESPHome dev team wanted to do this, I’d be happy to help test. But frankly I wouldn’t want to divert development resources away from any other ESPHome work. To me, the HA UI is just another web site I go to when I want to do something specific. It’s just as easy to click on a link to ESPHome on my laptop as it is to click on a link to ESPHome in the HA dashboard.

This is a well known issue with rpi3 and been discussed in detail and if you had used thr search box first, you would have seen this. You wish there was a way to send the file to another pc and compile it there? There are many easy ways to do this. The most obvious way is to open a browser on any pc, log into your HA and compile from that machine… yep! It’s that simple!. You can even still use your rpi3 you just need to temporarily stop large add ons like node red or vs code, etc. Stop those then compile, then restart the add ons. Simple!

Taking this idea to it’s logical next step, it would be possible for the ESPHome UI to be web-based (like it is in the HA add-on.) Then you could access it from anywhere, including inside the HA dashboard.

Indeed you can do exactly that :slight_smile:

Launch the ESPHome dashboard in a regular docker container on any machine you like; Getting Started with the ESPHome Command Line — ESPHome

I run the dashboard on an old i7 laptop… HA currently runs on the same machine, but it does not need to…

Then (as long as you are just using plain HTTP) you can add something like this you your HA configuration.yaml to get a sidebar item in HA (mine is currently commented out as I broke it when I switched HA to HTTPS)

#panel_iframe:
#  router:
#    title: "ESPHome"
#    url: "http://<IP of ESPHome machine>:6052"
#    icon: mdi:chip

Of course you can just access the ESPHome dashboard directly at http://<IP of ESPHome machine>:6052

Cheers.