sorry ive just realised i have included the error message from one switch and the code from another… the error is the same on all HS-110s since the update though , functionally they seem fine and it looks like i only get the error after a restart
If I have such cases, as before for fritzbox_callmonitor, iRobot, etc. etc. Where and how to change the settings then afterwards if they change?
Before I opened the config.yaml changed e.g. user, pw, token or whatever other options. After migration to UI, most of the times, there is no chance to change them in UI? What are the thoughts behind this?
- Remove and re-add every time I want to change any option
- Change this in hidden .storage yaml files
Both are the opposite of UI setup - in my point of view.
HI,
I installed 2012.5.13 from scratch, but the initial process never ends. the docker container doesn’t start
I’m now reverting to 2012.5.12 to see if it is HW issue
Anyone experiment similar issue
Just disable the entity… easy.
The known_devices.yaml wasn’t deprecated for everything… I still have a device tracker writing to it. The Fritz integration mentioned removing yaml config in the release notes as well BTW…
After upgrade is done, i do not see any automations. Only the blueprints, scenes and scripts are available.
After a second restart, also automations appeared.
Just if s.o. is having the same issue.
No, dont get me wrong, not criticism at all! Was merely wondering what the advantage was, and I understand you’re appreciation for ordering now.
I have everything in packages, so all was ordered under either sensor, or binary sensor, which is done for all other platforms that either provide sensors, or binary sensors.
For me, it would have therefor been more sensible to give the new trigger based sensors
a new platform: trigger. Allowing us to add that under these main integrations sensor and binary_sensor.
The fact we now have to order everything under a new and dedicated template: was surprising to me all the more considering quite some effort was taken to remove the _template suffix in various places of the configuration.
Added to that, I simply don’t understand why the example in the release notes would be a template sensor, because it isnt. It is a regular binary_sensor, triggered by a trigger: event
binary_sensor:
- platform: trigger
sensors:
motion:
trigger:
- platform: event
event_type: netatmo_event
event_data:
type: movement
name: Motion
# We use auto_off, so just set it to true on each trigger
state: "true"
device_class: motion
# Automatically turn off 60 seconds after the last event
auto_off: 60
# and a true trigger based template sensor:
motion_template:
trigger:
- platform: template
value_template: >
{{is_state('binary_sensor.motion','on')}}
name: Motion template
# We use auto_off, so just set it to true on each trigger
state: "true"
device_class: motion
# Automatically turn off 60 seconds after the last event
auto_off: 60
would have made more sense to me
well, not exactly, there are quite some device_trackers still using the known_devices (ping, Nmap, Bluetooth…) … only those integrations using the UI config are no longer in known_devices.
Well, even Life360 which is configured via the UI writes to known_devices.
No, it’s deprecated. Things can still be in use and deprecated 
Can you point to the release notes saying it’s deprecated because I don’t think you will find them. I know they wanted to deprecate it but it’s still in use for some integrations…
In the integration, click on the Fritz box entities. Then select an entity. There should be an option on that page to disable it.
Also, hopefully the UI has an option to not track new devices/entities. If not make a feature request.
no, that’s not in between, it is accurate
1 Like
“Being phased out” and “deprecated” are pretty well synonymous.
2 Likes
@petro thanks for the tip.
I’ve just done the update again with the yaml removed first, and there’s a lot less duplicates this time. A few items need some tweaking, but it’s in a much better state than before. There’s still a few of the Android ones, but I need to hunt those down as they might be in the router.
My other “issue” is I have a fritz repeater as well as a fritz box (as a mesh network), so this time I’ve just put the repeater integration to ignore or else I think I’ll get even more duplicates. But I still have a few devices (a couple of Pi’s and my iPhone) which have 2-3 devices, only some of which work.
of course, I was also responding to the second sentence I quoted. It may be deprecated, or phased out, but we don’t do ‘everything’ through the UI just yet.
Since the integrations still using the known_devices.yaml hold many of our ‘presence detectors’, this is a statement that needs some dedicated precision.
Yep, I feel like people are trying to argue semantics here. It’s been almost 3 years since the announcement. Continue to use known_devices at your own risk but it can be ripped from your grips whenever the integrations get updated into the UI. It’s not a planned deprecation where it’s dead 2 weeks from now. It’s planned as in “We’ll remove it when we update the integrations that use it”.
2 Likes
Maybe but until the integrations using it are migrated it’s still current and not deprecated even if being phased out… If 10 integrations used it and 8 have been migrated it’s being phased out but still current - not deprecated - for the other 2.
1 Like
sure. but still… there’s much confusion over the term deprecated, and it seems to be taken as ‘no longer in use’, where ‘being phased out’ decribes the process more accurately.
o well. let’s enjoy the day
2 Likes
The file its self is being deprecated… seeing that you wont take this at face value, here’s the definition:
All developers are recommended to “Not use it”. Also, PR’s that use it will be rejected.
1 Like
In the context or HA, deprecated and ‘being phased out’ have different meanings. When there is a GUI way of removing them it will be deprecated/gone.