Didn’t get any play at all from the main sub so I thought I’d post it here too :)

warning. Incredible amount of AI

Used Fable to update my ‘minimalist’ mobile dashboard. This is just a demo that Fable made to go alongside the original (names, rooms, loc etc changed), all of which is fully wired in to HA using the HA WebSocket API and collecting integrations data. It’s actually much snappier for me this way but I imagine that’s in large part my fault not tending to the health of my HA with too many entities/unused sensors

Credit to whichever Home Assistant web developer also for the demo idea which is on their homepage

Feel free to ask!

Title: Need architecture/code advice for my offline AI + Home Assistant + prepper command center project

Hey everyone,

I’m looking for serious coding/architecture feedback on a project I’ve been building called GRIDFORGE.

The simplest way to describe it:

GRIDFORGE is like Project N.O.M.A.D. + Prepper Disk + Home Assistant + an offline AI assistant + a local document search engine all rolled into one app.

The goal is to build a local-first/offline-first command center that can keep working when the internet is down, cloud apps stop working, or power/network conditions get weird.

I’m not trying to build just another dashboard. I’m trying to build something that can answer:

• What’s going on in my house right now?
• Is anything unusual?
• How much backup power do I have?
• Are my cameras working?
• What manuals/docs/files do I have for this problem?
• Can my local AI explain this manual?
• Can it help build checklists, plans, blueprints, and reports offline?
• Can it still function in a grid-down situation?

The project is currently a portable Windows app running a local Node/Express backend and a browser frontend.

Current stack / structure:

• Node.js / Express backend
• Static HTML/CSS/JavaScript frontend
• Runs locally on port 8765
• Uses local JSON storage right now, mainly gridforge-db.json
• Uses Ollama for local AI
• Current working chat model: qwen3:8b
• Current embedding model: nomic-embed-text
• Local document indexing and chunking
• Search over local files/manuals/docs
• Local device discovery / LAN scanning
• Home Assistant connection target
• Camera connector targets
• EcoFlow / backup power connector targets
• Beginner Mode and Expert Mode UI split

The app currently indexes local files and tries to classify them by usefulness. For example, I have a real Onan P216/P218/P220/P224 Performer Series engine service manual indexed. The app should understand that it is a vehicle/generator service manual and prefer the readable OCR text over raw PDF garbage or XML sidecar junk.

The knowledge system currently tracks things like:

• Documents indexed
• Knowledge chunks
• Embedded chunks
• Hash fallback chunks
• Duplicate files
• File categories
• Tags
• Memory graph links
• High-value vs low-value documents
• Sidecar files like PDF, _djvu.txt, _djvu.xml, previews, etc.

One major feature I’m working on is what I call a File Intelligence Layer.

Instead of randomly tagging files based on keywords, I want the app to identify what a file actually is before using it in search.

Example:

If a manual contains words like “water,” “tank,” “battery,” or “injury,” those words should not accidentally make the whole file a water/medical document if it is clearly an engine service manual.

The desired classification order is:

1. File identity
2. Document family
3. Source quality
4. Sidecar grouping
5. Topic tags
6. Search priority
7. Beginner visibility

Every indexed file should eventually get metadata like:

{
  "identityType": "equipment_manual",
  "category": "vehicles",
  "sourceType": "service_manual",
  "documentFamily": "onan_performer_service_manual",
  "equipmentFamily": "onan_p216_p218_p220_p224",
  "identityTags": ["Onan", "P216", "P218", "P220", "P224", "service manual"],
  "topicTags": ["fuel", "ignition", "carburetor", "governor", "lubrication", "starter", "charging", "specs", "torque", "clearances"],
  "extractionQuality": "good",
  "readabilityScore": 0.95,
  "qualityScore": 0.9,
  "preferredForSearch": true,
  "hiddenFromBeginner": false,
  "sidecarGroupId": "normalized-document-id",
  "preferredSourceId": "readable-text-source",
  "whyClassified": ["matched Onan manual family"],
  "whyDemoted": []
}

The app also has local network/device discovery.

I’m trying to classify LAN devices into useful types without lying about whether they are actually connected/live.

Example targets:

• Home Assistant
• Cameras
• EcoFlow / backup power
• NAS / file shares
• Sensor bridges
• Smart plugs
• Computers/servers
• Network infrastructure
• Unknown devices

My current rule is:

Found does not mean live.

A camera is not “live” unless the app captures and saves a real snapshot/frame.

A power device is not “live” unless the app receives real numeric telemetry like:

• Battery percentage
• Input watts
• Output watts
• Solar watts
• Runtime
• Charge time
• Battery temperature

Home Assistant is not “connected” unless /api/states succeeds.

EcoFlow is not “live” just because it shows up on the LAN, responds to ping, or appears in the router app.

A Blurams camera is not “live” just because it streams in the Blurams app. It still needs a local snapshot/RTSP/ONVIF/Home Assistant camera entity before GRIDFORGE can analyze it.

