I added two devices - iPhone (tracked via iCloud and FritzBox) & Apple Watch (tracked via FritzBox) - to my Person. When going out for a run - only carrying the Watch with me and leaving the Phone at home - my status switches back to “home” after a couple of minutes. I guess that’s because the Phone is still at home.
Is there a way to get the correct status (=not_home) when tracking two devices, even when one of the devices stays at home?
I very much doubt that… this is where the Bayesian sensor would help… but seriously how can it possibly differentiate?
Thanks, I will have a look at the Bayesian sensor.
In case of device_tracker the device with the “not_home”-state should overrule the device with the “home”-state. When tracking more than one device for a person it’s likely that one is left at home.
Or has a flat battery.
Have a look at monitor component, forget routers
I just updated to 0.88.2. While I managed to get rid of all the breaking changes, there is one error I am unable to get rid of.
I am using Telegram Bot via webhooks and my HA is installed on Docker in Synology NAS. To get it working, I have to put my local IP into the trusted_networks key as described in Getting Telegram webhooks working with Nginx.
Unfortunately, 0.88.2 gives this error…
Your configuration contains extra keys that the platform does not support.
Please remove [trusted_networks]. (See /config/packages/telegram_bot.yaml, line 5).
If I remove trusted_networks from the telegram configuration, it stops working.
Anyone else facing this issue?
Looks like it needs a issue report on github. The docs still say the trusted_networks is valid. https://www.home-assistant.io/components/telegram_bot.webhooks/
At least it is only a warning at this stage.
yeah… it’s confusing. the documentation said it’s valid but the error says otherwise. will open a report soon. thanks anyway.
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.
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
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.