| 20 Jun 2021 |
 instantepiphany | In reply to @schnecfk:ruhr-uni-bochum.de
Probably for high flexibility of the automations. While I prefer a DSL or something structural, the system that HA uses is rather weak and often requires workarounds like template sensors I'm not sure why this is something that needs to be decided in this project though - should we be opinionated on that? Or choose a protocol so that any language/executable can be used as long as it follows the interface? | 09:32:13 |
 piegames | In reply to @instantepiphany:matrix.org
I'm not disagreeing, just curious - what use case is there for an interpreted language? So a few use cases that you may want to consider that would make good use of a scripting language:
- User can write a few lines of code to create automation behavior
- Plugin system
- Dynamically loading modules. Let's be frank, if you want to load Rust code at run time you won't have fun.
| 09:40:14 |
| instantepiphany | In reply to @piegames:matrix.org
So a few use cases that you may want to consider that would make good use of a scripting language:
- User can write a few lines of code to create automation behavior
- Plugin system
- Dynamically loading modules. Let's be frank, if you want to load Rust code at run time you won't have fun.
I think the first might be covered by allowing any executable to be called as long as it follows the API. This could be bash, or python, or whatever.
Definitely agree for third.
However for plugins, I was thinking we could do that through the config - e.g the config supplied by the user would specify what protocol should be used to communicate with the target, and set various rules for the automation. I would like to keep as much logic in the config as possible.
| 09:44:41 |
| instantepiphany | So to create automation behaviour, the user would modify the config, via text at first, maybe a GUI much further down the road. | 09:45:49 |
| piegames | Will the configuration format be a turing complete DSL? Or will it be a simple structured format with inline code blocks in different languages? | 10:11:33 |
| instantepiphany | I'm not really sure, but if we go with inline code blocks that might make it difficult to have GUI plugins later - they would have to be able to infer meaning from n supported languages... Though I suppose the code could just be to get or set a state, then we might be able to do that. | 10:28:42 |
 Mic92 (Old) | What other components do they plan to make stateful? | 11:17:08 |
| Mic92 (Old) | In home-assistant? | 11:17:16 |
 CRTified | In reply to @joerg:bethselamin.de
What other components do they plan to make stateful? Afaik they want to migrate always from the YAMl configuration completely, making the while configuration of all integrations stateful | 11:20:09 |
| Mic92 (Old) | In reply to @schnecfk:ruhr-uni-bochum.de
Afaik they want to migrate always from the YAMl configuration completely, making the while configuration of all integrations stateful Do you have a source for that? This reads different: https://www.home-assistant.io/blog/2020/04/14/the-future-of-yaml/ | 11:21:37 |
| CRTified | In reply to @joerg:bethselamin.de
Do you have a source for that? This reads different: https://www.home-assistant.io/blog/2020/04/14/the-future-of-yaml/ The section about ADR0010 explains that in the long term, YAML will fade out, as new integrations won't be allowed to use of YAML (except in rare cases) | 11:45:03 |
| Mic92 (Old) | In reply to @schnecfk:ruhr-uni-bochum.de
The section about ADR0010 explains that in the long term, YAML will fade out, as new integrations won't be allowed to use of YAML (except in rare cases) Mhm. I am probably ok with having only my automations in yaml for now. Maintaining a project like home-assistant seems otherwise like a huge effor. | 11:46:26 |
| CRTified | At least for some integrations, although the line between "communicates with a service" and "bridges a protocok" seems fairly thin to me | 11:46:57 |
| Mic92 (Old) | Well maybe depends on the integration | 11:47:00 |
 @hexa:lossy.network | Mic92: https://github.com/home-assistant/core/pull/37800#issuecomment-657707769 | 11:47:58 |
| CRTified | I mean, even esphome does not support yaml anymore | 11:48:04 |
| @hexa:lossy.network | huh, what? | 11:48:28 |
| @hexa:lossy.network | oh, you mean on the home-assistant side | 11:48:35 |
| @hexa:lossy.network | but esphome works great with zeroconf | 11:48:46 |
| CRTified | In reply to @hexa:lossy.network
oh, you mean on the home-assistant side https://www.home-assistant.io/integrations/esphome/ that one, yes | 11:49:02 |
| @hexa:lossy.network | also they're talking about doing this because then they have control over config migration | 11:49:58 |
| Mic92 (Old) | In reply to @hexa:lossy.network
also they're talking about doing this because then they have control over config migration Which did not work very well in the past. I remember I had to delete my icloud storage multiple times in the past. | 11:53:11 |
| @hexa:lossy.network | yeah, well. shit happens. | 11:55:35 |
| @hexa:lossy.network | but the general arguments they're giving have merit | 11:55:46 |
| @hexa:lossy.network | because we are not really the intended target audience | 11:56:39 |
| @hexa:lossy.network | I mean, we're using hass inspite of these things | 11:57:06 |
| @hexa:lossy.network | * I mean, we're using hass in spite of these things | 11:57:32 |
| piegames | Having configuration management from both config files and UI is an incredibly hard task. Usually, you end up getting the worst of both worlds. If you then assume that the configuration is generated from something like Nix and thus is immutable to the UI, things get messy quickly in the UI. | 12:12:35 |
| @hexa:lossy.network | Fabian Affolter: homeassistant-cli click 8 compat would be nice, looks like completions are failing | 17:07:47 |
| @hexa:lossy.network | also there are two clis apparently
- https://github.com/home-assistant-ecosystem/home-assistant-cli
- https://github.com/home-assistant/cli
| 17:08:39 |
