TL;DR: My meter dropped offline for ~13 days. Home Assistant's long-term stats came back wrong — a -4,500 kWh bar, a phantom 862 kWh solar spike. The dashboard is a view. The truth is in the statistics table. You fix it with one SELECT to find the damage and one UPDATE to undo it.

For a while now, my energy dashboard in Home Assistant reports that my house had produced negative 4,500 kWh in April. It was finally time to fix that.

<img width="1080" height="1527" alt="Image" src="https://github.com/user-attachments/assets/01335840-93b5-4d80-ae45-1bb972650269" />

Each sensor stores two values per hour in the statistics table. state is the raw meter reading. sum is HA's cumulative total, computed from the deltas between readings. When a total_increasing sensor blinks out and back, sum gets corrupted — but state is almost always still fine. So you trust state and rebuild sum to match.

Stop HA and back up the DB first — you're editing prod. Then: find the broken row, read its numbers, plug them into the fix.

1. Find it

Get the metadata_id, then dump the rows around the glitch. Select start_ts too — those raw unix timestamps are what you'll paste into the fix:

`sql SELECT id, statisticid FROM statisticsmeta WHERE statistic_id LIKE '%balkonkraftwerk%'; -- -> 142

SELECT id, startts, datetime(startts,'unixepoch','localtime') AS t, state, sum FROM statistics WHERE metadataid = 142 AND startts BETWEEN strftime('%s','2026-05-04') AND strftime('%s','2026-05-05') ORDER BY start_ts; `

You're hunting for the row where the story breaks. There are two shapes it takes, and they want different fixes.

Fix A — phantom spike (state flat, sum jumps)

The output:

id start_ts t state sum ... 2643324 1777917600 2026-05-04 20:00:00 862.271 1031.552 <- last sane row 2643402 1777921200 2026-05-04 21:00:00 862.271 1893.823 <- sum leapt, state didn't

state is identical across both rows, so no energy was actually produced. The damage is the jump in sum:

phantom = 1893.823 - 1031.552 = 862.271 (the bad delta) from id = 2643402 (first row carrying it)

sum is cumulative, so that 862.271 rides along in every later row too. Subtract it once, from the bad row onward:

sql UPDATE statistics SET sum = sum - 862.271 WHERE metadata_id = 142 AND id >= 2643402;

Fix B — gap + reset (state advanced, sum restarted at 0)

Same SELECT, different sensor (155, the grid meter), around the outage:

start_ts t state sum 1775044800 2026-04-01 14:00:00 4922.912 4792.995 <- last reading before the gap 1776171600 2026-04-14 15:00:00 5127.167 0.382 <- meter's back, sum reset to ~0

Two things broke: sum fell off a cliff to 0.382, and the 13 days between are simply missing. But state kept counting through the outage, so it tells you the truth. Derive everything from those two rows:

real consumption during gap = state_after - state_before = 5127.167 - 4922.912 = 204.255 where sum SHOULD be at 14.04 = sum_before + that = 4792.995 + 204.255 = 4997.250 offset to re-base later rows = should_be - actual = 4997.250 - 0.382 = 4996.868

