In reply to @robert:funklause.de
We were mentioned on: Self-Hosted: 47: Whose License Is It Anyway? https://selfhosted.show/47 Didn't listen to it though.

Again, if anyone wants this elsewhere I’ll move it, but here is my rough plan (obviously I have decided to make this a side-project and am happy to have contributors).

At first it will probably not benefit from help as I’ll be drawing up the basic architecture. But once I have a decent architecture in place with support for extensibility (like components in HA) then our dev scalability goes up significantly.

Definitions:

Service: A HTTP listener that retrieves and sets state for targets in response to REST calls.
Target: a readable sensor, or controllable device (or combination of).
Action: an instruction sent to one or more targets, that should react by returning state, changing state, or both.

Written in Rust
• Great cross ISA support (ARM for RPI etc)
• Performant
• No memory class errors, (insert usual Rust spiel here)

Service MVP features:

• Listens with HTTP and runs a shell action, returning the response.
• Listens with HTTP and runs a Philips HUE action, returning the state of a sensor
• Listens with HTTP and runs a Philips HUE action, returning the state of a light
• Listens with HTTP and runs a Philips HUE action, returning an RTSP stream (probably just a HTML 5 video tag?)

MVP non-features:
• Web-ui frontend
• App frontend
• Authentication/security hardening (this will be a local demo application, not intended for “production” use
• Config (later of course will be nix based)
• Dashboard/overview (not even an API call for this)
Non-features above are to come after MVP gives us more of a direction.

Again, if anyone wants this elsewhere I’ll move it, but here is my rough plan (obviously I have decided to make this a side-project and am happy to have contributors).

At first it will probably not benefit from help as I’ll be drawing up the basic architecture. But once I have a decent architecture in place with support for extensibility (like components in HA) then our dev scalability goes up significantly.

Definitions:

Service: A HTTP listener that retrieves and sets state for targets in response to REST calls.
Target: a readable sensor, or controllable device (or combination of).
Action: an instruction sent to one or more targets, that should react by returning state, changing state, or both.

Written in Rust
• Great cross ISA support (ARM for RPI etc)
• Performant
• No memory class errors, (insert usual Rust spiel here)

Service MVP features:
• Listens with HTTP and runs a shell action, returning the response.
• Listens with HTTP and runs a Philips HUE action, returning the state of a sensor
• Listens with HTTP and runs a Philips HUE action, returning the state of a light
• Listens with HTTP and runs a Philips HUE action, returning an RTSP stream (probably just a HTML 5 video tag?)

MVP non-features:
• Web-ui frontend
• App frontend
• Authentication/security hardening (this will be a local demo application, not intended for “production” use
• Config (later of course will be nix based)
• Dashboard/overview (not even an API call for this)
Non-features above are to come after MVP gives us more of a direction.

Again, if anyone wants this elsewhere I’ll move it, but here is my rough plan (obviously I have decided to make this a side-project and am happy to have contributors).

At first it will probably not benefit from help as I’ll be drawing up the basic architecture. But once I have a decent architecture in place with support for extensibility (like components in HA) then our dev scalability goes up significantly.

Definitions:

Service: A HTTP listener that retrieves and sets state for targets in response to REST calls.
Target: a readable sensor, or controllable device (or combination of).
Action: an instruction sent to one or more targets, that should react by returning state, changing state, or both.

Written in Rust
• Great cross ISA support (ARM for RPI etc)
• Performant
• No memory class errors, (insert usual Rust spiel here)

Service MVP features:
• Listens with HTTP and runs a shell action, returning the response.
• Listens with HTTP and runs a Philips HUE action, returning the state of a sensor
• Listens with HTTP and runs a Philips HUE action, returning the state of a light
• Listens with HTTP and returns an RTSP stream (probably just a HTML 5 video tag?)

MVP non-features:
• Web-ui frontend
• App frontend
• Authentication/security hardening (this will be a local demo application, not intended for “production” use
• Config (later of course will be nix based)
• Dashboard/overview (not even an API call for this)
Non-features above are to come after MVP gives us more of a direction.

In reply to @instantepiphany:matrix.org

Again, if anyone wants this elsewhere I’ll move it, but here is my rough plan (obviously I have decided to make this a side-project and am happy to have contributors).

At first it will probably not benefit from help as I’ll be drawing up the basic architecture. But once I have a decent architecture in place with support for extensibility (like components in HA) then our dev scalability goes up significantly.

Definitions:

Service: A HTTP listener that retrieves and sets state for targets in response to REST calls.
Target: a readable sensor, or controllable device (or combination of).
Action: an instruction sent to one or more targets, that should react by returning state, changing state, or both.

Written in Rust
• Great cross ISA support (ARM for RPI etc)
• Performant
• No memory class errors, (insert usual Rust spiel here)

Service MVP features:
• Listens with HTTP and runs a shell action, returning the response.
• Listens with HTTP and runs a Philips HUE action, returning the state of a sensor
• Listens with HTTP and runs a Philips HUE action, returning the state of a light
• Listens with HTTP and returns an RTSP stream (probably just a HTML 5 video tag?)

MVP non-features:
• Web-ui frontend
• App frontend
• Authentication/security hardening (this will be a local demo application, not intended for “production” use
• Config (later of course will be nix based)
• Dashboard/overview (not even an API call for this)
Non-features above are to come after MVP gives us more of a direction.

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?