HomeNetwork/docs/salotto-overview-switch-investigation.md

Salotto Overview Switch Investigation

Date: 2026-04-17

Instance: Casa

No write actions were taken during this pass. This was a read-only Home Assistant investigation.

Scope

This document investigates why the main Salotto light control in the Overview dashboard no longer works, while the individual Salotto lights still turn on correctly.

MQTT-level debugging was not needed for this pass because the Home Assistant entity, dashboard, history, and automation data were enough to isolate the problem.

Executive Summary

The Overview control is not directly toggling the Salotto light group.

Instead:

1. The card displays light.luci_buone_salotto.
2. Its tap action calls switch.toggle on switch.nitori_salotto_1_left.
3. The automation automation.pulsanti_luce_salotto listens for changes on that switch and then turns light.luci_buone_salotto on or off.

That means the dashboard button depends on an indirect path:

Overview card -> switch.nitori_salotto_1_left -> automation.pulsanti_luce_salotto -> light.luci_buone_salotto

Right now that path is out of sync:

• light.luci_buone_salotto is currently off
• switch.nitori_salotto_1_left is currently on
• the switch has not changed state since 2026-04-14T16:17:11Z
• the light group has continued changing independently through 2026-04-17T09:59:53Z

So the Overview card is using the light group as its displayed state, but it is controlling a different entity whose state no longer matches the light group. That is the reason the button appears broken.

Confirmed Facts

1. The Casa instance was queried

The active Home Assistant instance returned:

• location name: Home
• base URL: http://supervisor/core
• architecture: Casa-sized instance with about 1414 entities and 11 areas

This matches the expected Casa fingerprint.

2. The Overview dashboard Salotto control targets the wrong entity for a direct light toggle

In the lovelace dashboard, the main Salotto controls were found in multiple places, including:

• .views[0].badges[4]
• .views[0].sections[0].cards[1]
• .views[9].sections[0].cards[3]

All of them display light.luci_buone_salotto, but the action is:

tap_action:
  action: perform-action
  perform_action: switch.toggle
  target:
    entity_id:
      - switch.nitori_salotto_1_left

The icon tap action is wired the same way.

So the card is not toggling the light entity it displays.

3. The switch is part of a Zigbee2MQTT wall switch device

switch.nitori_salotto_1_left belongs to device:

• device: nitori_salotto_1
• model: Smart light switch - 3 gang without neutral wire
• integration: zigbee2mqtt

Related entities:

• switch.nitori_salotto_1_left
• switch.nitori_salotto_1_center
• switch.nitori_salotto_1_right

4. The automation still links that switch to the Salotto light group

automation.pulsanti_luce_salotto is configured to react to state changes of the left switch and then control the group:

• if the switch is off -> light.turn_off on light.luci_buone_salotto
• if the switch is on -> light.turn_on on light.luci_buone_salotto

So the dashboard button currently relies on this automation path instead of directly toggling the group.

5. The switch and the light group are no longer aligned

Current state snapshot:

• switch.nitori_salotto_1_left: on
• light.luci_buone_salotto: off

Recent history shows:

• the switch last changed on 2026-04-14T16:17:11Z
• the light group continued changing after that, including:
  • 2026-04-15T15:28:57Z -> on
  • 2026-04-15T22:52:06Z -> off
  • 2026-04-16T16:03:40Z -> on
  • 2026-04-16T22:12:21Z -> off
  • 2026-04-17T09:57:13Z -> on
  • 2026-04-17T09:59:53Z -> off

This confirms the light group is being controlled independently of the switch, so the dashboard button and the displayed light state can no longer be trusted to represent the same thing.

6. The automation path itself is not missing

Recent traces exist for automation.pulsanti_luce_salotto, including runs on 2026-04-13 and 2026-04-14, triggered by switch.nitori_salotto_1_left.

That means the automation definition is present and did run when the switch state changed. The issue is not a missing automation.

Diagnosis

The Overview control broke because it mixes:

• display state from light.luci_buone_salotto
• control action on switch.nitori_salotto_1_left

This only behaves correctly while the switch state and the light group state stay synchronized.

They no longer do.

Once the switch remained on while the group was later turned off by some other path, pressing the Overview button stopped behaving like a normal room-light toggle. The card looks like a light control, but it is really driving an unrelated intermediate switch entity.

Secondary Findings

• light.salotto also exists as a separate group entity that includes all Salotto lights.
• light.luce_salotto exists but is currently unavailable and appears to be a Tuya entity. It does not appear to be the Overview control target found in this investigation.
• The main failure is the dashboard action wiring, not a full outage of the Salotto light entities.

Recommended Fix

The safest fix is to make the Overview Salotto card toggle the actual light group it displays instead of the wall-switch entity.

Good options:

1. Change the card action to toggle light.luci_buone_salotto directly.
2. If the desired room-level target is broader, use light.salotto directly instead.

Less robust option:

1. Keep the switch-based path and add more logic to keep the switch state synchronized with the light group.

That indirect design is the source of the breakage, so direct light control is the cleaner fix.

Applied Changes

The following Home Assistant changes were applied on the Casa instance during this pass:

