Project: LAN previews for Hugo websites#

Goal#

Preview Homelab and DashApps on HP1Docker without publishing changes to GitHub or triggering Cloudflare Pages. First make the previews work on the LAN; Pangolin hostnames are an optional later enhancement.

Current setup#

• HP1Docker: 10.1.2.202
• Homelab Hugo project: /home/marc/hugo/homelab; preview port 1313
• DashApps Hugo project: /home/marc/hugo/dashapps; preview port 1314 (confirmed available)
• Mac push has a documented --sync-only option that syncs Homelab content without publishing.
• Normal publish commands push website source to GitHub and trigger Cloudflare. Do not use them for previews.

1. Confirm preview ports on HP1Docker#

• 1.3 Confirm port 1313 is available for the Homelab preview on HP1Docker.

Home Assistant Database Management Project Plan#

First establish safe Recorder purge and repack settings. Then create and validate an export target for historical Home Assistant data.

Keep approximately 30 days of detailed history locally. Complete and verify the Recorder maintenance setup before starting the export work.

1. Configure Recorder Purge and Repack#

• 1.1 Set purge_keep_days to 30.
• 1.2 Enable auto_purge.
• 1.3 Enable auto_repack.
• 1.4 Validate the configuration and restart Home Assistant if required.
• 1.5 Confirm that automatic purge and repack are active.
• 1.6 Confirm that the database remains within the 30-day retention period.
• 1.7 Confirm that sufficient free space remains for maintenance operations.

Do not begin the export-target work until the Recorder purge and repack settings have been configured and verified.

Home Assistant - Cloudflare Pages Build Usage#

1. Project Objective#

Add a simple Home Assistant sensor that shows how much of the Cloudflare Pages monthly build allowance has been used.

The sensor should answer:

How many of my 500 Cloudflare Pages builds have I used this month?

2. Project Scope#

The project will deliver one Home Assistant entity:

sensor.cloudflare_pages_builds

The sensor will show:

• builds used this month;
• builds remaining;
• percentage of the monthly allowance used;
• usage by Pages project;
• the current reporting month;
• the time of the last successful update;
• whether the information is current or unavailable.

This project does not include a dashboard, automation, custom integration, HACS component, or unrelated Home Assistant changes.

GenDash Site Improvements#

1. Project Direction#

• 1.1 Define the website’s three purposes: explain GenDash clearly and drive App Store downloads; provide a technical reference; and offer a Quick Start Guide.
• 1.2 Analyse whether the site is simple, fast, privacy-focused, and easy to maintain through Obsidian and Hugo. Conclusion: simple for visitors and content editing; static and generally fast; privacy-focused for app data; and maintainable, although the publishing infrastructure is more complex than the website itself.
• 1.3 Analyse whether the existing Hugo publishing workflow and English, French, and Spanish structure should be preserved. Conclusion: preserve the current workflow and language structure; they are clear, working, and the English DEV preview fits naturally within them.

2. Homepage#

• 2.1 Analyse whether the homepage explains GenDash clearly within a few seconds.
  • Finding: Yes. The headline, supporting statement, and dashboard mockup quickly establish that GenDash monitors a generator; the iOS app context arrives later in the third paragraph.
• 2.2 Analyse whether the hero headline and supporting text communicate the main problem GenDash solves.
  • Finding: Yes. The Time-to-Empty question makes the outage problem concrete. “Your generator, monitored.” is memorable, but needs the supporting copy to explain the practical benefit.
• 2.3 Analyse whether the homepage presents the most important product benefits in a concise, scannable way.
  • Finding: Partly. The benefits are strong, but they sit in two long paragraphs rather than a short scannable list or set of feature highlights.
• 2.4 Analyse whether support for gas, propane, diesel, battery generators, Home Assistant, and custom telemetry is explained clearly.
  • Finding: Partly. All of these capabilities are named, but they are compressed into one sentence. Home Assistant and custom telemetry would be easier to understand if separated and briefly explained.
