tofubl

joined 2 years ago
[–] tofubl@discuss.tchncs.de 1 points 1 month ago

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.

[–] tofubl@discuss.tchncs.de 3 points 1 month ago (4 children)

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?

[–] tofubl@discuss.tchncs.de 1 points 1 month ago

What does that mean?

[–] tofubl@discuss.tchncs.de 1 points 1 month ago* (last edited 1 month ago) (1 children)

"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.

[–] tofubl@discuss.tchncs.de 2 points 1 month ago (2 children)

Capture the flag?

[–] tofubl@discuss.tchncs.de 4 points 1 month ago* (last edited 1 month ago) (6 children)

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!

[–] tofubl@discuss.tchncs.de 2 points 1 month ago

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

[–] tofubl@discuss.tchncs.de 1 points 1 month ago

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.

[–] tofubl@discuss.tchncs.de 2 points 1 month ago* (last edited 1 month ago) (2 children)

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:

Shelly AZ Turn-ON delay (standard deviation) Turn-OFF delay (standard deviation)
HTTP Polling 2.0s (0.8s) 2.3s (0.7s)
MQTT Subscription 1.9s (0.8s) 2.2s (0.8s)

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.

[–] tofubl@discuss.tchncs.de 1 points 1 month ago

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.

[–] tofubl@discuss.tchncs.de 1 points 1 month ago (3 children)

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?

[–] tofubl@discuss.tchncs.de 2 points 1 month ago (4 children)

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.

view more: ‹ prev next ›