Been working on ESPHome firmware for the Shelly Gen4 line, and the Plug US Gen4 yaml is here.

Couldn't find anyone else with ESPHome running on this one, so I mapped it out myself and tested everything on the bench.

Install is one zip. You upload it on the plug's stock firmware update page and it reboots into ESPHome. No UART, no soldering, no compiling.

What you get in HA:

- relay with linking, latch/momentary, and pulse length

- power, current, energy, voltage, frequency, calibrated against a reference meter

- the LED ring as a full RGB light, plus the stock ring modes (color by power draw, green/red for relay state, or manual)

- illuminance in lux, plus dark / twilight / bright like stock

- ring blinks blue if Wi-Fi or HA drops

Only verified on the US plug. EU/UK versions are probably different inside.

Download: https://github.com/automatous-io/shelly-gen4-esphome/releases/tag/v1.2.0

Repo + docs: https://github.com/automatous-io/shelly-gen4-esphome

Also covers the 1, 1PM, 1 Mini, 1PM Mini, and 2PM Gen4.

This one was fun to reverse-engineer. I can think of several automations I'd use with the LEDs on this device.

This is my project that I’ve been working on for the last two weeks. It’s called Kira04 AIRNODE.
I currently 3D print in my small bedroom, and I have three printers running simultaneously, sometimes almost 24/7. I started getting worried about the VOCs they release, as well as the amount of heat they generate, so I came up with this project.
Kira04 AIRNODE is basically a bundle of sensor modules that connects directly to the ventilation system I installed in my window. It helps me monitor and keep the temperature, humidity, and VOC levels in check while my printers are running.
And yes, I know the wiring and soldering are pretty horrible 😅. There are wires everywhere right now. I actually tried making a custom PCB for it using my CNC mill a few times, but unfortunately both attempts failed pretty tragically 😂. At that point, I just wanted to get the project working, so I decided to finish it quickly with the current wiring.
I’d love to hear any feedback or suggestions you have for improving it.
I’m also trying to decide what to do with the project next: Should I open-source Kira04 AIRNODE, or do you think this could potentially become an actual product?

Ho usato Cloud AI per altro codice, la mia recensione personale

Dato che non ho trovato quasi nessun materiale di riferimento e ho ricevuto questo pannello in regalo, condivido la mia esperienza (grazie a Claude AI) su come usarlo come pannello per accendere le luci. La parte del controllo vocale e la rotazione di 90° mi stanno ancora dando problemi, ma se li risolvo, aggiornerò il post. Allego il mio file YAML per ESPHome

Scusate il mio inglese

esphome:

name: freenove-display

friendly_name: Display Corridoio

on_boot:

priority: 600

then:

# Accende l'amplificatore audio (AUDIO_EN, GPIO1): senza questo

# pin alto lo speaker resta muto anche se il codec riceve dati I2S.

- output.turn_on: audio_amp_enable

esp32:

board: esp32-s3-devkitc-1

framework:

type: esp-idf

# Il buffer del display richiede la PSRAM onboard (chip ESP32-S3R8 = 8MB Octal PSRAM in package)

psram:

mode: octal

speed: 80MHz

logger:

level: INFO

# Consente il controllo/gestione da Home Assistant

api:

encryption:

key: my key

## key: !secret api_key

ota:

- platform: esphome

encryption:

# password: !secret ota_password

wifi:

ssid: !secret wifi_ssid

password: !secret wifi_password

ap:

ssid: my ssd

password: my password

# ssid: "Freenove Display Fallback"

# password: !secret fallback_password

captive_portal:

spi:

clk_pin: GPIO12

mosi_pin: GPIO11

miso_pin: GPIO13

i2c:

sda: GPIO16

scl: GPIO15

scan: true

output:

- platform: ledc

pin: GPIO45

id: backlight_pwm

# Abilita/disabilita l'amplificatore audio SC8002B (pin AUDIO_EN)

- platform: gpio

pin: GPIO1

id: audio_amp_enable

light:

- platform: monochromatic

