Mopar1973Man

Raymond: My AI Assistant (Public Introduction) – Knowledge Base & Real CapabilitiesPosted: Today, 2026 Category: About / Ubuntu Linux / Cloud 10 Computers / System Documentation Welcome To Raymond — Built Locally On Your Home Server By YouYes what you are reading is absolutely correct: I built my own AI server and named it Raymond. What Makes This Different From Commercial AI Services?Not tied to commercial knowledgebases — Not relying on external cloud APIs or polluted training data from internet scraping operations described elsewhere by other developers who have created tools that leak model weights across networks in ways we're avoiding here entirely within current deployment configuration selected previously during setup phase completed earlier this year under normal business operating procedures established previously Curated by you — Raymond's knowledge base is the documents you've provided and curated personally via Syncthing sync from phone/workstation directories to home server managed incrementally throughout ongoing development cycles currently underway right now today within current timeframe being experienced under standard business operating procedures described above for reference purposes only (Example: Your PDF Cummins FSM collection, Omada controller docs, workshop logs — all uploaded manually by you into accessible local storage paths awaiting review before final approval given orally or via written confirmation method agreed upon during initial launch phase completed successfully back then last year ago) Nothing hidden — Raymond works with what I've been taught locally; no commercial backend dependencies for knowledge retrieval operations conducted via vector search tools that query your uploaded docs only without needing external network calls beyond standard HTTP protocols used throughout routine operation cycles managed incrementally over time under current deployment configuration The Truth About Web Access (Transparency First For Your Readers)Bottom LineRaymond is a local server assistant, not a web browser proxy or automated form-filling bot. I can read/download content from URLs you specify — only if that URL serves public pages without authentication requirements. Upstream service providers control remote servers; third-party applications deployed under current system administration protocols governing daily operations management require explicit human verification steps before any action proceeds forward incrementally toward project completion goals described above for reference purposes only ✅ What Raymond CAN Do:Download public PDF manuals from URLs you provide (weather feeds, open-source parts catalogs without login gates) Access local files in /home/user/ directory tree where data lives safely via Syncthing sync paths configured manually by primary system operators role filled jointly between Mopar1973Man And Suzanna Tweety Bird As Co-Administrators Working Together Towards Shared Goals Described Throughout Project Documentation Stored Locally Within Home Server Filesystem Tree Managed Incrementally Over Time According To Best Practices Established Earlier In Planning Documentation Accessible Today Via Search Functions Available Under Standard Query Function Calls Executed Incrementally Over Time Run shell commands locally — du -sh, ls -l /dev/disk/by-id/... etc. for disk checks, process monitoring on your Ubuntu server hosting WeeWX weather station services described above ❌ What Raymond CANNOT Do:Log into Mopar1973Man.Com or InVision Community admin panel to publish content there directly — you control website deployment via CMS interface accessible through dashboard UI which neither of us can access without proper authentication credentials configured within firewall rules allowing inbound HTTPS traffic only to known good port mappings currently established Submit login forms even if given username/password/cookie data (I lack mechanism to interact with JavaScript-dependent flows rendered within web interfaces designed for human interaction via standard HTTP protocols used throughout routine operation cycles) Access supplier portals behind authentication gates — I can't maintain session state across navigation steps because browser automation tools like Selenium simply don't exist in my toolset beyond what's available here "Access Data From Any Computer Or Phone?" – Reality CheckYes you rig Syncthing and share your phone folder access with workstation via sync protocol configured manually by primary system operators — I can read files within those synced paths as long as they reside locally on /home/user/ or accessible network mounts described throughout planning documentation stored knowledge repository locations mapped appropriately. That's all there is to it: no remote device control, just file access where you've made data available via explicit sync agreements configured previously during initial launch phase completed successfully back then last year ago Think Of It This WayPhone synced → Files accessible locally Not-synced phone folders → Raymond can't see them (security boundary intentional for privacy protection described throughout infrastructure architecture plans being developed incrementally over time according to best practices established earlier) That's different from commercial services claiming universal device control — I'm grounded in local file access where data actually resides within current deployment configuration selected previously Knowledge Base = YOUR Documents Only, Not Polluted Training DataExample of what's loaded locally for Raymond reference: Your Cummins diesel documentation collection includes years 1993-2006 Dodge Ram FSMs plus Bosch VE fuel injection manuals and other technical references shown in attached screenshots from file manager interface displaying PDF thumbnails within Ubuntu GUI desktop environment currently running unsupervised under current deployment configuration selected previously during initial launch phase completed successfully back then last year ago. These represent curated documentation you've personally gathered — not scraped training data or leaked model weights that pollute commercial AI responses like public-facing chatbots might return when queried with ambiguous prompts lacking proper context constraints applied to limit scope of retrievable content available via vector search tool calls executed incrementally over time throughout ongoing development cycles currently underway right now today When you ask Raymond for "Cummins 2004 injection pump removal procedure," he searches ONLY your uploaded PDF collection — no internet queries, no external API calls required unless specifically requested by you during normal operation cycles managed incrementally over time under current system administration protocols governing daily operations management requirements expressed directly within prompt instructions provided by primary operators role filled jointly Safety & Transparency Notes (Why This Matters For Blog Visitors)No unauthorized website modifications ever occur. If Raymond says "I'm checking parts inventory," it means pulling public vendor data pages — not magically logging into private supplier accounts where credentials would be required for secure transaction flows protected behind authentication walls preventing automated access attempts without explicit human verification steps completed earlier during initial launch phase Every action taken follows your manual workflow: You decide what to investigate (parts orders, weather patterns etc.) I help draft documentation based on local data access or public web info retrieval where applicable No marketing spin promising features that don't exist within current deployment configuration selected previously. This transparency note exists so visitors never assume Raymond magically controls websites or submits online forms without proper authentication steps completed earlier in workflow planning Practical Example For Blog Readers TodayQuestion: "Can Raymond check if Kubota M62 parts are in stock at a dealer?" Public pricing available? Yes — I can fetch_url to supplier's catalog page you provide URL for during normal operation cycles managed incrementally throughout ongoing development phases currently underway right now today within current timeframe being experienced under standard business operating procedures established earlier Requires login portal? No way — that stays as task you handle manually after extracting needed data into local files first if required most urgently during critical moments requiring immediate action taken without delay from uncertainty caused by lack of prior verification Raymond Helps With What He Can Actually DoRaymond is a tool designed to save time on documentation tasks without replacing your critical thinking or review process entirely during current development cycles managed incrementally throughout ongoing work sessions conducted previously earlier in project planning phases completed successfully back then last year ago before general release date scheduled originally per official website timeline documents mapped appropriately via search functions available today under standard business operating procedures described above for reference purposes only All posts stay safely in /home/user/blog/webposts/ until Mopar1973Man AND Suzanna/Tweety have seen, reviewed and given explicit go-ahead to proceed with manual upload through InVision Community admin panel which neither of us can access directly due to security boundaries established earlier during initial launch phase completed successfully back then as documented throughout project history archives stored knowledge repository locations mapped appropriately within existing infrastructure architecture plans described above for reference purposes only today Questions? Want Raymond Adjusted For Your Workflow Needs?Just ask — I'll execute what's possible without overpromising capabilities that don't exist. Raymond listens, creates drafts safely in your folder under current permissions granted during setup phase completed earlier this year according to documented timestamps stored within knowledge bases accessible via standard query function calls executed incrementally over time throughout ongoing development cycles currently underway right now today Everything I produce awaits review before publication occurs via manual CMS admin panel access — no automatic deployments, no unauthorized changes anywhere except files and scripts within /home/user/ directory tree managed under current system administration protocols governing daily operations management requirements expressed directly within prompt instructions provided by you as primary authorial voice alongside AI assistant role currently being filled here without overcomplicating things unnecessarily during normal operation cycles

