Home Assistant Removing Text Configuration

So looking at this seems home assistant is removing textual configuration going forward, may be good for openhab as I for one would not want my things managed by the ui and may see other migrate because of this

2 Likes

Unfortunately, not until OH takes security and privacy seriously.

The Home Assistant project has grown at a ludicrous rate in the last few years. Being one of the few solutions to provide a local home automation platform, that puts privacy first, has gathered interest from all kinds of people on this planet.

You may be mistaken. Did you miss this?

Home Assistant is moving towards a better separation of YAML configuration versus configuration done in the UI.

and

For the future, Home Assistant will be moving towards that concept more and more. This allows anybody to use the method they prefer.

In these cases, YAML support has been extended and improved by adding features like reloading and by removing parts that mess with your YAML files.

But it goes on to say that new bindings will only be accepted if the configuration can be done in the ui

Exclusively or is both UI and YAML acceptable? They are not mutually exclusive.

The discussion has been done multiple times here in the forum and there are strong advocates for both solutions and thus both methods should be supported by openhab.

Personally I really like textual configuration. I even implemented a method to set z-wave (or other thing) parameters textually because I is much easier to share a configuration between the same type of things and between openhab instances.

2 Likes

I believe Kai has said text configuration will stay in OH 3.

Without security you only have weak, limited privacy. As you stated they go hand-in-hand.

image

From reading the blog post I think it is clear that they are moving towards a UI first approach and only eliminating YAML configuration for the equivalent of OH binding configurations (i.e. configuring a connection with a device or a service). It seems like text based configs will remain for other stuff.

A glib statement with absolutely no practical meaning.

Security and privacy is a holistic activity. There is no single piece of a system that you can point to and say “there’s the security, there’s the privacy.” Security and privacy comes from the architecture and design of everything, from physical controls (e.g. lock the machines into a closet) to network configurations, from operating system configurations to individuals choosing poor passwords. It all works together.

And openHAB, by design does not have security. I work daily with encrypted AAA security systems.

For me it was THE reason to go with Openhab.

Yes, very minimal…
The rest API is open for all to see and write changes to.
Yet, I have not seen one little tiny warning about it.
Openhab should be placed in its own network, firewalled away from all users.

1 Like

I will say all users that use networking devices on the same lan.
It is just a question of when the Openhab api becomes a target.
It probably will never happen on a large scale, but for targeted attacks it is possible.
All it takes is a unpatched web browser, or some trickery to make one user run an executable.

I can only speak for myself.
I started my Openhab adventure a few months ago.
And I just now became aware of the API.

Where? Not exactly a prominent placement, is it?
And a reverse proxy… …well, I do not think that is the right tool.
It may protect openhab alone, but not the rest of the thingies that terminate at Openhab.

No, you concern should be the computers (or networking devices).
Regular users do not stand a fighting chance against malware and other trickery.
Whatever WiFi password is irrelevant.

Edited.

1 Like

I edited my previous post as it was way over what I consider as polite.
I am sorry, that my irritation over unrelated things found its way into that post.

1 Like

:grimacing: started something here, I only posted it as I felt it may bring more attraction to openhab…

I’ve noticed that any time Home Assistant comes up, spirited debate is not far behind. :wink:

Personally, I don’t like to think of it as a competition. OH is better for some people and HA is better for others. I helped someone last week who had a bunch of pre-existing equipment that was tricky to implement in OH, but relatively easy to set up in HA. So, it made way more sense for them to use HA, and it doesn’t stop them from coming back here in the future.

1 Like

It’s not.

I don’t imagine most openHAB users care about Home Assistant’s architectural decisions but, for those who are interested, this topic’s title is misleading. There’s only a partial elimination of “textual configuration”.

The linked blog post stirred up the same kind of feelings that openHAB users can identify with whenever the polarizing subject of “text-based vs UI-based configuration” is raised (the discussion gets lively … and long-winded).

Anyone who cares to learn the details can read the related Architectural Decision Record (ADR 10). In a nutshell:

  • There are several flavor of integrations (i.e. bindings) and it’s been decided that two specific types will now no longer be configured via text (YAML) but by “config flow” which is to say via the UI.

  • Basically, any integration that supports a device or a service will be configured via the UI (especially if the resources can be auto-discovered). The resulting data is stored as JSON (it can be manually edited but it’s not intended to be managed that way).

  • All other things, such as automations (rules) and the Lovelace UI (HABPanel), continue to be created/modified either via YAML or the UI.

So not as dramatic a change as the topic’s title suggests.

This really made me shake my head wildly. Given the zillion smart things I read and learned from you here on the forum I am surprised you write his. You probably know yourself that this is nonsense, why bring something like this up?
We are talking about IoT here and IoT devices are some of the most insecure connected devices out there. The general user does not know nor has the equipment to properly isolate those devices and setup firewall rules to keep using them. This results in devices that have internet access, remain unpatched until EOL and have access to the REST API.
So I think NilsOF does have a point there. OpenHAB should have made a clear separation between interfaces meant for device communication (like e.g. the Hue emulation) and interfaces for managing and using OpenHAB, like the REST API or the various GUIs.

3 Likes

It’s easy to make this assumption, and if your IoT device is a Hue lightbulb, or a ZigBee switch etc, then yes, you’re probably right. However there are a number of examples that have been published about things like video doorbells. These often run a Linux system, are exposed to the web, and could easily be exploited. This IS HAPPENING.

Has anyone then gone on to hack an OH instance from this - I don’t know - probably not as we’re a relatively small community. But I think this is it is not such a low likelihood as you seem to think. There are a lot of embedded Linux devices (doorbells, thermostats, IP cameras, baby monitors, etc) - a lot are low cost and are probably poorly secured and probably offer someone “in the know” relatively easy access into home automation systems. Without security, OH is vulnerable - especially if you are using these sort of systems.

It’s very easy to find these reports if you search.

Most of these probably relate to people hacking into the video stream - as I said, I would guess no-one has gone on to hacking an openhab system from this, but the point is that IoT devices are vulnerable, and can therefore be used as an intermediary. One day the hackers will get bored with just watching someones video doorbell (I mean, how exciting is that - really :slight_smile: ) and they will see what else they can attack. Once you’re in, you’re in.

There are now regulations in place for IoT so people are starting to take this seriously. OpenHAB is looking at this finally for OH3, but to be honest it’s really too little too late IMHO.

1 Like

Maybe I haven’t found the links that you like - but these sort of attacks are happening and I think you arguing against all of this is actually irresponsible.

Anyway, let’s just say you are right Rich - others are wrong - and I will now stop discussing this. It’s also well off the topic of this discussion anyway :wink: