Lamp always gets turned off with delay - help diagnosing why, I'm out of ideas

Configuration
1

So I’ve got a weird issue and I can’t figure out why.

In my living room, I’ve got a wall switch and behind it a Fibaro Zwave double switch (FGD212) connected. One button handles a lamp above the couch with 6 smart light bulbs (Innr RB 251 C E14 RGBW). The Fibaro switch and the actual switch above it are configured as momentary switch: button is pressed, it just sends a pulse to close/open the relay and immidiately comes back, so it doesn’t have any on/off position.

In the past, it worked as expected: press the button lights turn on, press it again they turn off (by electricity being cut). At a certain point a year or so ago, it started to behave differently: when I turn it on, lights directly turn on as expected, but when I press it again to turn off, there’s a delay of around 2-3 seconds, and only after that do the lights turn off (not instantly, but with a ~1 second transition).

I thought it might be some delay configured in the fibaro relay itself, but looking at its parameters there is none. I thought maybe it’s something in HA, but there’s no automation or setting I could think of. What was even weirder is my HA was down for the last year (Raspberry Pi died), and that lamp behaved the same way. I have the same configured on another lamp in my living room: fibaro relay behind a switch, lamp with 6 smart Innr light bulbs, and it doesn’t behave this way (it turns off instantly once I press the button).

I’m at my wit’s end what is going on here, especially considering the fact that once the button is pressed and electricity is cut, it should be impossible for the lamps to continue having lights (where would they get the power from?). Anyone have any ideas what could be going on here?

2

A long long story, and yet we’re kept in the dark, please post your “Configurations” unless you ask for “blindfolded” guesses/replies

3

Did you mean the configuration.yaml? If yes, here it is:


# Loads default set of integrations. Do not remove.
default_config:

# Load frontend themes from the themes folder
frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

recorder:
 purge_keep_days: 10
 auto_purge: true
 auto_repack: true
 exclude:
  entities:
   - sensor.date_time
   - sensor.date_time_iso
   - sensor.time
   - sensor.time_date

In case you meant the system information, here it is:

## System Information

version | core-2025.12.4
-- | --
installation_type | Home Assistant OS
dev | false
hassio | true
docker | true
container_arch | amd64
user | root
virtualenv | false
python_version | 3.13.9
os_name | Linux
os_version | 6.12.51-haos
arch | x86_64
timezone | Europe/Berlin
config_dir | /config

<details><summary>Home Assistant Community Store</summary>

GitHub API | ok
-- | --
GitHub Content | ok
GitHub Web | ok
HACS Data | ok
GitHub API Calls Remaining | 5000
Installed Version | 2.0.5
Stage | running
Available Repositories | 2500
Downloaded Repositories | 2

</details>

<details><summary>Home Assistant Cloud</summary>

logged_in | false
-- | --
can_reach_cert_server | ok
can_reach_cloud_auth | ok
can_reach_cloud | ok

</details>

<details><summary>Home Assistant Supervisor</summary>

host_os | Home Assistant OS 16.3
-- | --
update_channel | stable
supervisor_version | supervisor-2025.12.3
agent_version | 1.7.2
docker_version | 28.3.3
disk_total | 294.6 GB
disk_used | 7.4 GB
nameservers | 192.168.1.1
healthy | true
supported | true
host_connectivity | true
supervisor_connectivity | true
ntp_synchronized | true
virtualization | kvm
board | ova
supervisor_api | ok
version_api | ok
installed_addons | File editor (5.8.0), Z-Wave JS (0.27.0), Z-Wave JS UI (6.1.2), Get HACS (1.3.1), Mosquitto broker (6.5.2), Zigbee2MQTT (2.7.1-1)

</details>

<details><summary>Dashboards</summary>

dashboards | 2
-- | --
resources | 0
views | 0
mode | storage

</details>

<details><summary>Network Configuration</summary>

