The external guest link icon was fading in/out on every WebSocket update,
creating a distracting visual effect. Now the fade-in animation only plays
when the URL first becomes available (initial load or when saving a new URL),
rather than re-triggering on every state update.
- Add fadeIn keyframe animation to Tailwind config
- Track animation state with shouldAnimateIcon signal
- Only animate on transition from no URL to having a URL
- Clear animation flag after 200ms to prevent re-triggering
- Add double-checks in global click handlers to prevent race conditions
- Add isCurrentlyMounted flag to prevent cleanup during re-renders
- Remove onBlur handler that was causing premature editor closure
- Simplify conditional logic in click handlers
These changes improve the robustness of the inline editor when
websocket updates occur during editing sessions.
The AnimatedMetric wrapper was causing distracting slide-up/slide-down
animations on every websocket update. While visually interesting, the
high-frequency updates made the dashboard feel too busy. Replaced with
direct value display while maintaining color-coded speed indicators.
Critical fixes to prevent the inline URL editor from closing during API updates:
1. Implement stable guest store with reconcile:
- Use createStore with reconcile() to maintain stable object references
- Key function ensures each guest keeps same proxy instance across updates
- Prevents <For> loop from remounting rows during websocket updates
2. Allow switching between guest editors:
- Mark guest name spans with data-guest-name-editable attribute
- Click handler allows clicking another guest name to switch editors
- Prevents click consumption when opening a different guest's editor
This ensures the inline editor stays open and preserves user input even when
websocket updates arrive, while still allowing seamless switching between
editing different guests.
Redesigned guest URL management from a bulky settings table to streamlined
inline editing directly on the dashboard:
Features:
- Single-click guest name to edit custom URL
- Text cursor indicates editability
- Inline editor with save (✓) and delete (✕) buttons
- Auto-focus and text selection on edit start
- Tag badges hidden during editing to maximize input space
- Click-away closes editor without activating underlying elements
Technical improvements:
- Global editing state prevents multiple simultaneous edits
- Smart click capture intercepts mousedown/click events when editor is open
- Prevents accidental row expansion or other actions during editing
- Delete button (✕) removes URL and icon entirely
- Escape key closes without saving
- Enter key saves and closes
- Add instant-display tooltip on temperature column showing min-max range
- Color-code min/max temperatures individually (green/yellow/red)
- Remove unused NodeCard.tsx component from codebase
- Keep table row height consistent by using tooltip instead of inline display
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Track minimum and maximum CPU temperatures since monitoring started.
This provides better insight into temperature trends and cooling
adequacy over time.
Changes:
- Backend: Add CPUMin, CPUMaxRecord, MinRecorded, MaxRecorded fields
to Temperature model
- Backend: Implement min/max tracking logic in monitoring cycle that
preserves values across polling cycles
- Backend: Initialize min/max on first reading, update on extremes
- Frontend: Update Temperature TypeScript interface with new fields
- Frontend: Display min/max range in NodeCard tooltip (e.g., "52°C
(48-67°C since monitoring started)")
- Frontend: Rebuild dist assets
Temperature display now shows:
- Current temperature with color coding (green/yellow/red)
- Tooltip with full min-max range and context
- Min/max tracked in-memory (resets on Pulse restart)
Example tooltip: "CPU: 52°C (48-67°C since monitoring started)"
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Addresses #101
v4.23.0 introduced a regression where systems with only NVMe temperatures
(no CPU sensor) would display "No CPU sensor" in the UI. This was caused
by the Available flag being set to true when NVMe temps existed, even
without CPU data, triggering the error message in the frontend.
Backend changes:
- Add HasCPU and HasNVMe boolean fields to Temperature model
- Extend CPU sensor detection to support more chip types: zenpower,
k8temp, acpitz, it87 (case-insensitive matching)
- HasCPU is set based on CPU chip detection (coretemp, k10temp, etc.),
not value thresholds
- This prevents false negatives when sensors report 0°C during resets
- CPU temperature values now accepted even when 0 (checked with !IsNaN
instead of > 0)
- extractTempInput returns NaN instead of 0 when no data found
- Available flag means "any temperature data exists" for backward compatibility
- Update mock generator to properly set the new flags
- Add unit tests for NVMe-only and 0°C scenarios to prevent regression
- Removed amd_energy from CPU chip list (power sensor, not temperature)
Frontend changes:
- Add hasCPU and hasNVMe optional fields to Temperature interface
- Update NodeSummaryTable to check hasCPU flag with fallback to available
for backward compatibility with older API responses
- Update NodeCard temperature display logic with same fallback pattern
- Systems with only NVMe temps now show "-" instead of error message
- Fallback ensures UI works with both old and new API responses
Testing:
- All unit tests pass including NVMe-only and 0°C test cases
- Fix prevents false "no CPU sensor" errors when sensors temporarily report 0°C
- Fix eliminates false "no CPU sensor" errors for NVMe-only systems
