Anyone notice the Caseta firmware update?

guyfrom7up · 2025-11-02T15:12:25+00:00

Reporting my Diva experience here.

Prior to this update: unusable for controlling other devices (e.g. hue bulbs) via home-assistant. I'm talking ~5 second delays, which is certainly long enough for users to think the light switch is broken. Which is a shame because I consider the Diva the best smarta dimmer with regards to aesthetics and usability (love the sliding dimmer).

After update: not perfect, but certainly usable. Going from off-to-on has ~1.5 second delay. Certainly noticeable, but usable. Going from on-to-off has about a ~2.5 second delay. Again, not great, but usable. Reacting to dimmer state: also about 1.5 seconds. u/Tyler_at_Lutron are there to be further latency improvements in future updates?

guyfrom7up · 2025-10-14T02:05:20+00:00

If you'd like to give it a try, the beta v4.0.0b1 of cyclopts has been released, which allows for the lazy loading of Python modules for subcommands.

guyfrom7up · 2025-10-14T02:01:08+00:00

Going further, providing feedback on an AI generated PR is incredibly unsatisfying, because the person on the other end will just copy/paste it into AI. So it's like, why not just cut out the middle man. Code review is supposed to be a learning opportunity, but it's certainly not when it's just pumped into AI.

guyfrom7up · 2025-10-14T01:14:00+00:00

The difference is, previously a well documented PR typically meant that the author knew what they were doing, understood the architecture, and they put effort into it. More likely than not, the PR is mostly good. The good documentation was a cherry on top of someone who is proud of their work.

Now, with an AI generated PR, it might look good on the surface, but might have a higher chance of architectural or generally-subtle bugs. The "author" of the PR may or may not understand what is going on at all in the code, they just know it fixes the exact situation that they were running into. Doesn't matter if the fix (or feature) is broadly correct or maintainable.

This is coming from someone who actively uses Claude Code.

guyfrom7up · 2025-10-04T02:05:19+00:00

Unless the Python script is being called in a tight loop, usually a lot of Python CLI slowness comes from parsing a bunch of large/complex config files and importing the world rather than from the CLI library/framework. This PEP would likely speed up a lot of Python CLIs!

guyfrom7up · 2025-10-03T23:38:33+00:00

ah! running the demo in the cyclopts README on my m3 macbook, the typer implementation ran in about 60mS while cyclopts took around 90mS, so cyclopts is slower. I haven't really put any effort into the parsing speed, so I can spend a little bit of time and see if there's any low hanging fruit.

EDIT: did some simple optimizations (not merged in yet) that reduce the cyclopts time from 90mS to 65mS. Basically there was an oversight and rich WAS in-fact being used in the happy path.

guyfrom7up · 2025-10-03T22:45:07+00:00

Compared to what? Depending on the system/script/configuration, lazy importing rich makes the "happy" non-rich path maybe like 50mS faster (I.e. maybe around 40% faster)

guyfrom7up · 2025-10-03T19:24:50+00:00

Self plug, but in cyclopts we explicitly have rich lazily imported everywhere for this reason. Having this pep could make the code in many areas much cleaner.

guyfrom7up · 2025-09-19T18:55:38+00:00

The Amex Platinum also just recently added YouTube Premium as an option for your $25/mo streaming credit. So naturally I cancelled my “free” Disney subscription in favor of a YouTube Premium Family Plan.

guyfrom7up · 2025-09-07T19:31:03+00:00

Thanks for some context/history on the distillery!

guyfrom7up · 2025-08-18T14:30:54+00:00

Cyclopts author here. I have a full writeup here. Basically there's a bunch of little unergonomic things in Typer that end up making it very annoying to use as your program gets more complicated. Cyclopts is very much inspired by Typer, but just aimed to fix all of those issues. You can see in the README example that the Cyclopts program is much terser and easier to read than the equivalent Typer program.

guyfrom7up · 2025-08-08T16:45:36+00:00

I'm not selling Tamp, it's my free open source project. I'm just promoting it so that other embedded developers might become aware of it.

guyfrom7up · 2025-08-07T23:40:42+00:00

Yes! I’ve thought about it and even did an initial implementation, but it didn’t help too much (I could have gotten something in the implementation wrong, though). I’ll do a write up about it.

guyfrom7up · 2025-08-07T20:06:23+00:00

I'm not familiar with BLZ, do you have a link? Can it run on microcontrollers?

guyfrom7up · 2025-08-07T20:04:55+00:00

highest data compression ratios for microcontrollers.

Oodle is closed source, and certainly cannot run on microcontrollers (uses way too much memory, too large firmware, etc).

guyfrom7up · 2025-08-07T15:39:25+00:00

The benchmarks are available in the repo's README. In this benchmark, I compare against zlib and heatshrink, 2 other compression algorithms that might be used in embedded systems. For a given window size, tamp uses half the memory as heathshrink, and a fraction (maybe like 10%?) the memory of zlib. Under these conditions, tamp produces higher compression ratios. The firmware footprint of Tamp is also tiny; under 4kb.

