I am hacking on a project I’ve named “Flux Regulator” for our off grid cabin. I mentioned working on IR control a few weeks back, That’s now come together into a setup where I have a Rust program running on a raspberry pi, with the following access:
Real-ish-time power in from the rooftop solar via CANBus
Real-ish-time power out to AC in building via CANBus
Approximate energy stored in the batteries
Current building humidity and temperature via Arduino
hourly weather projections
And is then able to do exactly one thing: Control the HVAC state between off/heat/cool/dehumidify.
I’m now digging for algorithms that go beyond regular PID control and look at “ok, so, it’ll be cloudy tomorrow, so if we spend all our energy overnight keeping the building in the ideal comfort zone, we will be hosed tomorrow, so we need to accept the building will be a bit colder than normal”. If anyone knows of research in control algorithms / scheduling in this area I’m super interested.
I’m kind of combining experiences building PID loops for BBQ smokers with control loops in k8s operators haha, which I’m not sure is ideal, but at least the building is warm r/n.
Also, it’s a surreal experience of modifying the environment you are currently in as you code. Last night was like “damn I’m so cold my fingers hurt, need to rewrite this routine so it pushes the heat higher asap”
This sounds like a nice project! As far as forecasts go (and trying to anticipate changes in your HVAC system) you could look at historical Heating/Cooling Degree Days. You could come up with an adjustment factor, taking into consideration a few variables, and then apply it to your scheduled setting.
I’ve been working on alternate firmware for the Novation LaunchPad Pro, a MIDI controller consisting of an 8x8 grid of pressure-sensitive pads and 32 buttons, all with RGB LEDs. Novation released open source code for it a few years ago, but for various reasons (explained in the README) it doesn’t include the default functionality, it’s more of a blank-slate framework.
I’ve been building on that, and I’ve reproduced the basic “notes mode” and added a chord mode and better support for different scales. The end goal is to add a sequencer.
I’m doing this in C++17 with an OO design, despite the fact the hardware has only 20KB RAM, a few hundred KB flash, and zero standard library (not even memcpy, let alone malloc.) so far it’s going great. I’m having fun seeing how far I can push constexpr — I have classes for notes, scales, modes and chords but there’s no runtime overhead. I can write Mode major(“*-*-**-*-*-*“) and it compiles into a uint16_t. So far I’ve used about 35KB of code and maybe 1KB RAM (mostly for double-buffering the LEDs.)
I made the weird discovery that, since my musical model classes are nearly all constexpr, they can have compile-time unit tests! I just use static_assert for my assertions, and I can see my IDE flag them as passing or failing as I type, without even having to build. It’s quite weird.
That’s amazing! Do you plan to post something (blog, notes) somewhere? I would be super curious to read about that as I am looking to settle for a groovebox but lurking on the various grid-based hardware existing too.
Thanks! I hope to push it to GitHub in the next few days. It’s a useful tool by now, and the code’s decent enough that I feel ok letting other people see it. I just need to change the settings page a bit and write a new README.
Ludum Dare 48 is this weekend. It’s a game jam where you produce a game from scratch in 48 hours. I’ve been participating in these for several years now and it’s always a lot of fun.
I’m continuing to work on Spellblade. I just got its eBook generation via Nix pipeline set up and I am going to see about setting up some kind of CI for it.
I’m working on a phoenix live view-like project for haskell. So far it’s promising and I’m cautiously optimistic that this will actually work quite nicely. Since it’s very small at the moment, it’s easy to mess with – github link here. If anyone’s looking to toy around with haskell or share ideas about what it could look like, by all means feel free. This should be a good time.
This weekend I’m hoping to get hot reloading / the developer repl working to make sure it’s fast enough to really use.
Have you heard about concur-replica? It is also a haskell version of live view. I’ve never used it, but it might be interesting for you to see their approach.
I have, it’s pretty cool. I’ll definitely be looking at it more to see how they’ve done some things, and it’ll be interesting to see how this diverges from concur-replica
Compiling every public Rust crate and mining them for data. For a start, deducing minimum rustc version required for each crate, to display on https://lib.rs (example). Next I plan to get clippy lints for all of them.
No crater. I’m using docs.rs’ docker image + cargo check --message-format=json + awful lot custom scripting to get it all out, parse, and store.
Currently I’m struggling with the fact that I want to keep target and cargo registry caches to speed the checks as much as possible, but these directories quickly grow to comically large sizes.
I found an old flash game that I used to play as a kid on the Internet Archive, emulated with Ruffle. It gave me some nostalgia, so I want to see how quickly I can clone the core gameplay. If I do this (as opposed to working on another project), I’ll do it in Common Lisp, see how long I can keep a single image running (incremental development), time myself, and maybe even record my screen.
It would be fun to see what the difference is between my initial estimate of how long it’ll take (2 hours) and how long it actually takes. I think that the rule of thumb in software development is “triple your initial estimate”, in which case it would go from being a puzzle to a full-day project…
Probably gonna fight through the boring task of finishing up some config parser for a project of mine. Sometimes the hobby project also has boring parts to do. I have a couple of draft ideas for some blog posts, so I’ll probably pick one out and work on a blog post.
Also looking forward to spend some time outside and enjoy the sun, probably take the hammock out somewhere with a good book.
Home improvement. Building shelves to make a coat closet into a pantry. Flushing a neighbor’s tankless water heater. Painting my front door. And putting edging around planters in the yard.
I’m trying to make my app aware of database being down and buffer write to a local badger db then sync the change back to db once our db is backed up.
My app is an email forwarding app so I cannot have downtime, I have enough domains to manage that I’m processing about 20 emails per days so I want to decouple the mail server from the postgres database. It’s ok for the webapp to be down when we maintain db but mail server cannot be down.
Luckily a majority of change between mail server <-> postgres is append only so I can buffer write to badger db,and write back to postgres later on.
$HOME: I have a couple of vegetable to plant, also other stuff will need water.
$CODE: As part of babelia, I spent some time catching up about ReactJS / preact hooks, and eyeing on snabbdom, morphdom and nanodom. I think I will cut the chase and go with preact without relying on hooks. I was thinking to go straight to coding, but I might start with mockups in inkscape. I pushed a repository of early rework draft dubbed ‘OKDB: Ordered Key-Value Store with extensions, documented, and implemented’: The basis is a rework of SRFI-167 that was inspired by FoundationDB, but here I will focus on the embedded case, and depart from the interface inherited from BerkeleyDB / wiredtiger to include the “estimated count of keys in a subspace” and “estimated bytes size of a subspace”. The sample implementation will be done with Scheme. I need both the gui mockups, and OKDB in the next couple month. I could do the frontend without OKDB. Eventually after Babelia 1.0 is complete (official ETA 9 months), I will need OKDB. It does not help that I have a smaller project in mind, a static resume / cv powered by a single page frontend app, that could demonstrate that OKDB is useful in the frontend, and where I could (in theory) quickly demonstrate (again!) how to implement a search engine. In anycase, I will augment the Q/A style Gambit Scheme documentation, to help myself, and hopefully help others discover the awesome features of that implementation of Scheme.
I am hacking on a project I’ve named “Flux Regulator” for our off grid cabin. I mentioned working on IR control a few weeks back, That’s now come together into a setup where I have a Rust program running on a raspberry pi, with the following access:
And is then able to do exactly one thing: Control the HVAC state between off/heat/cool/dehumidify.
I’m now digging for algorithms that go beyond regular PID control and look at “ok, so, it’ll be cloudy tomorrow, so if we spend all our energy overnight keeping the building in the ideal comfort zone, we will be hosed tomorrow, so we need to accept the building will be a bit colder than normal”. If anyone knows of research in control algorithms / scheduling in this area I’m super interested.
I’m kind of combining experiences building PID loops for BBQ smokers with control loops in k8s operators haha, which I’m not sure is ideal, but at least the building is warm r/n.
Also, it’s a surreal experience of modifying the environment you are currently in as you code. Last night was like “damn I’m so cold my fingers hurt, need to rewrite this routine so it pushes the heat higher asap”
This sounds like a nice project! As far as forecasts go (and trying to anticipate changes in your HVAC system) you could look at historical Heating/Cooling Degree Days. You could come up with an adjustment factor, taking into consideration a few variables, and then apply it to your scheduled setting.
I’ve been working on alternate firmware for the Novation LaunchPad Pro, a MIDI controller consisting of an 8x8 grid of pressure-sensitive pads and 32 buttons, all with RGB LEDs. Novation released open source code for it a few years ago, but for various reasons (explained in the README) it doesn’t include the default functionality, it’s more of a blank-slate framework.
I’ve been building on that, and I’ve reproduced the basic “notes mode” and added a chord mode and better support for different scales. The end goal is to add a sequencer.
I’m doing this in C++17 with an OO design, despite the fact the hardware has only 20KB RAM, a few hundred KB flash, and zero standard library (not even memcpy, let alone malloc.) so far it’s going great. I’m having fun seeing how far I can push
constexpr
— I have classes for notes, scales, modes and chords but there’s no runtime overhead. I can writeMode major(“*-*-**-*-*-*“)
and it compiles into auint16_t
. So far I’ve used about 35KB of code and maybe 1KB RAM (mostly for double-buffering the LEDs.)I made the weird discovery that, since my musical model classes are nearly all constexpr, they can have compile-time unit tests! I just use
static_assert
for my assertions, and I can see my IDE flag them as passing or failing as I type, without even having to build. It’s quite weird.That’s amazing! Do you plan to post something (blog, notes) somewhere? I would be super curious to read about that as I am looking to settle for a groovebox but lurking on the various grid-based hardware existing too.
Thanks! I hope to push it to GitHub in the next few days. It’s a useful tool by now, and the code’s decent enough that I feel ok letting other people see it. I just need to change the settings page a bit and write a new README.
Once it’s up I’ll post it to Lobsters, of course.
Ludum Dare 48 is this weekend. It’s a game jam where you produce a game from scratch in 48 hours. I’ve been participating in these for several years now and it’s always a lot of fun.
I’m continuing to work on Spellblade. I just got its eBook generation via Nix pipeline set up and I am going to see about setting up some kind of CI for it.
I’m working on a phoenix live view-like project for haskell. So far it’s promising and I’m cautiously optimistic that this will actually work quite nicely. Since it’s very small at the moment, it’s easy to mess with – github link here. If anyone’s looking to toy around with haskell or share ideas about what it could look like, by all means feel free. This should be a good time.
This weekend I’m hoping to get hot reloading / the developer repl working to make sure it’s fast enough to really use.
Have you heard about concur-replica? It is also a haskell version of live view. I’ve never used it, but it might be interesting for you to see their approach.
I have, it’s pretty cool. I’ll definitely be looking at it more to see how they’ve done some things, and it’ll be interesting to see how this diverges from concur-replica
Compiling every public Rust crate and mining them for data. For a start, deducing minimum rustc version required for each crate, to display on https://lib.rs (example). Next I plan to get
clippy
lints for all of them.Fun times, I’ve been there before. Are you using
crater
, or something else?No crater. I’m using docs.rs’ docker image +
cargo check --message-format=json
+ awful lot custom scripting to get it all out, parse, and store.Currently I’m struggling with the fact that I want to keep
target
and cargo registry caches to speed the checks as much as possible, but these directories quickly grow to comically large sizes.I found an old flash game that I used to play as a kid on the Internet Archive, emulated with Ruffle. It gave me some nostalgia, so I want to see how quickly I can clone the core gameplay. If I do this (as opposed to working on another project), I’ll do it in Common Lisp, see how long I can keep a single image running (incremental development), time myself, and maybe even record my screen.
It would be fun to see what the difference is between my initial estimate of how long it’ll take (2 hours) and how long it actually takes. I think that the rule of thumb in software development is “triple your initial estimate”, in which case it would go from being a puzzle to a full-day project…
Implementing a CRC library for fun!
Probably gonna fight through the boring task of finishing up some config parser for a project of mine. Sometimes the hobby project also has boring parts to do. I have a couple of draft ideas for some blog posts, so I’ll probably pick one out and work on a blog post.
Also looking forward to spend some time outside and enjoy the sun, probably take the hammock out somewhere with a good book.
I am intended to work on a PR for
stgit
that I have initiated to be able to use it as part of my dayjob workflow.I really love the tool.
Home improvement. Building shelves to make a coat closet into a pantry. Flushing a neighbor’s tankless water heater. Painting my front door. And putting edging around planters in the yard.
I’ll get back to my desk Monday.
I’m trying to make my app aware of database being down and buffer write to a local badger db then sync the change back to db once our db is backed up.
My app is an email forwarding app so I cannot have downtime, I have enough domains to manage that I’m processing about 20 emails per days so I want to decouple the mail server from the postgres database. It’s ok for the webapp to be down when we maintain db but mail server cannot be down.
Luckily a majority of change between mail server <-> postgres is append only so I can buffer write to badger db,and write back to postgres later on.
$HOME: I have a couple of vegetable to plant, also other stuff will need water.
$CODE: As part of babelia, I spent some time catching up about ReactJS / preact hooks, and eyeing on snabbdom, morphdom and nanodom. I think I will cut the chase and go with preact without relying on hooks. I was thinking to go straight to coding, but I might start with mockups in inkscape. I pushed a repository of early rework draft dubbed ‘OKDB: Ordered Key-Value Store with extensions, documented, and implemented’: The basis is a rework of SRFI-167 that was inspired by FoundationDB, but here I will focus on the embedded case, and depart from the interface inherited from BerkeleyDB / wiredtiger to include the “estimated count of keys in a subspace” and “estimated bytes size of a subspace”. The sample implementation will be done with Scheme. I need both the gui mockups, and OKDB in the next couple month. I could do the frontend without OKDB. Eventually after Babelia 1.0 is complete (official ETA 9 months), I will need OKDB. It does not help that I have a smaller project in mind, a static resume / cv powered by a single page frontend app, that could demonstrate that OKDB is useful in the frontend, and where I could (in theory) quickly demonstrate (again!) how to implement a search engine. In anycase, I will augment the Q/A style Gambit Scheme documentation, to help myself, and hopefully help others discover the awesome features of that implementation of Scheme.