You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use Case:
When toggling critical switches (e.g., main power to servers or sensitive equipment), it's important to prevent accidental actions. Currently, Home Assistant’s built-in button card does not support separate confirmation dialogs for toggling an entity from on→off versus off→on. In many (if not most) cases it is not both cases that need confirmation. Like with the server switch. Turning it OFF should be confirmed but turning it ON should just be done. With at heater it could be the other way around. Turning it ON should be confirmed but turning it OFF should just be done immediately.
Proposed Feature:
Adjust the built-in frontend (src/panels/lovelace/common/handle-action.ts) to support two different confirmation dialogs based explicitly on the entity's current state: confirmation_on (when turning on) and confirmation_off (when turning off). Existing generic confirmation behavior should remain supported for backward compatibility.
Example UI Configuration:
type: buttonentity: switch.my_critical_switchname: Critical Switchtap_action:
action: toggleconfirmation_on:
text: "Are you sure you want to turn ON the critical switch?"confirmation_off:
text: "Are you sure you want to turn OFF the critical switch?"
Frontend Behavior:
If the entity is OFF and the user toggles it ON:
"Are you sure you want to turn ON the critical switch?"
If the entity is ON and the user toggles it OFF:
"Are you sure you want to turn OFF the critical switch?"
If the new attributes aren't defined, fallback to the existing confirmation attribute:
tap_action:
action: toggleconfirmation:
text: "Are you sure you want to toggle the critical switch?"
Detailed Implementation Proposal:
The following conceptual implementation should replace lines 49→93 and is aimed to preserving existing logic, adding the new state-based confirmation functionality, and is hopefully good enough documented:
// Check if any confirmation configuration exists; if not, simply toggle the switchif(actionConfig.confirmation||actionConfig.confirmation_on||actionConfig.confirmation_off){// Read the current state of the switch using the entity ID provided in actionConfigconstentityId=actionConfig.entity;letisOn=false;if(entityId&&hass.states[entityId]){isOn=hass.states[entityId].state==="on";}else{console.warn("Entity not found or entityId is not set in actionConfig");}// Determine which confirmation configuration to use based on the current stateletconfirmationConfig: any=null;if(!isOn){if(actionConfig.confirmation_on!==undefined){confirmationConfig=actionConfig.confirmation_on;}elseif(actionConfig.confirmation!==undefined){confirmationConfig=actionConfig.confirmation;}}else{if(actionConfig.confirmation_off!==undefined){confirmationConfig=actionConfig.confirmation_off;}elseif(actionConfig.confirmation!==undefined){confirmationConfig=actionConfig.confirmation;}}letconfirmation_text: string|null=null;if(confirmationConfig){if(confirmationConfig.exemptions&&confirmationConfig.exemptions.some((e: any)=>e.user===hass!.user?.id)){confirmation_text=null;}else{if(confirmationConfig.text&&confirmationConfig.text.trim().length>0){confirmation_text=confirmationConfig.text;}else{if(!isOn&&actionConfig.confirmation_on){confirmation_text=hass.localize("ui.panel.lovelace.cards.actions.action_confirmation_on")||"Are you sure you want to turn ON the switch?";}elseif(isOn&&actionConfig.confirmation_off){confirmation_text=hass.localize("ui.panel.lovelace.cards.actions.action_confirmation_off")||"Are you sure you want to turn OFF the switch?";}else{confirmation_text=hass.localize("ui.panel.lovelace.cards.actions.action_confirmation")||"Are you sure you want to toggle the switch?";}}}}if(confirmation_text){forwardHaptic("warning");if(!(awaitshowConfirmationDialog(node,{text: confirmation_text,}))){return;// If user cancels, do not proceed with the toggle}}}// Proceed with toggling or calling the service as desiredawaithass.callService("homeassistant","toggle",{entity_id: actionConfig.entity,});
Questions for Maintainers:
Does modifying handle-action.ts align with current design philosophies?
Are the proposed attribute names (confirmation_on, confirmation_off) clear and acceptable?
Any additional considerations or suggestions to enhance security or maintainability?
Disclaimer
This is very much dry swim from my part. Code isn't tested or anything because I frankly don't have the setup for it. I just thought this would be useful to me and tried to contribute as best I can 😊
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Use Case:
When toggling critical switches (e.g., main power to servers or sensitive equipment), it's important to prevent accidental actions. Currently, Home Assistant’s built-in button card does not support separate confirmation dialogs for toggling an entity from on→off versus off→on. In many (if not most) cases it is not both cases that need confirmation. Like with the server switch. Turning it OFF should be confirmed but turning it ON should just be done. With at heater it could be the other way around. Turning it ON should be confirmed but turning it OFF should just be done immediately.
Proposed Feature:
Adjust the built-in frontend (
src/panels/lovelace/common/handle-action.ts
) to support two different confirmation dialogs based explicitly on the entity's current state:confirmation_on
(when turning on) andconfirmation_off
(when turning off). Existing genericconfirmation
behavior should remain supported for backward compatibility.Example UI Configuration:
Frontend Behavior:
If the entity is OFF and the user toggles it ON:
If the entity is ON and the user toggles it OFF:
If the new attributes aren't defined, fallback to the existing
confirmation
attribute:Detailed Implementation Proposal:
The following conceptual implementation should replace lines 49→93 and is aimed to preserving existing logic, adding the new state-based confirmation functionality, and is hopefully good enough documented:
Questions for Maintainers:
handle-action.ts
align with current design philosophies?confirmation_on
,confirmation_off
) clear and acceptable?Disclaimer
This is very much dry swim from my part. Code isn't tested or anything because I frankly don't have the setup for it. I just thought this would be useful to me and tried to contribute as best I can 😊
Beta Was this translation helpful? Give feedback.
All reactions