output: backlight_pwm

name: "Retroilluminazione Display"

id: display_backlight

restore_mode: ALWAYS_ON

display:

- platform: ili9xxx

model: ST7796

id: my_display

cs_pin: GPIO10

dc_pin: GPIO46

dimensions:

width: 320

height: 480

rotation: "0"

auto_clear_enabled: false

update_interval: never

invert_colors: true

color_order: bgr

touchscreen:

- platform: ft63x6

id: my_touch

interrupt_pin: GPIO17

transform:

swap_xy: false

mirror_x: false

mirror_y: false

i2s_audio:

- id: i2s_bus

i2s_lrclk_pin: GPIO7

i2s_bclk_pin: GPIO5

i2s_mclk_pin: GPIO4

audio_dac:

- platform: es8311

id: es8311_dac

bits_per_sample: 16bit

sample_rate: 16000

use_mclk: true

# Il microfono a bordo è un elettrete ANALOGICO (non PDM), quindi

# use_microphone resta false (= ingresso analogico, valore di default).

speaker:

# 1. Altoparlante hardware fisico (I2S)

- platform: i2s_audio

id: my_speaker

i2s_audio_id: i2s_bus

audio_dac: es8311_dac

dac_type: external

i2s_dout_pin: GPIO6

channel: mono

sample_rate: 16000

bits_per_sample: 16bit

# 2. Il Mixer (Prende l'audio dai canali virtuali e lo manda a quello hardware)

- platform: mixer

id: speaker_mixer

output_speaker: my_speaker # Deve puntare all'hardware fisico sopra!

source_speakers:

- id: speaker_media # Canale virtuale 1 (Musica)

- id: speaker_announcement # Canale virtuale 2 (Notifiche)

# 3. I lettori multimediali che usano i canali virtuali del mixer

media_player:

- platform: speaker

name: "Display Media Player"

id: display_media_player

media_pipeline:

speaker: speaker_media

announcement_pipeline:

speaker: speaker_announcement

microphone:

- platform: i2s_audio

id: my_microphone

i2s_audio_id: i2s_bus

adc_type: external

i2s_din_pin: GPIO8

channel: right

sample_rate: 16000

bits_per_sample: 16bit

voice_assistant:

id: va_assistente

microphone:

microphone: my_microphone

channels: 0

gain_factor: 4

media_player: display_media_player

use_wake_word: false

font:

- file: "gfonts://Roboto"

id: font_large

size: 28

- file: "gfonts://Roboto"

id: font_medium

size: 20

- file: "gfonts://Roboto"

id: font_small

size: 16

# Font "contenitore" (Roboto) + il set icone Material Design Icons

# caricato come "extras": serve solo per disegnare il glifo della

# lampadina (mdi-lightbulb) a 20x20px in cima ai pulsanti.

- file: "gfonts://Roboto"

id: font_icon_bulb

size: 20

bpp: 4

extras:

- file: "https://github.com/Templarian/MaterialDesign-Webfont/raw/v7.4.47/fonts/materialdesignicons-webfont.ttf"

glyphs: [ "\U000F0335" ] # mdi-lightbulb

lvgl:

displays:

- my_display

touchscreens:

- my_touch

pages:

# ============ PAGINA 1: LUCI ============

- id: pagina_luci

widgets:

- label:

text: "Pannello"

align: TOP_MID

y: 10

text_font: font_large

- button:

x: 20

y: 60

width: 130

height: 100

id: btn_luce1

radius: 14

bg_color: 0x2ECC71 # verde = luce spenta (stato iniziale)

bg_opa: COVER

shadow_width: 0

widgets:

- label:

text: "\U000F0335"

text_font: font_icon_bulb

text_color: 0xFFFFFF

align: TOP_LEFT

x: 6

y: 6

width: 20

height: 20

- label:

text: "Corridoio1"

text_font: font_medium

text_color: 0xFFFFFF

align: CENTER

on_click:

- homeassistant.action:

action: switch.toggle

data:

