Considering ESPhome

Hardware
1

I hope people can offer some beginner level guidance about ESPhome.

As I understand it, ESPHome is an alternative firmware for ESPs and Raspberry Picos?
You have to compile it especially for each device and it's sensors and actuators, which implies a development environment on a computer - cf the Arduino IDE on a PC.

Currently I use Tasmota for ESPs. I have used Arduino IDE too.
I would like to compare these with ESPhome.

Can I compile and burn ESPhome images from a command line only Raspberry Pi?
Should I consider installing on WIndows instead?
What do I have to install, and how?
Is there a web based UI for this IDE?

I am not going to install Home Assistant and preferably not Docker.
All of the online guides seem to focus on Home Assistant.

Does a microcontroller with ESPhome have a web console similar to Tasmota devices?

I know there is a node-red-contrib-esphome, but if ESPhome can publish and subscribe to MQTT, why would I need this?

3

ESPHome is using yaml as an input format, from which it has to compile to a binary format and flash the device.
You will need some tooling to make the compiling happen, they have a docker container available for this purpose which can be exposed as a commandline utility. Once the device has esphome running then it can be updated over the air.

The node-red-esphome node is only used for communication with a esphome based device (just like the tasmota nodes for example).

4

I think @TotallyInformation AKA Julian uses ESPHome, so you may get some feedback from him.

1 Like
6

As often happens, Andreas Spiess has a good video on this topic.

1 Like
7

Esphome is custom built for home assistant. While it is true that you can use mqtt in liu of the api, mqtt is not fully implemented in all components. Voice assistant and media players, for instance, have no mqtt implementation.

I use esphome heavily but I also run HA. Esphome does have a cli tool that can be used to compile.

https://esphome.io/guides/installing_esphome

8

Not so much any more. It was but many of us use it without HA now. It isn't a problem at all and non-HA use is very well supported. I do everything via MQTT as you'd expect. It works brilliantly.

I've not found any but I only use a 1/2 dozen or so. I don't use voice assistant but it doesn't surprise me as I think that it probably needs to do processing in HA, probably similar for video streaming as well.

AFIK all of the sensor and control options work just fine with MQTT.

ESPHome is easy to use from the command line and VS Code. Once you've done a single update over USB, you can do all future updates via WiFi. Simples.

I've not read through this but certainly various people have worked on supporting camera modules at least without needing HA.

Regarding media playing - this greatly depends on what you want to do I think. There is I²S Audio Media Player — ESPHome which allows media playback with suitable hardware on the ESP32.

9

Absolutely. :slight_smile: You will need Python and a few other things but the install should take care of everything. As I think is recommended, I use a Python virtual environment to ensure that I have the appropriate Python version and all libraries.

While that may sound like extra work, in truth it isn't. It has the advantage that your firmware build is targeted for the device which avoids some of the crashes you may get with some other more generic firmwares.

You use YAML files to define the config for each device and its sensors, controlelrs, etc. But the great news is that you can split the YAML files such that each sensor, your wifi config, etc, etc are each in their own small file. Then your device file simply imports the right parts and sets the device name.

I have numerous and very different ESP devices ranging from D1-Mini's all the way up to an M5 Basic which is an ESP32 with built in screen/buttons/sensors. But the configuration for each is really simple.

The other thing I really appreciate about ESPHome is that it is trivial to drop into a bit of C/C++ to do something custom. Not often needed but it can be really helpful - just as in Node-RED, it is great that you can drop into a function node if needed.

Just follow the instructions on the website - they aren't too hard to follow.

There is a web UI to support some things - I don't think I've ever bothered using it.

I use VS Code to do the editing - you can use the remote editor features if you want to do your edit/build on a headless Pi. I do it on my Windows dev PC but because it is Python based, it really makes no difference.

Yes, it does - if you want it.

It also has a remote command line if you want it.

After your first firmware build/deploy, all other deploys can happen over Wi-Fi, no cables needed.

Good question, I've never used it.

10

Right but if you look at the media player component there are no mqtt commands. Esphome was once a stand alone project that about a year ago was brought under the open home foundation, HA's parent entity.

I could be wrong but I don't believe there is much work being done for mqtt integration since it is now primarily part of HA. The api is available and would have the ability to control all components.

