Home Assistant, for who is it for?

Development
101

i disliked yaml in the first period too.
and for sure for automation and combined with jinja templates.
thats why i started to use appdaemon for my automations.
over time i have learned to understand yaml and now i can see the advantages from it.
also learning about yaml made it better to read and write it.

things like that i can write this:

  slaapkamerschakelaars:
    name: Slaapkamer
    entities: [ "switch.slaapkamer_1_30_11","switch.slaapkamer_1_30_12","switch.slaapkamer_1_30_13"]

instead of this

  slaapkamerschakelaars:
    name: Slaapkamer
    entities:
      - switch.slaapkamer_1_30_11
      - switch.slaapkamer_1_30_12
      - switch.slaapkamer_1_30_13

made my yaml a lot more readable.
but most of all, when automating everyone needs to know a bit about lists and dictionaries (there is no way around that) and yaml is just that. a collection from lists and dictionaries.

102

I actually enjoyed the granularity that I had using yaml for automation, but finally caved and moved over to node-red for all automation. It was a learning curve in itself just to transition written configuration to a node-red flow, but I got there and prefer my automation be handled there instead now.

103

So in summary then: who is home assistant for? Not someone who has a shed load of sensors, hates yaml and having to type lists into the groups file. :wink:

3 Likes
104

My notes after studying and trying to build something lately. Perhaps it helps to set realistic expectations:

  • Most commercial smarthome hubs work best (or only) with same vendor/supported devices, and have reasonable nice UI, so 90% of people, also your grandmother can use it. If this is enough, and you value your time, then use any of them.
  • Homey looks really nice combination of quite reasonably priced all-in-one hardware (all radios built-in), flexibility and all the ready-made 3rd party integrations, and ease of use. I suspect it uses node-red internally. But many could be confused from so many options, so it is more like for above average tech-savvy ones, lets say “top” 40-50%.
  • all the next options make sense if you are DIY, “fancy computers” and want low-level control and use your own hardware, usually raspberry pi: for the “top” 10% .
  • If you like Java then you make find openHAB good. As Java in general, it looks ageing stuff now
  • home-assistant is nice if you like more modern python development. However, if you want to have more fine-grained control over dashboard or automation rules, then it seems to become complicated. It is not about programming language, but because of some core design choices.
  • if you like even more modern node.js, then use node-red which is better (i.e. more flexible and clear, even if it is graphical) automation tool, and you can use it in combination for home-assistant, especially if you already have HA setup
  • you can build complete system with node-red alone, which has also some UI dashboard tools etc, and gives more finegraned control over result than home-assistant.
1 Like
105

I think that those who favour a GUI possibly don’t realise that the config still has to be stored in a text file. So you are stuck with yaml, or some other equally unfathomable text representation, when the chips are really down and you want to take total control.

Yaml goes hand in hand with python. You could use other representations, like XML or JSON (which is a subset of YAML anyway) but that wouldn’t make it any easier to read or understand. XML is just overly noisy and hard to debug.

So yeah, by all means make a GUI that simplifies writing your yaml file, but at the end of the day you are going to need to work out how to read the yaml file to debug the extra level of error that the GUI has brought to the table.

106

Homey does look interesting, if limited in it’s hardware support. In fact I challenge any other home automation system to show support for the 1082 components that HA supports.

107

It seems like the only point where people really disagree with you is where you imply that someone else should do the actual work.

5 Likes
108

Perhaps I could simplify things:

Home Assistant is to Linux as
SmartThings is to Windows.

In Windows, there are some programs that would require you to edit the text file(s). Even the registry, although it should be untouched unless you know what you are doing.

1 Like
109

you can run homeassistant on any platform, also on windows :wink:

110

Please take analogy into account.

If you don’t want to mess with text files when it comes to configuring a server, use Windows Server 2016 (w/ Desktop Experience).
If you don’t mind configuring a server using text files, use Linux.

In other words:

If you don’t want to mess with YAML, buy SmartThings and forget about open source.

1 Like
111

Is it realistic even to expect the software to do everything ie all the integrations, run local, be very easy and have a nice front end and not be a commercial product?

I looked at homey too but opted for home assistant instead. Mainly because home assistant had been around much longer and being a community based project and not commercial would be less susceptible to the downsides of commercial products i.e. the hub is bricked should the company fail or suddenly decides to stop supporting your particular component.

Another reason I also switched from stringify they got bought by Comcast and all development stopped.

In my experience there is always a compromise somewhere and up till home assistant i’d always found free software to be a bit poor and buggy. Typing some yaml doesn’t seem so bad

2 Likes
112

That’s why I organize my config including groups in packages, whenever possible.

113

This also depends on whether or not a component supports discovery. My Zwave multi-sensor created all it’s entities automagically. Only needed to add automations. :slight_smile:

1 Like
114

You got me!! :laughing:

It’s for people how are willing to devout time learning the yaml syntax as their way to interact with software (mostly configuration). And is also willing to dive into documentation and this forum to get more “advanced” things done.

I do wonder if yaml is a philosophical choice or is just here to make things work fast. It expands and relies so heavily upon that I don’t see any real changes in the near future.

115

The other logical choices would be ini or json. if you think yaml is hard, can you imagine the backlash and trouble the average user would have with json? Those commas and brackets will F you every time!

116

Yes, I’m quite sure that I’ve been obnoxious for many. However, I feel the argument “if you don’t like, go do it yourself” does not advance the conversation as a community.

Maybe let me rephrase the comment I did. I’m wrong saying that the community doesn’t want some changes, however, I don’t think they share the same mindset on how important/indispensable they are.

117

what do you think other programs rely on?
the configuration must be saved somehow.
that can be YAML, inifiles, databases, etc.

do you prefer another type of file to put the config in?
the choices you have are: restricted, not modifyable or YAML or JSON.
which would you prefer?

118

Yes, it would be as bad for the user.
We just don’t know if the idea is to address this “issue” soon or it’s something for later on the project.

119

It’s an “issue” that will get fixed “when someone gets around to it”. If someone thinks it should be a high priority, they can start writing the code to implement it.

Being open source, it’s just waiting on someone to come along and think that it’s enough of a need that they start working on it. You seem really adamant about it being a necessity. Have you thought about learning how to write an interface? :wink:

1 Like
120

I really wish I could. Complaining was my way to maybe encourage some of our developers to take a look at it, or at least tell their ideas.
Also, my ideas might sound too radical for the project.