!QhvgabMQzwEQeWehhZ:lossy.network

NixOS Home Automation

509 Members
Declarative Home Automation and other Sidequests | https://wiki.nixos.org/wiki/Home_Assistant133 Servers

Load older messages

SenderMessageTime
18 Jun 2021
@schnecfk:ruhr-uni-bochum.deCRTifiedI think that's a really nice concept, as it keeps the declarative concept of nix working while still allowing customization by using the GUI13:02:54
@schnecfk:ruhr-uni-bochum.deCRTifiedAnd the interaction between YAML/JSON and nix is really nice, because it's straightforward to translate an attrset to YAML - not only in code, but also while thinking about the problem. It's basically "just a different syntax"13:03:47
@instantepiphany:matrix.orginstantepiphanyInteresting, thanks for the links and ideas! I'll think about this and chime in later, hopefully with a basic plan and some links. I'll make sure to explicitly ask at that time if anyone wants to be involved, assuming I do want to try this out. But I also don't want to flood this room about a specific project, so if it gets busy we can make a separate room.13:07:00
@hexa:lossy.network@hexa:lossy.networkhappy to lurk :)13:07:34
@schnecfk:ruhr-uni-bochum.deCRTified Just don't use home in the name for the project, otherwise it will get confused with home-manager 🙈 13:08:21
@instantepiphany:matrix.orginstantepiphany set a profile picture.13:08:47
@instantepiphany:matrix.orginstantepiphany
In reply to @schnecfk:ruhr-uni-bochum.de
Just don't use home in the name for the project, otherwise it will get confused with home-manager 🙈
One of the hardest problems in software... 		13:09:33
@robert:funklause.dedotlambdaWe were mentioned on: Self-Hosted: 47: Whose License Is It Anyway? https://selfhosted.show/47 Didn't listen to it though.14:32:01
@hexa:lossy.network@hexa:lossy.network thanks, will listen later 14:32:29
@hexa:lossy.network@hexa:lossy.networkas soon as the colleague jumps out of the call 😆14:32:37
@hexa:lossy.network@hexa:lossy.networkhow did you find it?14:34:30
@balsoft:balsoft.rubalsoft
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.
Timestamp 20:30 		14:43:24
@robert:funklause.dedotlambda
In reply to @balsoft:balsoft.ru
Timestamp 20:30
It has chapter marks 		14:44:26
@robert:funklause.dedotlambdaAs any good podcast should have14:44:42
@robert:funklause.dedotlambda
In reply to @hexa:lossy.network
how did you find it?
I'm actually subscribed cause I was bored and looking for new podcasts some day. 		14:45:36
@robert:funklause.dedotlambdaThey present the dispute in a way very favorable to us btw and then go on to speculate about why HA developers are frustrated and burnt out and how to fix that.14:46:51
@hexa:lossy.network@hexa:lossy.networkawesome14:52:52
@hexa:lossy.network@hexa:lossy.networkyeah, they talk about solar power and battery and zigbee stuff in the beginning14:53:05
@hexa:lossy.network@hexa:lossy.networkthat goes just up my alley14:53:08
@zhaofeng:zhaofeng.liZhaofeng Li
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.
It has a "frenck" tag which is pretty amusing 😛 		18:33:55
@robert:funklause.dedotlambdaLet's subscribe to frenck: https://selfhosted.show/tags/frenck/rss18:36:55
@hexa:lossy.network@hexa:lossy.networkfirst time I've seen a jsonfeed btw18:37:28
@zhaofeng:zhaofeng.liZhaofeng LiJust listened to it, and one of the hosts said that the drama spread to Reddit as well, but I haven't seen any thread other than in the programmingcirclejerk and HN subs19:10:43
@zhaofeng:zhaofeng.liZhaofeng Li... and neither of them seems to be blowing up. Am I missing something?19:11:19
@hexa:lossy.network@hexa:lossy.networkyup, haven't found the reddit thread either19:27:26
19 Jun 2021
@instantepiphany:matrix.orginstantepiphany Any thoughts on the name “Automation Station” for a new NixOS home automation service? No home in the title 😌 01:13:53
@instantepiphany:matrix.orginstantepiphany

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.

01:36:38
@instantepiphany:matrix.orginstantepiphany *

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.

01:37:06
@instantepiphany:matrix.orginstantepiphany *

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.

01:38:11
@linus.heckemann:matrix.mayflower.deLinux Hackerman
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.

What's the use case for RTSP? 		06:15:27

Show newer messages

Back to Room ListRoom Version: 6