Correct. I added it to my sidebar as a test and it generated the error. Will probably be fixed with the next VScode update as mentioned.
You can ask the author of the extension to update the schema to include the new features.
Here: https://github.com/keesschollaart81/vscode-home-assistant/issues
Or you can do it yourself locally: https://github.com/keesschollaart81/vscode-home-assistant/wiki/HowTo:-Update-the-schema's
Hey guys,
I noticed some strange German translations within the “Server Management”-Page:
“Reload Input Booleans”
“Reload Input Numbers”
“Reload Input DateTime”
etc.
They’re called
“Eingabe-Booleans neu laden”
“Eingabenummern neu laden”
“Eingabe-Datums- und Zeitfelder neu laden”
etc…
In my opinion this is a strange german wording:
My suggestion here is:
“Umschalt-Helfer neu laden”
“Nummern-Helfer neu laden”
“Text-Helfer neu laden”
“Datum & Uhrzeit-Helfer neu laden”
“Dropdown-Helfer neu laden”
The functions are already translated within the "Helpers-Menu, the current translation kind of differs from these “Helpers-Menu”-translations in strange ways.
Am I the only one? 
New 
bug 
introduced in this release. I would post it on github but I was blocked (by @balloob) because of my last feature request for the android app to make it accesible 
for more people - sad but true. Wonder what the Code of Conduct is actually for… 
The bug is the following (reproduced on two different hass servers and various clients, mobile & desktop as well with various browsers and the android app Libre Assistant)
Opening any entity in lovelace, for example this one:
And clicking the wheel 
up right:
followed by a click on the tab “related” will give you this nice list of related entities:
they are clickable and in the past (prior to this release 0.113) they opened the entity directly.
The new behavior is that it’s not presented in front of this modal but behind - which is quite useless 
1 Like
Just tried it out. It opens indeed behind the modal. Tested on 0.113.1.
Or just this:
value_template: "{{ trigger.to_state.state == 'Button B' }}"
1 Like
Thank’s for confirming… hope some one will see this one day…
Just to be clear; this means a few idiots willing to break their test instances (with alpha code)
And does not refer to the quality of those testers
2 Likes
the more-info pop-ups on AirVisual card no longer work. Anyone else seeing this?
IKEA integrations - Any body else having isues with the ikea integration? in 0.113 i need to re-integrate my two ikea gateways to have connection to the lights. this has to be done again after a while.
A couple of quick optimizations:
trigger:
- entity_id: sensor.remote2
platform: state
- entity_id: sensor.remote4
platform: state
can be:
trigger:
- entity_id:
- sensor.remote2
- sensor.remote4
platform: state
- condition: template
value_template: "{{ states[trigger.to_state.domain][trigger.to_state.object_id].state == 'Button A' }}"
can be:
- condition: template
value_template: "{{ trigger.to_state.state == 'Button A' }}"
1 Like
Probably a better way to implement this is:
- trigger:
- platform: state
entity_id: binary_sensor.laundry_door_sensor
to: 'on'
action:
- service: light.turn_on
entity_id: light.laundry_lights
- trigger:
- platform: state
entity_id: binary_sensor.laundry_door_sensor
to: 'on'
for: '00:05'
- platform: state
entity_id: binary_sensor.laundry_door_sensor
to: 'off'
action:
- service: light.turn_off
entity_id: light.laundry_lights
1 Like
Thank you, I appreciate the feedback.
That’s the first time I’ve seen multiple triggers defined that way. That’s always been available? How have missed this?!? 
I’m going to have to experiment with it.
No, those are two automations.
Great tip!!
Well OK then. At least I didn’t sleep through some major enhancement.
If that’s two separate automations, why are the trigger options hyphenated?
To clarify, by hyphenating the two trigger statements, it gives me the impression I can have a single automation that supports multiple “sub-automations” where each has its own set of trigger/condition/action.
The assumption was the original code snippet (and hence my suggested change) was in the default automations.yaml file, which must contain a list of automations, where the start of each automation begins with a dash, which delineates a new list element.
I could have suggested this:
automation:
- trigger:
...
- trigger:
...
to try and make it clearer, but then people try putting the first line (automation:) into automations.yaml, too, and of course, that doesn’t work.
You can’t win here!