[jasonstantler]

Three things that work together on a wall display, all tested on a portrait touch screen.

Stacks

Several widgets in one spot, swiped between, while the rest of the dashboard stays put (like an iPhone Smart Stack).

• Make one in Move/Resize by holding a widget over another, or under Admin → Widgets → Stacks (which also picks the tabs it shows on).
• A quick sideways flick turns it, including on plugins (the frame's touch script relays a flick only while the plugin is in a Stack). Dots and arrows show on touch, then fade.
• Goes back to its first widget after a while untouched. Bring to front when… shows a widget while a Home Assistant entity is (or isn't) in a state, e.g. a grill card while the grill is on.
• Widgets shown in a placed Stack no longer count as "enabled but on no tab", so Admin doesn't ask to add them again.

Move/Resize

• Drag a widget onto a dock tab, hold it at the screen edge, or drop it on +, to carry it to another tab (phone style).
• Long-press a widget: Move to tab, Duplicate to tab (or a new tab), Widget settings, Remove from dashboard (asks, then Undo). On a Stack: the showing widget's settings, the others', Stack settings, Unstack.

Display Modes and takeovers (Admin → Displays → Modes)

• A mode (Morning, Dinner, Night…) turns on by schedule or from Home Assistant (a phone's next alarm, an entity's state, only while someone is home). It can start on a tab, dim the screen to off, and change what each Stack shows. Nothing on the dashboard moves.
• A small label beside the dock pins or switches modes. HomeGlow can create a dropdown helper in Home Assistant (Automatic, Normal and the modes) kept in sync both ways, and report the showing mode as a sensor.
• Takeovers: a widget can take over the top or bottom half, or the whole screen, while a Home Assistant rule is on, then hand the wall back. Plugins can raise or close their own with HomeGlow.attention() (documented in the plugin guide).

API

• GET /api/devices/:name/stacks/ha and /stacks/ha/entities
• /api/devices/:name/modes/ha (states, entities, helper, sync, select, report)
• PUT /api/devices/:name/widget-assignments/entry (Undo for Remove)

Tests

Client (Vitest, 972 passing) and check:i18n (English and Spanish). Server route tests for both Home Assistant reads, the restore-entry route and the flick relay. The four googleTimeouts tests need internet access, which my test sandbox does not have; they are unrelated to this change.

🤖 Generated with Claude Code

https://claude.ai/code/session_015FyTJ3CQ7VFGMpS8JsXcc3

[jherforth]

@jasonstantler drap and drop to tab has some hitches:

Test 1

1. I created a stack and added a new tab
2. I enabled layout edit and then dragged to the tab I just created and the stack's edit window is stuck on the screen and requires a page refresh to fix it.

Test 2

1. I purposefully did not create a new tab and edited the layout
2. I dragged a widget to the "+" to create a new tab which crashed the app

3. The widget just needs the tab reset in admin panel when it panics. I also saw it work correctly, where it prompted for a tab create and moved automatically to the new tab. Most of the time it just drops the tab from the widget and it needs to be reapplied.

Stacks seem to work well.
Haven't tried modes but it sounds neat. I think if we can tighten up drag and drop we can merge it in.

[jherforth]

@jasonstantler still a little buggy:

1. When I dragged the calendar to the bar to create a tab, it prompted, I created and it moved, as as expected, but during the same layout edit session I also moved two widgets on the home screen and repositioned them. Went back to the newly created tab to confirm that position looked good, and it did, so I saved the layout. I went back to the home tab the moved widgets went back to their old positions. Before modifying positions and saving again I just refreshed the page and they adopted the positions I had moved them to during the first layout edit, as expected, so the data is being saved and on refresh adopts the position, it just doesn't show the new positions unless the page is refreshed. That could be a data/timing issue or a purely client side issue because on refresh things were they should have been. If we can get that sorted then I'll merge.
2. Stacks seem to be working great.

[jherforth]

@jasonstantler when this is good, have claude rebase so the conflicts are resolved and then we can get it in.

[mrramam]

This is a neat addition!

A few issues that came up on a "take a quick look at this PR" on Claude.

1. Stacking deletes the members' tab entries. stackWidgets (and placeOn in StacksSettings) delete ${tab}::<widget>, but that entry holds more than position: Weather's location, unit and layout, Calendar's view mode and week start. Inside the Stack, Weather falls back to defaults, and saving its settings again 404s ("Assignment not found") because the entry is gone. Unstacking posts fresh entries with null layout, so the settings are lost for good, with no undo.

2. Ordinary Move/Resize drags now carry or stack by accident. Releasing in the bottom rows near the dock moves the widget to the nearest tab (pickDockTarget), resting within EDGE_PX of a screen edge for CARRY_DWELL_MS switches tabs with the widget in hand, and resting over another widget for 550ms makes a Stack on release. Placing a widget in the first or last column or the bottom row hits these easily.

3. droppedAwayRef can stay set and drop the next save. With collisions prevented, a drag onto another widget (or onto a dock tab with the cell underneath taken) never moves, so onLayoutChange never fires and the flag is only cleared by the next saveLayoutsToApi. That next real rearrangement is discarded and snaps back on reload.

4. Rolling back hides stacked widgets. Members are removed from config_json and only stack:<id> plus widgetStacks record them, so any build without this PR shows none of them while they stay enabled.

5. A late alarm turns a mode on for up to 12 hours. alarmWindow wraps to the next until when the alarm rings after it (Morning until 09:00, alarm at 09:30, on until 21:30), and automaticModeAt checks alarms before schedules, so an evening alarm overrides Night. A ring after until should open no window.

Also worth a look:

• One failed HA poll in useDisplayModes sets states: {}, and stepRules forgets every rule, so dismissed takeovers come back and urgent ones wake and chime again.
• Repeated attention('urgent') renews at each call, so it chimes every time and the dismissal never sticks.
• The HA polls run on a plain setInterval with no in-flight guard, and errors aren't cached, so requests pile up while HA is down.

For the rebase onto #375: the new writers (moveWidgetToTab, stackWidgets, unstackOnTab, confirmRemoveWidget, undoRemoveWidget) capture API_DEVICE_URL at render time across awaits, so they should resolve the device at call time the way fetchWidgetAssignments now does. onLayoutsSaved running before the PATCH lands would also drop the touched ids early in reconcileLayoutWithLive and reopen the snap-back that #375 fixed.

[jherforth]

@jasonstantler Thanks, this is close. On the latest head (12b25f5), server tests (745), client tests (1018), check:i18n and the build all pass. In Edge, against a real server:

• The snap-back from my second comment is fixed: two widgets moved on Home, a visit to the new tab and Save, then back to Home leaves them where they were moved. The server and a reload agree.
• Dropping a widget on + opens the new-tab dialog and moves it into the new tab, with no errors.
• A drop just above the dock stays on its tab. A Stack keeps its widgets' entries (marked in_stack), and when it's on screen at page load it moves to another tab with them.

Two things need fixing before merge:

1. A Stack made by holding one widget on another breaks the page until a refresh. This is my Test 1 from the first comment. Steps:

1. In Move/Resize, hold Photos on Chores (or Photos on Calendar) until "Stack with…" shows, then let go.
2. The console logs "Maximum update depth exceeded", and it keeps happening (1, then 3, then 9 errors over a few seconds).
3. The Stack grows on screen (405px wide, then 607px, then 1102px, at an x that doesn't line up with the grid), and a widget card is left floating over its neighbour.
4. Add a tab with + and drag the Stack onto it in the dock. Nothing happens and no request is sent. Sometimes a tap no longer selects the Stack at all.

After a refresh, the same Stack selects, drags to the other tab and takes its widgets along, with no errors. So the trouble is in the session where the Stack was made. The loop shows up in Chores' useEdgeFade ResizeObserver, but that's only where React notices it: the widget keeps re-rendering because the grid around it keeps changing size. My guess is the grid's own layout still has the dragged widget at its last drag position after it went into the Stack, and that fights the new widgets list. Worth checking alongside droppedAwayRef.

2. The display-mode Home Assistant routes can write to any input_select in Home Assistant, with no PIN. The server doesn't check the admin PIN on these routes, and plugin frames can't reach them, but any browser on the network can:

• POST /api/devices/<any>/modes/ha/helper with { "entity_id": "input_select.<anything>" } runs set_options on that helper, replacing its options with Automatic/Normal/the modes;
• PATCH /api/devices/<name>/settings can set displayModes.ha.helper (or helperId) to any helper. After that, /modes/ha/sync rewrites its options and /modes/ha/select sets its state.

An input_select often drives household automations (house mode, alarm mode), so this lets a kid's tablet change them. HomeGlow's other Home Assistant writes go through each plugin's scoped access, and unlocking or disarming needs the PIN. Suggested fix:

• Make displayModes.ha server-owned: the settings PATCH keeps the stored ha.helper/helperId and ignores incoming values.
• Have /modes/ha/helper check the admin PIN the way /api/plugin/v1/ha/:pluginId/action does: checkAdminPin, unless the display remembers it.
• Also, /modes/ha/helper calls writeDevice → ensureDeviceExists, so it creates a device row for an unknown name. Return 404 instead, as the viewport route from feat(mirror): remote-control mirror mode to configure another display #375 does.

The sensor that /report posts to is limited to sensor.homeglow_*_showing, which is fine.

Small and unrelated: under npm run dev, react-grid-layout's prebundled react-draggable reads process.env.DRAGGABLE_DEBUG, so any drag throws "process is not defined" in the dev server. Production builds are fine. This happens on main as well, not because of this PR.

Stacks and the Move/Resize changes otherwise look good. Once 1 and 2 are fixed, I'll recheck and merge.

🤖 Generated with Claude Code

[jherforth]

@jasonstantler Rechecked on 18a777b. Server tests (764), client tests (1031), check:i18n and the build pass.

1 (a Stack made live breaks the page) is fixed. In Edge, holding Photos on Chores makes the Stack with no "Maximum update depth" errors, and none come later. The Stack stays one card wide, nothing is left floating, and dragging it onto a new tab in the dock moves it with both widgets (their settings kept, still marked in_stack). My full run passes 22 of 22, up from 18.

2 (the display-mode Home Assistant routes) is unchanged, so that's what's left before merge:

• POST /api/devices/<any>/modes/ha/helper with { "entity_id": "input_select.<anything>" } still runs set_options on that helper with no PIN, and still makes a device row for a name that doesn't exist.
• PATCH /api/devices/<name>/settings still accepts displayModes.ha.helper / helperId from the client, after which /modes/ha/sync and /modes/ha/select write to that helper.

The fix suggested last time still fits: keep the stored displayModes.ha when the settings PATCH arrives, check the admin PIN on /modes/ha/helper (as /api/plugin/v1/ha/:pluginId/action does: checkAdminPin unless the display remembers it), and return 404 for an unknown device. Once that's in, I'll recheck and merge.

🤖 Generated with Claude Code