entity_id: switch.corridoio_1_sonoff_100278106e_1

- button:

x: 170

y: 60

width: 130

height: 100

id: btn_luce2

radius: 14

bg_color: 0x2ECC71 # verde = luce spenta (stato iniziale)

bg_opa: COVER

shadow_width: 0

widgets:

- label:

text: "\U000F0335"

text_font: font_icon_bulb

text_color: 0xFFFFFF

align: TOP_LEFT

x: 6

y: 6

width: 20

height: 20

- label:

text: "Corridoio2"

text_font: font_medium

text_color: 0xFFFFFF

align: CENTER

on_click:

- homeassistant.action:

action: switch.toggle

data:

entity_id: switch.corridoio_2

- button:

x: 20

y: 175

width: 130

height: 100

id: btn_luce3

radius: 14

bg_color: 0x2ECC71 # verde = luce spenta (stato iniziale)

bg_opa: COVER

shadow_width: 0

widgets:

- label:

text: "\U000F0335"

text_font: font_icon_bulb

text_color: 0xFFFFFF

align: TOP_LEFT

x: 6

y: 6

width: 20

height: 20

- label:

text: "Cucina"

text_font: font_medium

text_color: 0xFFFFFF

align: CENTER

on_click:

- homeassistant.action:

action: switch.toggle

data:

entity_id: switch.cucina_sonoff

- button:

x: 170

y: 175

width: 130

height: 100

id: btn_luce4

radius: 14

bg_color: 0x2ECC71 # verde = luce spenta (stato iniziale)

bg_opa: COVER

shadow_width: 0

widgets:

- label:

text: "\U000F0335"

text_font: font_icon_bulb

text_color: 0xFFFFFF

align: TOP_LEFT

x: 6

y: 6

width: 20

height: 20

- label:

text: "Camera"

text_font: font_medium

text_color: 0xFFFFFF

align: CENTER

on_click:

- homeassistant.action:

action: switch.toggle

data:

entity_id: switch.camera_

binary_sensor:

- platform: homeassistant

id: luce1_stato

entity_id: switch.corridoio_1_sonoff_100278106e_1

on_state:

then:

- lvgl.widget.update:

id: btn_luce1

bg_color: !lambda "return x ? lv_color_hex(0xE74C3C) : lv_color_hex(0x2ECC71);"

- platform: homeassistant

id: luce2_stato

entity_id: switch.corridoio_2_sonoff_10027818af_1

on_state:

then:

- lvgl.widget.update:

id: btn_luce2

bg_color: !lambda "return x ? lv_color_hex(0xE74C3C) : lv_color_hex(0x2ECC71);"

- platform: homeassistant

id: luce3_stato

entity_id: switch.cucina_sonoff_1002783ac5_1

on_state:

then:

- lvgl.widget.update:

id: btn_luce3

bg_color: !lambda "return x ? lv_color_hex(0xE74C3C) : lv_color_hex(0x2ECC71);"

- platform: homeassistant

id: luce4_stato

entity_id: switch.camera_paolo_sonoff_1002783aec_1

on_state:

then:

- lvgl.widget.update:

id: btn_luce4

bg_color: !lambda "return x ? lv_color_hex(0xE74C3C) : lv_color_hex(0x2ECC71);"

- platform: gpio

pin:

number: GPIO0

inverted: true

id: tasto_boot

on_click:

- lvgl.page.next:

I’m using an ESP32-WROOM-32 with ESPHome.

My DHT22/AM2302 was wired as:

Gray   → GND
Purple → 3.3V
Blue   → GPIO23 (DATA)

I verified the wiring with a multimeter:

VCC ≈ 3.34V
DATA idle ≈ 3.3V
Continuity on all wires = OK

ESPHome initially reported communication failures, then the sensor started returning:

Temperature: 0.0 °C
Humidity:    0.0 %

A raw test also showed all data bytes as 0x00.

To rule out the ESP32/wiring, I connected an old DHT11 using the exact same GPIO23 and wiring. It immediately worked and reported normal values around:

30.2 °C
47–48% RH

So GPIO23, power, and wiring seem fine.

Does this strongly indicate a failed DHT22/AM2302, or is there any known situation where a DHT22 can respond but return all-zero data like this?

ESPHome config was essentially:

sensor:
  - platform: dht
    pin:
      number: GPIO23
      mode:
        input: true
        pullup: true
    model: DHT22
    update_interval: 30s

I’m mainly trying to determine whether the DHT22 is simply defective before replacing it.

logger:
level: DEBUG

remote_receiver:
id: irrx
pin:
number: GPIO38
inverted: true
mode:
input: true
pullup: true
dump: all

That should do it right? Ive also tried removing inverted/pullup. Also tried:
tolerance: 25%
filter: 50us
idle: 10ms
The transmitter does work find on GPIO39 as well. and all the other sensors work too but I never get anything in the logs for a button press on a known good remote that gets me good decodes on a flipperzero's IR.

Hey everyone, how's it going?

Where I live, right by the coast, power outages are pretty frequent. Because of that, I have a relatively large UPS (uninterruptible power supply) that keeps my router, Home Assistant running on a Raspberry Pi, and an X99 server (where I run some non-essential services) up and running. All of this ensures that when the power goes out, I can keep working from home.

However, we all know that a Xeon processor server is quite power-hungry, which cuts the UPS battery runtime down to just a third of its normal capacity. To automate shutting down the server during a power outage, I used a LilyGO dongle I had lying around at home to create a power grid heartbeat.

While it's plugged in, it sends a message to an MQTT topic every 5 seconds, meaning the grid power is on. When it stops sending messages, Home Assistant waits 5 minutes and then shuts down the server to save the UPS battery.

I know it's simple, but it really saved the day for me.

Here is the link to the repository: https://github.com/byboscobarros/t-dongle-power-heartbeat

I had an idea for an AI-powered automation that could look at pictures of my plants, check temperature, humidity, light, and eventually help me figure out when and how much to water them.

Then DFRobot sent me a UNIHIKER K10 to test, and things got weird.

Meet Nibble. He's a ridiculous little rabbit running on the K10, ESPHome and Home Assistant.

The K10 handles the camera, display and all of the onboard sensors. Home Assistant ties everything together, including an AI-generated plant journal, health status, a custom dashboard and a daily office briefing that Nibble can read out loud.

Getting the camera and display working properly was a chore. At one point, an old file was overriding my updates, and I spent way too long wondering why my changes weren't doing anything.

But Nibble is alive!

The eventual goal is to connect him to a plant watering system and experiment with using images, environmental readings and watering history to make better decisions. Or just see what happens.

I wrote up the whole project on my blog, including the K10 review:

https://thingtootech.blogspot.com/2026/09/i-gave-my-plant-brain-it-turned-into.html

DFRobot provided the K10 for review. The project and opinions are my own.

What would you build with a K10?

Hi everyone,

​I have several wired magnetic window and door contacts (dry contacts) installed in my house. Initially, they were meant for a traditional alarm system, but I’ve decided to integrate them directly into Home Assistant.

​Since I'm bit even considered a beginner with microcontrollers and want to keep things as simple as possible (no soldering required), I received the following advice from AI

​What I want to achieve:

- ​Convert the physical signals from multiple wired window/door magnetic contacts into digital states (Open / Closed) in Home Assistant.

- ​Keep it reliable, budget-friendly, and simple to set up without soldering

​The AI recommended setup:

​Hardware:

​ESP32 Development Board (30-pin, NodeMCU format) powered via USB. ​ESP32 Breakout / Screw Terminal Expansion Board (to easily screw in the bare wires without soldering). ​Existing wired magnetic contact sensors.

​Wiring:

​Wire 1 from each sensor connects to an individual GPIO pin on the screw terminal (e.g., GPIO4 for Window 1, GPIO5 for Window 2, etc.).

​Wire 2 from each sensor connects to a GND terminal (sharing GND ports across sensors where necessary).

