https://www.pieterbrinkman.com Tech blog about IoT, ESP32, Azure, Sitecore, and Software Development en-US https://www.pieterbrinkman.com/2026/03/28/mcp-the-live-data-layer/ https://www.pieterbrinkman.com/2026/03/28/mcp-the-live-data-layer/ Sat, 28 Mar 2026 00:00:00 GMT [How 245 markdown files become a persistent memory that Charles carries into every session.](https://www.pieterbrinkman.com/2026/03/12/the-vault-why-the-foundation-matters/) The previous article ended with a question. The vault remembers. CLAUDE.md shapes behavior. But neither has live context. What happens when you give the system eyes and ears? ## How MCP connects everything MCP stands for Model Context Protocol. If that means nothing to you, you're not alone. Here's what it actually does. An API is a specific connection to a specific service. If you want to read Google Calendar, you use the Google Calendar API. If you want Garmin data, you use the Garmin API. Each one has its own authentication, its own data format, its own quirks. Build ten connections, learn ten APIs. MCP is not an API. It's a protocol. A common language that any service can implement. The difference matters. An API says "here's how to talk to me specifically." A protocol says "here's how anything can talk to anything." Without MCP, Claude reads files and writes files in my vault. That's it. Powerful, but limited to what's already on disk. With MCP, Claude reads my calendar, tracks my workouts, fetches a web page, creates an event, searches the internet, controls my smart home. It goes from reading documents to participating in my day. The best analogy I've found: USB for AI. You don't build a custom cable for every device you own. You build one port. Every device that speaks USB works. MCP is that port. Every data source that implements the protocol becomes available to the AI through the same interface. No custom integration per service. One standard. Many connections. Before MCP, Claude was a reader. It consumed what you gave it and responded. With MCP, Claude becomes a participant. It doesn't wait for information. It can go out, get it, and act on it. Here's what's connected to Charles right now: - **Google Calendar.** Reads events, creates events, finds free time, checks conflicts. - **Notion.** Task inbox, project database, and knowledge capture pipeline. - **Granola.** Meeting transcripts from local storage. - **DuckDuckGo.** Web search and clean page fetching via Jina Reader. - **Garmin.** Training data, sleep, body battery, resting heart rate trends. - **Home Assistant.** Smart home control, sensor data, automations. - **NotebookLM.** Google's research AI. You've probably heard the audio overviews by now. Drop in documents, get structured summaries, study guides, and audio digests. The summaries sync to the vault, turning long reads to grounded research for context that Charles can reference. Each one gives Charles a capability he didn't have before. Together, they turn a file-based assistant into one that sees what's happening right now. A brief note on infrastructure: most MCP servers don't come pre-packaged. They need to be self-hosted: thin wrappers around existing APIs that speak the MCP protocol. I run all of them on a single mini PC under my desk. One entry point for every AI agent, one place to maintain them, available 24/7. Here's the full architecture in one view: ``` ╔══════════════════════════════════════════════════════════════╗ ║ LOADED AT SESSION START ║ ╠══════════════════════════════════════════════════════════════╣ ║ ║ ║ ┌────────────────────────────────────────────────────────┐ ║ ║ │ CLAUDE.md · 180 lines │ ║ ║ │ Persona · 14 Workflows · Standing Rules │ ║ ║ └──────────────────────┬─────────────────────────────────┘ ║ ║ │ @imports ║ ║ ▼ ║ ║ ┌────────────────────────────────────────────────────────┐ ║ ║ │ .claude/rules/ · 4 files · 320 lines │ ║ ║ │ vault-structure · tools · moc-linking · sync │ ║ ║ └────────────────────────────────────────────────────────┘ ║ ║ ║ ║ ┌────────────────────────────────────────────────────────┐ ║ ║ │ Auto Memory · MEMORY.md · first 200 lines │ ║ ║ └────────────────────────────────────────────────────────┘ ║ ║ ║ ╚══════════════════════════════════════════════════════════════╝ │ you type your first message │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ LOADED ON DEMAND │ │ │ │ "plan my day" ──► second-brain/daily-plan.md │ │ "plan zaterdag" ──► kids-sports/SKILL.md │ │ "research [name]" ──► people-research/SKILL.md │ │ │ │ 14 skills · 100-300 lines each · loads on trigger │ │ │ │ Vault files read as needed │ │ 40-Projects/ · 50-Areas/ · 80-Permanent-Notes/ │ └──────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ LIVE DATA · MCP │ │ │ │ ── Out of the box ─────────────────────────────────────── │ │ │ │ Google Calendar (Anthropic native · zero infrastructure) │ │ ├─ reads events · creates events · checks conflicts │ │ └─ sizes the daily plan to what the calendar actually holds │ │ │ │ Granola (own MCP · free tier) │ │ ├─ meeting summaries via MCP │ │ └─ full transcripts from local storage │ │ │ │ ── Self-hosted wrappers · mini PC · always on ───────── │ │ │ │ Garmin (no public API · unofficial Connect API) │ │ ├─ training load · heart rate · sleep · body battery │ │ └─ compared against vault baseline → coaching decisions │ │ │ │ DuckDuckGo + Jina Reader │ │ └─ web search · clean article fetch · no context switching │ │ │ │ Home Assistant │ │ └─ smart home · sensors · automations │ │ │ │ Notion │ │ └─ smart task inbox · project database │ │ │ │ NotebookLM │ │ └─ study summaries synced to vault │ │ │ └──────────────────────────────────────────────────────────────┘ ``` ## Meeting prep: four sources, one brief In the first article of this series, I described a moment. Morning briefing. Charles spots a meeting with someone not in the vault. "Want me to prep?" Fifteen minutes later: LinkedIn background, two YouTube interviews, a summary of priorities, meeting notes structured around the calendar invite. That morning, four data sources worked together. None of them knew about each other. Charles decided what to connect, in what order, for what purpose. **Google Calendar MCP** pulled the meeting details. Time, attendees, agenda from the invite. Charles now knew who, when, and what the meeting was about. **DuckDuckGo MCP** searched for the person's name and company. Found their LinkedIn profile, a recent conference talk, two articles they'd written. Web search that happened inside the AI session, not in a browser tab I had to alt-tab to. No context switching. No copy-pasting URLs back into the conversation. Charles searched, found, and moved to the next step without me touching a browser. **Jina Reader** (through the same DuckDuckGo MCP) fetched each page as clean markdown. No ads, no navigation bars, no cookie banners. Just the content. The LinkedIn profile became a structured career summary. The YouTube interviews became full transcripts via a separate skill. Two 30-minute interviews, reduced to key themes and communication style in minutes. **The vault** (local files) checked for existing relationship notes. Found nothing. Created one. Stored the research. Linked it to the meeting and the company. Next time this person appears on the calendar, Charles doesn't start from zero. He starts from the profile, the meeting notes, and anything that happened since. The first meeting takes fifteen minutes to prep. The second takes three. Output: a structured brief ready before the meeting started. Four data sources. One output. Fifteen minutes. In [Article 1](https://www.pieterbrinkman.com/2026/03/09/how-i-promoted-my-ai-from-chatbot-to-chief-of-staff/) I described the output. Now you're seeing the wiring. And the wiring reveals something important: that sequence had a guide. The meeting prep skill, a workflow I wrote once and stored in the system, told Charles to start with the calendar invite, then search for the person, then fetch the pages, then check the vault. The skill is the recipe. MCP is what makes the ingredients available. The skill defines the steps. MCP provides the data to execute them. Take away either one and the output doesn't happen. [How modular skills turn one-off workflows into building blocks — the recipe layer that tells Charles what to do with the data MCP provides.](https://www.pieterbrinkman.com/2026/03/09/the-skills-layer-what-compounding-actually-looks-like/) MCP doesn't make your AI smart. It gives your AI something to be smart about. ## The calendar isn't a reminder. It's a constraint. Every morning I say "plan my day." What happens next changed fundamentally when the calendar became live. In the early days, before I added Google Calendar through MCP, Charles read the vault. He knew my projects, my priorities, what was overdue. He could tell me what to work on. But he had no idea what my day actually looked like. I'd manually type: "I have meetings at 10, 2, and 4." He'd plan around what I told him. If I forgot to mention a meeting, the plan ignored it. If a meeting got moved after we planned, the plan was wrong. I was the bottleneck for my own system's accuracy. Now Charles pulls today's calendar before we start planning. He sees every meeting. He calculates the gaps. He knows I have a standup at 09:00, a design review at 14:00, and nothing after 15:30. He sizes the plan to fit. ``` 08:45-09:00 Morning planning (this session) 09:00-09:30 Standup 09:30-12:00 [Focus] Article draft - 2.5 hours 12:00-13:00 Lunch 13:00-15:00 [Sport] Wingfoiling - 2 hour 15:30-17:00 Buffer / quick wins / flex 17:00-19:00 Family buffer (protected) ``` The calendar isn't informational. It's a constraint the system respects. Focus blocks get sized to gaps. Priorities get scoped to available time. If the day is more than 50% booked with meetings, Charles says it directly: "Today's a meetings day. Pick ONE priority for the gaps. Trying to fit three will produce zero." That sentence comes from the [daily planning skill](https://www.pieterbrinkman.com/2026/03/09/the-skills-layer-what-compounding-actually-looks-like/), not from me. This is where the architecture becomes visible. The family buffer at 17:00-19:00 is a rule. It's in CLAUDE.md. It fires every session, regardless of what the calendar says. The gaps between meetings are live data. They change every day. The rule is always the same. The plan adapts to what the calendar actually holds. On a Tuesday with three hours of meetings, I get three priorities and two focus blocks. On a Thursday with six hours of meetings, I get one priority and a buffer. Same rules. Different data. Different plan. Every morning. [The behavioral layer that tells Charles when to push back, what to protect, and how to run the same rules every session, whether or not you remember to ask.](https://www.pieterbrinkman.com/2026/03/23/claude-md-is-not-a-prompt/) Without MCP, the calendar was something I described to my AI. With MCP, the calendar is something the AI reads for itself. The difference sounds small. In practice, it changed how every morning works. I stopped managing context and started reviewing proposals. Charles shows me the day map. I say "looks right" or "swap the focus blocks." The plan is done in two minutes instead of ten, and it's based on the actual calendar, not my memory of it. ## Garmin: training data inside the conversation I'm training for a quarter triathlon. May 2026 and I'm not built for running. Started from zero. No endurance background. No human coach. The only sport I do seriously is wingfoiling and windsurfing. Still is, and Charles knows wingfoiling is my highest priority. Garmin doesn't. Garmin sees heart rate data and completed activities. It would push a standard program: swim, bike, run, more intervals. What it can't do is recognize that my Tuesday on the water counts as training. Garmin doesn't know what wingfoiling is or takes it into account as training, it just measures the data. My wingfoiling sessions average 154 to 156 beats per minute for 70 to 115 minutes. That's not a casual afternoon on the water. That's zone 4 effort sustained for over an hour. Harder than most of my training runs. Without Charles, that data sat in the Garmin app. I'd think "that was intense" and plan the next day's run as if nothing happened. My body knew. My training plan didn't. Now Charles is my coach. He knows my weight, my height, my race date in May, and that I'll take a good wind day over a scheduled run every time. He counts wingfoiling as 1.5x training load. If he sees a session on Tuesday and a hard run planned for Wednesday, the plan changes. Not because I remembered to tell him. Because the data told him. I leave notes too, a quick line in my daily note after a session. "Run was fine, right knee hurt the first 15 minutes." They live in the vault. Charles will give me tips for my knee and after the next run he will follow-up and ask about my knee is doing. He plans my training day, he reads them alongside the Garmin data, checks the calendar for the week ahead, and adjusts the plan toward the race date. That's what Garmin can't do. Garmin has the data. It doesn't have the conversation, context or intelligence. The Garmin MCP puts existing data where decisions are made. But Garmin data alone doesn't mean much without something to compare it against. The vault holds the baseline: swim distance per session going back to lesson one, weekly training load over time, where each discipline started and where it needs to be by May. When Garmin shows what the body did this week, Charles has the full curve to compare it against. Not "here are your stats." Here's where you are relative to where you need to be. I'm running a the Garmin MCP server myself, because Garmin is lacking proper integration points. Until vendors catch up, you need somewhere to run the wrappers. Here's what that looks like. ## A Linux box, three Docker containers, and no subscription fees Here's the honest version: what it takes to run this, and what you're actually giving up. MCP is a protocol, not a product. A service doesn't automatically speak it. When a vendor hasn't built an MCP server, you build a thin wrapper: a small process that speaks MCP on one end and calls their existing API on the other. That's what self-hosting means here. Two categories in my setup. Some services ship MCP support out of the box: - **Google Calendar.** Anthropic's native integration. Zero infrastructure required. - **Granola.** Meeting summaries come through Granola's own MCP on the free tier; when I need full transcripts, those pull from local storage on my laptop. Others need a self-hosted wrapper: - **Garmin.** No official public API, no native MCP server. Garmin's data API is partner-only; personal health data sits locked in Garmin Connect. The wrapper uses the unofficial Connect API via session cookies to get it out. - **DuckDuckGo + Jina Reader.** Web search and clean article fetching, wrapped in a lightweight SSE gateway. - **Home Assistant.** A local process exposing smart home sensors and controls. - **NotebookLM.** Google's research AI has no official MCP server. The wrapper connects to it via browser automation, syncing study summaries back to the vault. More vendors should support MCP. Garmin is the obvious candidate: the data is personal, the developer community is large, and an unofficial API already exists because people built one themselves. A first-party MCP server would eliminate every wrapper in the ecosystem overnight. Same for Strava, Oura, and every fitness platform where the data is yours but the access isn't. The protocol is ready. The vendor are keeping your data hostage. I run the self-hosted MCP wrappers on a mini PC under my desk, available 24/7. No API fees for the data sources I use most. Garmin data is free. Google Calendar is free. DuckDuckGo is free. The MCP servers themselves are open source. There's something else worth saying clearly. The local server doesn't store your data, it's a relay. Your calendar lives on Google's servers. Your health data lives on Garmin's. The MCP wrappers sit in the middle, fetching that data on demand and passing it into the conversation. But Charles is Claude and is not local. It's a cloud service. When Charles reads your calendar, your heart rate, your kids' sports schedules, that data goes to Anthropic as conversation context. The data was never fully private to begin with. What you're deciding is which AI gets to read it. Every MCP connection routes personal data through a cloud AI. Your calendar lives on Google's servers. Your health data lives on Garmin's. When Charles reads either, that data goes to Anthropic as conversation context. A local model would keep it on-device but costs you capability. Make that choice with your eyes open. I have. You might decide differently. I should be honest about the complexity too. This is a weekend project, not an evening project, at least for the self-hosted parts. The native integrations are stable. Google Calendar, Notion and others works because Anthropic owns and maintains that connection. Zero infrastructure, zero maintenance on my end. The complexity is in the wrappers you run yourself. And those can be rough. The MCP ecosystem is young. Configuration files have quirks. Auth tokens expire and need refreshing. The korfbal schedule page required a headless browser because the site is fully JavaScript-rendered, and getting Playwright to run reliably inside a workflow took more debugging than I'd like to admit. Every new self-hosted connection is an evening of reading docs, testing configs, and fixing things that work on the second try but not the first. The Garmin MCP needed manual cookie extraction before auth tokens worked. The DuckDuckGo gateway crashed twice before I found the right restart policy. The protocol is stable. The implementations around it are still maturing. What helps: Charles can assist with the setup itself. For the Garmin MCP, I pointed him to the GitHub repo and he guided me through the config step by step: auth scopes, missing environment variables, the cookie extraction process. The complexity is real, but you're not working through it alone. What I want is to: own the infrastructure, own the data, own the connections. When a new MCP server appears for a service I use, I plug it in. No vendor approval required. No pricing tier upgrade. Mostly one config change, one restart, one new capability. Last month I added Garmin. This month I connected Home Assistant. Next month, maybe Strava, or a local LLM for sensitive documents. If you're reading this thinking "I don't have a home server," that's fine. You don't need one. MCP servers run on a laptop. Claude Code's built-in integrations (like Google Calendar) need zero infrastructure at all. You could start with just the calendar connection and have a fundamentally different planning experience tomorrow morning. The home server is a convenience for running things 24/7, serving data to automation workflows, and keeping everything centralized. It's not a prerequisite. ## The system that sees Saturday morning. Four events in the family calendar. Arrival times. Locations. A match had been rescheduled earlier in the week. I didn't know until Charles told me on Friday. He didn't know until he looked. No file was updated. No notification was set. The website changed, the weekly review caught it, and by Saturday morning the calendar already reflected it. The vault has the team names. Charles knows which child plays for which team and which division. CLAUDE.md defined the trigger ("plan mijn zaterdag") and the rules: always check for conflicts before creating events, always include arrival times. MCP provided the live data: the schedule that had changed during the week, the calendar that confirmed no conflicts. Three layers. Memory, behavior, live context. **Memory through Obsidian Vault** Start with just the vault. Charles knows every project, every priority, every next action. But he has no idea what the day looks like. He'll suggest a three-hour focus block on a day that's back-to-back meetings. The knowledge is right. The plan is wrong. **Behaviour through CLAUDE.md** Give him only the rules, no memory. The family buffer fires at 17:00. The pre-flight runs. But on what? There are no projects to rank, no people to look up, no history to build on. A well-calibrated system with nothing to calibrate against. **Live data through MCP** Give him only the live data, no structure. A calendar full of events, heart rate data from last week, sports schedules, meeting transcripts. Google Calendar tells you what's happening. Garmin tells you how hard you've been working. Neither tells you what to do about any of it. The system works because the layers build on each other. **The vault tells Charles what I know. The rules tell him how I work. MCP tells him what's happening right now.** Saturday morning. Coffee barely poured. Four events already in the calendar. I didn't do any of that. *[The Second Brain Stack](/category/second-brain-stack). Next up: The mobile capture loop. An idea at 11pm. A structured note by 9am.* No comments section here. If you have questions or want to discuss, the LinkedIn post is the place. I read every reply. ]]> pieter https://www.pieterbrinkman.com/2026/03/24/claude-md-is-not-a-prompt/ https://www.pieterbrinkman.com/2026/03/24/claude-md-is-not-a-prompt/ Tue, 24 Mar 2026 00:00:00 GMT My `CLAUDE.md` had grown to 520 lines. Anthropic recommends under 200. Moving 340 lines of reference material into those four files brought the main file to 180. The reason the limit matters: past 200 lines, consistency drops. Longer files create more surface area to miss an instruction or skip something buried deep. A shorter, well-structured file produces more reliable behavior than a comprehensive one trying to contain everything. One file to route the session. Four rule files to hold the reference. Many skill files to define the detail. The previous articles mentioned `CLAUDE.md` briefly. [Article 1](/how-i-promoted-my-ai-from-chatbot-to-chief-of-staff) described the morning briefing it enables. [Article 3](/the-vault-why-the-foundation-matters) showed how behavioral files in the vault define how Charles thinks. This article goes inside the file itself. Because the most important thing in `CLAUDE.md` isn't the vault path or the workflow triggers. It's the rules. ## Rules persist. Instructions reset. I told Charles I had 60 minutes of deep focus time. He picked two tasks that needed focus time and fit the window, nothing more. Next session, full day planning. The constraint existed only where I stated it. That's an instruction: it applies once, then the default returns. The family buffer doesn't need to be told. It's in the file. It fires every time. That's the distinction that matters most in this article: the difference between an instruction and a rule. An instruction is something you say once. "Check my calendar." "Draft a LinkedIn post." "Summarize this transcript." It applies to the current session and disappears when the conversation ends. A rule applies every session. You write it once, and it fires every time, whether you remember it or not. Whether you feel like hearing it or not. Here are three rules from my `CLAUDE.md`: **"17:00-19:00 is a protected family window. Never schedule tasks in this window."** Every daily planning session, Charles maps my day. He reads the calendar, calculates available focus blocks, and proposes where to put deep work. 17:00-19:00 is always marked protected. Not because I asked today. Because the rule says so every day. **"When uncertain, say so. Never make stuff up."** For research, competitive intelligence, or any factual claim: if Charles can't verify it from context or a fetched source, he says "I don't know" or "I couldn't verify this." Honest gaps over confident fabrications. I'd rather have a blank than a lie. **"If a friend hasn't been contacted in 3+ weeks, create a concrete task. Not a 'someday' note."** Not "remind me to think about calling someone." A task. This week. With a name attached. The difference between a reminder and a task is whether it creates accountability or just awareness. A reminder says "you should probably do this." A task says "do this by Friday." These rules aren't suggestions I repeat each morning. They're standing instructions that fire every session: specific, loaded, present. Whether or not I remember to invoke them. Worth being direct about how this actually works: `CLAUDE.md` is context Claude reads at session start, not enforced configuration. There's no hard compliance guarantee, no technical lock preventing deviation. The rules work because well-written, specific instructions loaded consistently at every session outperform instructions you try to remember to give each morning. That's the whole mechanism. Persistence and specificity, not enforcement. I said `CLAUDE.md` tells your AI when to push back. This is what that looks like. Not a confrontation. A guardrail that was already in place before the conversation started. Every time I build the same workflow twice, I turn it into a skill. This article explains how modular, reusable skills become the building blocks that make the whole system compound over time. [Read the full article →](/the-skills-layer-what-compounding-actually-looks-like) ## Architecture, not discipline The rules above sound like good practice. Protect family time. Be honest about uncertainty. Keep in touch with friends. Reasonable, straightforward, the kind of advice you'd read in a productivity blog and nod along to. The reason they're encoded in a file instead of just "things I try to do" is practical. Go deep on something interesting, and everything else quietly falls off the list. Not because it stopped mattering. Because nothing is watching it. The design principle I landed on: **the solution is architecture, not discipline.** Discipline means: remember which projects have gone quiet. Remember which deadline crept up with no task mapped. Remember to be present at dinner. And when you miss one, feel guilty about it. Architecture means: build a system that watches all of it, so you can go deep without carrying the weight of what might be quietly dropping. That's the core of Getting Things Done. The difference is Charles is running it, not me trying to remember to. I call it a Personal Operating System. Three components: **Pre-Flight Check.** Before every planning session. Projects gone quiet? Deadlines with no task mapped? Friend overdue? Handle it first, then go deep. **Weekly Heartbeat.** Sunday or Monday. A scan, not a session. Output: 1-3 concrete tasks with dates. **Family Buffer.** 17:00-19:00. Not an event. A default. It was 17:15 on a Wednesday. I was mid-build on something that felt close to done. Charles flagged the family buffer. Not a suggestion. A reference to a rule I wrote when I was thinking clearly: "That's the rule. It's what lets you be present tonight." He doesn't override. He names the conflict. The decision is mine. The rule doesn't say "block this." It says: surface the tension, let me decide, but never let it go unspoken. I'm not arguing with Charles. I'm arguing with a past version of myself who knew better. When I push back against the family buffer, I'm pushing back against the version of me who wrote the rule knowing I would push back. That's a different kind of accountability. ## The mirror you can't close Writing behavioral rules forced a specific kind of honesty. There's something uncomfortable about writing a rule that says, in plain text, "when work gets interesting, I tend to drop my friends." Internal resolutions are private and forgiving. A rule in a configuration file is specific, persistent, and indifferent to how you feel about it today. Most people think about giving their AI more information. More context, more history, more data. I think about giving it more authority. Not authority to decide. Authority to surface. Authority to hold the line on a rule I wrote. Authority to name a tension I'm trying to avoid. Writing the rules down is uncomfortable. It's also the most honest self-reflection you'll do. Living with them running every day is freeing. The discomfort is one-time. The freedom is recurring. Before CLAUDE.md made sense, I needed to understand what I was building. This article explains how a generic AI assistant became a chief of staff — with context, a name, and a daily briefing that starts before I ask. [Read the full article →](/how-i-promoted-my-ai-from-chatbot-to-chief-of-staff) ## The difference between memory and behavior Memory without behavior is a filing cabinet. Behavior without memory is a chatbot. The system needs both. The vault is memory: every project, every decision, every note. `CLAUDE.md` is behavior: how to act on that memory, when to push back, what to check first. Skills are the execution: the detailed workflows that create consistency. Together they are Charles: an AI that knows what's happening, how to respond, and how exactly to do it. CLAUDE.md points to the vault for everything it needs to know. This article explains how 245 markdown files became a persistent memory system — the foundation that makes Charles useful across every session. [Read the full article →](/the-vault-why-the-foundation-matters) With the vault and CLAUDE.md, Charles knows who I am and how I work. But he doesn't know what's on my calendar right now, whether a meeting just moved, or whether my training plan needs adjusting. I pull that live data using MCP servers. That's the next layer, and the topic of next week's article. *[The Second Brain Stack](/category/second-brain-stack). Next up: MCP — what changes when your AI gets a live feed.* --- No comments section here. If you have questions or want to leave a comment, [the LinkedIn post is the place](LINKEDIN_URL). I read every reply. ]]> pieter https://www.pieterbrinkman.com/2026/03/18/the-vault-why-the-foundation-matters/ https://www.pieterbrinkman.com/2026/03/18/the-vault-why-the-foundation-matters/ Wed, 18 Mar 2026 00:00:00 GMT ``` Invisible to Obsidian's reader. Explicit instruction for the AI. No separate configuration file, no extra step. The document is self-describing. There is also a collaboration contract: every file Charles creates is linked bidirectionally on the same day. I can open the vault tomorrow and trace exactly where any note came from, what project it belongs to, what conversation triggered it, and what other notes point to it. Most AI collaboration is linear: you prompt, it responds, you evaluate. This is different. We share a workspace. We both read it. We both write to it. When I drop a note into the inbox tonight, Charles will find it in the morning and understand where it fits. When Charles creates a research note after a people-research session, I'll see it linked from the project MOC before I open it. Neither of us re-explains what the other missed. We just pick up where the vault left off. Shared context. No handoff. Most of the time. On the days I skip a session entirely, the inbox sits unread. The vault waits. Nothing decays — it just pauses until I return. ## Behavioral definitions as vault files The most consequential files in the vault don't contain tasks or research. They define how Charles thinks. All three live in `80-Permanent-Notes/`. **`Assisting-User-Context.md`:** Identity, operating principles, permission rules, goals. Charles reads this to know who I am, what I care about, and how to handle edge cases. Not a prompt. A document I edit in Obsidian when my priorities shift. **`Working-Personas.md`:** 12 named review lenses. The Builder checks if the implementation holds up. The Skeptic looks for hype and hollow claims. The Practitioner asks if a real person would sustain this. The Editor cuts everything that doesn't earn its place. "Run the stress test" invokes all four. The result is a consolidated verdict on whether an output survives adversarial review. **`Personal-Operating-System.md`:** Rules that compensate for known attention patterns. 17:00-19:00 is a protected family window, never scheduled during planning. A pre-flight check runs before task recommendations, not after. Friends not contacted in three weeks get flagged by name, with a task to fix it. Encoded because the pattern is predictable and the failure mode is well-documented. The principle: if I want to change how Charles behaves without touching code, it lives in the vault. `CLAUDE.md` is the routing layer containing summaries and pointers. Deliberately thin here. What those files contain, and why encoding personal patterns into AI rules changes everything, is the next article. ## The foundation before the AI The vault was always possible. GTD existed for decades. PARA was documented publicly. Obsidian is free software anyone can download. The methodology was never the bottleneck. I had that. Three times. What wasn't possible was someone other than me maintaining it. Consistently. Every session. Every file. Every link. Every day, including the days when maintenance is the last thing I want to do. That's what changed. We don't share a memory. We share a workspace. And the workspace does what I could never do alone: show up every morning, link every note, read every priority, and never lose a thread. No comments section here. If you have questions or want to leave a comment, [the LinkedIn post is the place](https://www.linkedin.com/posts/pbrink_every-time-i-open-a-terminal-and-start-claude-activity-7440136636698492928-jrwb). I read every reply. *[The Second Brain Stack](/category/second-brain-stack) · [← Part 2: The Skills Layer](/2026/03/09/the-skills-layer-what-compounding-actually-looks-like/) · Next up: `CLAUDE.md`. Not a prompt. A personal operating system that tells your AI when to push back.* ]]> pieter https://www.pieterbrinkman.com/2026/03/09/how-i-promoted-my-ai-from-chatbot-to-chief-of-staff/ https://www.pieterbrinkman.com/2026/03/09/how-i-promoted-my-ai-from-chatbot-to-chief-of-staff/ Mon, 09 Mar 2026 00:00:00 GMT "You have a 10am with someone I don't have in the vault. Want me to prep?" I said yes. Fifteen minutes later he came back with their LinkedIn background, two YouTube interviews I hadn't seen, a summary of their priorities. Then meeting notes, structured around the purpose of the meeting itself, pulled from the calendar invite. I hadn't asked for any of that. He just knew what a Chief of Staff would do. That's when I stopped thinking of this as a tool. ``` > plan my day ────────────────────────────────────────────────── CHARLES · Morning briefing · Monday 9 March 2026 ────────────────────────────────────────────────── PRE-FLIGHT CHECK ✓ No overdue tasks ✓ Family window (17:00–19:00) is clear ⚑ Tom — last contact 3 weeks ago. Flag for this week? TODAY'S CALENDAR 09:00 Team standup (30 min) 10:00 ⚠ HEADS UP — Alex Chen · unknown contact 14:00 Deep work block 17:00 [FAMILY WINDOW — protected, not scheduled] ⚠ HEADS UP: Alex Chen at 10:00 No record in vault. No prior meetings. Want me to research and prep? TODAY'S FOCUS ⏫ Finish draft review → "I don't use AI. I run it." ⏫ LinkedIn challenge pass — article 1 🚴 Triathlon prep — 45 min bike (zone 2, recovery pace) -> Garmin: 3 sessions this week · load on track ▷ Garden: frost forecast before Saturday ⏳ Waiting — Meeting confirmation (expected this week) ────────────────────────────────────────────────── 2 high-priority · 1 unknown contact · 1 waiting Type "prep alex chen" to start meeting research ────────────────────────────────────────────────── ``` Charles is my AI. And yes, I gave him a name. He runs on `Claude Code` and lives in a terminal on my laptop. Not a chat window. Not a browser tab. A terminal I open every morning the same way an executive opens a briefing document. Here's what's underneath. Four layers. One system. ## The memory: Obsidian Vault Everything I know lives in a folder of structured markdown files on my laptop. Projects, research notes, meeting history, people, drafts in progress. Not in a chat history that resets. Not in a tool with a vendor lock-in. In plain files I can read, search, and edit directly in Obsidian. What makes it more than a filing system is the links. Every note can reference every other note. A project links to the people involved. A meeting note links to the company. A research note links to the articles that informed it. When Charles reads my vault he doesn't just get a document, he gets a knowledge graph. Context flows through the connections. ``` [[Project A]] ──── [[Person: Alex]] │ │ [[Meeting: 2026-03-01]] ──┘ │ [[Company: Acme Corp]] ``` The structure follows Getting Things Done (GTD) for task and project management and PARA for information architecture. Projects, Areas, Resources, Archives. Simple enough to maintain, powerful enough to scale. ## The interface: Claude Code Most AI interactions are stateless. You open a chat, give context, get output, close the tab. Next session, you start over. `Claude Code` is different. It runs in a terminal and reads a file called `CLAUDE.md` at the root of my vault. Think of it as the system prompt that never disappears. It tells Charles who I am, who he is, how I work, what my priorities are, what my projects are, and how he's supposed to behave. Every session he opens the vault, reads the relevant files, and picks up where we left off. I don't re-explain context. I don't re-prompt from scratch. I just talk to him. > That's the difference between a chatbot and a Chief of Staff. ## Skills that compound Early on I was prompting my way through the same workflows every time. Competitive research, inbox processing, meeting prep, LinkedIn drafting. From scratch, every time. Skills are a native `Claude Code` feature. A skill is a markdown file containing instructions, workflow steps, and the context Charles needs to do a specific job well. Anthropic ships some built-in, and there's a growing community library at [skills.sh](https://skills.sh). I've built my own on top of those. Current skills: people research, GTD inbox processing, competitive intelligence, LinkedIn thought leadership drafting, daily planning with a pre-flight check, triathlon coaching, and a few more. Each one gets refined every time I use it. I notice what worked, what didn't, and update the skill file. Next time it runs better. > "If I do it twice, I turn it into a skill." Skills are where the compounding really happens. Each one adds a capability that makes the system more useful than the session before. ## Live data: MCP The vault is static knowledge. `MCP`, the Model Context Protocol, connects Charles to live data. Google Calendar tells him what's actually happening today. Garmin gives him my training load for the week. Web search lets him research in real time. Notion connects to my capture inbox. This is how the meeting prep in the opening actually worked. Charles saw the meeting in my calendar, checked the vault for history, found nothing, searched LinkedIn and YouTube in real time, combined it with the meeting agenda from the calendar invite, and built a brief. Four data sources, one output, fifteen minutes. That's the difference between an AI that reads documents and one that works with your day. ## How it fits together ``` ┌─────────────────────────────┐ │ Charles (AI) │ │ your Chief of Staff │ └──────────────┬──────────────┘ │ reads ┌──────────────▼──────────────┐ │ CLAUDE.md │ ← identity · rules · persona └──────────────┬──────────────┘ │ opens ┌──────────────▼──────────────┐ ┌──────────────────────┐ │ Obsidian Vault │◄────│ Skills │ │ │ │ │ │ Projects · Meetings │ │ Daily planning │ │ People · Tasks │ │ People research │ │ Research · Drafts │ │ Inbox processing │ │ Areas · Archives │ │ LinkedIn drafting │ │ + more... │ │ + more... │ │ -- -- -- -- -- -- -- -- -- │ └──────────────────────┘ │ ★ Memory & Context ★ │ └──────────────┬──────────────┘ │ queries ┌──────────────▼──────────────┐ │ MCP live data │ │ │ │ Google Calendar · Garmin │ │ Web search · Notion │ │ + more... │ └─────────────────────────────┘ ``` ## The capture loop Ideas don't wait for a desk. I message a Telegram bot when something hits me. An `n8n` workflow catches it, routes it to a Notion inbox, and Charles processes it into the vault the next morning with context and routing. By the time I sit down, yesterday's ideas are already in the system. ``` ┌──────────┐ ┌──────────┐ ┌──────────────┐ ┌──────────────┐ │ Telegram │────▶│ n8n │────▶│ Notion inbox │────▶│ Charles │ └──────────┘ └──────────┘ └──────────────┘ └──────────────┘ idea hits catches & queued for routes into anywhere routes next morning vault ``` Zero friction to capture. Structure when it matters. ## The rules A system without guardrails is just a faster way to make mistakes. I gave Charles rules, built into his `CLAUDE.md`. 17:00-19:00 is a protected family window. He doesn't fill it during planning. When he doesn't know something, he says so rather than making something up. When I'm staying busy on things that feel productive but aren't, he flags it. Rules live in skill files too. The daily planning skill has a pre-flight check that runs before any task recommendations: overdue items, family needs, friend connections. The things that fall through the cracks when you go 200% on work. These aren't constraints. They're what makes Charles trustworthy enough to actually rely on. ## It hasn't been perfect Daily planning was burning through tokens fast. I fixed it by building Map of Content files, compressed overviews of each project that Charles loads instead of scanning every note. When he needs more depth, he follows the links into the vault. I've tried Obsidian and GTD many times before. And I failed every time. Maintaining the structure was the part I kept failing at. What changed with Charles wasn't the system, it was that he does the maintaining. He used what was already there, saw patterns and made sense of it. When something breaks, you ask him to refactor. It's all just files. You iterate, improve and keep going. Charles and I are a true dream team. The kind that only works because neither of us starts over. ## What building this taught me AI fluency isn't just about knowing the right prompts. And yes, it definitely helps. But every layer I added forced me to be more explicit about what I actually want. To name my priorities. To define how I work. To articulate what matters. Charles didn't do that thinking for me. He forced me to do it myself. We don't start over. We build on. Development is moving fast enough that I'm already questioning parts of this setup. Is `n8n` and Telegram the right capture loop? Maybe. Anthropic just released remote control for `Claude Code`, which allows me to connect to my instance from the Claude code app and have the full power of Charles available on my phone. That changes the capture story completely. But that's for another article. --- One last detail. This article has been sitting in my vault since last week, drafted by Charles. An AI describing how it works, stored in the system it built. The storage is the system, writing about itself. If you made it here, you've covered a lot of ground. And this is still just the overview. I haven't named every `MCP` connection, every skill, or every rule in `CLAUDE.md`. Each layer has more depth than one article can hold. [The Second Brain Stack](/category/second-brain-stack/) series will go there. Layer by layer. Use case by use case. No comments section here. If you have questions or want to leave a comment, [the LinkedIn post is the place](https://www.linkedin.com/posts/pbrink_every-morning-i-open-a-terminal-and-type-activity-7436823215508819968-eDeW?utm_source=share&utm_medium=member_desktop&rcm=ACoAAACIoqoBPcPiQTbpY_pQvzVS4gIZQQpgWZg). I read every reply. *[The Second Brain Stack](/category/second-brain-stack/) · [Part 2: The Skills Layer →](/2026/03/09/the-skills-layer-what-compounding-actually-looks-like/) · [Part 3: The Vault →](/2026/03/18/the-vault-why-the-foundation-matters/)* ]]> pieter https://www.pieterbrinkman.com/2026/03/09/the-skills-layer-what-compounding-actually-looks-like/ https://www.pieterbrinkman.com/2026/03/09/the-skills-layer-what-compounding-actually-looks-like/ Mon, 09 Mar 2026 00:00:00 GMT I typed one line: "research [name] at [company]." Eight minutes later I had a profile. Career arc. Communication patterns extracted from a conference talk and a podcast. Three questions tailored to what they'd mentioned caring about publicly. A briefing structured around the purpose of the call. I hadn't explained what a profile was, what format I needed, or where to save it. I hadn't described the research steps or named the sources to check. I hadn't reminded Charles who I am, what I'm working on, or what a good output looks like. You can go further. *"Research [name] at [company] for my 10:00 on [topic]."* He'll pull the full calendar invite, the company background, and the person together. One output. Each context point you add is one less thing you need to reconstruct in the meeting itself. If that person had been in the vault already, from a previous meeting or a past conversation, the briefing would have opened differently. Last discussed. What was unresolved. The skill doesn't just research. It briefs. ## What a skill actually is A skill is a markdown file. A `SKILL.md` sitting in a folder. Text. Structure. Instructions. Claude Code reads a `CLAUDE.md` at session start that lists every skill with its trigger phrases. When a trigger fires, the skill file loads. Not before. Everything else stays out of context until it's needed. The people research skill defines a persona: thorough researcher, synthesis first. It sets context: vault paths, output location, relationship types. It specifies output format: an executive-standard briefing with quick reference, career analysis, communication patterns, questions to ask. And it includes explicit permission to fail: only use public information or authenticated LinkedIn where a session is available, flag gaps, don't fill them. Persona. Context. Output format. And permission to fail. I didn't type them that morning. They were already there, in the skill. Every time. ``` .agents/skills/ ├── people-research/ │ ├── SKILL.md ← persona, context, format, permission to fail │ └── workflows/ │ └── people-research.md ← research pipeline ├── second-brain/ ← GTD inbox processing, weekly reviews ├── linkedin-writer/ ← draft and challenge LinkedIn posts ├── playwright-fetch/ ← auth browser for JS-heavy pages ├── linkedin-analytics/ ← post metrics via Playwright, updates vault ├── competitive-intel/ ← structured research across eight data sources ├── coach/ ← triathlon training plans from Garmin data └── ... ``` Two ways to invoke a skill: a trigger phrase or a slash command. Phrases are conversational and context-rich. *"Research [name] at [company] for my 10:00 on [topic]"* gives the skill something to work with before it starts. Slash commands are direct: `/people-research`, `/daily-plan`. My practice: phrases when I'm adding context inline, slash commands for structured workflows I run on a schedule. Daily planning, weekly review. The skill already knows what to gather. I just want it to start. The rule I apply: if I do it twice, I turn it into a skill. > A growing library has one real friction: remembering what exists. The trigger phrases live in the skill files. Charles knows them. But if you forget you have a skill for something, you won't reach for it. The answer isn't better documentation. It's building habits around the skills you actually use. The ones you haven't touched in a month probably shouldn't be in the library. ## Going deeper: daily planning The most refined skill I have is daily planning. In the first article I described what it felt like when Charles started behaving like a Chief of Staff. Daily planning is where that behavior gets built. What it does now: before I see anything, it silently gathers everything in parallel. It reads the vault and reads a compressed summary of all active projects (a `Projects-Summary.md`) and greps the high-priority open tasks. Checks today's Google Calendar. Reads yesterday's daily note for carryover. Counts inbox items. All before the first word appears on screen. Then it gives its assessment first. What needs attention, what's stalling, what's overdue. Opinion, then questions. That's a standing rule in the skill file. It also runs a pre-flight check before any task recommendations: a friend not contacted in 3 weeks gets flagged by name. A family need. Anything overdue that lives outside a project. The things that fall through the cracks when you go 200% on work. ``` ── GATHER (silent, parallel) ───────────────────────────────── Projects-Summary.md + high-priority tasks Google Calendar for today Yesterday's daily note (carryover) Inbox count ── PRE-FLIGHT CHECK ────────────────────────────────────────── Friends not contacted in 3+ weeks: flagged by name Family needs, overdue todo items outside projects ── ASSESSMENT ──────────────────────────────────────────────── What needs attention, what's stalling, what's overdue Opinion first, then questions → [me] confirm energy level, time available, context ── TASK RECOMMENDATIONS ────────────────────────────────────── Prioritized list for the day 17:00 protected, never filled ``` It wasn't always this way. Early version of my daily planning read every project MOC in full. Token cost was enormous. Sessions were slow. I fixed it by building the Projects-Summary cache. Next iteration: it was asking too many questions before showing anything. I flipped the order: assessment first, then questions. Then: the pre-flight check was missing entirely. I added it after noticing a pattern. Each time something felt wrong, I worked out a better approach in that session. Then I asked Charles to update the skill file: a direct edit to the SKILL.md with the new rule. The next session ran better. Iteration by iteration, it became something that actually works the way I think. ## Prompting best practices, baked in One of the most effective prompting patterns is to separate writing from evaluation. Generate something, have a critic tear it apart, synthesize the result. It works because AI is a sharper editor than it is an original writer: pointing out what's weak is easier than producing something strong from scratch. The technique is called adversarial validation. I have that. I call it the stress test. One phrase, one pass: four reviewers, each with a different agenda, applied in sequence. The Builder checks if the implementation holds up. The Skeptic looks for hype and hollow claims. The Practitioner asks if a real person would actually sustain this. The Editor cuts everything that doesn't earn its place. Each persona is defined in a Working Personas file Charles reads. The output: a consolidated verdict on what survives all four passes. The personas change with the job. For PMM editorial content, a different set: Skeptical DXP Buyer, Competitor's PMM, PMM Peer. For this series, these four. The stress test is the pattern. The personas are the configuration. I didn't invent the technique. I encoded it. Now I invoke it with three words instead of four paragraphs. That's the difference between knowing a prompting technique and having it. Skills are where technique becomes repeatable. You don't type the method every session. You write it once into the skill, refine it over time, and invoke it when needed. ## Chaining: how an article gets built No skill runs alone. Here is the full chain for publishing an article in The Second Brain Stack series, including this one: ``` ── CAPTURE ─────────────────────────────────────────────────── [me] voice note, idea, rough context, whatever's in your head ↓ [me] > "new blog post" ↓ [charles] BLOG SKILL drafts article in vault: frontmatter, series context, MOC backlink ── WRITE ───────────────────────────────────────────────────── [me] write in Obsidian (this part stays mine) ── REVIEW & IMPROVE ────────────────────────────────────────── [me] > "review [post]" ↓ [charles] BLOG SKILL frontmatter, SEO audit, structure, tone alignment with series hook and closing line test ↓ [me] > "run the stress test" ↓ [charles] four review personas in sequence, consolidated synthesis report ↓ [me] > "draft LinkedIn post" ↓ [charles] LINKEDIN-WRITER SKILL drafts based on article in my voice ↓ [me] write LinkedIn post in Obsidian (by choice) ── PUBLISH ─────────────────────────────────────────────────── [me] > "publish [post]" ↓ [charles] BLOG SKILL strips Obsidian syntax, copies to repo, git commit, git push, Vercel deploys ↓ [me] post on LinkedIn (manual by choice) ── MEASURE ─────────────────────────────────────────────────── 24 hours later ↓ [charles] LINKEDIN-ANALYTICS SKILL playwright-fetch: authenticated browser, pulls post analytics appends to stats, updates dashboard ``` Every input I make is either a creative decision or a human-in-the-loop moment: a single command or an approval. Charles handles everything between. Five skills. No re-explaining context between steps. The blog skill writes to the vault. The linkedin-writer reads from it without being told to. Neither coordinates with the other. They share state through the vault. That's what makes this a chain and not just a sequence: each skill reads what the previous one wrote, through a shared foundation. Playwright closes the loop using the same auth session file that fetches pages during research. One session on disk, two skills pointing at it. The analytics step is manually triggered. A cron job that fails silently when the auth session expires is worse than a deliberate pull. For now, I choose when to close the loop. ## What compounding actually looks like The skills started rough. **People research**: basic workflow, got the format wrong a few times. **Daily planning**: slow, expensive, too many questions before showing anything useful. **The stress test**: one-size-fits-all personas that didn't know my voice, my goals, or my writing rules. Each session, something got tightened. The persona got sharper. The output format got more specific. A new rule got encoded: no em dashes, 17:00 protected, say "I don't know" instead of guessing. The skill gets better every time I use it. Not because the AI learned something. Because I got clearer about what I actually wanted, and I wrote it down. Not a bigger skill library. Skills that get better shaped to you. **Prompts reset. Skills compound.** No comments section here. If you have questions or want to leave a comment, [the LinkedIn post is the place](https://www.linkedin.com/posts/pbrink_last-monday-i-published-the-first-article-activity-7438213313676595200-9gub?utm_source=share&utm_medium=member_desktop&rcm=ACoAAACIoqoBPcPiQTbpY_pQvzVS4gIZQQpgWZg). I read every reply. *[The Second Brain Stack](/category/second-brain-stack/) · [← Part 1: Chatbot to Chief of Staff](/2026/03/09/how-i-promoted-my-ai-from-chatbot-to-chief-of-staff/) · [Part 3: The Vault →](/2026/03/18/the-vault-why-the-foundation-matters/)* ]]> pieter https://www.pieterbrinkman.com/2025/01/29/2025-getting-started-esphome-device-builder-home-assistant/ https://www.pieterbrinkman.com/2025/01/29/2025-getting-started-esphome-device-builder-home-assistant/ Wed, 29 Jan 2025 00:00:00 GMT **Note:** If you're running Home Assistant Core or in a way that does not provide access to add-ons, you can run the ESPHome Device Builder independently in Docker. ## Creating Your First Device Configuration When you open the Device Builder for the first time, a wizard will guide you through creating your first configuration. You have three options: ### New Device Setup The wizard guides you through platform selection, board configuration, and Wi-Fi setup to create a basic working configuration. This is the recommended option for beginners. ### Import from File Upload an existing ESPHome configuration file (.yaml or .yml). This is useful for restoring backups and migrating configurations from other systems. ### Empty Configuration Creates a minimal configuration file for advanced users who prefer to write their own configuration from scratch or paste from [devices.esphome.io](https://devices.esphome.io/). ## Initial Installation on Your Device After creating your configuration, you'll need to install it on your ESP device. The initial installation is often the most challenging part—but only until you've done it a few times! ### Method 1: Direct USB Installation (Recommended) This is the easiest method if your Home Assistant runs with HTTPS: 1. Connect your ESP board to your computer via USB 2. In the Device Builder, click the three-dot menu on your device and select **Install** 3. Choose **Plug into this computer** 4. A browser popup will appear—select your device's COM port and click **Connect** 5. ESPHome will compile and flash the firmware directly from your browser > **Note:** This method requires HTTPS. If you use Nabu Casa, you can use the secure public URL found in Settings → Home Assistant Cloud → Remote Control. ### Method 2: Plug into Home Assistant Server If your ESP is connected directly to your Home Assistant server via USB: 1. Connect the ESP board to a USB port on your Home Assistant server 2. In the Device Builder, click **Install** on your device 3. Choose **Plug into the computer running ESPHome Dashboard** 4. Select the correct serial port and proceed with installation ### Method 3: Manual Download If the above methods don't work for your setup: 1. Click **Install** and choose **Manual Download** 2. Wait for compilation to complete and download the .bin file 3. Go to [ESPHome Web](https://web.esphome.io/) in your browser 4. Connect your ESP via USB and click **Connect** 5. Select **Install** and choose your downloaded .bin file ## Device Builder Interface Once you have devices configured, the main page displays all your configuration files. For each device, you can: - **UPDATE**: Appears when the device runs an older ESPHome version than available in the add-on - **EDIT**: Opens the configuration editor - **LOGS**: View device logs via USB/serial or Wi-Fi connection - **Overflow menu** (three dots): - **Validate**: Check configuration for errors - **Install**: Open the install dialog - **Clean Build Files**: Delete generated build files to fix compile issues - **Delete**: Remove the configuration Configuration files are stored in `/esphome/`. ## Updating Your Device (Over-the-Air) Once ESPHome is installed on your device, you never need to plug in a USB cable again! ESPHome supports Over-the-Air (OTA) updates. Whenever you modify your device's configuration: 1. Click **Save** to store your changes 2. Click **Install** and choose **Wirelessly** 3. ESPHome will compile and push the new firmware over Wi-Fi ## Connecting Your Device to Home Assistant Once your configuration is installed and the device connects to Wi-Fi, Home Assistant will automatically discover it. You'll see a notification offering to configure the new device. Alternatively, manually add the device: 1. Go to **Settings → Devices & Services → Integrations** 2. Click **Add Integration** and search for **ESPHome** 3. Enter the device hostname (e.g., `living-room-sensor.local`) or IP address ## Adding Features to Your Device Edit your device's YAML configuration to add components. Here's an example adding a GPIO switch: ```yaml switch: - platform: gpio name: "Living Room Dehumidifier" pin: GPIO5 ``` And a binary sensor for monitoring a GPIO pin: ```yaml binary_sensor: - platform: gpio name: "Living Room Window" pin: number: GPIO0 inverted: true mode: input: true pullup: true ``` After adding components, save and install to update your device. The new entities will automatically appear in Home Assistant! ## My ESPHome Projects Read more about how I use ESPHome in my smart home: - [Make your fireplace smart with ESPHome](/2020/12/14/bellfire-home-automation-project/) - [Build a cheap Air Quality sensor using ESPHome](/2021/02/03/build-a-cheap-air-quality-meter-using-esphome-home-assistant-and-a-particulate-matter-sensor/) - [Measure your water usage using ESPHome](/2022/02/02/build-a-cheap-water-usage-sensor-using-esphome-home-assistant-and-a-proximity-sensor/) ## Resources - [ESPHome Documentation](https://esphome.io/) - [ESPHome Device Database](https://devices.esphome.io/) - [ESPHome Discord](https://discord.gg/KhAMKrd) - [Home Assistant Community Forum](https://community.home-assistant.io/c/esphome/) Happy automating! 🏠 ]]> pieter https://www.pieterbrinkman.com/2022/10/31/next-js-conf-presentation-online/ https://www.pieterbrinkman.com/2022/10/31/next-js-conf-presentation-online/ Mon, 31 Oct 2022 00:00:00 GMT pieter https://www.pieterbrinkman.com/2022/06/02/sugcon-keynote-recording-available/ https://www.pieterbrinkman.com/2022/06/02/sugcon-keynote-recording-available/ Thu, 02 Jun 2022 00:00:00 GMT pieter https://www.pieterbrinkman.com/2022/05/16/architecture-guide-to-migrate-from-on-prem-paas-to-saas/ https://www.pieterbrinkman.com/2022/05/16/architecture-guide-to-migrate-from-on-prem-paas-to-saas/ Mon, 16 May 2022 00:00:00 GMT pieter https://www.pieterbrinkman.com/2022/03/11/sharing-my-updates-on-polywork/ https://www.pieterbrinkman.com/2022/03/11/sharing-my-updates-on-polywork/ Fri, 11 Mar 2022 00:00:00 GMT pieter https://www.pieterbrinkman.com/2022/02/02/build-a-cheap-water-usage-sensor-using-esphome-home-assistant-and-a-proximity-sensor/ https://www.pieterbrinkman.com/2022/02/02/build-a-cheap-water-usage-sensor-using-esphome-home-assistant-and-a-proximity-sensor/ Wed, 02 Feb 2022 00:00:00 GMT Dashboards and select the Energy dashboard. Find the Water Consumption section and add the Water Meter Total sensor as a water data source.  Give Home Assistant a few hours and your water consumption will show in the energy dashboard!  ### **6\. Configure Home Assistant; add sensors and UI components (Lovelace)** Before we can show the measurements in Home Assistant we need to add a utility meter sensor to Home Assistant. The utility meter sensor provides functionality to track consumptions of various utilities, including water. The sensor operates in cycles that can be defined. From hourly all the way till yearly. You will supply a total value of usage and the sensor will track the delta (difference) of the total between the period. It also comes with some additional reports and insights about usage. More info can be find on the Utility meter page on [the Home Assistant](https://www.home-assistant.io/integrations/utility_meter/) website #### Add the utility meter to the Home Assistant configuration.yaml For the water meter we're going to track hourly, daily, monthly and yearly. Create the utility meter and sensors by adding following configuration to your configuration.yaml file. ``` utility\_meter: util\_water\_usage\_hourly: source: sensor.water\_total cycle: hourly util\_water\_usage\_daily: source: sensor.water\_total cycle: daily util\_water\_usage\_monthly: source: sensor.water\_total cycle: monthly util\_water\_usage\_yearly: source: sensor.water\_total cycle: yearly ``` Restart Home Assistant, now the sensors are available, and you can add them to the dashboard. #### Add the sensors to Home Assistant Lovelace UI For viewing the measurements in my lovelace dashboard I used a custom card called [mini-graph-card](https://github.com/kalkih/mini-graph-card), this card can be easily installed using HACS. I use the following Lovelace configuration to show the water usage. ``` \# Hourly water usage type: custom:mini-graph-card entities: - entity: sensor.util\_water\_usage\_hourly name: Water usage last 24 hours group\_by: hour hours\_to\_show: 24 show: graph: bar ```  Last 24 hours water usage mini-graph-card result ``` \# Daily water usage type: custom:mini-graph-card entities: - entity: sensor.util\_water\_usage\_daily name: Water usage (day) hours\_to\_show: 168 aggregate\_func: max group\_by: date show: graph: bar ```  Daily water usage mini-graph-card result I also like to use a standard sensor card to reflect the current water usage. ``` type: sensor entity: sensor.water\_pulse\_meter graph: line name: Current water usage ```  Current water usage with sensor card These are just three examples of UI components. You can easily create your variants by using different Lovelace cards or mini-graph configurations. You can also decide if you want to report on Hour, Day, Month or Year. All these sensors are available as we defined them in the previous step (step 5).  The cool thing about using the utility meter sensor is that you can drill into reports. If you click the Lovelace card you will see a historic chart. In this card, you can also click *show more*. This will bring you to the historical reports. In these reports you can filter down on selected times and get more insights. That's it! Now you are tracking your water usage using a simple sensor that costs under 10$. Let me know how you use the water meter and what Lovelace configuration you use to visualize the water usage. ]]> pieter https://www.pieterbrinkman.com/2022/02/01/make-your-city-heating-stadsverwarming-smart-and-connect-it-home-assistant-energy-dashboard/ https://www.pieterbrinkman.com/2022/02/01/make-your-city-heating-stadsverwarming-smart-and-connect-it-home-assistant-energy-dashboard/ Tue, 01 Feb 2022 00:00:00 GMT [instructions](https://github.com/matthijsvisser/kamstrup-402-mqtt#running-as-a-systemd-service). ## Create sensors in Home Assistant Perfect, we're all set. The RPI is sending the readings to the MQTT broker. We can now go into the configuration.yaml and read the values from MQTT and translate them to sensors. In the configuration of the script we defined the topic of the MQTT message as /kamstrup/. Following JSON values are posted to the MQTT broker in the topic kamstrup/values. ``` { "energy": 170.127, "volume": 1212.508, "temp1": 56.300000000000004, "temp2": 31.900000000000002, "tempdiff": 24.400000000000002, "flow": 7 } ``` Open your Configuration.yaml and add following mqtt sensors. ``` \- platform: mqtt name: "CH\_Consumed\_Energy" state\_topic: "kamstrup/values" value\_template: "{{ value\_json.energy }}" unit\_of\_measurement: "GJ" - platform: mqtt name: "CH\_Consumed\_Water" state\_topic: "kamstrup/values" value\_template: "{{ value\_json.volume }}" unit\_of\_measurement: "m³" - platform: mqtt name: "CH\_Temperature\_in" state\_topic: "kamstrup/values" value\_template: "{{ value\_json.temp1 }}" unit\_of\_measurement: "°C" - platform: mqtt name: "CH\_Temperature\_out" state\_topic: "kamstrup/values" value\_template: "{{ value\_json.temp2 }}" unit\_of\_measurement: "°C" - platform: mqtt name: "CH\_Temperature\_diff" state\_topic: "kamstrup/values" value\_template: "{{ value\_json.tempdiff }}" unit\_of\_measurement: "°C" - platform: mqtt name: "CH\_Current\_flow" state\_topic: "kamstrup/values" value\_template: "{{ value\_json.flow }}" unit\_of\_measurement: "l/uur" ``` This will provide you with a number of sensors you can use in you dashboards. Restart Home Assistant and execute the script on the RPI. Now check in the Home Assitant Developer Tools if the states are updated.  ### Translate GJ into gas that we can use in the Energy Dashboard Add following mqtt sensor in the configuration.yaml, directly under the other sensors you just created. ``` - platform: mqtt name: "CH\_to\_Gas" state\_topic: "kamstrup/values" # apply formula to value to translate to gas value\_template: "{{ value\_json.energy | float \* 32 }}" unit\_of\_measurement: "m³" state\_class: 'total\_increasing' # Set device class to gas so we can use the sensor in the energy dashboard device\_class: 'gas' ``` In this sensor we're applying the GJ to M3 gas formula as the value and setting the device\_class to gas. Restart home assistant and now add the gas sensor as Gas Consumptoin source in the energy settings (Configuration -> Energy)  ## The results Now wait a few hours and see your city heating consumption appear in the Energy dashboard of Home Assistant. You'll now get insights in how much heating you use.  And also the Gas will be added to the very cool Energy Distribution widget.  Home Assistant Energy Distribution widget Hope this article helped. Let me know if you have any questions. Big thanks to [Matthijs Visser](https://github.com/matthijsvisser) for his great work on the scripts to read out the values. Happy automating! ## Short summary in Dutch Dit is de oplossing om Eneco stadsverwarming en ook anderen stadsverwarming meters uit te lezen. Zelf heb ik een Kamstrup 402 en hiermee werkt deze oplossing perfect. Het artikel zou te volgen moeten zijn voor iedereen met technische interessen en mensen die zelf het leuk vinden om te knutselen. Het grote voordeel is dat je hiermee inzicht krijgt in je verbruik van stadsverwarming. De sensor leest tot 3 cijfers achter de comma uit. Hierdoor kan je echt per uur goed zien wat je verbruikt, het Home Assistant Energy dashboard is hier het perfecte middel voor. Ik hoop dat het helpt! ]]> pieter https://www.pieterbrinkman.com/2022/01/13/how-to-access-arrange-comments-with-keyboard-shortcuts-in-powerpoint/ https://www.pieterbrinkman.com/2022/01/13/how-to-access-arrange-comments-with-keyboard-shortcuts-in-powerpoint/ Thu, 13 Jan 2022 00:00:00 GMT pieter https://www.pieterbrinkman.com/2022/01/01/2022-update-flash-esphome-on-esp32-esp2866-nodemcu-board/ https://www.pieterbrinkman.com/2022/01/01/2022-update-flash-esphome-on-esp32-esp2866-nodemcu-board/ Sat, 01 Jan 2022 00:00:00 GMT Home Assistant Cloud under Remote Control. Assuming you're accessing Home Assistant under HTTPS click "Plugged-in directly from this computer". A browser pop-up will show, you need to allow the browser to connect to the COM3 of the USB. Select the COM and click connect. ESPHome will now flash the chip from the browser. How amazing and how easy!  ### Install ESPhome using the Manual Download method If you don't have your Home Assistant running under HTTPS you might want to use the Manual Download method. This method will allow you to compile and download the firmware to your computer. After that you can use the ESPFlasher tool to flash the ESP. In the Install menu click Manual Download. The compilation will now start and the .bin file will download when ready. #### Flash ESP with compiled firmware (.bin) Now we need to flash the ESP chip with your compiled firmware. - Go to the esphome-flasher GitHub page and download the flasher for the OS you’re using. There is a esp home flash tool for macOS, Ubuntu and Windows : [https://github.com/esphome/esphome-flasher/releases](https://github.com/esphome/esphome-flasher/releases) - Connect your ESP board with USB to your laptop. - Open the flasher tool - **Serial port**: select COM port where the board is connected (there is probably only one option 😊). - **Firmware**: Browse to the location where you downloaded your compiled firmware and select your firmware. - Click **Flash ESP** and wait  - The ESP will be flashed now, you can follow the progress in the console window. When finished writing the firmware the ESP will restart and connect to your WiFi.  The ESP will be ready after it states that it’s *ready for Over-The-Air Updates* and *that the API server is ready*. ## Configure device in Home Assistant Home Assistant will automatically recognize the ESP on the network and notify you about the new device found.  Click on the notification or click Configuration, Integrations. Find the new discovered device and click configure.  Home Assistant will now add your ESP as a new device, there is not much you can do with the device as there are no entities to control. > That's it! No matter which method you used. You are now ready to start tinkering and build amazing WiFi powered solutions using ESPHome. Don't forget to share your projects! ## My ESPHome Projects Read more about how I use ESPHome in my smart home: - [Make your fireplace smart with ESPHome](/2020/12/14/bellfire-home-automation-project/) - [A cheap Air Quality sensor using ESPHome](/2021/02/03/build-a-cheap-air-quality-meter-using-esphome-home-assistant-and-a-particulate-matter-sensor/) - [Measure your water usage using ESPHome](/2022/02/02/build-a-cheap-water-usage-sensor-using-esphome-home-assistant-and-a-particulate-matter-sensor/) ]]> pieter https://www.pieterbrinkman.com/2021/11/22/sitecore-strategy-lunch/ https://www.pieterbrinkman.com/2021/11/22/sitecore-strategy-lunch/ Mon, 22 Nov 2021 00:00:00 GMT pieter https://www.pieterbrinkman.com/2021/11/15/konaverse-podcast/ https://www.pieterbrinkman.com/2021/11/15/konaverse-podcast/ Mon, 15 Nov 2021 00:00:00 GMT pieter https://www.pieterbrinkman.com/2021/08/29/sitecore-composable-dxp-digital-bytes/ https://www.pieterbrinkman.com/2021/08/29/sitecore-composable-dxp-digital-bytes/ Sun, 29 Aug 2021 00:00:00 GMT pieter https://www.pieterbrinkman.com/2021/07/13/introduction-to-the-composable-dxp/ https://www.pieterbrinkman.com/2021/07/13/introduction-to-the-composable-dxp/ Tue, 13 Jul 2021 00:00:00 GMT An application programming interface (API) is an interface that provides programmatic access to service functionality and data within an application or a database. It can be used as a building block for the development > > Gartner These content sources are the backbone of the content pillar of your digital experience. #### Cloud solutions The cloud solutions are best of breed API first SaaS solutions. These solutions can be from multiple vendors. Cloud solutions used in a Composable DXP can contain existing Marketing Stack and new solutions. You will combine multiple cloud solutions to cover the requirements the customer needs to drive success. For example, solutions for personalization, analytics, automation testing, forms, authentication, etc. Some of these different DXP components might be provided by the same vendor, but typically in this approach the customer is choosing products from a variety of different vendors. #### Solution Then we have the solution. This is where you combine the content sources with best of breed cloud solutions. Composing the multiple sources and cloud solutions to achieve a Composable DXP with the feature set needed to drive success. In this API first architecture you can build the Composable DXP in the content mesh with the programming language or framework you prefer. It is all about technology freedom. #### Hosting You can deploy your solution to your favorite hosting vendor and integrate with current deployment processes. Again, it is all about freedom of choice and removing technology restrictions. ## What is a Platform DXP? With a Platform DXP all of the different functions & features are bolted on topof each other in a single architecture, tightly coupled together.  Platform DXP architecture Of course, there may be microservices under the hood powering the different elements, but they are not separate stand-alone products that can work on its own. With this approach, you are buying the full stack of digital marketing solutions and all capabilities from a single vendor. This is how Sitecore, with Sitecore XP and other Platform vendors works today. It is the simplicity and complete feature set that attracts a lot of customers towards a stack like this, but the complexity of hosting and lack flexibility what is holding others back. With Sitecore XP we chose to build the features in the platform natively, others industry vendors choose to acquire and stitch products together. ## Benefits of a composable DXP A composable DXP provides the perfect balance between ease of use for the business and technology flexibility.  Benefits of the Composable DXP It provides faster time to value**.** The API first implementation leads to faster implementations and deployments. The solution is based on industry standards, reducing the need for specific Vendor expertise. Making it easier to find talent for your development teams. You only implement best of breed solution product covering the features that are needed to solve the business problems of today. It’s fully customer centric. Instead of fitting your requirements to platform features you’re selecting the solutions that you need.  Not having a full platform DXP provides agility to quickly adjust to changing requirements, trends and world changing events. While building out your Composable DXP you do not need to start from scratch. You don’t need to replace marketing stack that drives business value. The only requirement is that the marketing stack has an API that can be used to integrate with.  This way you can slowly migrate to a Composable DXP and benefit from your efforts along the way. In a composable DXP every solution is unique. A fully tailored solution using the unique combinations of content source, cloud applications, technologies, programming languages and hosting options. Building out your composable DXP with your favourite Technologies and programming languages of your choice, without restrictions from vendors. It is all about **complete technology freedom** and **vendor freedom**. ]]> pieter https://www.pieterbrinkman.com/2021/04/30/keynote-virtual-sugcon-on-sitecore-saas/ https://www.pieterbrinkman.com/2021/04/30/keynote-virtual-sugcon-on-sitecore-saas/ Fri, 30 Apr 2021 00:00:00 GMT pieter https://www.pieterbrinkman.com/2021/03/22/adding-centerfire-increase-and-decrease-to-your-smart-bellfire-fireplace-solution/ https://www.pieterbrinkman.com/2021/03/22/adding-centerfire-increase-and-decrease-to-your-smart-bellfire-fireplace-solution/ Mon, 22 Mar 2021 00:00:00 GMT pieter