11

BTW, in my project layout, I keep all my include files in a sensible folder structure:

image
image226×459 4.88 KB

And then the master device configs in the parent folder:

image
image266×311 6.21 KB

Along with the separate secrets files. This makes it easy to commit all your configs to GitHub should you want to without sharing things like WiFi passwords.

Here is an example of one of the more complex device files - for the M5 Basic:

# M5 Basic Configuration for m5basic01
#    MAC Address: 84:0D:8E:3D:3B:D4
# NB: This configuration does not use Home Assistant (HA). It uses TotallyInformation's standard MQTT Schema for ESP devices.

# Pins/GPIO | ADC    | Touch   | DAC | Comments
  # 00      |        |         |     | Left button. Must be HIGH on normal boot
  # 02      | 12     | 2       |     | On-board LED.
  # 12      | 15     | 5       |     | 
  # 13      | 14     | 4       |     | 
  # 15      | 13     | 3       |     | 
  # 17      |        |         |     | 
  # 21      |        |         |     | Wire SDA
  # 22      |        |         |     | Wire SCL
  # 25      | 18     |         | 1   | Speaker (Buzzer)
  # 26      | 19     |         | 2   | 
  # 27      | 17     | 7       |     | 
  # 32      | 4      | 9       |     | Display Backlight
  # 33      | 5      | 8       |     | 
  # (34)    |        |         |     | ? Can't be an output
  # 35      |        |         |     | Right button. Can't be an output
  # 36      | 0      |         |     | Can't be an output
  # 37      |        |         |     | Can't be an output
  # 38      |        |         |     | Can't be an output
  # 39      | 3      |         |     | Can't be an output
  # ---- Display -  ---------------
  # 14      |        |         |     | 
  # 18      |        |         |     | SCLK
  # 19      |        |         |     | MOSI
  # 23      |        |         |     | RT
  # 05      |        |         |     | CS
  # 16      |        |         |     | DC
  #
  # === General ESP32 Pin data ===
  # GPIO00        | Must be LOW on normal boot (HIGH to boot into FLASH mode). Can be used as an output.
  # GPIO34-GPIO39 | Cannot be used as outputs.
  # GPIO32-GPIO39 | ADC capable (voltage measurements)
  # GPIO02        | This pin is connected to the blue LED on the board. It also supports the touch pad binary sensor like some other pins.
  #
  # === M5Stack Specific ===
  # @see https://github.com/m5stack/M5Stack/blob/master/src/utility/Config.h
  # ---- Display (IPS ILI9342C 2", SPI) ----
  # TFT_LED_PIN     | 32 | Backlight
  # TFT_DC_PIN      | 27 | 
  # TFT_CS_PIN      | 14 | 
  # TFT_MOSI_PIN    | 23 | SPI MOSI
  # TFT_MISO_PIN    | 19 | SPI MISO
  # TFT_CLK_PIN     | 18 | SPI Clock
  # TFT_RST_PIN     | 33 | 
  # ------ SD card (SPI) ------
  # TFCARD_MOSI_PIN | 23 | SPI MOSI
  # TFCARD_MISO_PIN | 19 | SPI MISO
  # TFCARD_CS_PIN   | 04 | 
  # ------ Buttons ------
  # BUTTON_A_PIN    | 39 | Left Button
  # BUTTON_B_PIN    | 38 | Middle Button
  # BUTTON_C_PIN    | 37 | Right Button
  # ------ BEEP PIN ------
  # SPEAKER_PIN     | 25 | (TONE_PIN_CHANNEL 0)
  # -------- LORA --------
  # LORA_CS_PIN     |  5 | 
  # LORA_RST_PIN    | 26 | 
  # LORA_IRQ_PIN    | 36 | 
  # -------- I2C ---------
  # SDA             | 21 | 
  # SCL             | 22 |
  # 
  # Grove Port A - I2C
  # IPS5306 (Power management SoC) - I2C

  # === BTC 2.1 Base ===
  # SHT30 Temperature/Humidity
  # I2C address: 0x44
#