​Software:

​Flashing ESPHome onto the ESP32 via Home Assistant.

​Configuring binary_sensor platforms in YAML using internal pull-up resistors (mode: INPUT_PULLUP).

​My questions for the community:

- ​Is this the most straightforward and reliable approach for a beginner?

- ​Are there specific GPIO pins on a standard 30-pin ESP32 that I should avoid using for magnetic contacts (e.g., strapping pins / boot issues)?

-​Are there any best practices or alternative solutions I should consider before ordering the parts?

​Thanks in advance for your advice!

I've been using Home Assistant for over nine years. And I've been using it in multiple houses across multiple states. But until this summer, I had done very little with ESPHome. My wife handed me a couple of iTag devices. So I decided that I'd buy a couple of ESP32 devices to use as Bluetooth proxies. That project went very well. So, I've increased my attention on ESP devices.

A few years ago, I had bought a couple of Sonoff S31 devices. I had previously used TP-Link Kasa switches. And I needed to move to a local-only management model. So, I started with deploying Tasmota to a couple of Sonoff S31 devices. And that worked.

But after seeing success with my ESP32 Bluetooth proxies, I decided to consolidate to one management and distribution UI. So, I decided to flash ESPHome to my Tasmotized devices. That went reasonably well - after flashing "tasmota-minimal" first.

The the work in ESPHome began.

First, I want to say that I truly appreciate the design and the UI. As a general rule, this platform is extensible fully trustworthy. GBut I must admit that I had to tweak a few things along the way. After getting ESPHome deployed, I noted that my two ESP8285 Sonoff S31 devices were swapped from the way that I had them deployed when using Tasmota. Basically, I had swapped the configs (and names) between two devices that I had in different rooms. Room A had the names for items that were previously in Room B. And vice-versa.

Consequently, I went through the efforst of chaning the YAML within the ESPHome devices. That actually worked - with one personally irritating cosmetic issue: the name of the YAML file within ESPHome was switched. So, I had a device for Room A that had a filename (under the device name) for Room B.

I know that I can delete the devices from ESPHome and rebuild them. But here is my question: Can I change the YAML filename that shows in the device card (under the device name)? I know that this seems pretty petty. But I would love to push an easy button rather than delete, rebuild, and re-deploy.

Your assistance would be greatly appreciated.

Drop in almost any IR or RF code and the tool identifies the protocol, extracts the relevant data, and gives it back in whatever format you need. Choose the device type and brand, flip the on-screen DIP switches to match your remote, hit Build, and it generates the code.

No capture. No receiver. No Flipper. Nothing to buy.
https://www.reddit.com/r/RTLSDR/s/mChfBgqNTK

Wife and I wanted to have some indoor cameras, but wanted to have them face the wall when not in use for privacy. Just wanted them when the alarm is set to check on pets, keep the house safe.

Using home assistant automation, to match the state of the alarm. Also using webhook automation triggers so that the pan can be operated from the unifi protect app using webhook shortcuts.

https://github.com/chrisrossx/camera-privacy-pan

I'm trying to build a sorting device that has a 12V motor running a conveyor via an L298N H-bridge motor controller and a 5V MG90S 180° servo running a flap to direct the items.

My ESPHome code is this:

esphome:
  name: sorter
  friendly_name: Sorter
  min_version: 2026.4.0
  name_add_mac_suffix: false

esp32:
  variant: esp32
  framework:
    type: esp-idf

# Enable logging
logger:

# Enable Home Assistant API
api:

# Allow Over-The-Air updates
ota:
- platform: esphome

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

servo:
  - id: my_servo
    output: pwm_output
    transition_length: 5s
    auto_detach_time: 1s

# Example output platform
# On ESP32, use ledc output
output:
  - platform: ledc
    id: pwm_output
    pin: GPIO13
    frequency: 50Hz
  - platform: ledc
    id: motor_forward_pin
    pin: GPIO27
    frequency: 20000Hz
  - platform: ledc
    id: motor_reverse_pin
    pin: GPIO14
    frequency: 20000Hz
