I´ve checked plenty of topics regarding display the correct state of the window in the dash: Open Close Tilt
For sure it´s quite easy but I´m not well know in program, just find some code blocks but nothing works in my case.
My setup:
1 binary sensor on each window connected to knx bus (open close tilt)
You don’t have onebinary_sensor, you have two. Otherwise this won’t work.
I assume/guess this should have been a template sensor, and you would need to put it under that domain. As you said you aren’t an experienced user, please provide more information on where you got that code, to see how it was implemented there.
However, trusting in my guess (), you’d need to setup a template binary sensor, that could be like this:
I must admit, I haven’t done such a thing via the UI, I just add that to my YAML files. In YAML you can easily set an icon, it is practically the same code, but instead of “offen”, you’d set an icon there, like “mdi:window-variant-open”.
{% if is_state('binary_sensor.fenster_kuche_offen', 'off') and is_state('binary_sensor.fenster_kuche_gekippt', 'off') %}
mdi:window-variant-open
{% elif is_state('binary_sensor.fenster_kuche_offen', 'on') and is_state('binary_sensor.fenster_kuche_gekippt', 'off') %}
mdi:window-open
{% else %}
mdi:whatever_fits_I_couldnt_find_a_fitting_icon
{% endif %}
Oh, I tought I just copy that in the sensor template and get some nice icons… but that doesn´t work.
Can you explain in detail what do you mean with “you just add that to the yaml files”?
(I know yaml files and where I find them… )
sorry for asking these basics
OK, I tried, I think it is simply not possible with the UI. At least I couldn’t find a way to template the icon…
So here we go with the YAML files. This will be a lot of new information, if you haven’t heard about that, so please take your time, and ask, if something is difficult!
I have my files sorted and split up with packages. Packages are an underestimated feature of HA, that is not used by many people. But they’re so great!
There are different ways to setup your files in HA, one is, to configure everything in configuration.yaml. I’m taking sensor as a very minimalistic example.
# configuration.yaml
sensor:
here would be the configuration for one or more sensors
Another way would be to move all sensor config into a seperate file
# configuration.yaml
sensor: !include sensor.yaml
Now you’d have your sensor configurations in one file. Makes it way better readable!
But it has the disadvantage, that you have to configure every sensor in that file. In the end, you have a lot of different files, like sensor.yaml or binary_sensor.yaml, but they are sorted by their domain (domain is sensor, binary_sensor, light…) and not by logic.
And that’s where packages come in handy. There you can sort everything by logic. You put every domain you need in one neat file.
# my_first_package.yaml
sensor:
config here
binary_sensor:
config here
input_boolean:
config here
Makes it really easy to keep an overview of what you’re doing.
That’s why I use packages. If you want to read more about this, see here
Let me know, what you think, and what your questions are. If you decide how you want to proceed, I can provide the correct code for that template sensor.
As I said, these are a lot of new things for a beginner, but just tell us, how you think you want to go further, than we can tell you the best way to do so!
once more, thanks a lot for your support an explanations. I´ve never been treated like this in other communities. Most of them refer me to the help-docs (which hard to unserstand, with more or less no knowledge of program)
What I understand:
In principle, all confirguration can be done in the configuration.yaml, but, that´s not very clean and bit confusing.
Unsing seperate files are better. That´s what I´ve already done with the KNX-addresses. (!include knx.yaml) and a create knx.yaml.
First question: You worte, " that you have to configure every sensor in that file". Means, when I create a sensor.yaml all sensor needs to be configure in that file, so the ones from the knx.yaml, too? I´ve several sensor in the knx,yaml (lux, wind, current,…).
e.g. from the knx.yaml
sensor:
- name: "Flur OG Helligkeit"
state_address: "5/1/4" #KNX group address
type: illuminance
state_class: measurement
device_class: illuminanace
Need to delete them from the kny.yaml to put in the sensor.yaml when I create that?
Or is the knx.yaml just to create the HA-entitys from the KNX group addresses? If yes, this would mean that an additional sensor.yaml is just for configurations sensors independet from the knx.yaml. Hope you understand what I want so say. knx.yaml → just for connection knx to HA (entity ↔ knx addresses) sensor.yaml → to configure sensors which are mentioned in the knx.yaml (and stay there)
Packages:
Sort by logic. Logic can be, e.g. sort by rooms or anything else
From my point of view right now, I´ve not that many configurations to use packages but I´m in the beginning of my HA era And I like clean and clear structures.
So, I prefer the way with the packages.
(And that´s what I´ve also done in my KNX config. I sort my group addresses by logic)
You’re welcome! And thanks for the cudos! HA has a steep learning curve at times, but we’re all (well, most users) here to help and enjoy our “hobby” Home Assistant! It’s like an addiction, you can’t escape after a while! You’ll see, you’re already hooked up.
I’ll take a little detour, but that should explain how things work in HA. In HA, all things are listed in so called domains, eg. light, sensor, binary_sensor and such. Everything starts with its domain. To know about this domain based system is what we need later on.
The configuration of HA is “normally” written in one file, configuration.yaml. If you split up this configuration, it will be later on combined into one large (internal) file, and will be worked with. Right were you set the include (compared to added at the end) in your configuration.yaml, the file will be included and used like it would be all one file from the beginning.
This approach means, you can only include a domain once. So sensor: can only be listed once. If you use it eg. in knx.yaml, you can’t use it anywhere else, neither in the “original” configuration.yaml, nor in any other file you split up.
That’s why people use sensor.yaml and set all their sensors in this file. Same goes for other domains.
And yes, that would mean, you’d have to delete the sensor configuration in knx.yaml and add it to sensor.yaml. As you already noticed, this seems kind of unintuitive, and that’s where packages come to the rescue.
Packages are a different system, and internally it will be handled differently, so you can use whatever domain you like in any package file you configure. That’s the beauty of it, and as you already noticed, it makes things way more logical.
You can setup your package files like you want to. Eg. with rooms, but also with other things. I personally like to set my packages up with their “meaning”. So I have a waste package, a router package, a flora package. I do have some room packages, but they are not a typical room package, in my case they’re for special things, like the kitchen. Eg. you have a fan, that “goes with you”. Mine is sitting on my desk right now, but if it’s to hot, I use it in the bedroom for the night. Where would you put that configuration? In “office_package” or in “bedroom_package”? Or much better, in a “fan_package.yaml”? You get the idea.
This gives you the flexibility to decide where you would remember it best - for me, this is the only logical approach on sorting things like that.
Long story short, if you use packages, you’ll have much more fun in the future! And if you haven’t done a lot of configuration yet, it’s even more usable. You don’t have to move from a different system to packages…
So, start setting up packages in configuration.yaml, so you can use them. I use this approach:
Don’t take that the wrong way, but just start with packages, and if problems come up, just ask!
But if I may suggest another good read, that will help you further down the road:
You might find some of the above advice in there to, eg. post #13…
Adn one last thing, that people tend to forget: if you’re at the beginning, think of a naming convention for your devices. There’s not much, that is more tedious than renaming things later on…
I hope this gets you started, and as already said numerous times: Ask, if I’m not clear enough or if you have any other questions!
This is why root level platform keys are “the old way” of yaml config. The current way is to have platforms under an integration key (template, knx, etc.). So each integration can have its own platform definitions in separate files.
This is perfectly fine
template:
sensor:
...
knx:
sensor:
...
and is also what happens when a root
knx: !include knx.yaml
is used. So whatever you do in your Knx.yaml file has no influence on the rest of your yaml configuration (except if you used a second root-level knx:, then it would overwrite the whole former one).
The “old” deprecated way, which is mostly obsolete nowadays looked like this:
sensor:
- platform: some_integration
...
If you see this in a tutorial or so, better check the docs if this is still valid for that integration.
Packages are fine, but have a downside of unprecise error messages when validation errors happen. AFAIK the line numbers won’t be correct then.
Does it work (For sure I can try it, but I would like to understand why and how things working…)
And yes, this is the domain-way
Next steps to understand a bit mor of the package way, especialle creating the files and struktur. But I would first study packages-help. After that I assume I come back with a lot of questions, don´t worry
Tbh, for beginners, I wouldn’t recommend to use packages or even !include. This way you can see what’s what based on indentation at a glance.
Given you use a decent editor (eg. vs code - maybe as Addon) you can collapse (hide) contents of keys to better browse the single configuration.yaml file you have.
This would look like:
knx:
# everything with this indentation is purely *knx*, and no concern of any other integration (root key).
# in Knx this is a key, so there can only be a single sensor key
sensor:
...
something:
# perfectly fine to have a "sensor" key in the "something" integration too
sensor:
...
template:
# everything with this indentation is purely *template*, and no concern of any other integration (root key).
# in template, these are lists (since "- " is used), so there can be multiple "sensor" list items
- sensor:
...
- sensor:
...
...
What !include does is just like copy and paste, but the copied files contents start at a different indentation level. So in your Knx.yaml you have a root sensor: key, but this will be a level below knx: when included.
Before starting to use packages, I’d strongly recommend to read its documentation. Everything works slightly different there then.
Ok understood. The intendation is significant. What !include do is just “cut” out the code out of the config.yaml to an seperat file to make the config.yaml a bit cleaner.
I use the studio code server it can also hide contents and show the !inculde content as well. great overview for me. (Just find out that funcion recently)
Now, I´ll setup all window states (as the inital post) in a template.
Is there in any lilst of all entities-id compared to the name in the yaml? In the UI I found them settings → entities sorted by Name and entity-id. Theres no way to print or copy to excel for e.g. That would be much more easier to handle all the entity-id
No. The name value in Knx yaml is only used for initial setup of the entity. Changing or removing it afterwards wouldn’t even make a difference.
The entity_id is set to a slugified version of that (“My Name” → “light.my_name”). So with vs code entity_id code completion you should be able to set them up pretty quickly.
As you said you aren’t an experienced user, please provide more information on where you got that code, to see how it was implemented there.
), you’d need to setup a 
HA has a steep learning curve at times, but we’re all (well, most users) here to help and enjoy our “hobby” Home Assistant! It’s like an addiction, you can’t escape after a while! 