• 2.5 Analyse whether the App Store download is the primary and most visible call to action.
  • Finding: Mostly. The App Store badge is the strongest action in the hero and links directly to the correct listing. It appears after three paragraphs and shares its row with About & Contact, so it could be given slightly more prominence.
• 2.6 Analyse whether the free trial, one-time US$4.99 purchase, and no-subscription model are clear.
  • Finding: Complete. The pricing card now states the 7-day trial, one-time US$4.99 purchase, local-equivalent clarification, and absence of subscriptions, ads, cloud accounts, and data harvesting.
• 2.7 Analyse whether the homepage links users effectively to the User Manual, Quick Start Guide, Privacy Policy, and About & Contact pages.
  • Finding: Partly. All four pages are in the navigation, and About & Contact plus the User Manual are linked in the page body. Quick Start Guide and Privacy Policy have no dedicated homepage links outside the navigation.
• 2.8 Analyse the homepage typography, spacing, colors, imagery, and overall visual hierarchy.
  • Finding: Strong overall. The clean typography, orange accent, generous spacing, and dashboard mockup create a calm, credible product page. The long body copy weakens scanning, and the pricing card is visually quieter than its value proposition deserves.
• 2.9 Analyse the homepage on mobile screens for readability, navigation, image sizing, and tap targets.
  • Finding: At a 390 px-wide iPhone viewport, there is no horizontal overflow; the mockup scales to 298 px and the App Store link remains available. The navigation collapses to a hamburger control, but its visible icon is only 18 × 18 px and should be made easier to tap.

3. Quick Start Guide#

• 3.1 Analyse and simplify the Quick Start Guide’s first-run path, including its order, required steps, optional features, and level of detail.
  • Finding: These concerns form one review rather than three separate tasks. A new user can understand the main path—onboarding, permissions, generator setup, optional integrations, load planning, and starting a run—but the guide is broader than a true start-to-finish quick start. The basic order is logical, yet the separate Home Assistant management flow appears before the first-run section, and advanced estimating and maintenance content follows the core task without a strong separation. The guide communicates valuable benefits, but technical details dilute the essential message: configure a generator, start a run, and know how much runtime remains. The EN, FR, and ES DEV guides now begin with an explicit first-run path and identify advanced topics as optional.
• 3.2 Analyse the guide’s typography, screenshots, callouts, spacing, and visual hierarchy.
  • Finding: The published page has a clear heading hierarchy, readable body text, consistent spacing, separators between major topics, and useful bold labels for actions. However, it contains no instructional screenshots or visual callouts, so the reader must translate text into the app interface. The page also renders two table-of-content blocks, which is redundant, and its repeated numbering restarts at 1 in each major topic. Visual hierarchy would improve if the minimum path were visually separated from optional and advanced reference sections.
• 3.3 Analyse the Quick Start Guide on mobile screens for readability and ease of following instructions.
  • Finding: At a 390 px-wide mobile viewport, the guide has no horizontal overflow; the article fits within a 334 px content column, headings wrap within the column, and the page remains readable. The main mobile limitation is length and text density rather than broken layout: a new user must scroll through many paragraphs and lists without screenshots or compact step cards. Mobile usability would benefit most from a shorter first-run path, expandable advanced sections, and more visual guidance rather than a major responsive redesign.
• 3.4 Evaluate whether to capture a small, maintainable set of GenDash screenshots from Xcode and the iOS Simulator, then add them to the shared Images folder and the EN, FR, and ES Quick Start Guides if justified.

4. User Manual#

• 4.1 Analyse whether the User Manual is complete, logically organized, and easy to navigate.
  • Finding: The manual is comprehensive, covering licensing, the product model, onboarding, generator setup, Home Assistant, preferences, environment, notifications, backup, load planning, sessions, history, Live Activities, fleet management, maintenance, reset, FAQs, and real-world examples. Its 19 major sections are broadly logical, but the 10,000-word scope makes it read more like an encyclopedia than a manual for everyday use. The published page also renders two table-of-content blocks, creating redundant navigation. The main opportunity is to preserve the coverage while improving grouping, entry points, and scanning.
• 4.2 Analyse whether the manual clearly explains GenDash features, supported hardware, integrations, and expected user outcomes.
  • Finding: Coverage is strong. The manual explains gasoline, propane, natural gas, diesel, and battery systems; the generator library and custom profiles; Home Assistant; appliance loads; estimating; sessions; fleet management; maintenance; backups; and Live Activities. It generally connects each feature to an outcome such as more accurate Time to Empty, safer load planning, or better outage awareness. The volume of detail can obscure the most important outcomes, so each major section would benefit from a short “what this helps you do” introduction.
• 4.3 Analyse whether technical instructions and terminology are understandable to the intended user.
  • Finding: Instructions are concrete and often supported by examples, field-by-field explanations, and safety notes. However, the manual assumes a technically confident reader and introduces many terms—TTE, Seed Library, LAN/WAN, Long-Lived Access Token, SwiftData, rated versus surge watts, load curves, and kWh/Wh—across a long document. The intended user can follow it, but first-use definitions or a small glossary would reduce cognitive load. UI labels should also remain consistent with the current app.
• 4.4 Analyse the manual’s typography, headings, screenshots, spacing, and visual hierarchy.
  • Finding: The published page has a strong heading hierarchy, bold action labels, useful tables, and safety/privacy callouts. It contains no instructional screenshots or diagrams, so the manual is entirely text-led apart from the site icon. The 19-section length, dense paragraphs, repeated nested headings, and duplicate table of contents make the visual experience heavy. A small number of stable visuals could help, but the maintenance cost should be weighed against the benefit; clearer section summaries and selective callouts are the lower-maintenance improvement.
• 4.5 Analyse the User Manual on mobile screens for readability, navigation, and image sizing.
  • Finding: At a 390 px-wide mobile viewport, the page itself has no horizontal overflow; the article fits within a 334 px content column and headings wrap correctly. There are no instructional images to resize. The main mobile weaknesses are the manual’s length, dense text, and large number of links, which make navigation and scanning tiring. The generator model table is slightly wider than its mobile content area and may need a small table-specific overflow check, but no major responsive failure was observed.

5. Privacy Policy#

• 5.1 Analyse whether the Privacy Policy clearly explains what GenDash collects, stores, and processes.
  • Finding: The policy clearly states that GenDash does not collect generator telemetry, financial information, or personal data on its own servers, and that app data is stored locally. It does not yet describe location data used for weather lookups, the Open-Meteo service, exported backup files, or the information submitted through the website contact form. The policy should distinguish app processing from website and support-service processing.
• 5.2 Analyse whether the policy accurately describes local-only app processing, offline operation, and the absence of user accounts.
  • Finding: The local-first, offline-ready, and no-account claims are generally clear. The Home Assistant statement is too narrow because the app supports a user-configured remote URL as well as a local-network URL. The policy should explain that Home Assistant data goes to the user’s own configured server, locally or remotely, and that internet access is also used for weather data when automatic location mode is enabled.
• 5.3 Analyse whether the website’s analytics and external services are addressed accurately.
  • Finding: No analytics, advertising, or tracking code was found in the site source, but the policy should state whether Cloudflare web analytics and hosting logs are enabled or disabled. The contact page sends form submissions to a Google Apps Script endpoint, which is an external service and is not mentioned. The policy should also identify Apple App Store processing, the Open-Meteo weather API, the user’s Home Assistant server, and the Google contact-form service with appropriate links to their policies where relevant.
• 5.4 Analyse whether the policy is readable, trustworthy, and appropriate for the intended audience.
  • Finding: The six short sections are easy to scan and use plain language. Trust would improve with an effective date and last-updated date, a clear description of the developer/data controller, a more precise scope for deletion and retention, and a note that exported backups may contain sensitive generator, history, and Home Assistant configuration data. The EN page uses H3 headings for its main sections while FR and ES use H2 headings; the heading level should be standardized across languages.
