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."
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?
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.
"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.
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!
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:
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.
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.
You mean fire out data as fast as possible and take care of processing on the server? I'd be okay with that if necessary, but so far I haven't found one that seems to even measure the power consumption fast enough. They all average over some time frame between a few seconds and even minutes. This is of course fine for regular home appliances, but not fast enough for the problem I'm trying to solve.
Sadly, manual reflash is sort of a non-starter for my specific situation, but I have found devices that ship with Tasmota and ESPHome preflashed. I ordered a few to test.
What a perfectly reasonable headline to read.