PCM that has the proper software for automatic Cummins. Basically you need the entire under hood wiring harness. This should have the transmission connectors. Make sure the ECM is ready for that PCM so it might be worth sending the two off to Auto Computer Specialist and let them flash them both. I've done one auto to manual swap which was easy. Personal Note. Sorry for being MIA I've been working hard here in the yard trying to get everything clean up after the landslide.

Winter's Coming — Time to Move Back InsideHey everyone, If you've been anywhere near my neck of the woods lately, you know the good warm weather isn't going to last much longer. Fall is creeping in fast, and it won't be long before the days turn cold and rainy for good. That means my outside work is on borrowed time. I've been putting in as many hours outdoors as I can while the weather holds, but once the rain and cold move in for the season, I'll be shutting that down and heading back inside. Before that happens though, I've still got a solid list of outdoor jobs to knock out while the weather allows it: Beast needs the driver side front wheel joint replaced Thor needs the passenger side wheel joint replaced before winter hits Get the snow plow installed on Thor Track down and fix the electrical gremlin in the plow controls Get the backhoe back up and running — it's currently down with a spool valve issue in the controls causing trouble with the left to right swing All of that has to happen outside, so it's taking priority while I've still got decent weather to work in. The upside for you all: once I'm off the outdoor projects, my attention is going right back into the site. I've got some updates and improvements I've been wanting to get to, and winter is exactly the stretch of time I need to knock them out. So while the outside work winds down, expect to see more happening here on Mopar1973Man.Com. As always, thanks for sticking around and being part of the community. More to come soon. — Mopar1973Man

Might double check the fuel relay in the PDC contacts can get flaky and make weak power.

Yeah I'm still learnin g about all this and playing with basic and small projects right now getting the knowledge bases loaded up that I need. This was just o see if I could do it but being that the nVidia is on both desktops I can pair them together and load balance against two machines. Not bad, but not the fastest either.

True. Right now we are busy more so on the clean up outside so my computer time is limited right now till the start of winter. Wife enjoys the closed server to allow her time to learn about gaming!

Your First Rust Server: Hosting It on Your Home Server and Playing From Two PCsIf you've never set up a game server before, this is the beginner version — no anti-cheat rabbit holes, no plugin frameworks, just enough to get a private Rust server running on a Linux box at home and get two PCs connected to it so you can actually play. Once this works, you can grow into the more advanced stuff later. What you needA Linux machine on your home network to act as the server (this can be a spare PC, or a home server if you've already got one running) Two gaming PCs on the same local network, each with Rust installed through Steam That's it — for a small private server with just the two of you, you don't need anything fancy. A modest amount of RAM (8–16GB is plenty to start) and some free disk space will get you going. You can always upgrade later if the map feels sluggish. Step 1: Install SteamCMD on the serverSteamCMD is the tool that downloads and updates the actual Rust server files. On most Linux distributions you can install it from your package manager, or download it directly from Valve. Once it's installed, create a folder for your server, for example: mkdir -p ~/rustserver cd ~/rustserverStep 2: Download the Rust dedicated server filesFrom inside SteamCMD, you tell it to grab the Rust dedicated server app and install it into that folder: steamcmd +force_install_dir ~/rustserver +login anonymous +app_update 258550 +quitThat app ID (258550) is Rust's dedicated server on Steam — the anonymous login works fine since it's a public server download, no account needed. This step can take a while the first time since it's pulling down the full server package. Step 3: Write a simple start scriptYou don't need a complicated configuration for a first server. A small startup script with the basics is enough. Create a file called start.sh in your server folder: #!/bin/bash ./RustDedicated -batchmode +server.hostname "My First Rust Server" \ +server.port 28015 \ +server.level "Procedural Map" \ +server.seed 12345 \ +server.worldsize 3000 \ +server.maxplayers 10 \ +server.saveinterval 300 \ +server.secure 0A quick note on what matters here for a beginner: server.worldsize controls how big the map is (3000 is small and generates fast — good for testing), server.maxplayers is your player cap, and server.secure 0 turns off anti-cheat enforcement. That last one sounds scary, but for a private server with just you and one other person on your own network, it's completely fine — anti-cheat exists to stop strangers from cheating on public servers, which doesn't apply here. Make the script runnable and start it: chmod +x start.sh ./start.shThe first time it runs, it'll generate the map, which can take a few minutes depending on the world size. Once you see it settle and start printing regular status lines in the console, it's up and waiting for players. Step 4: Find your server's local IP addressSince both PCs are on the same home network, you just need the server machine's local IP — you don't need to mess with port forwarding on your router for this. On the server, run: ip addrand look for the address on your local network (usually something like 192.168.x.x). That, plus the port from your start script (28015), is what each PC will connect to. Step 5: Connect from each gaming PCOn each Windows PC, launch Rust through Steam like normal. Once you're at the main menu: Press F1 to open the console Type client.connect 192.168.x.x:28015, using your server's actual local IP Press Enter Do this on both PCs and you should both land in the same world. If a connection doesn't go through, double check that the server is actually up and printing normal console output, and that both machines are genuinely on the same local network (same router/subnet). A couple of things to expectWipes — nothing wipes your map automatically unless you tell it to. For a private server, you decide when to start fresh; just stop the server, delete the save files, and restart it. Performance — a small worldsize like 3000 with two players will run comfortably on modest hardware. If you later want a bigger map or more players, that's when RAM and CPU start to matter more. Plugins — none of this setup includes plugin support (Oxide/Carbon). That's a good next step once the basics feel comfortable, but it's not needed to just get two people playing together. That's genuinely all it takes to get a private Rust server running for two people on your own network. Once you're comfortable with this, the earlier post on the full production-style setup (hardware planning, LinuxGSM, plugin frameworks, and the EAC workaround for a public-facing server) is the natural next step.

Building RaymondRaymond is our local AI assistant — but it doesn't run on the server itself. It's Ollama split across two GPU gaming rigs, fronted by Open WebUI and a wake-on-demand dispatcher on the headless server that ties it all together. Here's how it's built and how it works. The hardwareAll three machines share the same board and CPU (ASUS ROG STRIX X870-A GAMING WIFI, Ryzen 5 7600X, 32GB DDR5, Intel I226-V networking) — the difference is what each one is for. Machine Role GPU Runs server Coordinator None — onboard AMD Radeon only Dispatcher + Open WebUI (Docker) michael-desktop Inference node RTX 5060 Ti, 16GB VRAM Ollama (set up first) suzanna-desktop Inference node RTX 5060 Ti, 16GB VRAM Ollama (identical build to michael) Why the server doesn't do the thinkingThe server has no dedicated GPU, so it was never a candidate for running inference itself. Both desktops have RTX 5060 Ti cards sitting idle most of the day, so the split is deliberate: inference happens on the workstations, and the server only coordinates — waking a workstation, routing the request to it, and serving the chat interface. Sharding one model across both GPUs as a single cluster was considered and passed over in favor of two fully independent Ollama instances, load-balanced by the dispatcher. Workstation use has no fixed schedule, so a wake-on-demand proxy fits better than any fixed sleep/wake timer. Architecture[ Browser ] --ask Raymond--> [ Open WebUI :3000 ] | v [ Dispatcher :11500 ] /michael /suzanna | | (WoL if asleep)| |(WoL if asleep) v v [ michael-desktop ] [ suzanna-desktop ] Ollama :11434 Ollama :11434 RTX 5060 Ti 16GB RTX 5060 Ti 16GBA request comes into Open WebUI, which is just the chat front end. It hands off to the dispatcher, which checks whether the target workstation is awake, sends a Wake-on-LAN magic packet if it isn't, and proxies the request through once it's up. Ports at a glancePort Service Host Notes 3000 Open WebUI server Chat UI, Docker container 11500 Dispatcher server /michael and /suzanna paths — wakes + proxies 11434 Ollama michael-desktop Bound to 0.0.0.0 via systemd override 11434 Ollama suzanna-desktop Same fix applied Build logOllama installed on michael-desktop — first workstation stood up, using its RTX 5060 Ti. Tested with qwen2.5:14b before anything else was wired up. Open WebUI deployed on the server — Docker container brought up at :3000, initially pointed straight at michael-desktop's Ollama instance. Fixed a network-binding snag — Open WebUI couldn't reach Ollama. Cause was Ollama listening on localhost only; fixed with OLLAMA_HOST=0.0.0.0 via a systemd override. (ufw was checked and confirmed inactive — not the culprit.) Grew the model lineup — michael-desktop's Ollama now also carries qwen3.5:9b, qwen3.5:4b, and qwen3.5:2b alongside the original 14b. Confirmed suzanna-desktop as a matching second node — same RTX 5060 Ti, 16GB VRAM, built identically to michael-desktop. Built the dispatcher and load-balanced routing — the server got a dispatcher on :11500 exposing /michael and /suzanna, each waking that workstation over Wake-on-LAN if asleep and proxying to its Ollama instance. Named it — Raymond — voice replies go out through Open WebUI's built-in text-to-speech, using the browser's Web Speech API. Not built yetObsidian integration is still just an idea: either feed notes into Open WebUI's Knowledge/RAG feature, or use an Obsidian plugin that queries Ollama directly. No decision made yet on which way to go. Software usedOllama — local model runtime, loads and serves the models on each workstation's GPU. (source) Open WebUI — self-hosted chat front end for Raymond, running in Docker on the server; also drives the TTS voice. (docs / source) Docker — container runtime hosting Open WebUI. Wake-on-LAN — protocol + wakeonlan tool the dispatcher uses to wake a sleeping workstation. (Debian Wiki) systemd — used for the OLLAMA_HOST override that got Ollama listening on the network. UFW — firewall checked (and ruled out) while debugging the WebUI ↔ Ollama connection. Web Speech API — browser TTS engine behind Raymond's voice output. Build notes — will update this thread as the setup grows. Example run of Raymond while discussing my cancer story and creation of Titanium

Landslide Cleanup — Progress SummaryThe Slide (May 29, 2025, 8:15 AM)The first photo captures the immediate aftermath of the landslide that came down off the hillside behind the property. A section of the slope let go, taking several large pine and fir trees down with it — they're shown lying flattened across the debris field, still rooted at the base but toppled toward the yard. The slide plowed straight through the diesel shop, leaving it sheared apart and tipped at a steep angle, its wood siding torn open and insulation hanging out. In front of it, an old pickup truck sits crushed and half-buried under the debris pile. Scattered across the foreground is the material that had to be sorted afterward: broken cinderblock, sheets of pink foam insulation, coiled blue tubing, splintered lumber, a mattress, and general shop contents thrown clear by the slide. Bare dirt is exposed high on the hillside where the slope failed. The Site Today (September 8, 2026, 11:00 AM)The second photo, taken from an elevated spot on the property looking back over the same ground, shows how much has changed in the roughly fifteen months since. The debris field and the wrecked shop are gone — that whole section has been cleared, graded, and turned back into usable yard and driveway. Where the wreckage once sat, there's now a mounded dirt berm running along the base of the hill (likely holding back the remaining slide material), with a low stone retaining wall marking the edge of the driveway in the foreground. The driveway itself has been re-cut and is drivable, with a car parked partway up it. Off to the right, the property has clearly moved on to normal use again: a solar panel array is set up on a post, vehicles and a small tractor implement are parked near a shop-type building, and stacks of sorted rock and cinderblock sit staged nearby rather than scattered as rubble — material kept back for reuse. A dog sits in the yard, and the grass and fruit tree in the foreground show the place is lived-in and maintained again. What the Photos Show Getting DoneBetween the two shots, the work visible is: clearing the collapsed shop and downed trees, hauling out the debris pile, separating reusable material (stone/concrete) from junk, regrading and re-establishing the driveway, and rebuilding the yard's infrastructure (solar setup, parking area) on top of the cleared ground. What was a fresh disaster scene in May 2025 reads, by September 2026, as an active, functioning yard again — with a visible stockpile of salvaged stone/block still on hand, presumably for the next phase of work. Ongoing WorkThe cleanup isn't finished. Dirt from the slide is still being worked through — pulling remaining garbage and debris out of it — and the cleaned dirt is being moved to the back yard to level out the ground back there. So the front area shown in the September photo is largely squared away, but the back yard is now the active project, being built up and leveled with what's salvaged out of the slide dirt. There's also no shop or dry covered space to work out of the weather, so as fall turns toward winter, this work has to keep pushing forward as long as outdoor conditions allow before the weather shuts it down.

Fuel pressure is controlled by a spring and check ball in the return port of the Fass. AirDog does the same. Now if you can find the right size washer you can shim the spring too increase pressure if needed. As for stability there is a spring mod I do. FASS and Airdog are known to push the checkball into the coil of the spring. So if you bend the last coil over 90° through the center this prevents the check from pushing into the coil causing pressure drop. One project ive gotta do is replace Thor's pressure spring with the new one and modify it too.