What use cases do you imagine for LLMs in home automation?
I have HA and a mini PC capable of running decently sized LLMs but all my home automation is super deterministic (e.g. close window covers 30 minutes after sunset, turn X light on if Y condition, etc.).
the obvious is private, 100% local alexa/siri/google-like control of lights and blinds without having to conform to a very rigid structure, since the thing can be fed context with every request (e.g. user location, device which the user is talking to, etc.), and/or it could decide which data to fetch - either works.
less obvious ones are complex requests to create one-off automations with lots of boilerplate, e.g. make outside lights red for a short while when somebody rings the doorbell on halloween.
maybe not direct automation, but ask-respond loop of your HA data. How are you optimizing your electricity, heating/cooling with respect to local rates, etc
Yes but so would a "stop asking" option. I don't find this as a flaw, instead it's a pretty good feature. Everything should be able to be revisited, if only because times change and there's unintended consequences.
Just because you can still drive over speed bumps and knock over road blocks doesn't mean that they aren't effective tools.
That design you describe is what is pictured at the top of the article.
Problem is that then the keys are not equally spaced chromatically (e.g. larger spacing between B and C than between C and C#).
You could probably get used to play like that, but it would be ineficient in terms of space for both the fingers and the mechanics of the piano (hammers, strings).
So what you do, in reality, is move some of the black keys down a bit (C#, F#) and some up (Eb, Bb) so that the spacing between the center of the keys is regular.
I don't think that's what's described in the article though?
Janet is very small, apparently smaller than Lua, and is also intended to be embedded into native-code programs. Hence, I suppose, the decisions that make it "too" simple: it apparently is not intended for writing large amounts of code.
> lot of clojure developers could benefit from this immensely.
Curious what you think Clojure developers could benefit from specifically.
Having done web services in both languages I much prefer the experience in Clojure. E.g. found error handling in Gin to be very cumbersome (AbortWithStatusJSON and such). The deployment story is nicer in Go, tho.
Clojue CLR is behind JVM support (and performance), but it has been a thing from the start, not just a "port".
The German social contract for a long time was that the working class gets low wages, which keeps German exports competitive and combined with the large internal market, prices low. In return for making the owning class wealthy, workers also get a relatively good social support system and job security.
I'm not sure this model ever applied to A & CH, and might be starting to collapse in D as well.
> I'm missing clarity about how do I escape Instant DB when I need to, and how to make it part of a larger system.
Instant is completely open source. We have no private repos, so in the event that you want to run the system yourself, you can fork it.
> how to make it part of a larger system.
If you have an existing app, right now I would suggest storing the parts that you want to reactive on Instant.
We're working on a Postgres adapter. This would let you connect an existing database, and use Instant for the real-time sync. If you'd be interested in using this, reach out to us at founders@instantdb.com!
There is no standard writing system for Swiss German. So she might have used it, but it would be unclear to most Swiss what it means/how it should be pronounced.
I have HA and a mini PC capable of running decently sized LLMs but all my home automation is super deterministic (e.g. close window covers 30 minutes after sunset, turn X light on if Y condition, etc.).