# \[APP\]\[Pro\] Esphome Controller App

**URL:** <https://community.homey.app/t/app-pro-esphome-controller-app/150421>\
**Category:** Apps\
**Tags:** app, flow, homey-pro\
**Created:** [February 1, 2026, 1:54pm UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421 "2026-02-01T13:54:22Z")\
**Posts on this page:** 20\
**Page:** 10

<div class="post-metadata">

**Author:** ![ugrbnk](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ugrbnk/32/145764_2.png) [@ugrbnk](https://community.homey.app/u/ugrbnk)\
**Post date:** [April 9, 2026, 9:17am UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/182 "2026-04-09T09:17:58Z")

</div>

Hello, I added this based on user feedback since I don’t have a Ratgdo device. I’d appreciate it if you could explain the non-functioning feature from a technical perspective. If there’s any YAML code, I’ll try to include it to the best of my ability.

---

<div class="post-metadata">

**Author:** ![ugrbnk](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ugrbnk/32/145764_2.png) [@ugrbnk](https://community.homey.app/u/ugrbnk)\
**Post date:** [April 10, 2026, 5:47pm UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/183 "2026-04-10T17:47:02Z")

</div>

I have released a separate app for the Konnected Alarm Panel and GDO. This app is much more stable and offers broader support. For this reason, I will be removing the Konnected Alarm Panel drivers from the Ephome app. I kindly ask users who wish to use the Konnected Alarm Panel and GDO to please use the Konnected Alarm Panel & GDO app.

> **[Konnected Home Security & Garage | Homey](https://homey.app/en-tr/app/com.konnected.security/Konnected-Home-Security-&amp;-Garage/)**
>
> Your DIY devices, seamlessly integrated

---

<div class="post-metadata">

**Author:** ![gwouwerling](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/gwouwerling/32/122620_2.png) [@gwouwerling](https://community.homey.app/u/gwouwerling)\
**Post date:** [April 10, 2026, 8:04pm UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/184 "2026-04-10T20:04:28Z")

</div>

Hi,

I have an issue with Zuidwijk ESP home doorbell ([https://github.com/zuidwijk/esphome-doorbell](https://github.com/zuidwijk/esphome-doorbell)), not being able to generate a notification on my phone when the doorbell rings.

I have installed the doorbell and it’s physically working (it powers up, the doorbell push button triggers the bell so the relay is working and the ESP is powered up, wifi is working and accessible and the device is visible to the ESP home controller). However, the triggers are not visible to Homey in the insights view, nor are they being picked up by Flows. I can see the status of the doorbell change in ESPhome, but that status change isn’t being picked up by either flow or insights.

Am I configuring something wrong or is there something else going on? I have attached screenshots of both Homey and the ESP configuration for your convenience.

With kind regards,

 ![Screenshot 2026-04-10 at 22.02.10](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/d/8/d89ca269e8d2a2e9359e4c2524f43c1b93f8120e.jpeg)

 ![Screenshot 2026-04-10 at 22.02.48](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/5/4/54bc88c6176c4d46a3d93c4facac60524bbfde09.jpeg)

 ![Screenshot 2026-04-10 at 22.03.38](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/8/2/824a6bb72e1f9d2d9cf2c78bd8366b98002fd417.jpeg)

 ![Screenshot 2026-04-10 at 22.03.54](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/2/9/292a96d190b39fe35466e60fbce3a07f5a0f570a.png)

 ![Screenshot 2026-04-10 at 22.04.03](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/1/d/1dc7e1d8aef84e5e8ddf116f55a2f17c8dbdc9ca.png)

Geert

---

<div class="post-metadata">

**Author:** ![ugrbnk](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ugrbnk/32/145764_2.png) [@ugrbnk](https://community.homey.app/u/ugrbnk)\
**Post date:** [April 10, 2026, 8:23pm UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/185 "2026-04-10T20:23:04Z")

</div>

> [@gwouwerling](#):
>
> I have an issue with Zuidwijk ESP home doorbell ( [GitHub - zuidwijk/esphome-doorbell: ESPHome based DoorBell · GitHub](https://github.com/zuidwijk/esphome-doorbell) ), not being able to generate a notification on my phone when the doorbell rings.
> 
> I have installed the doorbell and it’s physically working (it powers up, the doorbell push button triggers the bell so the relay is working and the ESP is powered up, wifi is working and accessible and the device is visible to the ESP home controller). However, the triggers are not visible to Homey in the insights view, nor are they being picked up by Flows. I can see the status of the doorbell change in ESPhome, but that status change isn’t being picked up by either flow or insights.
> 
> Am I configuring something wrong or is there something else going on? I have attached screenshots of both Homey and the ESP configuration for your convenience.

Thank you for the detailed report and screenshots — very helpful.

From what I can see, Homey **is receiving the doorbell events** (the `contact alarm`entries in Insights confirm this), so ESPHome connectivity is working correctly.  
The most likely issue is that the Flow is listening to the wrong entity (for example `Status Doorbell` instead of the actual `Doorbell` button sensor).

Could you please try this exact Flow setup:

1. **When** → `ESPHome Controller` → `Binary sensor changed`

2. **Device** → your `smart-doorbell`

3. **Sensor** → `Doorbell` ( **not** `Status Doorbell`)

4. **And** → `state = true`

5. **Then** → send push notification

Also check:

- In device settings, leave **Entity Key** empty (or set it only to the actual Doorbell binary sensor key, not the status sensor key).

- If the button pulse is very short, add this in ESPHome to make it easier for Homey to catch:

- 

```auto
filters:

delayed_off: 500ms

```

If it still doesn’t notify, please send:

- A screenshot of the Flow card configuration

- A new Diagnostic Report ID

I’ll help you fine-tune it quickly.

---

<div class="post-metadata">

**Author:** ![gwouwerling](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/gwouwerling/32/122620_2.png) [@gwouwerling](https://community.homey.app/u/gwouwerling)\
**Post date:** [April 11, 2026, 5:46am UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/186 "2026-04-11T05:46:35Z")

</div>

Hi,

I have tried to set up the logic according to your instructions, but I can’t seem to locate the state = true verification - I have attached a snippet of the available ESPhome Controller actions for “when” and “end”.

The state change is clearly visible in the device when the doorbell is pressed (doorbell = yes when pressed) but Flows isn’t able to pick up the state change, neither through binary sensor change nor through the dedicated flow card in the doorbell.

I have attached the test flow (which I tested with testing just it either just on binary sensor and with the doorbell status on), but neither trigger a notification or a variable change.

ID = 2BFDFE2C

Hope this helps..

Geert

 ![Screenshot 2026-04-11 at 07.38.53](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/4/4/449f5c0d5afcb03e95db594c7c818ca5bdfa4b3c.jpeg)

 ![Screenshot 2026-04-11 at 07.41.37](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/9/6/9695dc1342d555aa9063f754e9e2a78b4cc8e231.png)

 ![Screenshot 2026-04-11 at 07.42.43](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/9/8/98ce52266d4709d651d6e2fe4e02f78a4d839901.jpeg)

---

<div class="post-metadata">

**Author:** ![ugrbnk](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ugrbnk/32/145764_2.png) [@ugrbnk](https://community.homey.app/u/ugrbnk)\
**Post date:** [April 11, 2026, 7:04am UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/187 "2026-04-11T07:04:21Z")

</div>

The key point is: for the **ESPHome Controller → Binary sensor changed** trigger, there is no separate “state = true” dropdown. The `state` is a **tag/token** from the trigger event.

Also, in your current test flow, the `Is on` condition can miss the ring because a doorbell pulse is very short (it may already be off by the time that condition is checked).

### Please try this exact test flow (no conditions):

1. **When** : `Doorbell - Gang` → **Het contactalarm gaat aan**

2. **Then** : send mobile push message

> Do not add `Is aan` or `Status Doorbell = ja` for this test.

If this works, then the trigger is fine and we can add logic afterwards.

* * *

### If you want to use the generic ESPHome trigger:

1. **When** : `ESPHome Controller` → `Binary sensor changed` (sensor = Doorbell)

2. Use the trigger tag `state`:

---

<div class="post-metadata">

**Author:** ![gwouwerling](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/gwouwerling/32/122620_2.png) [@gwouwerling](https://community.homey.app/u/gwouwerling)\
**Post date:** [April 11, 2026, 7:26am UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/188 "2026-04-11T07:26:29Z")

</div>

Testing the above logic doesn’t trigger a notification so I assume the trigger length is too short to be picked up. I will check with the doorbell vendor if we can change the trigger delay, although I’m a bit surprised that the ESPhome controller doesn’t pick up on state changes after the bell has rung even though it is clearly visible in the device itself.

---

<div class="post-metadata">

**Author:** ![ugrbnk](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ugrbnk/32/145764_2.png) [@ugrbnk](https://community.homey.app/u/ugrbnk)\
**Post date:** [April 11, 2026, 8:56am UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/189 "2026-04-11T08:56:32Z")

</div>

> [@gwouwerling](#):
>
> I have an issue with Zuidwijk ESP home doorbell ([GitHub - zuidwijk/esphome-doorbell: ESPHome based DoorBell · GitHub](https://github.com/zuidwijk/esphome-doorbell)), not being able to generate a notification on my phone when the doorbell rings.
> 
> I have installed the doorbell and it’s physically working (it powers up, the doorbell push button triggers the bell so the relay is working and the ESP is powered up, wifi is working and accessible and the device is visible to the ESP home controller). However, the triggers are not visible to Homey in the insights view, nor are they being picked up by Flows. I can see the status of the doorbell change in ESPhome, but that status change isn’t being picked up by either flow or insights.
> 
> Am I configuring something wrong or is there something else going on? I have attached screenshots of both Homey and the ESP configuration for your convenience.

I’ve made a fix. Please install the beta version of the app, delete the device you added earlier, add it again, and try it out. I’d appreciate it if you could let me know how it goes.

> **[ESPHome Controller | Homey](https://homey.app/en-tr/app/com.ugrbnk.esphome/ESPHome-Controller/test/)**
>
> Your DIY devices, seamlessly integrated

---

<div class="post-metadata">

**Author:** ![gwouwerling](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/gwouwerling/32/122620_2.png) [@gwouwerling](https://community.homey.app/u/gwouwerling)\
**Post date:** [April 11, 2026, 9:41am UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/190 "2026-04-11T09:41:53Z")

</div>

No change unfortunately - find below a second diagnostics ID including attached ESPhome log for the doorbell.

ID: BDB365F2

 ![Screenshot 2026-04-11 at 11.40.30](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/e/b/eb664e2728d748bcc951eced99f89d7adf7186f5.jpeg)

---

<div class="post-metadata">

**Author:** ![ugrbnk](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ugrbnk/32/145764_2.png) [@ugrbnk](https://community.homey.app/u/ugrbnk)\
**Post date:** [April 11, 2026, 10:31am UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/191 "2026-04-11T10:31:07Z")

</div>

> [@gwouwerling](#):
>
> No change unfortunately - find below a second diagnostics ID including attached ESPhome log for the doorbell.

I’ve prepared another test version. Please reinstall it, delete the device, and add it again. If that doesn’t work either, the issue might be on the automation side. If you let me know the result, I’ll see what I can do. By the way, the reports you’ve sent aren’t reaching me. [ESPHome Controller | Homey](https://homey.app/en-tr/app/com.ugrbnk.esphome/ESPHome-Controller/test/)

---

<div class="post-metadata">

**Author:** ![gwouwerling](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/gwouwerling/32/122620_2.png) [@gwouwerling](https://community.homey.app/u/gwouwerling)\
**Post date:** [April 11, 2026, 10:59am UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/192 "2026-04-11T10:59:53Z")

</div>

This appears to have done it!

What I did differently: reading your comment in the changelog in this being the door sensor I just added the “doorbell” as a door sensor device. This then gave the new card with “doorbell was pressed” - which I directly connected to the notification card, and this worked.

Two snips for your convenience.

Geert

 ![Screenshot 2026-04-11 at 12.58.41](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/7/6/76e51771ad8c3285cd89e60a1c738ac965730e38.png)

 ![Screenshot 2026-04-11 at 12.59.38](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/1/5/156f338165db61f61666a57e1886e4dd1dd6b5a2.jpeg)

---

<div class="post-metadata">

**Author:** ![MarcM](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/marcm/32/17200_2.png) [@MarcM](https://community.homey.app/u/MarcM)\
**Post date:** [April 19, 2026, 9:57pm UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/193 "2026-04-19T21:57:53Z")

</div>

To update previous information I posted here, there are now two versions of the App made by Uğur:

> **[ESPHome Controller | Homey](https://homey.app/en-us/app/com.ugrbnk.esphome/ESPHome-Controller/)**
>
> Your DIY devices, seamlessly integrated

**ESPHome Controller** App is for all ESPHome devices, except Konnected panels and GDO’s.

> **[Konnected Home Security & Garage | Homey](https://homey.app/en-us/app/com.konnected.security/Konnected-Home-Security-&amp;-Garage/)**
>
> Your DIY devices, seamlessly integrated

**Konnected Home Security & Garage** App is for Konnected Panels and GDO’s only.

After weeks of intensive back and forth implementing, testing, and fixing, I can testify that this **Konnected Home Security & Garage** App is now rock solid, managing pretty much anything supported by the Konnected Panels:

- **Standalone Alarm System** or **Alarm System Interface** modes
- **Alarm Arming codes** , **API Password** and **Encryption Key**
- Full support for the 12 Zones, 3 Outputs and even the Restart button
- Full device information, including **ESPHome version** , **Konnected**  **Project version** and even **Reboot reason**!
- Quick and handy **Clear Alarm** push button
- Multiple panels support (I tested on 2 x 12 ports panels)
- All Konnected sensors types supported (I tested **Door** , **Window** , **Motion** , **Fire/Smoke** , **Carbon Monoxide** , **Water/Leak** , **Sound** and **Tamper** sensors)
- Timeline notifications including Alarm type and Triggering sensor (Neigbours hate me now!)
- All corresponding flowcards

Thanks again Uğur for you amazing work and dedication, I am 100% sure the Homey Konnected Users will appreciate and hopefully will donate a little too to help you supporting it in the future! From my side, I will try to help new Users if it concerns Konnected 6- or 12-ports Panels (I do not have GDO’s).

---

<div class="post-metadata">

**Author:** ![ugrbnk](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ugrbnk/32/145764_2.png) [@ugrbnk](https://community.homey.app/u/ugrbnk)\
**Post date:** [April 20, 2026, 5:06am UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/194 "2026-04-20T05:06:43Z")

</div>

Without your amazing feedback, I wouldn’t have been able to provide such extensive support. You deserve just as much credit for this success as I do. Your feedback was so helpful that, thanks to you, it felt as though I actually had a Konnected panel device—even though I didn’t. Marc, thank you so much for all your hard work. I hope Homey and Konnected can combine their strengths through this app and reach even more users.

---

<div class="post-metadata">

**Author:** ![Robin\_van\_Kekem](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/robin_van_kekem/32/8187_2.png) [@Robin\_van\_Kekem](https://community.homey.app/u/Robin_van_Kekem)\
**Post date:** [April 20, 2026, 10:22am UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/195 "2026-04-20T10:22:51Z")

</div>

I have a slimmelezer (which is a Dutch smart meter reader, based on ESPHome).  
The device: [https://www.zuidwijk.com/product/slimmelezer-plus/](https://www.zuidwijk.com/product/slimmelezer-plus/)

The device reads cumulative power which is a setting in the driver:

> **[hashtagCumulative measuring devices - Energy | Homey Apps SDK](https://apps.developer.homey.app/the-basics/devices/energy#cumulative-measuring-devices)**
>
> Devices in Homey can either consume energy (e.g. a light bulb), generate energy (e.g. solar panels) or measure the home's total usage (e.g. a P1 meter or current clamp). For this the measure\_power and meter\_power capabilities are used by Energy. | By...

Could you create a driver with the class of a sensor and with the option to tell homey the device reads cumulative power?

> substitutions:
> 
> device\_name: slimmelezer
> 
> esphome:
> 
> name: ${device\_name}
> 
> name\_add\_mac\_suffix: false
> 
> esp8266:
> 
> board: d1\_mini
> 
> restore\_from\_flash: True
> 
> wifi:
> 
> ssid: “Mansion IoT”
> 
> password: !secret wifi\_password
> 
> # Enable fallback hotspot (captive portal) in case wifi connection fails
> 
> ap:
> 
> ```
> ssid: "${device_name} fallback hotspot"
> 
> password: !secret slimmelezer_ap_password
> 
> ```
> 
> captive\_portal:
> 
> # Enable logging
> 
> logger:
> 
> baud\_rate: 0
> 
> # Enable Home Assistant API
> 
> api:
> 
> ota:
> 
> - platform: esphome
> 
> web\_server:
> 
> port: 80
> 
> uart:
> 
> baud\_rate: 115200
> 
> rx\_pin: D7
> 
> rx\_buffer\_size: 1700
> 
> dsmr:
> 
> id: dsmr\_instance
> 
> max\_telegram\_length: 1700
> 
> gas\_mbus\_id: 1
> 
> request\_interval: 30s
> 
> sensor:
> 
> - platform: template
> 
> - platform: template
> 
> - platform: template
> 
> - platform: dsmr
> 
> - platform: wifi\_signal
> 
> - platform: uptime
> 
> text\_sensor:
> 
> - platform: dsmr
> 
> - platform: version

 ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/0/3/03bb17c608655470cb2d56f0762721b868bf2783.png)

---

<div class="post-metadata">

**Author:** ![ugrbnk](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ugrbnk/32/145764_2.png) [@ugrbnk](https://community.homey.app/u/ugrbnk)\
**Post date:** [April 20, 2026, 10:43am UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/196 "2026-04-20T10:43:55Z")

</div>

> [@Robin\_van\_Kekem](#):
>
> Could you create a driver with the class of a sensor and with the option to tell homey the device reads cumulative power?

Hello, I’ll try to add it, and I’ll let you know when it’s done.

---

<div class="post-metadata">

**Author:** ![ugrbnk](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ugrbnk/32/145764_2.png) [@ugrbnk](https://community.homey.app/u/ugrbnk)\
**Post date:** [April 20, 2026, 1:15pm UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/197 "2026-04-20T13:15:49Z")

</div>

I created a separate driver. Could you please test it and provide feedback?

 ![Ekran Resmi 2026-04-20 16.15.11](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/a/9/a9e89f7f911ae2ae8c28992fd60759e81b2c4aff.png)

> **[ESPHome Controller | Homey](https://homey.app/en-tr/app/com.ugrbnk.esphome/ESPHome-Controller/test/)**
>
> Your DIY devices, seamlessly integrated

---

<div class="post-metadata">

**Author:** ![Robin\_van\_Kekem](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/robin_van_kekem/32/8187_2.png) [@Robin\_van\_Kekem](https://community.homey.app/u/Robin_van_Kekem)\
**Post date:** [April 21, 2026, 9:04am UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/198 "2026-04-21T09:04:00Z")

</div>

Works great! Thanks!

However I’m missing gas:  
gas\_delivered:  
name: “Gas Consumed”

And Power Produced Phase 3 and Power Consumed Phase 2

 ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/c/0/c00b7ff520ca09317b707e2b8d905727090b8827.png)

---

<div class="post-metadata">

**Author:** ![Aco\_Mihaljevic](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/aco_mihaljevic/32/121367_2.png) [@Aco\_Mihaljevic](https://community.homey.app/u/Aco_Mihaljevic)\
**Post date:** [April 21, 2026, 10:16am UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/199 "2026-04-21T10:16:27Z")

</div>

Hi Ugur,

First of all, thanks for all the work on this app. I see you really want to do something extraordinary, which is what Athom was officially supposed to do.  
The pace of beta releases is impressive 🙌

I would like to suggest an improvement that, in my opinion, could actually reduce your workload in the long run, not increase it. Because basically, after a while people lose motivation to maintain the app, no donations, private life and other circumstances

I noticed this pattern looking through this thread.  
A lot of requests follow the same shape: someone has a non-standard smart ESP device (beehive scale, LD2410 presence sensor, Konnected GDO, doorbell, and in my case in progress a Cat Heating Pad, Smart Irrigation System and a custom Smart UPS), users send their YAML, and you build or extend a dedicated driver for it. That works, but it doesnt scale well — every exotic device means another driver. And if you ask me, people have mainly opted for the ESP solution for devices you cant buy in a store, and each creator adapts them to their own needs. So each device is a story in itself

\*\*  
Idea/suggestion:\*\*

This is something, how can this work I explored and researched myself with AI tool. You are the expert here, I wont get too involved in the app architecture.

Extend the generic **ESPHome Device** driver to fully use the metadata ESPHome Native API already sends for each entity:

- **Detect capability type** from `device_class` first (temperature, humidity, signal\_strength, duration, battery, power, voltage, timestamp…), fall back to `unit_of_measurement`, then to entity type (`text_sensor` → string, `switch` → onoff, `number` → slider, `button` → action, `select` → enum).

- **Create sub-capabilities dynamically** using `object_id` as the unique sub-ID — e.g. `measure_temperature.pad_temp` and `measure_temperature.ambient_temp` for two temp sensors on the same device, each with its own display name from the `name` field. This would also clean up the multiple-capabilities-of-the-same-type situation Peter\_Kawa ran into earlier.

- **Respect the full metadata set** — `name` as display title, `icon`, `accuracy_decimals`, min/max/step for numbers, `options` for selects.

- **Group entities (better UX)** following the logical structure in the YAML where possible, so a device with 15+ entities doesn’t end up as one flat wall of controls (e.g. Diagnostics: wifi rssi, uptime, ssid — separate from Control).

The user just writes proper ESPHome YAML (which is already good practice for HA compatibility) — `device_class`, meaningful names, correct units. No Homey-specific directives needed.

\*\*  
You can apply this to dedicated drivers too:\*\*

The same logic could be applied to dedicated drivers. Right now when I add a simple on/off light, I still get brightness, RGB and color temperature sliders that dont apply to me. If the Light driver reads from ESPHome metadata which features the entity actually supports (brightness,color\_mode, color\_temperature, etc.), the UI shows only what is really there. Better UX without losing any functionality.  
An example (I doing this with Baldhor app): I have added a few more unusual light capabilities (screenshot) while I’m testing this ESP for my lights. Once everything is tested and working I will delete them from YAML. And it will be a clean, beautiful light device with just ON/OFF switch

 ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/d/1/d11bb0b8a923f303121a00a5e137abd9f981277c.png)

\*\*  
Long term, product perspective\*\*

Instead of maintaining 20+ drivers and adding a new one every time someone shows up with an exotic device, you maintain one smart generic driver plus usual specialized drivers where the UI really adds value (Thermostat with temperature history, Light with color picker, etc.). Exotic devices work out of the box, no manual work from you

One honest limitation Im thinking: if an ESPHome entity uses a unit Homey doesn’t have in its standard capability catalog, falling back to a generic numeric measure is fine, that is a Homey platform limit, not something this approach can fix, and users will understand

I have several ESPHome devices with mixed entity types, also in a month Im starting to work on a Smart Indoor Irrigation system, it is going to be fun (Im creating a web UI and of course integration for Homey here 🙂  
I see this has the potential to be a stable app for all ESP enthusiasts like me, and I want to help 😁  
Im glad to test betas and help here as much as I can

Thanks man again, for everything you have built here! 🙌

---

<div class="post-metadata">

**Author:** ![ugrbnk](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/ugrbnk/32/145764_2.png) [@ugrbnk](https://community.homey.app/u/ugrbnk)\
**Post date:** [April 21, 2026, 11:03am UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/200 "2026-04-21T11:03:13Z")

</div>

> [@Aco\_Mihaljevic](#):
>
> First of all, thanks for all the work on this app. I see you really want to do something extraordinary, which is what Athom was officially supposed to do.  
> The pace of beta releases is impressive 🙌
> 
> I would like to suggest an improvement that, in my opinion, could actually reduce your workload in the long run, not increase it. Because basically, after a while people lose motivation to maintain the app, no donations, private life and other circumstances
> 
> I noticed this pattern looking through this thread.  
> A lot of requests follow the same shape: someone has a non-standard smart ESP device (beehive scale, LD2410 presence sensor, Konnected GDO, doorbell, and in my case in progress a Cat Heating Pad, Smart Irrigation System and a custom Smart UPS), users send their YAML, and you build or extend a dedicated driver for it. That works, but it doesnt scale well — every exotic device means another driver. And if you ask me, people have mainly opted for the ESP solution for devices you cant buy in a store, and each creator adapts them to their own needs. So each device is a story in itself
> 
> \*\*  
> Idea/suggestion:\*\*
> 
> This is something, how can this work I explored and researched myself with AI tool. You are the expert here, I wont get too involved in the app architecture.
> 
> Extend the generic **ESPHome Device** driver to fully use the metadata ESPHome Native API already sends for each entity:
> 
> - **Detect capability type** from `device_class` first (temperature, humidity, signal\_strength, duration, battery, power, voltage, timestamp…), fall back to `unit_of_measurement`, then to entity type (`text_sensor` → string, `switch` → onoff, `number` → slider, `button` → action, `select` → enum).
> - **Create sub-capabilities dynamically** using `object_id` as the unique sub-ID — e.g. `measure_temperature.pad_temp` and `measure_temperature.ambient_temp` for two temp sensors on the same device, each with its own display name from the `name` field. This would also clean up the multiple-capabilities-of-the-same-type situation Peter\_Kawa ran into earlier.
> - **Respect the full metadata set** — `name` as display title, `icon`, `accuracy_decimals`, min/max/step for numbers, `options` for selects.
> - **Group entities (better UX)** following the logical structure in the YAML where possible, so a device with 15+ entities doesn’t end up as one flat wall of controls (e.g. Diagnostics: wifi rssi, uptime, ssid — separate from Control).
> 
> The user just writes proper ESPHome YAML (which is already good practice for HA compatibility) — `device_class`, meaningful names, correct units. No Homey-specific directives needed.
> 
> \*\*  
> You can apply this to dedicated drivers too:\*\*
> 
> The same logic could be applied to dedicated drivers. Right now when I add a simple on/off light, I still get brightness, RGB and color temperature sliders that dont apply to me. If the Light driver reads from ESPHome metadata which features the entity actually supports (brightness,color\_mode, color\_temperature, etc.), the UI shows only what is really there. Better UX without losing any functionality.  
> An example (I doing this with Baldhor app): I have added a few more unusual light capabilities (screenshot) while I’m testing this ESP for my lights. Once everything is tested and working I will delete them from YAML. And it will be a clean, beautiful light device with just ON/OFF switch
> 
> ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/d/1/d11bb0b8a923f303121a00a5e137abd9f981277c.png)
> 
> \*\*  
> Long term, product perspective\*\*
> 
> Instead of maintaining 20+ drivers and adding a new one every time someone shows up with an exotic device, you maintain one smart generic driver plus usual specialized drivers where the UI really adds value (Thermostat with temperature history, Light with color picker, etc.). Exotic devices work out of the box, no manual work from you
> 
> One honest limitation Im thinking: if an ESPHome entity uses a unit Homey doesn’t have in its standard capability catalog, falling back to a generic numeric measure is fine, that is a Homey platform limit, not something this approach can fix, and users will understand
> 
> I have several ESPHome devices with mixed entity types, also in a month Im starting to work on a Smart Indoor Irrigation system, it is going to be fun (Im creating a web UI and of course integration for Homey here 🙂  
> I see this has the potential to be a stable app for all ESP enthusiasts like me, and I want to help 😁  
> Im glad to test betas and help here as much as I can
> 
> Thanks man again, for everything you have built here!

Hello, thank you for this thoughtful post—you clearly have a good grasp of the architecture, and your feedback is truly valuable 🙏

There are a few points that need clarification, because some of what you described is actually already available:

What’s already been implemented: The general ESPHome Device driver does exactly what you suggested — it reads the device\_class, unit\_of\_measurement, and entity type values from the Native API metadata at runtime and dynamically maps them to Homey skills. Sub-skills with object\_id-based identifiers (e.g., measure\_temperature.pad\_temp) are already supported, so each of the two temperature sensors on the same device has its own slot with its own display name. The smart entity filter also resolves most of the “control wall” issue you mentioned.

Based on your feedback, here’s what I just fixed: The light driver was the only place where this wasn’t fully implemented—dimming, RGB sliders, color temperature, and mode switches were statically defined and displayed for all lights regardless of what the hardware actually supported. This has now been fixed. The driver reads the `supportedColorModes` from ESPHome metadata and adds only the features the device actually has. Existing devices will be automatically cleared upon the next app restart; thus, on your simple on/off bulb, only the on/off button will appear, and nothing else.

Regarding the broader vision of a “single smart universal driver”: I support the steps being taken in this direction, and things are largely moving in that direction. Specialized drivers (Light, Climate, etc.) will remain for cases where the user interface truly adds value (such as a color picker or thermostat history), but the universal driver is designed to manage the long list of exotic devices without requiring any manual work on my part.

Your irrigation system and cat heating pad will work out of the box with the general driver—just write a clean YAML file with the appropriate device\_class and meaningful names, and Homey will recognize them correctly.

I look forward to your feedback on the beta version.

---

<div class="post-metadata">

**Author:** ![Silicon](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/silicon/32/120849_2.png) [@Silicon](https://community.homey.app/u/Silicon)\
**Post date:** [April 22, 2026, 2:24am UTC](https://community.homey.app/t/app-pro-esphome-controller-app/150421/201 "2026-04-22T02:24:40Z")

</div>

ratgdo32 disco: vehicle arriving and departing/ presence, dist, target dist, etc. [This](https://github.com/ratgdo/esphome-ratgdo/blob/main/static/v32disco.yaml) (shown below) is pulled on top of the [base](https://github.com/ratgdo/esphome-ratgdo/blob/main/base.yaml) yaml:

```yaml
substitutions:
  id_prefix: ratgdo32disco
  friendly_name: "ratgdo32disco"
  uart_tx_pin: GPIO17
  uart_rx_pin: GPIO21
  input_obst_pin: GPIO4
  status_door_pin: GPIO26
  status_obstruction_pin: GPIO25
  dry_contact_open_pin: GPIO13
  dry_contact_close_pin: GPIO14
  dry_contact_light_pin: GPIO27

web_server:
  include_internal: true
  local: true

esphome:
  name: ${id_prefix}
  friendly_name: ${friendly_name}
  name_add_mac_suffix: true
  min_version: 2026.2.0
  project:
    name: ratgdo.v32disco_secplus2
    version: "32disco"

esp32:
  board: esp32dev
  framework:
    type: arduino

dashboard_import:
  package_import_url: github://ratgdo/esphome-ratgdo/v32disco.yaml@main

packages:
  remote_package:
    url: https://github.com/ratgdo/esphome-ratgdo
    ref: main
    files: [base.yaml]
    refresh: 1s
  # remote_package: !include
  # file: base.yaml

# Sync time with Home Assistant.
time:
  - platform: homeassistant
    id: homeassistant_time

api:
  id: api_server

improv_serial:

esp32_improv:
  authorizer: none

wifi:
  ap:
    ssid: "ratgdo"

captive_portal:

logger:
  logs:
    sensor: NONE

binary_sensor:
  - platform: ratgdo
    id: ${id_prefix}_vehicle_detected
    type: vehicle_detected
    name: "Vehicle detected"
  - platform: ratgdo
    id: ${id_prefix}_vehicle_arriving
    type: vehicle_arriving
    name: "Vehicle arriving"
  - platform: ratgdo
    id: ${id_prefix}_vehicle_leaving
    type: vehicle_leaving
    name: "Vehicle leaving"

number:
  - platform: ratgdo
    id: ${id_prefix}_target_distance_measurement
    type: target_distance_measurement
    entity_category: config
    name: "Vehicle distance target"
    mode: box
    unit_of_measurement: "mm"
  - platform: ratgdo
    id: ${id_prefix}_closing_delay
    type: closing_delay
    entity_category: config
    name: "Closing Delay"
    unit_of_measurement: "s"

output:
  - platform: ledc
    pin: GPIO33
    id: ${id_prefix}_ledc
  - platform: ratgdo
    id: ${id_prefix}_beeper
    type: beeper
    rtttl: ${id_prefix}_rtttl
    song: "alert:d=8,o=5,b=120:a,p,a,p,a,p,4b,p"

rtttl:
  - id: ${id_prefix}_rtttl
    output: ${id_prefix}_ledc

switch:
  - platform: ratgdo
    id: ${id_prefix}_led
    type: led
    pin: GPIO2
    name: "LED"
    entity_category: config
  - platform: ratgdo
    id: ${id_prefix}_laser
    type: led
    pin: GPIO23
    name: "LASER"
    entity_category: config

sensor:
  - platform: wifi_signal
    name: "WiFi Signal"
    update_interval: 120s
  - platform: ratgdo
    id: ${id_prefix}_vehicle_distance_actual
    type: distance
    name: "Vehicle distance actual"
    unit_of_measurement: "mm"
    internal: true
    filters:
      - throttle: 1ms
      - heartbeat: 1ms
  - platform: copy
    source_id: ${id_prefix}_vehicle_distance_actual
    name: Vehicle distance actual filtered
    filters:
      - min:
          window_size: 5000
          send_every: 5000
  - platform: adc
    pin: GPIO34
    name: "Voltage"
    attenuation: auto
    update_interval: 60s
    filters:
      - calibrate_linear:
          - 1.16 -> 5
          - 2.783 -> 12
      # uncomment to convert voltage scale to a % for lead acid batteries
      # - 2.43 -> 0 # 10.5v = 0%
      # - 2.98 -> 100 # 12.85 = 100%
      # - clamp:
      # min_value: 0
      # max_value: 100
    # unit_of_measurement: "%"

```

[Previous page](https://community.homey.app/t/app-pro-esphome-controller-app/150421.md?page=9)

[Next page](https://community.homey.app/t/app-pro-esphome-controller-app/150421.md?page=11)