1. The lovelace Overview Salotto controls were changed to toggle light.luci_buone_salotto directly instead of calling switch.toggle on switch.nitori_salotto_1_left.
2. A new automation, automation.sync_salotto_control_switches, was created to mirror the state of light.luci_buone_salotto back to:
   • switch.nitori_salotto_1_left
   • switch.switch_cucina_neo_l2

The intent of that automation is:

• when the light group turns on -> both control switches should be turned on
• when the light group turns off -> both control switches should be turned off

This preserves:

• direct and reliable dashboard control of the actual light group
• consistent switch state for the two wall-switch control paths

Additional Finding: the Nitori switch is currently stale at the service layer

After applying the config fix, a direct switch.turn_off call was sent to switch.nitori_salotto_1_left to reconcile its stale on state with the currently off light group.

The service call was accepted, but Home Assistant could not verify a state change.

Current evidence:

• light.luci_buone_salotto is off
• switch.switch_cucina_neo_l2 is off
• switch.nitori_salotto_1_left still reports on
• switch.nitori_salotto_1_left has not changed state since 2026-04-14T16:17:11Z
• Home Assistant system logs contain repeated warnings that switch.nitori_salotto_1_left is "missing or not currently available" when targeted by services

This means the original dashboard problem and the current switch-state problem are related but not identical:

1. Dashboard problem: fixed by changing the card to control the light group directly.
2. Nitori state-sync problem: still blocked because the switch.nitori_salotto_1_left entity is not currently accepting or reflecting Home Assistant service commands reliably.

Practical Conclusion

The reliable control path is now:

Overview card -> light.luci_buone_salotto

The intended synchronization path is now:

light.luci_buone_salotto -> automation.sync_salotto_control_switches -> both wall-switch entities

However, the Nitori leg of that sync will only work once switch.nitori_salotto_1_left is healthy again at the Zigbee2MQTT/device layer.

So the configuration fix is in place, but full synchronization of the Salotto Nitori switch still depends on restoring normal commandability of that switch entity.

MQTT and Zigbee2MQTT Restore Diagnostics

Broker-level MQTT diagnostics were run against the Casa Zigbee2MQTT base topic after creating the local file:

• .local/mqtt-home.env

What Zigbee2MQTT still knows about the device

The retained bridge/devices record still contains nitori_salotto_1:

• friendly name: nitori_salotto_1
• IEEE address: 0xa4c1386a5b20e7a7
• model: TS0013
• vendor: Tuya
• interview state: SUCCESSFUL
• supported: true
• type: EndDevice

So the device has not been removed from Zigbee2MQTT and still exists in the coordinator database.

Important difference vs the working kitchen switch

Using the same broker-level probe against the working fallback switch Switch_Cucina_Neo produced:

• a live topic payload on zigbee2mqtt_2/Switch_Cucina_Neo
• fresh state values such as state_l2
• a successful response on zigbee2mqtt_2/bridge/response/device/configure

Using the same probe against nitori_salotto_1 produced:

• no live topic payload on zigbee2mqtt_2/nitori_salotto_1
• no availability payload
• no bridge log output
• no response on zigbee2mqtt_2/bridge/response/device/configure

This is a strong indicator that Zigbee2MQTT still has the device definition, but the device is not currently responding on the Zigbee network.

What this means

At this point the likely fault domain is one of:

1. the switch has lost effective connectivity to the Zigbee mesh
2. the switch is powered but stuck and not answering Zigbee commands
3. the device has fallen off the mesh badly enough that reconfigure requests never complete

This is not behaving like a dashboard, automation, or Home Assistant entity-registry issue anymore.

Best Next Restore Step

The highest-probability recovery action now is:

1. physically power-cycle the Nitori switch circuit or otherwise restore power to the device
2. immediately retest Zigbee2MQTT commandability
3. if it still does not answer, re-pair or re-interview the device in Zigbee2MQTT while preserving the same friendly name if possible

Because the kitchen comparison proved the MQTT request flow is correct, there is no value in continuing to tweak the Home Assistant dashboard or automation config until the Nitori device starts answering Zigbee2MQTT again.

Successful Recovery

The device was recovered without a power-cycle by putting nitori_salotto_1 back into pairing mode while Zigbee2MQTT permit-join was open.

During the recovery watch, Zigbee2MQTT reported:

• bridge/response/permit_join with status: ok
• bridge/event with type: device_announce for nitori_salotto_1
• fresh live payloads again on zigbee2mqtt_2/nitori_salotto_1

Fresh MQTT payloads after re-announce included:

• state_left: OFF
• state_center: OFF
• state_right: OFF
• backlight_mode: normal
• linkquality around 134-145

After the re-announce:

• Home Assistant updated switch.nitori_salotto_1_left back to off
• switch.nitori_salotto_1_right also recovered from stale state and updated to off
• the Salotto light group and kitchen fallback switch remained synchronized

Final validation:

1. The left Nitori button was pressed once after recovery.
2. switch.nitori_salotto_1_left changed from off to on.
3. light.luci_buone_salotto turned on immediately after.
4. switch.switch_cucina_neo_l2 was then synchronized to on by automation.sync_salotto_control_switches.

So the switch is now restored at the Zigbee2MQTT layer and the end-to-end control path is working again:

nitori_salotto_1_left -> automation.pulsanti_luce_salotto -> light.luci_buone_salotto -> automation.sync_salotto_control_switches -> fallback switch state