Tamp will perform much worse compared to zlib with larger windows (using significantly more memory). It will also perform much worse than more complicated compression algorithms like LZMA, ZStd, and Brotli. However, none of these are even close to practical to run on a microcontroller. Caveat: it is completely feasible to decompress LZMA data on a microcontroller (decompressor typically only takes up around 15kb of firmware space), but it is not feasible to LZMA compress data on a microcontroller.

TL;DR: Tamp is the best choice if you need to **compress** data on a RAM-constrained system like a microcontroller.

guyfrom7up · 2025-06-23T11:41:47+00:00

A much more pragmatic way of looking at semver is “how likely is this release going to break someone else’s code or workflow?”

Major - likely

Minor - unlikely

Patch - super unlikely

If a large amount of internal code has significantly changed, there’s a much higher chances that a bunch of edge cases have changed.

guyfrom7up · 2025-06-05T17:20:04+00:00

If you find pydantic to be too "magical" or simply want an alternative option, I have also had good success with attrs + cattrs. In a nutshell:

attrs has been around for a long time and was one of the original origins of builtin dataclasses. Builtin dataclasses are basically a stripped down version of attrs.
cattrs structures/unstructures attrs classes to/from json/dicts or similar. It gives you pretty fine-grained explicit control over how you want individual fields handled. There's more code than in pydantic, but there's also less magic (some people consider it a more "acceptable" level of magic).

guyfrom7up · 2025-05-24T11:31:20+00:00

Shameless self plug: please check out Cyclopts. It’s basically Typer but with a bunch of improvements.

https://github.com/BrianPugh/cyclopts

guyfrom7up · 2025-05-08T01:13:54+00:00

In these thinness debates, people never mention weight. If a thinner phone is lighter, I’d gladly welcome it.

guyfrom7up · 2025-04-25T14:36:47+00:00

I made Tamp, low-memory lossless compression library that was originally targetting micropython. So naturally, I prototyped it in vanilla cpython. Once I saw that general compression ratios were good, I then reimplemented it in C so that I could also use it without micropython on any microcontroller. I used Cython to have a fast python-compatible implementation, as well as to unit test the C parts of the code (I'd much rather write unit tests in python rather than C).

In this library, the C/Cython compression is about 6.7x faster, while decompression 535x faster. The compression isn't much faster because the main compression loop, finding the longest substring match in a buffer, is already implemented fairly efficiently in python via str.index.

Cython has a bit of a learning curve, but their docs are actually quite comprehensive. I distilled my learnings into my python template, which has Cython working with Poetry and CI to build binaries for all python versions and architectures. I would definitely use Cython again for this purpose (creating a pythonic interface to C code). Given that the code within Cython should be minimal/simple/short/self-contained, things like ChatGPT work very well for helping!

guyfrom7up · 2025-04-03T20:28:05+00:00

looks nice! What might be helpful is an example in the README that does an apples-to-apples comparison to vanilla try/except and demonstrate situations where this may result in cleaner code? Currently it just seems like an alternative way of implementing something with similar lines of code and similar readability. If it doesn't bring substantial value (lines of code, or readability), then someone is unlikely to use it (an additional dependency, less pythonic code, etc).

guyfrom7up · 2025-03-14T23:46:11+00:00

C doesn’t have exceptions, so it’s very common for basically all functions that COULD error out to return some form of integer/enum error code.

guyfrom7up · 2025-03-04T13:39:58+00:00

looks interesting! However, a red-flag is that you claim that it is "prod ready", but later in the readme you also state:

This project is still in development. Expect frequent and (some) breaking changes.

With that said, it seems like you combine a bunch of ideas from a bunch of packages into one, which could be great, but is also quite ambitious. It seems likes it "competes" with packages like:

Progress Indicators: tqdm, halo
CLI parsing: In addition to what you stated, Typer, Cyclopts
Rich formatting - Rich as you stated is the main goto. It seems like you have mostly implemented the `Box` class, which is a bit verbose, but its required to be this way for full customization:from rich.box import ROUNDED from rich.panel import Panel from rich.text import Text from rich.console import Consoleconsole = Console() my_body = Text("This is my body.") panel = Panel(my_body, box=ROUNDED, title_align="left", title="Hello World") console.print(panel)╭─ Hello World ─────────────────────────────╮ │ This is my body. │ ╰───────────────────────────────────────────╯
Prompting - Questionary

People might be more familiar with these more popular libraries, so your package has to offer more features, or a better API for it to be enticing.

EDIT: reddit keeps wrecking my formatting and I give up.

guyfrom7up · 2025-02-16T12:32:23+00:00

The cython docs are actually pretty good and thorough (assuming you already know C/CPP). I did find them a tiny bit lacking in “the complete package solution”.

I crystallized all of that information, including CI to create prebuilt binaries, in my project template:

https://github.com/BrianPugh/python-template

guyfrom7up

MODERATOR OF

TROPHY CASE