substitutions: # All have to be strings, the substitution process will convert them to the correct types
  devicename: m5basic01
  upper_devicename: M5BASIC01
  device_location: Office
  device_description: Knightnet Home custom sensor platform using ESPhome firmware

  mqtt_root: ESP
  mqtt_prefix: ESP/m5basic01 #$mqtt_root/$devicename
  mqtt_broker: !secret mqtt_broker 
  mqtt_username: !secret mqtt_username
  mqtt_password: !secret mqtt_password

  publish_interval: 50s

  ipaddress: 192.168.1.193
  wifi_power_save_mode: light # none, light, high
  wifi_fast_connect: "true"
  wifi_ssid: !secret WiFi_SSID
  wifi_password: !secret WiFi_password
  wifi_domain: !secret WiFi_domain
  wifi_gateway: !secret WiFi_gateway
  wifi_subnet: !secret WiFi_subnet
  wifi_dns1: !secret WiFi_DNS1
  wifi_ap_password: !secret WiFi_AP_Password

  log_level: info # none, error, warn, info, debug, verbose
  esp_platform: ESP32
  esp_board: m5stack-core-esp32
  
  sun_latitude: !secret sun_latitude
  sun_longitude: !secret sun_longitude 

  #light_sensitivity: "100" # 31->69->254 - bh1750 sensor measurement duration # DEPRECATED

globals:
  - id: backlight_level
    type: float
    restore_value: yes
    initial_value: '0.5'
    
<<: !include includes/mqtt.yaml # For some reason, the config checker doesn't like this as a package
packages: # These allow merging whereas global includes do not
  common: !include includes/common.yaml
  logger: !include includes/logger.yaml
  wifi: !include includes/wifi.yaml
  m5basic: !include includes/m5stack-basic.yaml # All of the config, standard buttons, backlight, etc
  color: !include color/COLOR_CSS # Standard CSS colour names
  common_sensors: !include includes/common-sensors.yaml # Includes number, text and binary
  common_switches: !include includes/common-switches.yaml
  common_intervals: !include includes/common-intervals.yaml
  
esphome:
  includes:
    - lib/common.h
  on_boot:
    - light.control:
        id: backlight
        brightness: !lambda |-
          return id(backlight_level);

# Basic configuration for ESP32 based boards. https://esphome.io/components/esp32.html
# Board names: https://registry.platformio.org/platforms/platformio/espressif32/boards
esp32:
  board: $esp_board

sensor: # NB: See also common_sensors
  # Temperature & Humidity
  - <<: !include includes/sensors/th_sht3xd.yaml
  
  # Ambient light intensity
  - <<: !include includes/sensors/light_bh1750.yaml
# --- End of sensor --- #

text_sensor: # NB: See also common_sensors
  - platform: template # Template text sensor wifi channel
    id: wifi_channel
    lambda: |-
      // --- ESP8266 version ---
      //std::string out;
      //char buffer[64];
      //sprintf(buffer, "%u", wifi_get_channel());
      //out.append(buffer);
      //return out;
      // --- ESP32 version ---
      wifi_ap_record_t wifidata;
      esp_wifi_sta_get_ap_info(&wifidata);
      std::string out;
      if (wifidata.primary != 0) {
        char buffer[64];
        sprintf(buffer, "%u", wifidata.primary);
        out.append(buffer);
      }
      return out;

  - platform: mqtt_subscribe
    name: "Landing Temperature (D1M04)"
    id: landing_temperature
    topic: environment/temperature/Landing/temperature
  - platform: mqtt_subscribe
    name: "Landing Humidity (D1M04)"
    id: landing_humidity
    topic: environment/humidity/Landing/humidity

  - platform: mqtt_subscribe
    name: "Bathroom Temperature"
    id: bathroom_temperature
    topic: environment/temperature/Bathroom/temperature_measured
  - platform: mqtt_subscribe
    name: "Bathroom Humidity"
    id: bathroom_humidity
    topic: environment/humidity/Bathroom/humidity

  - platform: mqtt_subscribe
    name: "Front Hall Temperature"
    id: front_hall_temperature
    topic: environment/temperature/Front Hall/temperature_measured

  - platform: mqtt_subscribe
    name: "Rear Hall Temperature (D1M02)"
    id: rear_hall_temperature
    topic: environment/temperature/Rear Hall/temperature
  - platform: mqtt_subscribe
    name: "Rear Hall Humidity (D1M02)"
    id: rear_hall_humidity
    topic: environment/humidity/Rear Hall/humidity

  - platform: mqtt_subscribe
    name: "Kitchen Temperature"
    id: kitchen_temperature
    topic: environment/temperature/Kitchen/temperature_measured
