| 19 Jun 2021 |
 CRTified | instantepiphany: do you want to rely on something hue specific, or on zigbee2mqtt for that? | 10:06:49 |
| CRTified | One non-mvp feature that's important would also be logging | 10:09:13 |
| CRTified | 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 😌 Yeah, something like automation was also in my mind. For a nix-specific one I was thinking about "Automationix" | 10:10:45 |
| CRTified | In the end, it's just a working title right now | 10:11:10 |
 instantepiphany | In reply to @schnecfk:ruhr-uni-bochum.de
One non-mvp feature that's important would also be logging Agreed! | 10:29:48 |
| instantepiphany | 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.
| 10:31:53 |
| CRTified | I think that zigbee2mqtt is the best way of handling most of these devices, as it's easy to access (mqtt, which should also be a nice first automation goal), is already well established and nicely maintained and has an insane number of supported devices | 10:34:06 |
| CRTified | MQTT is already a protocol/platform that works nicely with many devices (esphome interacts with it, too), it "only" misses nice UIs and automation AFAIK | 10:36:38 |
| instantepiphany | Great, I'll look at mqtt as a first protocol to support. | 10:38:37 |
| instantepiphany | Thanks for the info :thum | 10:38:45 |
| instantepiphany | * Thanks for the info :thumbup: | 10:38:54 |
| instantepiphany | * Thanks for the info! | 10:39:05 |
 dotlambda | 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. | 13:27:05 |
| CRTified | 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. But you need some platform for testing and developing that automation engine | 13:27:45 |
 @hexa:lossy.network | automation engine = event bus? | 13:27:52 |
| dotlambda | In reply to @hexa:lossy.network
automation engine = event bus? Kinda, I guess. I think that's where existing solutions could maybe be improved. The more devices you have in your home that report data, the less feasible it is for every automation you wanna script to listen to all events, which are mostly state changes. So if I were to design such a system, I would take good care to have every automation define the events or data points it cares about. Let's say some heating automation cares about outside temperature (now and prediction for 1h, 2h, ... from now), inside temperature, people present, ... Then that automation should only be triggered when one of these states changes. | 13:34:25 |
| @hexa:lossy.network | right, I think at the core there needs to be an event bus, maybe something pub/sub, and everything that hooks into it needs to follow a certain interface, so there is a generic way to talk to certain device classes | 13:34:26 |
