Good tires and adequate pressure and I haven’t had a single puncture in years. But I get your sentiment, and of course it’s not for everybody. Although for me, the number one best way to get away from cars is gravel and single trails. So that, and being in the woods, are the main reasons for my love of gravel riding.

Where I’m from, the Eurovelos actually live up to their grand concept and are fully developed and paved as far as I’ve seen (and therefore a bit boring for me), but I don’t have to go far (a day’s ride across a border) and our “pan-european cycle path” is actually “the perfectly good street we happened to have lying around here; have fun!”

I agree with your take on Osmand; a problem many big FOSS projects seem to share. I’m almost certain that there must be a way to properly penalise unpaved roads for routing with brouter, by the way. I’d check it out for you, but I truly dread the settings menus of those two apps…

My main motivation for trying out brouter was to prepare for the Komoot exodus when it will inevitably happen, and I have a different experience to yours. I find the routing to be on par with Komoot (often nearly identical routes, actually), and that’s been the best I’ve seen for my purposes so far. My main priority is to avoid roads for my gravel tours as much as possible (the larger the more urgently) with trail and woods segments actually being a plus and direct path not being important at all.

That said, I do hate the user experience with brouter+Osmand. I have no clue why brouter has to be a separate app. I have no clue how to properly configure it, and I am completely overwhelmed with Osmand’s millions of options, views, and settings. Software that makes me feel dumb and inadequate.

Ah, I see. I thought this was about an issue with FreeCAD, but it is actually a process problem. (Why wouldn’t FreeCAD allow me to stuff arbitrarily complex meshes into a model, and of course that can lead to slow computation times.)

That said, analysis tools built into the software would probably be a useful thing to investigate what makes a file “slow.”

There’s also brouter which acts as a routing companion app to Osmand. It’s a bit of a pain to set up, but gives very good results.

Thanks for writing it up, although the blog post raises more questions for me than it answers. Is that a common thing? I’ve never noticed overly large files, but maybe I wasn’t paying attention? What is the cause of it, complex geometries? What can be done in such a case to optimise?

Lawyer?! I hardly even know her.

I wasn’t advocating to get a J4125 in 2025, I was sharing my experience with it. I can’t confirm it choking with Jellyfin.

I’m doing everything you list and quite a bit more on a QNAP with a Celeron J4125. A fraction of the cpu performance you’ll have, yet very capable of all the tasks I ask of it. 16gb of memory is a good starting point I think.

What does your build come out at?

What does that mean?

“Just” some highly specific VM settings, in the end. I don’t know much about that, and terms like qemu don’t mean anything to me so I followed blog posts until it worked. (This one and maybe this one, I think.) It’s possible that it is actually trivial.

It’s been a while, but I can look up what I have when you need it. Feel free to ping me!

Yes, it was exactly that: Once I got the NICs set up the way I wanted them it was a breeze and everything just works. And I really like that I made every part work myself, no magic. I learned a lot, and wouldn’t have had I relied on Proxmox fiddling with the right parts for me.

Capture the flag?

I was in a similar spot not too long ago, setting up a firewall and general network box. I was going to go with Proxmox but a fellow Lemmy guy strongly advocated for Incus on top of vanilla Debian. I was intrigued and ended up going for it. Learned a lot about networking with systemd (bridging, IP assignment and so on) for things I could have gotten for free in Proxmox (literally a few clicks), and had to fight Incus to work with a FreeBSD VM for Opnsense, but I love the setup now. Pure debian with a few Incus VMs and Docker inside of those as needed. So clean!

Right, so I would need to do an OTA update for all devices I want to deplay. Thanks for the insight!

Ah, I see. I thought EM and PM are just other smart plug models. Sadly, not a viable solution for me- I need it to be a smart plug type of device. I wonder if those have more precise or faster measuring circuitry or if it’s just a different firmware for a different use case.

Hm, is it possible that “virtually immediately” means different things to us? I have now thoroughly benchmarked a Shelly AZ and am currently investigating a Shelly PlusPlug S (Gen2 I think), and they are both far from where I would like them to be.

Here’s the result from a 1.5h run, toggling the load every few seconds:

The PlusPlugS V2 is even worse.

The real problem with this, other than delayed and missed events, is the standard deviation. A constant delay would be okay.

That’s not a hard requirement, but I thought it would be easier if the device pushes out a single message when there is significant change in current (as the Shellies do) instead of having to poll as fast as possible and hope for a timely response. My limited experience with these devices is that they are not the fastest or most reliable HTTP servers. I can poll a Shelly AZ’s state at a maximum of around 3 or 4 times per second, for example.

A tight power_delta threshold and a millisecond timestamp in the MQTT message would probably solve my problem very nicely, but the Shelly I tested has no configurable threshold and only sends timestamps in minutes, which is of course unusable for me.

This together with runtime configurable thresholds would solve my problem completely.

I ordered one of their ESPHome and one of their Tasmota models yesterday. When you talk about configuration, that actually means compiling a firmware binary and doing an OTA update, right? Or is it actually just a config file I give the device?

The goal is to measure precise on-time for certain kitchen appliances, and to be able to differentiate operating modes (e.g. standby vs. operating, potentially power setting when on.)

It’s not exactly that, but let’s say you’d like to measure exactly how long a mixing device is mixing something, and you could guess the speed setting with some confidence.

It actually isn’t so much about receiving the data as fast as possible, but about precision in timing, which the plugs I’ve tested so far don’t really offer. Best I have seen so far is ~2s delay with a standard deviation of up to another second on a Shelly AZ… Not good enough. The investigation continues.

That sounds good. Will test.

Have ordered a few devices to test and will give it a go. Thanks!