adapters | lo (disabled), enp6s18 (enabled, default, auto), docker0 (disabled), hassio (disabled), vethe476d9d (disabled), vethd2fc9bb (disabled), veth22bf6ba (disabled), veth6f0e35e (disabled), veth8e4f935 (disabled), vetha4d7c45 (disabled), vethb3a1f22 (disabled), veth065b816 (disabled)
-- | --
ipv4_addresses | lo (127.0.0.1/8), enp6s18 (192.168.1.225/24), docker0 (172.30.232.1/23), hassio (172.30.32.1/23), vethe476d9d (), vethd2fc9bb (), veth22bf6ba (), veth6f0e35e (), veth8e4f935 (), vetha4d7c45 (), vethb3a1f22 (), veth065b816 ()
ipv6_addresses | lo (::1/128), enp6s18 (fe80::8eac:3e34:edfa:5738/64), docker0 (fe80::84b1:f5ff:feeb:4132/64), hassio (fd0c:ac1e:2100::1/48, fe80::f4b2:a3ff:feea:73b0/64), vethe476d9d (fe80::dcdd:c4ff:fef9:cff6/64), vethd2fc9bb (fe80::8c52:97ff:fea7:7e6b/64), veth22bf6ba (fe80::308e:cbff:fe33:ae83/64), veth6f0e35e (fe80::b0e3:c7ff:fef0:c6ef/64), veth8e4f935 (fe80::3091:54ff:fe62:dae3/64), vetha4d7c45 (fe80::6460:97ff:fe52:de62/64), vethb3a1f22 (fe80::644c:93ff:fefb:daaa/64), veth065b816 (fe80::3094:dcff:fe7b:5496/64)
announce_addresses | 192.168.1.225, fe80::8eac:3e34:edfa:5738

</details>

<details><summary>Recorder</summary>

oldest_recorder_run | December 21, 2025 at 14:00
-- | --
current_recorder_run | December 27, 2025 at 02:01
estimated_db_size | 25.37 MiB
database_engine | sqlite
database_version | 3.49.2

</details>
4

what I can see from
https://doc.eedomus.com/files/FGD-212-EN-A-v1.01-3.2.pdf
that’s no switch but a dimmer which can be setup without neutral (2-wires) or with neutral (3-wires) with or without bypass. So this wiring would be of interest.

The next thing is, why would you use smart bulbs (Zigbee?) together with a dimmer switch which would cut power from the smart bulbs eventually? You would either use smart switch and dumb bulbs or continues power and smart bulbs?!

5

True, it’s a dimmer. It’s setup with a neutral wire going into it, I saw it.

Why the setup? Once upon a time I want to be able to dim a lamp at that point, then we bought another lamp and the plan changed: I wanted to have smart bulbs there instead so I can configure the lights and be able to change color temperate to make use of adaptive lightning add-on. So I put the bulbs there, and the relay stayed behind the switch. Also the switch plates themselves are momentary switch, so they relay some relay behind them to actually turn itself on/off and cut electricity. And I’d like for any light switch in my home to be able to work in a dumb way, in case internet / home assistant is down.

6

I was thinking in regards to your Fibaro _Devices, and i.e “records” in log-files etc.
I’m away that a “delay” might not be “logged” in either “Activity” nor “core-log” , or zwave-integration, And i still haven’t experienced a need to “explore” my 868 MHz Devices, as it’s only few Temps and Door/motion Sensors, with are fairly stable/correct :slight_smile:

7

You mentioned you have another set of bulbs which don’t do this.

What happens if you swap out one of those bulbs & stick it instead one of the bulbs which have a transition? Do you see the same behaviour?

Asking because this might as well be a bulb issue and not a switch issue, despite the fact that cutting off power is being handled by the switch.

8

that would be my best guess, cutting the power but the Innr smart bulbs have some kind of capacitor inside which makes them slowly fade out (still a somewhat unusual setup)

9

Yeah, another option is to grab a dump of the Z-Wave params from both switches & compare them for any differences.
Maybe your misbehaving switch ran through the automatic calibration and incorrectly determined that it was connected to dimmable dumb bulbs.

10

I’ve done the following tests:

  1. Put a smart bulb form the “misbehaving” lamp to the “behaving” lamp.
    Result: Behaving lamp went on and off instantly, also with a “misbehaving” smart bulb.
  2. Put a smart bulb from the “behaving” lamp to the “misbehaving” lamp.
    Result: Misbehaving lamp still the same behavior of turning off with a delay, also with the “behaving” smart bulb.
  3. Put a smart bulb form the “misbehaving” lamp to a lamp without smart bulbs (but fibaro relay behind light switch).
    Result: Lamp turned on and off instantly.
  4. Put dumb bulb to the “misbehaving” lamp.
    Result: Misbehaving lamp still the same behavior of turning off with a delay, also with the dumb bulb. Funnily, the dumb bulb turned off a bit quicker than the smart bulbs.
11

but then it is for sure the “misbehaving” Fibaro dimmer, can you reset it and configure again?