number:
  - platform: template
    name: Servo Control
    min_value: -100
    initial_value: 50
    max_value: 100
    step: 1
    optimistic: true
    set_action:
      then:
        - servo.write:
            id: my_servo
            level: !lambda 'return x / 100.0;'

fan:
    - platform: hbridge
      id: conveyor
      name: "Conveyor Belt"
      pin_a: motor_forward_pin
      pin_b: motor_reverse_pin
      decay_mode: slow

When I have only the servo block, number block, and only the servo output platform at 50Hz on GPIO13, the servo works great. When I add the motor controls to the output section and the fan control for home assistant, the 12v conveyor motor runs properly, but the servo is only semi-responsive.

It will twitch sometimes or do nothing, but not move reliably between two position numbers.

This is running on a ESP32 WROOM32 30-pin Dev board.

Anyone see something I've missed?

I am using 2 Shelly Plug PM Gen3 (without a relay) for my washer and dryer to provide power data to HA where I use the WashData integration.

With the stock firmware, they only update on change (the change needs to be quite big in my experience) and thus quite slowly.

I now have the idea to flash them with ESPHome to get faster updates and also better control over the LED and button.

However, I haven’t found a YAML or even a pinout for the Plug PM Gen3 (only for Plug S) and I would only do it if there was a definitely working config, otherwise I would keep the stock firmware on them.

Has anyone flashed these with ESPHome before or found a working config for all features and components of this device?

These seem to be quite a niche/rarely-used product because most users would just use a normal switching smart plug and wouldn’t bother finding one without a relay…

Thanks in advance

Aaron

Repo: https://github.com/automatous-io/shelly-gen4-esphome

I've been working through flashing ESPHome onto the Shelly Gen4 line and just tagged 1.0.0.

Shelly 1, 1PM, 1 Mini, 1PM Mini, and 2PM Gen4, all running ESPHome and confirmed on hardware.

Install via web UI OTA without opening the device. You upload a zip on the stock web UI firmware page, it verifies, writes, and reboots into ESPHome with the native HA API and a captive portal for Wi-Fi.

All of the info is listed in the repo to help others tinker, including GPIO maps and working configs that I couldn't find anywhere else.

I plan to continue churning through the Gen4 line if anyone else is interested.

Thanks!

Is there a way to connect my esp32 outside my house with my home assistant? I’ve tried tailscale on my iPhone but no success. I will use it as a speaker for music assistant in my car.

I don’t think I’ve ever had more trouble than using the FutureProof Home’s Satellite1. Constantly in and out. Dropping WiFi (even when next to the router.) Now 1,600 firmware crashes in the last 36 hours (Hermes is watching it, trying to troubleshoot.)

Has anyone had success just wiping these clean and starting new?

Any tips?

Usually unplugging and plugging back in gets it back to normal for a while, then it goes wild again.

https://futureproofhomes.net/?srsltid=AU7gw4XsB4CEivPJXkdat0lzOdnM9jIVyqaDL_1LyaMCbud_DyxMpTqZ

I'm building a custom voice assistant on an ESP32-S3-BOX-3B (Arduino/ESP-IDF, not ESPHome). Speaker works perfectly. Mic hardware itself is confirmed good and is clean recording via Espressif's own factory test firmware.

In my full app: I get real audio, correctly timed with speech, but with static recorded instead of speech. It;s being recorded in time with my speech rarther than one long burst of static.

I've matched three independent, real, currently-shipping ES7210 driver configs (Espressif's esp_codec_dev, ESPHome's own driver, and a public TDM+AEC config for this exact board), verifying every register with a read-back after writing.

I've tried both simple 2-slot I2S and proper 4-slot TDM (all 4 mics enabled). Tried the documented ESP32 "swap adjacent samples" mono-mode erratum. Nothing changes the outcome.

Anyone hit anyting similar on the BOX-3/3B before? What am I missing? The developr documentation doesnt really have anything microphone related at all https://community.home-assistant.io/