2021.5: Stability, performance, triggers, color modes!

@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 :wink:

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.

No, deprecated means “still supported for the moment, but will be removed in future”.

2 Likes

@DavidFW1960 exactly. And even though I learned Petro’s thesaurus explanation in school, (some moons ago…), I also learned computer programmers can be thinking more from a digital perspective than their end-users who tend to use a more humane perspective :wink:

Now who needs to adapt here :wink:

btw, what’s the incorrect depreciate doing there, that’s a mistake being made here too, quite often to be honest. I am somewhat amazed it’s listed in the thesaurus?

this is a bit odd don’t you think? Who would be editing a known_devices.yaml, if it would be no longer used by the system. That would be pointless, and have no effect in the system at all.

Until then, it is created by the system, and we need to maintain it, because it is used. In my config by 129 devices…hardly semantics.

It’s not odd, that’s literally what the announcement was back in (apparently) 0.94… don’t shoot the messenger. Long term, that file will be no longer in use.

I noticed the same with my TP-Link plugs. Error appears only once during HA start and the entities seem to work just fine.

The error is quite odd, since the template itself is correct, but apparently not during startup, so something might not be loaded / available yet.

I like the mutesync integration, sounds better than my current scripting work-arounds. When I want to Download and execute this it reported by windows defender as “blocked because it could harm your device”, is it actually safe to download this?
(i cannot find any info on the HA forum or google on this)

Obviously it WILL BE removed it just hasn’t yet.

yep, at some time, when not a single integration in Ha uses it anymore.

I’ll be happy to delete the file then and there.

1 Like

Or when the devs say “2 more months only, then its right out the door”.

Then maintainers who aren’t paying attention or no longer care will miss the deadline. Users will rant and moan that the devs broke their system and that “this is the worst release ever”, “you stopped caring about users” and “I’m gonna move to smartthings” or “time for a fork”.

not that it will prevent the error you see, but you might safer write those template like:

friendly_name_template: "{{ state_attr('switch.driveway_light','friendly_name'))} Current"
value_template: '{{ state_attr('switch.driveway_light','current_a') | float }}

consider the startup considerations

since the update the boolean sensors provided by the sure petcare integration to indicate when my cats arrive/leave via the catflap have stopped working… they appear ok but there are no updates

I think it fails on the SSL-sertificate.
To make it work you have to have ssl: false in your motionEye addon config.
You also have to set a port to your web-interface in the same place.
Then use http://ip:port in the integration configuration. You can also use the hostname (a0d7b954-motioneye) here.
I found that it gives an error if you have blank passwords, so you should probably make them.

1 Like

I never told you to remove it. I wasn’t even talking to you. I was talking to the people who use Fritz box. You you and Others decided to bring me into a deprecation argument. Do whatever you wanna do, I don’t care.

3 Likes