I run a fairly extensive homelab xe2x80x94 Proxmox, QNAP, Home Assistant, Frigate NVR, and a growing stack of self-hosted services. Over time, I started using Claude as an ongoing technical partner, and naturally I wanted it to remember what we had built together. Claude’s memory system lets you store editable notes that persist across conversations, and for a while that worked fine. Then I hit the wall: 30 memory slots, maximum. With infrastructure facts, blog post preferences, camera counts, and a dozen other things taking up space, there was simply no room left for a proper logbook.
So I moved the logbook out of Claude’s memory entirely and into a local MySQL table xe2x80x94 persistent, structured, and queryable xe2x80x94 with Home Assistant acting as the bridge.
The Problem with Claude Memory
Claude’s memory system is useful for storing preferences and key facts, but it has hard limits that make it unsuitable for a growing logbook:
- 30 editable slots maximum xe2x80x94 shared across everything Claude needs to remember
- No structure xe2x80x94 each entry is a plain text string, not a queryable record
- No history xe2x80x94 older entries get consolidated or dropped over time
- Not local xe2x80x94 the data lives in Anthropic’s infrastructure, not yours
For a homelab logbook tracking infrastructure changes, published posts, and configuration decisions, these limitations matter. What I needed was a proper database table with a date, category, and entry xe2x80x94 something I could query, browse in phpMyAdmin, and write to programmatically.
The Architecture
The setup uses three components working together.
MySQL on QNAP xe2x80x94 I already run MariaDB on my QNAP TS-253D (port 3307) for other projects. I created a dedicated home database with a logbook table and a restricted mcp user.
PHP scripts on CT116 xe2x80x94 A Debian 12 LXC running Apache and PHP 8.2 hosts two small scripts: logbook_write.php (GET-based insert with token auth) and logbook_read.php (returns entries as JSON). Both use utf8mb4 to handle special characters cleanly.
Home Assistant as the bridge xe2x80x94 A rest_command in HA calls the write script locally, and a command_line sensor reads the JSON output and exposes it as a sensor with entries in its attributes. Claude reaches both via the Home Assistant MCP connector.
The Database Table
CREATE TABLE logbook (
id INT AUTO_INCREMENT PRIMARY KEY,
log_date DATE NOT NULL,
category VARCHAR(50),
entry TEXT NOT NULL,
created_at TIMESTAMP DEPFAULT CURRENT_TIMESTAMP
);
Simple and effective. The category field lets me filter by topic (Frigate, Infrastructure, WordPress, Home Assistant) and the created_at timestamp tracks when the entry was actually written, separate from log_date.
The PHP Scripts
logbook_write.php accepts a GET request with token, date, category, and entry parameters and inserts a row:
$mysqli = new mysqli('192.168.1.95', 'mcp', '***', 'home', 3307);
$mysqli->set_charset('utf8mb4');
$stmt = $mysqli->prepare('INSERT INTO logbook (log_date, category, entry) VALUES (?, ?, ?)');
$stmt->bind_param('sss', $date, $category, $entry);
$stmt->execute();
echo json_encode(['success' => true, 'id' => $stmt->insert_id]);
logbook_read.php returns the last N entries as JSON, ordered by date descending:
$mysqli = new mysqli('192.168.1.95', 'mcp', '***', 'home', 3307);
$mysqli->set_charset('utf8mb4');
$result = $mysqli->query("SELECT id, log_date, category, entry, created_at FROM logbook ORDER BY log_date DESC, id DESC LIMIT $limit");
$rows = [];
while ($row = $result->fetch_assoc()) { $rows[] = $row; }
echo json_encode(['success' => true, 'count' => count($rows), 'entries' => $rows]);
Both scripts are protected by a token parameter xe2x80x94 simple but sufficient for a local network setup.
Home Assistant Configuration
Two additions to configuration.yaml wire everything together.
The rest_command for writing:
rest_command:
logbook_write:
url: "http://192.168.1.16:81/logbook/logbook_write.php?token=YOUR_TOKEN&date={{ date }}&category={{ category }}&entry={{ entry }}"
method: GET
The command_line sensor for reading:
command_line:
- sensor:
name: logbook
command: "curl -s 'http://192.168.1.16:81/logbook/logbook_read.php?token=YOUR_TOKEN&limit=50'"
value_template: "{{ value_json.count }}"
json_attributes:
- entries
scan_interval: 3600
Claude reads the sensor via the HA MCP and force-refreshes it with homeassistant.update_entity before reading. Writing happens via rest_command.logbook_write with date, category, and entry as service call parameters.
A Note on UTF-8
One issue I ran into during migration: special characters like em dashes were stored as garbled sequences. The fix is two-part xe2x80x94 set the charset on the MySQL connection and make sure the table itself uses utf8mb4:
ALTER TABLE logbook CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
After that, entries with dashes and accented characters stored and retrieved cleanly.
The Result
Claude now writes logbook entries by calling rest_command.logbook_write through the HA MCP xe2x80x94 no memory slots used, no 30-entry limit, full history preserved in MySQL. I can browse the logbook in phpMyAdmin, query it by category or date, and the data lives entirely on my own infrastructure.
The 30 memory slots that were previously eaten up by logbook entries are now free for things that actually belong there: preferences, infrastructure facts, and instructions that Claude genuinely needs at the start of every session.
