I think too that the documentation is having a hard time keeping up with the code changes. Would pay to look at the source code if you understand python 
I really hope the documentation is correct because if otherwise, that means my Telegram bot might stop working in the future 
The docs are correct, but the code was relying on a bug to validate the config. Let’s hope someone fixes it soon before the warning becomes an error.
1 Like
default_config
Sounds like “damned if you do, damned if you don’t”!
On one hand, you have features added without telling people, while, on the other, you have the problem where people don’t know about new features, so can’t add them.
I’d suggest that either way is bad.
Look at auto-adding, for example. Say a particular installation requires a custom setting for a new component. But it gets added without notice and doesn’t work, so how do you find out so you can customise it? Also, what if it’s not wanted, or even seen as necessary to not install for a particular setup?
On the other hand, if you don’t auto-add, what if the new component is really important and necessary?
Perhaps a solution might be to have a page with a definitive list/table of the components together with a summary, a link to documentation, and the version it was added. That way, if you miss additions, you can still go back and check. It seems this would be useful for either hand…
Just updated to 0.88.2. Get the following warning:
Anyone have any ideas how to track this down? Searching through the config directory gets me dozens of icon tags but the only device tags are parameters being passed to AppDaemon classes…
check in the log
Which log? If I go to the dev-info screen, the log shown there shows nothing more useful:
Your configuration contains extra keys that the platform does not support. Please remove [device].
9:48 PM helpers/config_validation.py (WARNING)
Your configuration contains extra keys that the platform does not support. Please remove [icon].
9:48 PM helpers/config_validation.py (WARNING)
If I click the “show full log”, I can find the same warning there. Should I be looking at the component calls immediately before/after the warnings? Can I assume that’s what triggers it?
Thanks.
There is definitely room for improvement with default_config. Currently, it’s a huge hassle to disable a single piece that is considered “core” that really isn’t necessary in a lot of cases, e.g. cloud, conversation, discovery, mobile_app, sun. Trying to disable any one or more of these requires adding back a bunch of entries.
It would be nice if we could just exclude some things while using default_config, e.g.
default_config:
exclude:
- cloud
- conversation
- mobile_app
- sun
3 Likes
I have exactly the same warning and also no clue what is the cause. Logs indeed don’t give any extra info. I am also using Appdaemon, so maybe that’s the reason for the device warning. Will check that.
That’s a great idea for the default_config because it’s most likely useless for most people as is…
Anyone have any ideas how to track this down?
Take a look at mqtt auto-discovered entities? Do you have any?
I have a Xiaomi Dafang cam which is added via mqtt auto-discovery. Good chance that is the one causing the warnings indeed.
Seems you have hacked Mqtt camera, don’t you? It is basically from Dafang mqtt hack…
Updating Dafang fixes issue
1 Like
Yes, I have several. Most Tasmota, one is a Wyze/Dafang camera with hacked firmware. Looks like Tasmota does use “icon” and “device” in the MQTT message. Wyze might, too. Could it be that? If so, I assume the fix has to be on the Tasmota/Wyze side?
UPDATE: Looks like nothing to do with Tasmota. Updating the Wyze/Dafang firmware resolved the issue. Thanks everyone.
Second issue. I have a single device running ESPHome (a Bruh DIY multisensor). Under 0.87, I installed the add-on, set it up, it was autodiscovered, and everything worked great.
Now with 0.88 I got a “new device discovered” item from ESPHome. Probably foolishly, I clicked it. Now I seem to have two ESPHome integrations for the same device…
Here’s what it looks like now:
As you can see, bottom two entries are for the same device.
The sensors and such only appear once in the entities list, so that’s ok.
Is this a bug? Something I messed up? Can I safely delete one of the two?
I had that happen with every one of my ESPHome devices after I updated.
Just delete one of the integrations. After you do that it will look like the other one is also messed up (it will say “unavailable”) but when you restart HA everything will come back up normally.
1 Like
Attempting to future proof my device tracking when Persons eventually eliminates individual device tracker states. My original config included my phone and car wifi creating a group to allow my home status to activate faster. Without car wifi, my phone would often take 2 or 3 minutes to connect to home wifi (if in my pocket, probably asleep). With that delay, lights and other things would flip on up to 1 minute after physically walking into the house. With Persons, when my car turns off and disconnects from wifi while in my garage, it’s “not home” status overrides my person’s overall status as not home and thus lights go off 3 minutes after they turn on. This is working by design according to Persons stationary tracker hierarchy but is also at the heart of the issue. There are several fixes I can think of like creating a sensor to only flip when car is arriving home and not leaving home or boolean. All the fixes I can think of depend on individual device tracker states which, if going away, would eventually be null and void.
I must be missing something, any input would be greatly appreciated!
What do you mean “eliminates individual device tracker states”? As far as I know, only the merging of device trackers via things like known_devices.yaml is going away. Individual device trackers will not change. The logic in Persons is still very basic and will be improved as time goes on. There is an architecture discussion regarding that.
How did you previously group your devices? Did you use the group component and then reference that in your automations/config, e.g. group.person_name? My suggestion in that same thread is somewhat related to that.
Currently, the idea is that Person will just be some “default behavior” that will hopefully work for you. If it doesn’t, there’s not a lot of easy ways to customize the behavior right now. My idea was to add various utilities to device_tracker (device_tracker.group, device_tracker.template, device_tracker.composite, etc.). Then we could use those to customize the behavior and link that device tracker to our Person component.
For now, you could trying using the custom composite device tracker and see if that works better and allows you to use Person for your automations. Otherwise, I’d just stick with using the group and wait until Person is improved a bit.
1 Like
My mistake, I misunderstood where device trackers were headed, lead to my confusion. As long as individual device trackers don’t change my setup will work fine. I ended up creating a person for myself and another for my wife using our phone wifi and then creating a person for each of our cars and then grouping all phones and cars together in a group.person.
Thanks for your advice and clarification!