In reply to @linus.heckemann:matrix.mayflower.de
What's the use case for RTSP?

In reply to @instantepiphany:matrix.org
Any thoughts on the name “Automation Station” for a new NixOS home automation service? No home in the title 😌

In reply to @schnecfk:ruhr-uni-bochum.de
One non-mvp feature that's important would also be logging

In reply to @schnecfk:ruhr-uni-bochum.de
instantepiphany: do you want to rely on something hue specific, or on zigbee2mqtt for that?

In my mind I want to support as many "targets" as possible. I've only got HUE devices listed in MVP because I own some, so I can test them. So if there is a specific way of communicating that is broadly applicable to more targets of other brands, then we should consider that. I'll keep zigbee2mqtt in mind.

From reading HA docs, it seems that HUE only allow group control via "Scenes" which eventually get purged if not used for a while. So will have to look at a good way to handle that. IMO the more information stored in our system, and the less on target onboard memory, the better.

In reply to @robert:funklause.de
I think the core of a home automation should be some automation engine, not protocol support or anything. Fancy dashboards, even ones that act on button clicks, can be hacked together really fast and don't need such an engine.

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