# --- End of text_sensor --- #

font:
  # https://community.home-assistant.io/t/display-materialdesign-icons-on-esphome-attached-to-screen/199790/2
  # https://materialdesignicons.com/
  # https://fonts.google.com/specimen/Roboto
  # MD Icons: https://fonts.google.com/icons?selected=Material+Icons&icon.query=wifi
  # FA Icons: https://fontawesome.com/icons?d=gallery&p=2&q=wifi&m=free
  # 1 Point = 1.333333 Pixel. 12pt=16px, 16pt=22px, 18pt=24px, 22pt=26px, 24pt=32px, 26pt=35px, 30pt=40px :: https://reeddesign.co.uk/test/points-pixels.html
  - file: "fonts/Roboto-Medium.ttf"
    id: print_font_large
    size: 22
    glyphs: '!"%()+,-_.:°0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz/³µ'
  - file: "fonts/Font Awesome 5 Free-Solid-900.ttf"
    id: icon_font_large
    size: 22
    glyphs: [
      '', # thermometer-three-quarters
      '', # water-drop (tint)
      '' # WiFi
    ]
  - file: "fonts/Roboto-Medium.ttf"
    id: print_font_medium
    size: 20
    glyphs: '!"%()+,-_.:°0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz/³µ'
  - file: "fonts/Font Awesome 5 Free-Solid-900.ttf"
    id: icon_font_medium
    size: 20
    glyphs: [
      '', # thermometer-three-quarters
      '', # water-drop (tint)
      '' # WiFi
    ]
  - file: "fonts/Roboto-Medium.ttf"
    id: print_font
    size: 18
    glyphs: '!"%()+,-_.:°0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz/³µ'
  - file: "fonts/Font Awesome 5 Free-Solid-900.ttf"
    id: icon_font
    size: 18
    glyphs: [
      '', # thermometer-three-quarters
      '', # water-drop (tint)
      '' # WiFi
    ]

    # glyphs: [
    #   "", # mdi-thermometer
    #   "", # mdi-water-percent
    #   "ﴟ" # mdi-air-filter
    # ]

display:
  - platform: ili9341
    id: m5stack_display
    model: M5STACK_OLD
    cs_pin: 14
    dc_pin: 27
    led_pin: 32
    reset_pin: 33
    rotation: 0
    #brightness: 25% # not available in driver
    # Colours: https://css-tricks.com/snippets/css/named-colors-and-hex-equivalents/
    pages:
      - <<: !include pages/m5basic01/page1.yaml
      - <<: !include pages/m5basic01/page2.yaml
      - <<: !include pages/m5basic01/page3.yaml
      - <<: !include pages/m5basic01/page4.yaml

# Turn on backlight for 1min out of 5.
interval:
  # TODO: To be more flexible, change to a 1sec interval but check an external value to see if a set time
  #       has expired. This would let you have a variable time limit. (Ideas: https://www.instructables.com/ESPHOME-SONOF-S26-Timed-Light/)
  #       Also: Maybe use time:on_time and exclude night-time?
  - interval: 5min
    then:
      - wait_until:
          mqtt.connected:
      - light.turn_on: # Always turn on the backlight to the set level
          id: backlight
          # brightness: !lambda |-
          #   return id(backlight_level);
      #- display.page.show: page2 # And show page 2

# EOF

I also created some notes for myself since I very rarely ever need to touch the devices these days - so when I do, it can take a while to remember everything:

ESPhome Configuration

This contains my configuration for all ESPHome devices.

Folders

Root

Each device has a YAML file in the root folder.

Sensitive data is kept in the secrets.yaml file in the this folder. Assign these to substitutions in the top-level YAML file so that

they can be also used in included files. This file is not pushed to git. There is an example-secrets.yaml file that can be included to git.

includes

Common settings are in the ./includes folder and its sub-folders.