Step one, lift every post-reset row back onto the real baseline (using the gap's end timestamp, 1776171600):

sql UPDATE statistics SET sum = sum + 4996.868 WHERE metadata_id = 155 AND start_ts >= 1776171600;

Step two, draw a straight line across the empty gap. The CTE just holds the two endpoints — start (t0=1775044800, s0=4792.995) and the now-corrected end (t1=1776171600, s1=4997.250) — and fills an hourly row for each step between:

sql WITH RECURSIVE v(t0,t1,s0,s1) AS (SELECT 1775044800,1776171600,4792.995,4997.250), hours(ts) AS (SELECT t0+3600 FROM v UNION ALL SELECT ts+3600 FROM hours,v WHERE ts+3600 < v.t1) INSERT INTO statistics (metadata_id, created_ts, start_ts, sum) SELECT 155, h.ts, h.ts, v.s0 + (v.s1-v.s0)*(h.ts-v.t0)*1.0/(v.t1-v.t0) FROM hours h, v;

Restart, re-run the SELECT, confirm the line is boring again.

<img width="3422" height="1786" alt="Image" src="https://github.com/user-attachments/assets/12775462-3ed8-4399-885c-f26e6ea24af8" />

UPDATE, some hours later

I told you it was one UPDATE. I was wrong, and the next morning the dashboard told me so. The -4,500 bar was back. The 862 kWh spike was back. Same size, new date: today.

Nothing new had broken. My own fix had bounced back.

Here's what I'd missed. statistics isn't the only table. There's a second one — statistics_short_term, five-minute rows that HA rolls up into the hourly statistics table once an hour. And it still held the old, pre-fix cumulative sums. So every hour, HA dutifully re-aggregated the garbage and clobbered my correction, dumping the difference straight into the current hour. I wasn't fixing the data. I was fixing a cache while the source of truth quietly overwrote me.

Worse: HA was running the whole time. The recorder keeps short-term state in memory and flushes it on shutdown — so even my careful edits got stomped the moment it wrote back. Editing a database underneath a live application is like editing a file in vim while another process truncates it. Whoever writes last wins, and it isn't you.

So the boring line I buried up top — stop HA first — turned out to be the whole game. Not a footnote. The rule.

Stop the core properly. On HAOS that's ha core stop — and do it over real SSH, not the browser terminal, which is served through the frontend, dies with it, and locks you out. (Ask me how I know.) Then fix both tables:

sql UPDATE statistics SET sum = sum - 862.271 WHERE metadata_id = 142 AND id >= 2643402; UPDATE statistics_short_term SET sum = sum - 862.271 WHERE metadata_id = 142;

Before you start HA back up, check the seam: the highest sum in short-term should land right where your latest statistics row sits, with no cliff between them.

sql SELECT MIN(sum), MAX(sum) FROM statistics_short_term WHERE metadata_id = 142;

One nuance that explains why the first pass looked fine: short-term only keeps the recent stuff, ~10 days. If the hour you're editing is older than that, it's already purged and statistics is all you need. My April gap was ancient enough to ignore it. The recent spikes weren't — and that's exactly what came back to bite me.

This matters because coding agents will happily walk you straight into the dumb zone. A modern agent burns through tokens fast. A few file reads, a long debug session, a sprawling test run, and you're at 100k before lunch. Meanwhile vendors keep advertising windows of 200k, 1M, even 2M, as if those numbers represented a usable working set. They don't. Studies like RULER and Chroma's report on context rot show that effective context is a fraction of the advertised number, and that performance degrades gradually as you fill the window.

Large context windows are mostly a marketing number. The architectures behind them work, but they paper over a problem the underlying attention mechanism doesn't really solve. The number on the box gets bigger every release. The usable part doesn't keep up.

Modern agents are getting smart about this. Tools like Claude Code now auto-compact: when the session gets long, the agent summarizes the history and starts fresh. That helps. But auto-compaction kicks in after you've already spent time in the dumb zone, and the summary is itself produced by a model that's already degraded. Better than nothing, but I'd rather avoid the situation altogether.

What I do is open a new session and pass it a spec I wrote myself. That's a much higher signal handoff than any automated summary, because I get to decide what matters going forward. It's the breadcrumb approach applied to agents. Leave an artifact that the next session, or the next person, can pick up cleanly.

You can take this further. Projects like obra/superpowers and mattpocock/skills structure entire agent workflows around small, named artifacts. PRDs, plans, skills, sub-agent handoffs. Each one is a way to keep the working session in the smart zone by deliberately moving information out of the session into something the next session can read.

So I treat my context window like a budget. I assume only the first chunk is really working for me, and everything I can move out of the live session and into a written artifact is one less thing for attention to fight over.

The Open5e node provides access to 12 different D&D 5e resources through the Open5e API. Each resource supports three operations:

• Get Many: Retrieve multiple items with optional filters and pagination
• Get: Retrieve a single item by its identifier (slug or key)
• Search: Search for items by name or description

Example Workflows

1. Random Encounter Generator

Create random encounters by fetching monsters filtered by challenge rating:

1. Add an Open5e node to your workflow
2. Select Resource: Monster
3. Select Operation: Get Many
4. In Filters, add:
   • Challenge Rating: 5
   • Document Source: wotc-srd
5. Toggle Return All ON to get all matching monsters
6. Connect to a Function node to randomly select 3-5 monsters
7. Format the output as needed (Discord message, email, etc.)

2. Spell Lookup Bot

Build a Discord bot that looks up spell information:

1. Use a Discord Trigger node to listen for commands
2. Add a Function node to extract the spell name from the command
3. Add an Open5e node:
   • Resource: Spell
   • Operation: Search
   • Search Term: ={{ $json.spellName }}
4. Add a Function node to format the spell details
5. Send the formatted spell info back to Discord

3. Item Database Search

Search for magic items and weapons by name:

1. Add an HTTP Request trigger or Form trigger to accept search queries
2. Add an Open5e node:
   • Resource: Magic Item (or Weapon)
   • Operation: Search
   • Search Term: ={{ $json.query }}
   • Limit: 10
3. Format and return the results

Contributing

This is my first n8n community node. Contributions are welcome! Please feel free to submit a Pull Request or open an issue if you encounter any issues.

Brains are pattern recognition machines.

I seek structure, sometimes meta-structure.

I try to structure how I structure things.

Projects, stories and adventures often only become apparent when they are in the past.

They evolve naturally, organically. Starting a project can result in something completely different. Is there a structure in that?

I am trying to find structure again.

Life is chaotic, and that's okay.

I had this on my mind for quite some time. I'm trying to cope with chaos in my life. I like chaos, and I like turning chaos into order. But often, that does not work and I get frustrated.

Projects - no matter if programming, writing, planning an event or woodworking - are inherently chaotic. There is no structure in the concept of a "project". I want to think of a project as the sum of threads of actions towards a goal, and life is the sum of every project you ever started. I try to find a way to capture and grasp these "threads" - like commits on different branches of a code repository. On projects other than programming, this utterly fails.

I have to keep telling myself to be fine with the fact that life does not follow a structure. My personal takeaway is learning to recognize when I am seeking structure as a response to anxiety vs. when I'm doing it because it's actually useful.

Am I alone with this? Does this resonate with anyone out there? I'd love to hear from you.

• MacOS
• VSCode
• Vim Extension

The Issue

Long-pressing j or k (think "down" or "up" in Vim) only results in one down or up action, instead of continuous scrolling.

The Fix

In a terminal, run the following command:

defaults write com.microsoft.VSCode ApplePressAndHoldEnabled -bool false

Original post: https://stackoverflow.com/a/44010683

Additional tip

In the MacOS settings, set "Key Repeat Rate" and "Delay Until Repeat" to the highest setting to be able to scroll much faster.

<img width="478" height="92" alt="Image" src="https://github.com/user-attachments/assets/7bf85853-377d-4727-a5c8-2766f2794e8a" />

Lately, I was wandering if parts of the scientific method could more often be applied to every day life. There are many different resources out there explaining the scientific method, often with examples of how to apply it outside of an academic environment. The core method is always the same (in this case, taken from sciencebuddies.org):

1. Ask a Question
2. Do Background Research
3. Construct a Hypothesis
4. Test Your Hypothesis by Doing an Experiment
5. Analyze Your Data and Draw a Conclusion
6. Communicate Your Results

Related: To prove something is true, try disproving it first

1. There are three states of being. Not knowing, action and completion.
2. Accept that everything is a draft. It helps to get it done.
3. There is no editing stage.
4. Pretending you know what you’re doing is almost the same as knowing what you are doing, so just accept that you know what you’re doing even if you don’t and do it.
5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.
6. The point of being done is not to finish but to get other things done.
7. Once you’re done you can throw it away.
8. Laugh at perfection. It’s boring and keeps you from being done.
9. People without dirty hands are wrong. Doing something makes you right.
10. Failure counts as done. So do mistakes.
11. Destruction is a variant of done.
12. If you have an idea and publish it on the internet, that counts as a ghost of done.
13. Done is the engine of more.

Because creating a custom entity was not quite so straight forward as I'd hoped, I wanted to share how I did it.

I ended up using the input_number integration (which seems to come with Home Assistant) and defined an entity that I could reference through the API:

`yaml

configuration.yaml

inputnumber: easyfitnessauslastung: name: EasyFitness Auslastung initial: 0 min: 0 max: 100 step: 1 `

After reloading the configuration, the entity was ready to be written to.

As mentioned, I'm using a self-hosted instance of n8n on a Raspberry Pi to automate this. Using their Home Assistant Integration, you can simply address the new entity and update its state. And just like that, I was able to add a new Gauge to my dashboard!

I always stayed away from TeamViewer, because I was never really sure if that had a free plan, and the possibility of finding out mid-session that they don't have one was reason enough to save the hassle of yelling the installation instructions through the phone.

I remember hearing about RustDesk in a podcast a couple of years ago. The host claimed it to be a hassle-free open source replacement for TeamViewer, but by the time the next IT-support session arrived, I already forgot about it. Until yesterday!

Yesterday, I just didn't get enough information to be useful. I just needed a way to remotely access the computer, and that's then I remembered the promise of RustDesk. Going in blind, I quickly installed the client on my laptop and sent a mail with the instructions to my family member:

1. Click here (a download link to the executable file)
2. Press the windows key
3. Type "rust" (to search for the file)
4. Press enter
5. Tell me the ID and the onetime password on the screen

These instructions are fool-proof! And sure enough, they worked. I logged in and debugged the issue. No paywall, no corporate bullsh**, just a simple client that just works as intended out of the box. I was delighted to see that the plan has worked out. Going forward, Rustdesk will be my primary choice for remote IT support.

If you're interested: for some reason the browser window on their screen was resized to a tiny box near the edge of the screen, so whenever they clicked a bookmarked link on their desktop, instead of "nothing happening", they just didn't see the page opening in the browser.

TL;DR

Use RustDesk instead of TeamViewer for a free and easy way to access your family's computer remotely.

` diff --git a/lib/ui/screens/detail/components/body/eventbody.dart b/lib/ui/screens/detail/components/body/eventbody.dart index d19d70a..1a61380 100644 --- a/lib/ui/screens/detail/components/body/eventbody.dart +++ b/lib/ui/screens/detail/components/body/eventbody.dart @@ -3,6 +3,7 @@ class EventBody extends StatelessWidget { final EventDetails details; @@ -18,35 +19,43 @@ class EventBody extends StatelessWidget {

@override Widget build(BuildContext context) => Column( - crossAxisAlignment: CrossAxisAlignment.stretch, - children: [ - EventInfoView( - location: details.location, - start: details.start, - end: details.end, - certified: details.certified, - paid: details.paid, - points: null, // Already shown in app bar + crossAxisAlignment: CrossAxisAlignment.stretch, + children: [ + EventInfoView( + location: details.location, + start: details.start, + end: details.end, + certified: details.certified, + paid: details.paid, + points: null, // Already shown in app bar + ), + const SizedBox(height: 24), + Html( + data: details.description, + style: { + 'body': Style( + margin: Margins.zero, ... } `

But do you spot what has ACTUALLY been changed? In a real world scenario, it probably took you a while before you realised that it's the result of formatting the entire file. Nobody cares about whitespace when reviewing code. Or rather, your brain should not take the burden of having to care about that. That's what linters are for!

Let's look at the same diff with the --ignore-all-space (shorthand -w) flag activated:

diff --git a/lib/ui/screens/detail/components/body/event_body.dart b/lib/ui/screens/detail/components/body/event_body.dart index d19d70a..1a61380 100644 --- a/lib/ui/screens/detail/components/body/event_body.dart +++ b/lib/ui/screens/detail/components/body/event_body.dart @@ -3,6 +3,7 @@ class EventBody extends StatelessWidget { final EventDetails details; @@ -29,6 +30,14 @@ class EventBody extends StatelessWidget { points: null, // Already shown in app bar ), const SizedBox(height: 24), + Html( + data: details.description, + style: { + 'body': Style( + margin: Margins.zero, + ), + }, + ), Text(details.description, style: context.theme.textTheme.body2Regular), if (details.registrationUrl != null || details.programUrl != null) const SizedBox(height: 16), if (details.registrationUrl != null) ...[

Huh, so it's NOT just a formatted file. All whitespace changes have been stripped out, and you only see the changes that are relevant for the review. Neat!

Many tools also support ignoring whitespace. GitLab let's you disable Show whitespace changes in the merge request diff viewer. VSCode has the diffEditor.ignoreTrimWhitespace setting. So, if you want to make this the default in your tools, chances are there's an option for only showing relevant changes.

A bit of a sloppy post, but I hope this is useful to someone. Happy code reviewing!