In reply to @hexa:lossy.network
automation engine = event bus?

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?

In reply to @schnecfk:ruhr-uni-bochum.de
I'd prefer to not use Elm for the frontend, but that's highly opinionated. Purescript might be the better alternative

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.