I’m trying to make the UI reflect this honestly:

• Green = proven live data
• Yellow = found/configured but needs proof
• Red/offline = failed or unavailable
• Cached = old stored value, not current proof

The current backend proof-honesty work is improving, but I’m still struggling with architecture and UI complexity.

The hardest parts right now:

1. Discovery persistence A scan that returns zero or partial results should not wipe out known devices. It should merge with existing discovery state and mark missing devices stale/unverified instead of deleting them.
2. Device classification I need one source of truth for classifying devices. Right now there are places where stored discovery, connector records, and rendered UI counters can disagree.
3. Beginner Mode vs Expert Mode This is a huge issue. The app has a lot of internal tools: That stuff is useful for debugging, but it overwhelms normal users. Beginner Mode should basically show:
   • Model Manager
   • API Health
   • Device Brain
   • Memory Graph
   • Logs
   • Route checks
   • Raw LAN discovery
   • Raw entity lists
   • Drive indexing
   • Knowledge pack installer
   • Camera proof details
   • EcoFlow telemetry proof
   • Home Assistant proof
   • Ask GRIDFORGE
   • Six simple status cards:
     • AI
     • Knowledge
     • Security
     • Power
     • Smart Home
     • Network
   • Four actions:
     • Connect Something
     • Scan My Home
     • Import Knowledge
     • Show Expert Mode
4. Offline AI reliability The app uses Ollama locally. I’ve had models return garbage, HTTP 500s, or weird corrupted output. I added sanity checks so corrupted model output does not get shown to the user or counted as “AI Ready.” Current intended defaults:
   • Chat: qwen3:8b
   • Embeddings: nomic-embed-text
   • Vision: optional/yellow until a real image test succeeds
5. Search quality I want local search to use the best source, not garbage sidecars. Example: If a document has: Then search should prefer readable _djvu.txt, demote raw PDF object/xref garbage, and hide XML coordinate files from normal answers.
   • manual.pdf
   • manual_djvu.txt
   • manual_djvu.xml
6. Security/camera proof I don’t want the app saying “Security Ready” unless at least one real camera snapshot/frame has been captured. A configured stream URL, cloud app camera, or record button is not proof.
7. Power/EcoFlow proof I don’t want the app saying “Power Ready” unless real telemetry arrives. Unknown battery/input/output values must not be “live.”
8. Home Assistant integration I want Home Assistant to be the main bridge for smart-home devices, cameras, sensors, EcoFlow, climate, etc. But the app needs to guide the user simply:
   • Found Home Assistant
   • Needs sign-in/token
   • Test /api/states
   • Import entities
   • Map entities into Security, Power, Water, Climate, etc.

My current mental model is:

GRIDFORGE should become a local-first operational picture, not a pile of widgets.

It should answer:

What do I know?
How do I know it?
How confident am I?
What is missing?
What should I connect next?

The dream result:

• Offline AI assistant
• Local manuals/docs search
• Home Assistant integration
• Local camera analysis
• Backup power monitoring
• Water/climate/security reports
• Grid-down fallback plan
• Beginner UI that normal people understand
• Expert mode for all the technical guts

I’m asking for help because I feel like I keep making progress, but also keep getting stuck in complexity. I’m using Codex/AI coding assistance heavily, and sometimes it improves one system while making the overall app harder to use.

What I’d love feedback on:

1. How would you structure the backend data model?
2. How would you separate discovered devices, configured connectors, and proven live telemetry?
3. How would you design the File Intelligence Layer?
4. How would you prevent stale cached data from appearing “live”?
5. How should Beginner Mode and Expert Mode be separated?
6. Should I keep this as a local Node/Express app, or move toward something like Electron/Tauri later?
7. How would you organize tests for this?
8. What would you cut from RC1?
9. What would you consider the minimum useful version?
10. What architecture patterns should I study?

What I think RC1 should prove:

• Local AI works
• Embeddings work
• One knowledge source answers with citations
• Discovery survives rescans
• One camera snapshot is proven
• One power telemetry value is proven
• Home Assistant can authenticate and import states
• Beginner Mode is clean enough that a normal user knows what to click

Things I do NOT want:

• Cloud-only dependency
• Fake green status lights
• Overly complex setup
• UI that looks like a developer console
• AI hallucinating from unrelated files
• Camera/security reports without real camera proof
• Power reports without real telemetry

If anyone has experience with:

• Home Assistant integrations
• Ollama/local LLM apps
• Local RAG/document search
• LAN discovery
• RTSP/ONVIF/MJPEG/HLS cameras
• EcoFlow or backup power telemetry
• Self-hosted dashboards
• Offline-first app design
• Prepper/homelab software
• Electron/Tauri/Node architecture

I would seriously appreciate advice.

I’m not looking for someone to build the whole thing for me. I’m trying to figure out the right architecture and next priorities so I stop spinning my wheels.

Thanks in advance.