In reply to @instantepiphany:matrix.org

Just to clear something up - what I listed as "MVP non-features" means I won't be doing those as part of the MVP - I definitely think they add value.

My end goal is for this project to be installable by an end user (though of course a NixOS end user is certainly more likely to be technically minded) and provide all that the user needs to automate IoT devices in their home, though different devices will need specific plugins.

So the first thing to build, because everything else depends on it is what I called the "service" - this is the backend that actually communicates with the devices (targets) on one end, and a HTTP request on the other end.

Then, once this service is working, a web interface, or app interface could be built to present things in a more friendly manner.

So in the end the scope is quite large, much like HA, however for the "MVP" I just want to work on the service.

By the nature of IoT, different plugins that support different targets will require different protocols - HTTP, RTSP, MQTT, etc, so we can't really choose just one. Given MQTT supports many devices, and I have used it a little in the past, it seems like a logical place to start.

So the "core" would be the service, but more is definitely required for a complete solution. Though, it would be nice if someone could just install the core, and build their own frontend if desired.

Regarding architecture, specifically how people have mentioned event buses, pub/sub, I suspect that pub/sub would be an ideal candidate, though am very open to all suggestions! I think pub/sub is the simplest way to describe what happens - events happen, a camera seeing motion, a light turning on, or losing connection, an IRC message mentioning the user, etc.

So various pub/sub messages would be published, and some kind of logic engine in the service would subscribe to some of them, possibly generating "actions" in response, depending on the users configuration. So we could avoid the situation where an "automation" would have to process irrelevant events. This is one thing that I think redux-observable presents a really nice development experience for, which is why I have been describing "actions", which is the term they use.

Finally, regarding functional programming, I agree there are potential performance gains to be had via memoization, though I suspect that would only surface for large scale systems (say, more than 30 messages per second). I'm a big fan of measuring before optimizing, so while I think we should keep memoization in mind and build a system that would be easy to memoize, we shouldn't memoize things until we actually have performance issues.

With an event system such as pub/sub, it is not difficult to create crude approximations of that kind of heavy load, that will be a fun exercise :)

I was tempted to write this in Haskell, but I've never worked with high performance Haskell before, and suspect Rust will be more approachable for more people to contribute. Does anyone have any comments on language choice?

I'll create a github repository soon where we can add issues as requests for support for various targets.

Just to set expectations, I expect the MVP to take 2-4 weeks, and the soonest we will have a plug and play solution for just one target is likely to be 2 months. This is my only side project but I'm working full time and starting a new job in a couple weeks.

Well, if I do a good job architecting the service and plugin architecture, you would have some examples in rust and maybe other languages to work from - in a couple months.

I can't speak to the time requirements of the young human though - an essential and time consuming task on their own ❤️

In reply to @instantepiphany:matrix.org
Great, I'll look at mqtt as a first protocol to support.

In reply to @piegames:matrix.org
Either way, we also need to talk about scripting. The project will need a scripting language, whatever it may be. There are a few custom languages for this purpose, but there is also Python that works great together with Rust. I have no idea how scripting looks like in the Haskell ecosystem (I think Haskell can be interpreted too?)

In reply to @piegames:matrix.org
If you go for Rust, please don't let it be your first serious project. The odds of things getting painful are rather high on that path.

In reply to @schnecfk:ruhr-uni-bochum.de
Probably for high flexibility of the automations. While I prefer a DSL or something structural, the system that HA uses is rather weak and often requires workarounds like template sensors

In reply to @instantepiphany:matrix.org
I'm not disagreeing, just curious - what use case is there for an interpreted language?

So a few use cases that you may want to consider that would make good use of a scripting language:

• User can write a few lines of code to create automation behavior
• Plugin system
• Dynamically loading modules. Let's be frank, if you want to load Rust code at run time you won't have fun.

In reply to @piegames:matrix.org

So a few use cases that you may want to consider that would make good use of a scripting language:

• User can write a few lines of code to create automation behavior
• Plugin system
• Dynamically loading modules. Let's be frank, if you want to load Rust code at run time you won't have fun.

I think the first might be covered by allowing any executable to be called as long as it follows the API. This could be bash, or python, or whatever.

Definitely agree for third.

However for plugins, I was thinking we could do that through the config - e.g the config supplied by the user would specify what protocol should be used to communicate with the target, and set various rules for the automation. I would like to keep as much logic in the config as possible.

In reply to @joerg:bethselamin.de
What other components do they plan to make stateful?

In reply to @schnecfk:ruhr-uni-bochum.de
Afaik they want to migrate always from the YAMl configuration completely, making the while configuration of all integrations stateful