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.
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.
Hi,
I have an issue with Zuidwijk ESP home 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,
Geert
Thank you for the detailed report and screenshots — very helpful.
From what I can see, Homey is receiving the doorbell events (the contact alarmentries 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:
-
When →
ESPHome Controller→Binary sensor changed -
Device → your
smart-doorbell -
Sensor →
Doorbell(notStatus Doorbell) -
And →
state = true -
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:
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.
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
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):
-
When:
Doorbell - Gang→ Het contactalarm gaat aan -
Then: send mobile push message
Do not add
Is aanorStatus Doorbell = jafor 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:
-
When:
ESPHome Controller→Binary sensor changed(sensor = Doorbell) -
Use the trigger tag
state:-
In Advanced Flow, drag the
statetag to a Logic boolean check (is true) -
or include it directly in a test notification message
-
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.
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.
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
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
To update previous information I posted here, there are now two versions of the App made by Uğur:
ESPHome Controller App is for all ESPHome devices, except Konnected panels and GDO’s.
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).
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.
I have a slimmelezer (which is a Dutch smart meter reader, based on ESPHome).
The device: https://www.zuidwijk.com/product/slimmelezer-plus/
The device reads cumulative power which is a setting in the driver:
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_passwordcaptive_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
name: “Cumulative power”
id: cumulative_power
unit_of_measurement: W
update_interval: 30s
accuracy_decimals: 3
lambda: ‘return (id(power_consumed).state - id(power_produced).state) * 1000;’
platform: template
name: “Energy Consumed (cumulative)”
id: energy_consumed_cumulative
unit_of_measurement: kWh
update_interval: 30s
accuracy_decimals: 3
lambda: ‘return id(energy_consumed_tariff_1).state + id(energy_consumed_tariff_2).state;’
platform: template
name: “Energy Produced (cumulative)”
id: energy_produced_cumulative
unit_of_measurement: kWh
update_interval: 30s
accuracy_decimals: 3
lambda: ‘return id(energy_produced_tariff_1).state + id(energy_produced_tariff_2).state;’
platform: dsmr
energy_delivered_tariff1:
name: “Energy Consumed Tariff 1”
id: “energy_consumed_tariff_1”
energy_delivered_tariff2:
name: “Energy Consumed Tariff 2”
id: “energy_consumed_tariff_2”
energy_returned_tariff1:
name: “Energy Produced Tariff 1”
id: “energy_produced_tariff_1”
energy_returned_tariff2:
name: “Energy Produced Tariff 2”
id: “energy_produced_tariff_2”
power_delivered:
name: “Power Consumed”
id: power_consumed
accuracy_decimals: 3
power_returned:
name: “Power Produced”
id: power_produced
accuracy_decimals: 3
electricity_failures:
name: “Electricity Failures”
icon: mdi:alert
electricity_long_failures:
name: “Long Electricity Failures”
icon: mdi:alert
voltage_l1:
name: “Voltage Phase 1”
voltage_l2:
name: “Voltage Phase 2”
voltage_l3:
name: “Voltage Phase 3”
current_l1:
name: “Current Phase 1”
current_l2:
name: “Current Phase 2”
current_l3:
name: “Current Phase 3”
power_delivered_l1:
name: “Power Consumed Phase 1”
accuracy_decimals: 3
power_delivered_l2:
name: “Power Consumed Phase 2”
accuracy_decimals: 3
power_delivered_l3:
name: “Power Consumed Phase 3”
accuracy_decimals: 3
power_returned_l1:
name: “Power Produced Phase 1”
accuracy_decimals: 3
power_returned_l2:
name: “Power Produced Phase 2”
accuracy_decimals: 3
power_returned_l3:
name: “Power Produced Phase 3”
accuracy_decimals: 3
gas_delivered:
name: “Gas Consumed”
platform: wifi_signal
name: “WiFi Signaal”
id: wifi_signalstrength
update_interval: 900s
icon: ‘mdi:signal’
platform: uptime
name: “Uptime”
id: uptime_sensor
internal: true
update_interval: 600s
icon: ‘mdi:clock-outline’
filters:
- lambda: return x / 60;
unit_of_measurement: “min”
text_sensor:
platform: dsmr
identification:
name: “DSMR Identification”
p1_version:
name: “DSMR Version”
platform: version
name: “ESPHome Version”
hide_timestamp: true
Hello, I’ll try to add it, and I’ll let you know when it’s done.
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_classfirst (temperature, humidity, signal_strength, duration, battery, power, voltage, timestamp…), fall back tounit_of_measurement, then to entity type (text_sensor→ string,switch→ onoff,number→ slider,button→ action,select→ enum). -
Create sub-capabilities dynamically using
object_idas the unique sub-ID — e.g.measure_temperature.pad_tempandmeasure_temperature.ambient_tempfor two temp sensors on the same device, each with its own display name from thenamefield. This would also clean up the multiple-capabilities-of-the-same-type situation Peter_Kawa ran into earlier. -
Respect the full metadata set —
nameas display title,icon,accuracy_decimals, min/max/step for numbers,optionsfor 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
**
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.
ratgdo32 disco: vehicle arriving and departing/ presence, dist, target dist, etc. This (shown below) is pulled on top of the base 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: "%"