• 5.5 Analyse the Privacy Policy on mobile screens for readability and navigation.
  • Finding: The page is short, text-based, and unlikely to have a major mobile layout problem. It does not need a table of contents. The main mobile improvements are maintaining comfortable line length, making the support email a clear tap target, and checking that any added service-policy links wrap cleanly without horizontal overflow.

6. About & Contact#

• 6.1 Analyse whether the About & Contact page explains the motivation behind GenDash clearly and concisely.
  • Finding: The page explains the motivation well: the creator describes the frustration of estimating generator fuel during outages and the goal of providing a reliable, offline-first tool. The message is credible, but the two paragraphs are longer than necessary and the core purpose could be stated more quickly.
• 6.2 Analyse whether the page builds trust without becoming unnecessarily personal or lengthy.
  • Finding: Identifying the independent creator and emphasizing privacy builds trust. The references to “300 hours” and “more than 1000 modifications” are personal and may become outdated; they are optional proof points rather than essential information. The page presents an individual creator but the form says “our support team,” which should be made consistent.
• 6.3 Analyse whether the support email and Launch Mail App link are easy to find and use.
  • Finding: The email address is prominent, has a Copy button, and has a separate mailto button. The displayed email itself is not clickable, and the Clipboard API has no fallback if copying is unavailable. The French button text “Lancer l’application” is ambiguous; it should clearly mean opening the mail app. The EN, FR, and ES buttons should use equivalent wording.
• 6.4 Analyse whether the page communicates how support requests are handled.
  • Finding: The page says that support will reply by email, but gives no expected response time or guidance about what information to include. The contact form submits through Google Apps Script and uses a no-cors request, so the success message does not fully confirm that the backend accepted the message. The form’s data handling should be consistent with the Privacy Policy.
• 6.5 Analyse the page’s typography, spacing, links, and visual hierarchy.
  • Finding: The two-card layout creates a clear split between the creator/contact information and the message form. The orange action button, generous spacing, rounded cards, and dark-mode styles are consistent with the site. The page relies heavily on duplicated inline HTML/CSS across three language files, which increases maintenance cost. The decorative creator emoji is optional and should follow the same restrained visual approach as the rest of the site.
• 6.6 Analyse the About & Contact page on mobile screens for readability and ease of contact.
  • Finding: The flex-wrap layout should stack the cards on narrow screens, and the form controls use full width with comfortable padding. The main mobile checks are whether the email row wraps cleanly, whether the mail and submit buttons remain easy to tap, and whether the long creator text pushes the contact form too far down the page. No major responsive failure is apparent from the source structure, but it should be confirmed on an actual phone.

7. Final Cross-Site Review#

• 7.1 Compare English, French, and Spanish navigation, structure, and calls to action.
• 7.2 Verify Hugo front matter, titles, descriptions, dates, and canonical URLs across all pages.
  • Finding (checks 1–4): All 30 EN, FR, and ES pages—including DEV—now have front-matter titles, descriptions, dates, lastmod values, draft flags, and tags. Localized titles and descriptions are consistent, every page is set to draft: false, the six homepage files now have the title GenDash, the misspelled privaly tag was corrected to privacy, and all lastmod values were aligned with the current metadata update. Canonical URLs still require the local build/render check.
• 7.3 Check internal links, language links, missing assets, and broken links.
• 7.4 Check light-mode and dark-mode consistency across all pages.

8. Preview & Publish#

• 8.1 Analyse the best way to preview each English page locally before publication.
• 8.2 Analyse desktop, tablet, and mobile presentation before publication.
• 8.3 Analyse whether the existing pushgen workflow can publish the approved changes safely.
• 8.4 Analyse the published Cloudflare Pages site after deployment.
• 8.5 Record follow-up improvements based on the final review.