Another question about fans–
If an integration is using the deprecated control methods do we need to report that on GitHub?
I just noticed Emulated Hue in the log after using my Harmony remote for fan control
Calling fan.turn_on with the speed argument is deprecated, use percentage or preset_mode instead.
I’ve seen a lot of new posts talking about services that now include a “target:” key.
Is this now a requirement to add this to the service before the “entity_id:”? will the other way without that key be deprecated at some point?
What is the expected use case where adding the “target:” is necessary instead of just “entity_id:”?
No, it’s just a new method that allows us to target areas, devices or entity_ids on a service call. It should be the main method you use from now on but the old methods will always work… just don’t expect the old methods to work with area or device_id
Then it’s a good thing I never use those so I won’t have to worry about it. 
Until the day someone thinks it will be a good idea to remove state triggers etc. and only device triggers etc. will be available
The whole purpose of targets is to allow all 3 in one object 
removing entity_id would be fruitless and break everyone. Not gonna happen.
That has been said so many times about many things in the past and turned out to be wrong 
All my automations are full of templates, almost impossible to understand without visual editor.
Most automations show the comment below now, it’s a disaster:
Visual editor is not supported for this configuration: * Templates not supported in visual editor. You can still edit your config in YAML.
If you are that keen on using the visual editor, nearly all templates can be created using the newly available script syntax options. e.g. use choose instead of if/else templates. And by “script syntax” I mean script sequences and automation actions (they are the same thing).
I will check it out for new automations, but it doesn’t solve that most of my current automations look messed up. Some of them even giving errors while they always worked before.
I also send many templated messages with a lot of status information. It’s hard to get the layout smooth and nice without visual editor.
Just tried scripts. Gives exactly the same message as automations, not possible to use visual editor.
That is not the advice I gave. Use script syntax like choose in your actions instead of if/else templates. It can’t replace them all (your message templates for example), but it can replace most.
And yes you have to re-write them.
I went to
/usr/local/lib/python3.8/site-packages/pip-21.0.1.dist-info
and deleted all files, but nothing changed.
The same for
/usr/local/lib/python3.9/site-packages/pip-21.0.1.dist-info
Are these the right folders for the frontend?
I’ve tried also to pull from github the HA 4dev with the following command:
pip3 install --upgrade git+git://github.com/home-assistant/core/pull/47706
and I get the following error:
fatal: remote error:
home-assistant/core/pull/47706 is not a valid repository name
Thanks for your suggests!
I have concerns after today. I had the same password in a few random places. I know not the best practice, but it is not easy to guess. The new routine identified that this password was compromised. Unfortunately this doesn’t sit week after today as Google just notified me the same. So did home assistant cause the compromise.
Not a chance
I’m not overly concerned I have updated passwords where appropriate and the password I reused was intentionally never associated with anything that could be scary. I just find it way too coincidental that this popped up today. I guess it could be related to the privacy concerns a few weeks back, and that is what I am inquiring about. How do we know if we were compromised with the security threats from last release?
I don’t think there’s an easy way. You could check your logs, but they would probably be deleted by now.
Maybe HA and google both think the password is compromised, because, well, IT IS.
Yep not questioning that.
There were privacy concerns, not security threats. It’s not possible for what HA was sending to HIBP to compromise your password. Websites are breached all the time, would suggest you check a list of recent breaches (or wikipedia if you prefer) to see if something you use was compromised.
If you want more info about how HIBP works and why the data being sent to it can’t compromise your password would recommend starting with Troy Hunt’s blog post on this topic. Scroll down to the section labeled “Understanding k-Anonymity”. Or go straight to their launch blog post on the topic.
Crap. I do use choose syntax. Still most automations only available in YAML, because of my messages. Why degrading a perfect working system. Btw, I don’t have the time to rewrite hundreds of automations. Most of them work, but not user friendly to modify or write new ones. This is definitely a very bad side effect, besides all the good things.