Things common to all (at least most) devices are in the root. Specifics are in the sub-folders.

color

Contains lots of color definitions that match standard CSS colours. Include as required.

fonts

Contains any required font files. Include as required.

custom_components

Contains any custom ESPHome components such as my amended ILI9341 display component that has the correct colours for older M5Stack devices.

lib

Contains C++ files that can be included such that the contents are available to all lambda's.

pages

Split into sub-folders per device. Standard display page definitions.

builds

Contains the built/compiled software.

esphome

This is created when you create your Python virtual environment. See the installing section below.

\Users<userName>\AppData\Local\Packages\PythonSoftwareFoundation.\LocalCache\local-packages\Python38\site-packages\esphome

The master packages, updated when ESPhome is updated.

Installing and configuring


# Start with a root folder name

cd <root-folder>

# Create a python virtual environment - creates a new sub-folder called `esphome`

python -m venv env_esphome

# Run the activate script (see ./esphome/Scripts/) for your OS

./env_esphome/Scripts/Activate.ps1 # PowerShell example

# Now install ESPHome

pip install esphome

# And install pillow for font conversion

pip install pillow

# You can now run the command called `esphome`

See Using Python Environments in Visual Studio Code if working with VSCode as you can fix the envionment into your VSCode workspace.

See Getting Started with the ESPHome Command Line — ESPHome to get started with ESPhome. Here we are assuming that you already have a project

See Command Line Interface — ESPHome for all of the esphome commands.

See Release 2024.12.2 · esphome/esphome · GitHub for the latest changes

Build process

Initial build and upload to a device has to be over USB since the ESPHome OTA firmware won't yet be available. Subsequent build and upload can happen OTA.


# Start with the root folder name

cd <root-folder>

# Run the activate script (see ./esphome/Scripts/) for your OS

./env_esphome/Scripts/Activate.ps1 # PowerShell example

# Run esphome and compile then upload the firmware to the device

esphome run <devicename>.yaml # e.g. esphome run m5basic01.yaml

Validate any configuration changes

Checks for and reports any errors.


# Start with the root folder name

cd <root-folder>

# Run the activate script (see ./esphome/Scripts/) for your OS

./env_esphome/Scripts/Activate.ps1 # PowerShell example

esphome config <devicename>.yaml # e.g. esphome config m5basic01.yaml

Only compile

Just compiles all the code and produces but does not upload the firmware.

This is useful because it finds any compile-time errors but doesn't waste another set of changes to the device FLASH

which typically has a limited number of updates before failing.


# Start with the root folder name

cd <root-folder>

# Run the activate script (see ./esphome/Scripts/) for your OS

./env_esphome/Scripts/Activate.ps1 # PowerShell example

esphome compile <devicename>.yaml # e.g. esphome compile m5basic01.yaml

Upload to device

Uploads the latest compiled firmware to the device (don't forget to compile first)


# Start with the root folder name

cd <root-folder>

# Run the activate script (see ./esphome/Scripts/) for your OS

./env_esphome/Scripts/Activate.ps1 # PowerShell example

# Let esphome find all possible upload ports (you chose one)

esphome upload <devicename>.yaml # e.g. esphome upload m5basic01.yaml

# OR Pre-select the port - OTA is typically quicker than serial.

esphome upload <devicename>.yaml --device COM6 # e.g. esphome upload m5basic01.yaml --upload-port COM6

esphome upload <devicename>.yaml --device OTA # e.g. esphome upload m5basic01.yaml --upload-port OTA

Updating ESPhome

If NOT using a Python virtual environment as described here, you will probably need to do this from an elevated prompt since we are using the Windows Store (UWP) version of Python 3.9. Your milage may vary depending on how you have Python installed and whether you are using Python environments.


# Start with a root folder name

cd <root-folder> # e.g. c:/src/esphome

# Run the Python virtual env activate script (see ./esphome/Scripts/) for your OS

# ??? python -m venv env_esphome

./env_esphome/Scripts/Activate.ps1 # PowerShell example

# Now update ESPHome

pip install --upgrade esphome

pip install --upgrade pillow

Moving to new PC (maybe if moving to Python >3.9 from Windows Store)

I have had some issues when copying my root-folder to a new PC as the Virtual Environment doesn't recognise the Python install.

I simply created a new virtual environment and installed everything again.

Useful PowerShell Commands

  • Show the Windows PATH: $env:path -split ";"
1 Like
12

One of the things I like about ESPHome is that it is fairly easy to hack about with it if you need to. But without knowing specifically what you'd want to do with media playing (play on an ESP device from a file loaded to it? Stream to a device? Use buttons on the device to play elsewhere? ...) hard to know what might already have been done by the community and what might need some hacking with a bit of C/C++ and maybe the API. Certainly, you can easily use MQTT inputs and outputs from custom code.

13

Out of interest why are you considering changing from Tasmota ?

I cannot make any comparisons as I haven't used ESPhome - every time I looked at it I was put off as it seems overly complicated.

However I have yet to find anything I haven't been able to do using Tasmota, so I will be sticking with that :wink:

2 Likes
14

Thanks to everyone for the replies, especially Julian's detailed answer.

I'm just kicking the tyres, not really planning to buy a new car!
Tasmota does everything I need, but it is only for ESPs and one day an alternative microcontroller with superior price/performance might come along.
Apart from Tasmota devices being native MQTT speakers, the best feature is this web interface where I can easily check the sensors and send commands. I mainly want to see the equivalent for ESPhome.

image
image499×760 30.1 KB

Because I dislike installing software on my PC I initially tried following the instructions to install ESPHome CLI on a Pi.
Unfortunately step 1 python3 -m venv venv just lurks silently for 15 seconds and then returns to the dollar prompt.
Still mulling over whether I'm prepared to wrestle with python and powershell to repeat the exercise on the PC.

15

If you are going to us a pi, Esphome compile needs about a gig of free memory.

16

Sorry, I should have included that in my last post. :slight_smile:

image
image623×810 24.3 KB

image
image613×803 22.8 KB

You can see that things like switches automatically get one or more action buttons.

The ESPHome command line itself is very powerful but easy to use - as long as you know the address of the device you want to control, you can change switch statuses, restart, update the firmware, etc.

Incidentally, I built a simple home panel to show system/device status - using UIBUILDER of course. :rofl:

image
image722×785 26.9 KB

That is my dev version, not sure why the M5 isn't showing as active there because it absolutely is and I just tested by turning the backlight off/on from the device web page. The panel has links to device/service home pages where appropriate and the whole thing is driven by a Node-RED flow controlled by a persistent flow variable containing the device and service details.

image
image903×817 73.7 KB

It does seem that way to start with but once you've set up the environment and split out the different config files, the great advantage is that you have a firmware dedicated to each device and all the config is done via a simple file. I had problems before with generic firmware such as Tasmota or ESPeasy where the device would occasionally crash due to a variety of problems but largely related to memory issues. Possibly all those have been fixed now but you certainly stress the MCP out less by only including the things you actually need for that device. Updates are also easier and quicker.

Adding a new device type is usually also very simple. You look up the pinouts - you'll note that I keep a reference of them in the master YAML file, adjust the config if needed and include the elements you want to use on the device. Many devices already have configurations available and, as mentioned, not just ESP devices.

So yes, it is a bit more complex to start BUT should you even want to do anything off the main path, this is easy, everything is already there and you can simply drop into C/C++ within the YAML (or via a separate include file if you need something more complex but that is rare). From the YAML file I shared, there is this example of using C:

text_sensor: # NB: See also common_sensors
  - platform: template # Template text sensor wifi channel
    id: wifi_channel
    lambda: |-
      // --- ESP8266 version ---
      //std::string out;
      //char buffer[64];
      //sprintf(buffer, "%u", wifi_get_channel());
      //out.append(buffer);
      //return out;
      // --- ESP32 version ---
      wifi_ap_record_t wifidata;
      esp_wifi_sta_get_ap_info(&wifidata);
      std::string out;
      if (wifidata.primary != 0) {
        char buffer[64];
        sprintf(buffer, "%u", wifidata.primary);
        out.append(buffer);
      }
      return out;

Which creates a custom output because I wasn't happy with the default for sharing the WiFi data. This output would work with HA but also automatically outputs to MQTT and automatically appears on the device's web interface. I am NOT a C/C++ coder so any code I've written will have been "borrowed with pride" from other sources. The ESPHome forum, while not quite up to the standards of this one (what is!), is pretty good.

All that command does is to set up a new virtual environment. If you do an ls afterwards, you would find a new folder called venv. I probably should have used a less confusing name!

So when you get back to the command line after the command, you are good to move onto the next step.

I only use PowerShell because I know it and it makes sense on Windows - you can always do the steps manually. Also, VS Code continues to get better and better at Python so there may well be better ways to do things now. If you want something more visual, use VS Code to create a Jupyter Notebook - that is a great way to mix instructions with live code - using VS Code means you no longer need to set up a Jupyter server.

You may already have Python on your Windows PC if you've ever installed the developer tools for windows (which are included optionally when you install node.js). If not, you can simply grab it from the Windows Store which means it will self-update over time via Windows Update.

17

Oh that's bad news since the Pi I use for such experiments only has 512MB physical memory!

1 Like
18

As long as you are not also running HA on that device, you should be able to simply increase the swap size. Compilation will take a little longer but everything should work fine.

Oh, and I always forget, some clever clogs invented a web version of esphome! So, for simpler configurations anyway, you can maybe just use that version - might be a good way to get started.

https://web.esphome.io

Doh! There is a docker version as well - if you have docker set up somewhere, you could use that without any other installs. Must try that on my home automation server (an old Lenovo laptop with an i5 and 8GB RAM running headless).

Oh, and another advantage of ESPHome (maybe other firmwares do this too?) - because it natively supports MQTT, you can connect direct to your broker and receive data - this can be useful in the case that Node-RED fails for some reason. And, of course, those inputs can be used not only for display but also for control. You are not limited to a specific MQTT topic structure either, you can subscribe or output to any topic.

Looks like ESPHome has moved on a LOT since I last bothered to do anything with it (all my devices are extremely stable so no need to do anything with them). Especially in the area of displays. I could probably simplify things a fair bit now.

19

Running Home Assistant... Not elfin likely! :wink:
Actually one of those little Pies does run zram, resulting in more swap space...

pi@ZeroTwoGreen:~ $ free -h
               total        used        free      shared  buff/cache   available
Mem:           416Mi       196Mi       124Mi       188Ki       148Mi       220Mi
Swap:          721Mi        39Mi       682Mi

That's promising, hopefully it's on a par with the Tasmota in-browser installation. I'll root out a spare ESP and give it a go.

Edit: After a good deal of messing around with different USB cables and different ESPs I found a combination which did work. The device was a Witty Cloud ESP8266.
It successfully installed basic ESPhome and allowed me to configure Wifi and visit the web interface.

image
image1129×460 30.6 KB

Perhaps not surprisingly, the on-board light sensor is not displayed. (Neither is it at first using the Tasmota web installer)

Same as for Home Assistant!

I can see that might be desirable in some circumstances, I think maybe you can do something similar with Tasmota rules (?)
However for my home use, Mosquitto is on the same computer as Node-red and they are both/seem to be rock solid. Maybe that's just the magic of systemd.

2 Likes
20

I think that once you have invested some time learning a particular firmware you are inclined to stick with it. (And advocate for it!)

I also keep an eye out for alternatives, to make sure I'm not missing out.

So I read with interest what @TotallyInformation has described here, but there is nothing that stands out as being better than Tasmota, indeed for every specific point mentioned I feel Tasmota is the stronger option.

I mean just look how much prettier that web UI is :joy:

So I guess its really a matter of each to their own :stuck_out_tongue_winking_eye:

21

I actually think having a default standard MQTT structure is a good thing, but there many ways to customise this in Tasmota also, so there are no "limits".

Indeed I have been using the embedded Berry scripting built into Tasmota to emulate the openHASP project on top of Tasmota LVGL build.

22

While I don't use the Tasmota web UI every day, it is very handy for troubleshooting, and of course for config eg changing the telemetry interval. It's fairly approachable, though "Configure Other" and "Configure Template" could be improved.

OTA updates are rather iffy with Tasmota, at least on smaller ESP8266s, split into two steps. ESPhome is the clear winner here for me.
Mind you, there is not much reason to ever update the Tasmota version on an existing device.